From nobody Wed Dec 2 14:29:26 2015 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 A5F4E1B2E7B; Wed, 2 Dec 2015 14:29:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151202222924.12160.34123.idtracker@ietfa.amsl.com> Date: Wed, 02 Dec 2015 14:29:24 -0800 Archived-At: Cc: draft-ietf-bess-virtual-subnet@ietf.org, bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org, aretana@cisco.com Subject: [bess] Ben Campbell's No Objection on draft-ietf-bess-virtual-subnet-06: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 22:29:24 -0000 Ben Campbell has entered the following ballot position for draft-ietf-bess-virtual-subnet-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a couple of editorial comments: - section 1, first paragraph, 2nd sentence: The sentence is confusing, and may suffer from an editing or copy-paste error. I'm not sure what "costly at the risk" of means. Also, who "generally admits" this to be true? From nobody Wed Dec 2 18:30:32 2015 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 AB5641B2F3B; Wed, 2 Dec 2015 18:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03SMRMDNjv7n; Wed, 2 Dec 2015 18:30:26 -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 CFCDD1B2F38; Wed, 2 Dec 2015 18:30:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEY14512; Thu, 03 Dec 2015 02:30:22 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Dec 2015 02:30:21 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.64]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Thu, 3 Dec 2015 10:30:16 +0800 From: Xuxiaohu To: Ben Campbell , The IESG Thread-Topic: Ben Campbell's No Objection on draft-ietf-bess-virtual-subnet-06: (with COMMENT) Thread-Index: AQHRLVDrb3v6O9/uNkCHhVHnmZ7F+J64gZyg Date: Thu, 3 Dec 2015 02:30:15 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53912@NKGEML512-MBS.china.huawei.com> References: <20151202222924.12160.34123.idtracker@ietfa.amsl.com> In-Reply-To: <20151202222924.12160.34123.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.565FA93E.00D0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.64, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5dc24e03fb1f269163f76f83a98b281f Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" , "aretana@cisco.com" Subject: Re: [bess] Ben Campbell's No Objection on draft-ietf-bess-virtual-subnet-06: (with 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: Thu, 03 Dec 2015 02:30:28 -0000 SGkgQmVuLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUgbXkgcmVzcG9u c2UgaW5saW5lLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbiBD YW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVtLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIERlY2Vt YmVyIDAzLCAyMDE1IDY6MjkgQU0NCj4gVG86IFRoZSBJRVNHDQo+IENjOiBkcmFmdC1pZXRmLWJl c3MtdmlydHVhbC1zdWJuZXRAaWV0Zi5vcmc7IGFyZXRhbmFAY2lzY28uY29tOw0KPiBiZXNzLWNo YWlyc0BpZXRmLm9yZzsgbWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb207IGJlc3NA aWV0Zi5vcmcNCj4gU3ViamVjdDogQmVuIENhbXBiZWxsJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0 LWlldGYtYmVzcy12aXJ0dWFsLXN1Ym5ldC0wNjogKHdpdGgNCj4gQ09NTUVOVCkNCj4gDQo+IEJl biBDYW1wYmVsbCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3IN Cj4gZHJhZnQtaWV0Zi1iZXNzLXZpcnR1YWwtc3VibmV0LTA2OiBObyBPYmplY3Rpb24NCj4gDQo+ IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBD QyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBo LCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9y bWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiAN Cj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBi ZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWJlc3MtdmlydHVhbC1zdWJuZXQvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g Q09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gSnVzdCBhIGNvdXBsZSBvZiBlZGl0b3Jp YWwgY29tbWVudHM6DQo+IA0KPiAtIHNlY3Rpb24gMSwgZmlyc3QgcGFyYWdyYXBoLCAybmQgc2Vu dGVuY2U6DQo+IFRoZSBzZW50ZW5jZSBpcyBjb25mdXNpbmcsIGFuZCBtYXkgc3VmZmVyIGZyb20g YW4gZWRpdGluZyBvciBjb3B5LXBhc3RlIGVycm9yLg0KPiBJJ20gbm90IHN1cmUgd2hhdCAiY29z dGx5IGF0IHRoZSByaXNrIiBvZiBtZWFucy4NCg0KSG93IGFib3V0IGRvaW5nIHRoZSBmb2xsb3dp bmcgY2hhbmdlOg0KDQpPTEQ6DQoNCiIgSXQncyBnZW5lcmFsbHkgYWRtaXR0ZWQgdGhhdCBJUCBy ZW51bWJlcmluZyBvZiBzZXJ2ZXJzIChpLmUuLCBWTXMpIGFmdGVyDQogICB0aGUgbWlncmF0aW9u IGlzIHVzdWFsbHkgY29tcGxleCBhbmQgY29zdGx5IGF0IHRoZSByaXNrIG9mIGV4dGVuZGluZw0K ICAgdGhlIGJ1c2luZXNzIGRvd250aW1lIGR1cmluZyB0aGUgcHJvY2VzcyBvZiBtaWdyYXRpb24u ICINCg0KTkVXOg0KDQoiSXQncyBnZW5lcmFsbHkgYWRtaXR0ZWQgdGhhdCBJUCByZW51bWJlcmlu ZyBvZiBzZXJ2ZXJzIChpLmUuLCBWTXMpIGFmdGVyDQogICB0aGUgbWlncmF0aW9uIGlzIHVzdWFs bHkgY29tcGxleCBhbmQgY29zdGx5LiIgICANCg0KPiBBbHNvLCB3aG8gImdlbmVyYWxseSBhZG1p dHMiIHRoaXMgdG8gYmUgdHJ1ZT8NCg0KSSB0aGluayB0aGUgSUVURiBjb21tdW5pdHkgYXQgbGVh c3QgaGFzIGFkbWl0dGVkIHRoYXQuIFRoYXQncyB0aGUgcmVhc29uIHdoeSBOVm8zIFdHIGlzIGZv cm1lZCBhbmQgc2V2ZXJhbCBMQU4gb3Igc3VibmV0IGV4dGVuc2lvbiBwcm9wb3NhbHMgaGF2ZSBi ZWVuIGFjY2VwdGVkIGJ5IHRoZSBJRVRGLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUgDQoNCg== From nobody Wed Dec 2 18:59:39 2015 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 0D01A1B2FF2; Wed, 2 Dec 2015 18:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0u9fQoYVnUw; Wed, 2 Dec 2015 18:59:35 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D82A1B2FF1; Wed, 2 Dec 2015 18:59:35 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB32xPgg090097 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 2 Dec 2015 20:59:25 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: Xuxiaohu Date: Wed, 02 Dec 2015 20:59:24 -0600 Message-ID: In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53912@NKGEML512-MBS.china.huawei.com> References: <20151202222924.12160.34123.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53912@NKGEML512-MBS.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , The IESG , "aretana@cisco.com" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" Subject: Re: [bess] Ben Campbell's No Objection on draft-ietf-bess-virtual-subnet-06: (with 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: Thu, 03 Dec 2015 02:59:36 -0000 On 2 Dec 2015, at 20:30, Xuxiaohu wrote: > Hi Ben, > > Thanks for your comments. Please see my response inline. > [...] >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Just a couple of editorial comments: >> >> - section 1, first paragraph, 2nd sentence: >> The sentence is confusing, and may suffer from an editing or >> copy-paste error. >> I'm not sure what "costly at the risk" of means. > > How about doing the following change: > > OLD: > > " It's generally admitted that IP renumbering of servers (i.e., VMs) > after > the migration is usually complex and costly at the risk of extending > the business downtime during the process of migration. " > > NEW: > > "It's generally admitted that IP renumbering of servers (i.e., VMs) > after > the migration is usually complex and costly." That works to me, but see next comment. > >> Also, who "generally admits" this to be true? > > I think the IETF community at least has admitted that. That's the > reason why NVo3 WG is formed and several LAN or subnet extension > proposals have been accepted by the IETF. If so, then how about "The IETF community has recognized..." Thanks! Ben. From nobody Wed Dec 2 19:06:36 2015 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 A307E1B3032; Wed, 2 Dec 2015 19:06:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151203030635.7958.76303.idtracker@ietfa.amsl.com> Date: Wed, 02 Dec 2015 19:06:35 -0800 Archived-At: Cc: draft-ietf-bess-virtual-subnet@ietf.org, bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org, aretana@cisco.com Subject: [bess] Alia Atlas' Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 03:06:35 -0000 Alia Atlas has entered the following ballot position for draft-ietf-bess-virtual-subnet-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for a clear and well-written document. I have one point that is peripheral to most of the draft. In Section 4.3, it says: " In addition, for any other applications that generate intra-subnet traffic with TTL set to 1, these applications may not work properly in the Virtual Subnet context, unless special TTL processing for such context has been implemented (e.g., if the source and destination addresses of a packet whose TTL is set to 1 belong to the same extended subnet, neither ingress nor egress PE routers should decrement the TTL of such packet. Furthermore, the TTL of such packet should not be copied into the TTL of the transport tunnel and vice versa)." The idea of not decrementing TTL is quite concerning. I can conjecture cases where there is a routing loop between the relevant PEs - during reconvergence when a host moves from one datacenter to another is a trivial case. One approach may be to ask why a packet would have a TTL of 1 and determine if this case must be resolved. Another might detecting a loop back to an out-of-datacenter PE and dropping the packet. I'm sure you can develop other good ideas and solutions. From nobody Wed Dec 2 19:36:52 2015 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 34C2B1B3204; Wed, 2 Dec 2015 19:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 652WlMhqqa9X; Wed, 2 Dec 2015 19:36:49 -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 BFFFE1B317E; Wed, 2 Dec 2015 19:36:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEY19305; Thu, 03 Dec 2015 03:36:45 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Dec 2015 03:36:43 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.64]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Thu, 3 Dec 2015 11:36:36 +0800 From: Xuxiaohu To: Ben Campbell Thread-Topic: [bess] Ben Campbell's No Objection on draft-ietf-bess-virtual-subnet-06: (with COMMENT) Thread-Index: AQHRLVDrb3v6O9/uNkCHhVHnmZ7F+J64gZyg//+K4ACAAJAlgA== Date: Thu, 3 Dec 2015 03:36:36 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB5395E@NKGEML512-MBS.china.huawei.com> References: <20151202222924.12160.34123.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53912@NKGEML512-MBS.china.huawei.com> 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.99.55] 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.0A020201.565FB8CD.0099, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.64, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 501cd665e69e885a73e65844ec4b6dfc Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , The IESG , "aretana@cisco.com" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" Subject: Re: [bess] Ben Campbell's No Objection on draft-ietf-bess-virtual-subnet-06: (with 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: Thu, 03 Dec 2015 03:36:51 -0000 Hi Ben, > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Thursday, December 03, 2015 10:59 AM > To: Xuxiaohu > Cc: draft-ietf-bess-virtual-subnet@ietf.org; The IESG; aretana@cisco.com; > bess-chairs@ietf.org; martin.vigoureux@alcatel-lucent.com; bess@ietf.org > Subject: Re: [bess] Ben Campbell's No Objection on > draft-ietf-bess-virtual-subnet-06: (with COMMENT) >=20 > On 2 Dec 2015, at 20:30, Xuxiaohu wrote: >=20 > > Hi Ben, > > > > Thanks for your comments. Please see my response inline. > > >=20 > [...] >=20 > >> > >> > >> --------------------------------------------------------------------- > >> - > >> COMMENT: > >> --------------------------------------------------------------------- > >> - > >> > >> Just a couple of editorial comments: > >> > >> - section 1, first paragraph, 2nd sentence: > >> The sentence is confusing, and may suffer from an editing or > >> copy-paste error. > >> I'm not sure what "costly at the risk" of means. > > > > How about doing the following change: > > > > OLD: > > > > " It's generally admitted that IP renumbering of servers (i.e., VMs) > > after the migration is usually complex and costly at the risk of > > extending the business downtime during the process of migration. " > > > > NEW: > > > > "It's generally admitted that IP renumbering of servers (i.e., VMs) > > after the migration is usually complex and costly." >=20 > That works to me, but see next comment. >=20 > > > >> Also, who "generally admits" this to be true? > > > > I think the IETF community at least has admitted that. That's the > > reason why NVo3 WG is formed and several LAN or subnet extension > > proposals have been accepted by the IETF. >=20 > If so, then how about "The IETF community has recognized..." OK, I will update it accordingly in the next version. Best regards, Xiaohu > Thanks! >=20 > Ben. >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Wed Dec 2 20:08:57 2015 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 696AC1B2F93; Wed, 2 Dec 2015 20:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_-XIZA9IYY1; Wed, 2 Dec 2015 20:08:51 -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 276C61B2F92; Wed, 2 Dec 2015 20:08:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEY21210; Thu, 03 Dec 2015 04:08:47 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Dec 2015 04:08:46 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.64]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Thu, 3 Dec 2015 12:08:39 +0800 From: Xuxiaohu To: Alia Atlas , The IESG Thread-Topic: Alia Atlas' Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS) Thread-Index: AQHRLXe3HA0WnsBbkUWg0xymBa3L+Z64ozQA Date: Thu, 3 Dec 2015 04:08:39 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB5398E@NKGEML512-MBS.china.huawei.com> References: <20151203030635.7958.76303.idtracker@ietfa.amsl.com> In-Reply-To: <20151203030635.7958.76303.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.565FC050.008A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.64, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4a6cabdf7957241ce50397b58fe7b7d4 Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" , "aretana@cisco.com" Subject: Re: [bess] Alia Atlas' Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS) 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: Thu, 03 Dec 2015 04:08:53 -0000 SGkgQWxpYSwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGlhIEF0 bGFzIFttYWlsdG86YWthdGxhc0BnbWFpbC5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJl ciAwMywgMjAxNSAxMTowNyBBTQ0KPiBUbzogVGhlIElFU0cNCj4gQ2M6IGRyYWZ0LWlldGYtYmVz cy12aXJ0dWFsLXN1Ym5ldEBpZXRmLm9yZzsgYXJldGFuYUBjaXNjby5jb207DQo+IGJlc3MtY2hh aXJzQGlldGYub3JnOyBtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbTsgYmVzc0Bp ZXRmLm9yZw0KPiBTdWJqZWN0OiBBbGlhIEF0bGFzJyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtYmVz cy12aXJ0dWFsLXN1Ym5ldC0wNjogKHdpdGggRElTQ1VTUykNCj4gDQo+IEFsaWEgQXRsYXMgaGFz IGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYt YmVzcy12aXJ0dWFsLXN1Ym5ldC0wNjogRGlzY3Vzcw0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBw bGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWls DQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVl IHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4g DQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9k aXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBE SVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFs b25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmVzcy12aXJ0dWFsLXN1 Ym5ldC8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IA0KPiBUaGFuayB5b3UgZm9yIGEgY2xlYXIgYW5kIHdlbGwtd3JpdHRlbiBkb2N1 bWVudC4gIEkgaGF2ZSBvbmUgcG9pbnQgdGhhdCBpcw0KPiBwZXJpcGhlcmFsIHRvIG1vc3Qgb2Yg dGhlIGRyYWZ0Lg0KPiANCj4gSW4gU2VjdGlvbiA0LjMsIGl0IHNheXM6DQo+IA0KPiAgIiBJbiBh ZGRpdGlvbiwgZm9yIGFueSBvdGhlcg0KPiAgICBhcHBsaWNhdGlvbnMgdGhhdCBnZW5lcmF0ZSBp bnRyYS1zdWJuZXQgdHJhZmZpYyB3aXRoIFRUTCBzZXQgdG8gMSwNCj4gICAgdGhlc2UgYXBwbGlj YXRpb25zIG1heSBub3Qgd29yayBwcm9wZXJseSBpbiB0aGUgVmlydHVhbCBTdWJuZXQNCj4gICAg Y29udGV4dCwgdW5sZXNzIHNwZWNpYWwgVFRMIHByb2Nlc3NpbmcgZm9yIHN1Y2ggY29udGV4dCBo YXMgYmVlbg0KPiAgICBpbXBsZW1lbnRlZCAoZS5nLiwgaWYgdGhlIHNvdXJjZSBhbmQgZGVzdGlu YXRpb24gYWRkcmVzc2VzIG9mIGENCj4gICAgcGFja2V0IHdob3NlIFRUTCBpcyBzZXQgdG8gMSBi ZWxvbmcgdG8gdGhlIHNhbWUgZXh0ZW5kZWQgc3VibmV0LA0KPiAgICBuZWl0aGVyIGluZ3Jlc3Mg bm9yIGVncmVzcyBQRSByb3V0ZXJzIHNob3VsZCBkZWNyZW1lbnQgdGhlIFRUTCBvZg0KPiAgICBz dWNoIHBhY2tldC4gIEZ1cnRoZXJtb3JlLCB0aGUgVFRMIG9mIHN1Y2ggcGFja2V0IHNob3VsZCBu b3QgYmUNCj4gICAgY29waWVkIGludG8gdGhlIFRUTCBvZiB0aGUgdHJhbnNwb3J0IHR1bm5lbCBh bmQgdmljZSB2ZXJzYSkuIg0KPiANCj4gVGhlIGlkZWEgb2Ygbm90IGRlY3JlbWVudGluZyBUVEwg aXMgcXVpdGUgY29uY2VybmluZy4gIEkgY2FuIGNvbmplY3R1cmUgY2FzZXMNCj4gd2hlcmUgdGhl cmUgaXMgYSByb3V0aW5nIGxvb3AgYmV0d2VlbiB0aGUgcmVsZXZhbnQgUEVzIC0gZHVyaW5nIHJl Y29udmVyZ2VuY2UNCj4gd2hlbiBhIGhvc3QgbW92ZXMgZnJvbSBvbmUgZGF0YWNlbnRlciB0byBh bm90aGVyIGlzIGEgdHJpdmlhbCBjYXNlLg0KPiANCj4gT25lIGFwcHJvYWNoIG1heSBiZSB0byBh c2sgd2h5IGEgcGFja2V0IHdvdWxkIGhhdmUgYSBUVEwgb2YgMSBhbmQgZGV0ZXJtaW5lDQo+IGlm IHRoaXMgY2FzZSBtdXN0IGJlIHJlc29sdmVkLiAgQW5vdGhlciBtaWdodCBkZXRlY3RpbmcgYSBs b29wIGJhY2sgdG8gYW4NCj4gb3V0LW9mLWRhdGFjZW50ZXIgUEUgYW5kIGRyb3BwaW5nIHRoZSBw YWNrZXQuICBJJ20gc3VyZSB5b3UgY2FuIGRldmVsb3Agb3RoZXINCj4gZ29vZCBpZGVhcyBhbmQg c29sdXRpb25zLg0KDQpIb3cgYWJvdXQgZG9pbmcgdGhlIGZvbGxvd2luZyB0ZXh0IGNoYW5nZToN Cg0KIiBJbiBhZGRpdGlvbiwgZm9yIGFueSBvdGhlcg0KICAgIGFwcGxpY2F0aW9ucyB0aGF0IGdl bmVyYXRlIGludHJhLXN1Ym5ldCB0cmFmZmljIHdpdGggVFRMIHNldCB0byAxLA0KICAgIHRoZXNl IGFwcGxpY2F0aW9ucyBtYXkgbm90IHdvcmsgcHJvcGVybHkgaW4gdGhlIFZpcnR1YWwgU3VibmV0 DQogICAgY29udGV4dCwgdW5sZXNzIHNwZWNpYWwgVFRMIHByb2Nlc3NpbmcgYW5kIGxvb3AtcHJl dmVudGlvbiBtZWNoYW5pc21zIGZvciBzdWNoIGNvbnRleHQgaGF2ZSBiZWVuDQogICAgaW1wbGVt ZW50ZWQuIERldGFpbHMgYWJvdXQgc3VjaCBzcGVjaWFsIFRUTCBwcm9jZXNzaW5nIGFuZCBsb29w LXByZXZlbnRpb24gbWVjaGFuaXNtcyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1 bWVudC4iDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IA0KPiANCg0K From nobody Wed Dec 2 20:13:56 2015 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 6B5671B2FAB; Wed, 2 Dec 2015 20:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, USER_IN_WHITELIST=-100] 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 n5Z7EPcxc7hK; Wed, 2 Dec 2015 20:13:53 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C591B2FAA; Wed, 2 Dec 2015 20:13:53 -0800 (PST) Received: by obcse5 with SMTP id se5so44838566obc.3; Wed, 02 Dec 2015 20:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MIIvmJCXzcwc34k1ATHMKKMw2J79g8QNXc9cYnu3VF4=; b=rOA1e/UyLUFv+pnA4QBELltJ/NArLANUMLXMvETNjJy3fCUrO2063M/CzLsTu5yMx9 3Od3cXgLE/DhqBIV7fIid6k6fr5avB/jtaFgL8Zhj7LbXJOi0/zeY5HE+cQbOnyJsAzS B/74oGWbvtd6eVV4DJbTwQ3rVXobPm309X2nh/X5U4huqZapdQwfyfowuXUk0kLZgQb5 +wjKnGx/8Md0VqCQuJSF4T1cDjUOUU4rW4lNHrNzebhQLKB/TQJOn2DJ7Ta6vmnPh6Mu 0NtIaMeIfxwM7Lrsc/+c6JwClPel8jUxr6Ty41Nmcie0WrGwle8As7hXdxt81C9pfkni riPg== MIME-Version: 1.0 X-Received: by 10.60.41.73 with SMTP id d9mr6032600oel.27.1449116032460; Wed, 02 Dec 2015 20:13:52 -0800 (PST) Received: by 10.60.177.103 with HTTP; Wed, 2 Dec 2015 20:13:51 -0800 (PST) Received: by 10.60.177.103 with HTTP; Wed, 2 Dec 2015 20:13:51 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB5398E@NKGEML512-MBS.china.huawei.com> References: <20151203030635.7958.76303.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB5398E@NKGEML512-MBS.china.huawei.com> Date: Wed, 2 Dec 2015 23:13:51 -0500 Message-ID: From: Alia Atlas To: Xuxiaohu Content-Type: multipart/alternative; boundary=089e013cba485a6bef0525f69e7a Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , The IESG , "aretana@cisco.com" , "bess-chairs@ietf.org" , Martin Vigoureux , "bess@ietf.org" Subject: Re: [bess] Alia Atlas' Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS) 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: Thu, 03 Dec 2015 04:13:55 -0000 --089e013cba485a6bef0525f69e7a Content-Type: text/plain; charset=UTF-8 That works for me. Thanks, Alia On Dec 2, 2015 11:08 PM, "Xuxiaohu" wrote: > Hi Alia, > > > -----Original Message----- > > From: Alia Atlas [mailto:akatlas@gmail.com] > > Sent: Thursday, December 03, 2015 11:07 AM > > To: The IESG > > Cc: draft-ietf-bess-virtual-subnet@ietf.org; aretana@cisco.com; > > bess-chairs@ietf.org; martin.vigoureux@alcatel-lucent.com; bess@ietf.org > > Subject: Alia Atlas' Discuss on draft-ietf-bess-virtual-subnet-06: (with > DISCUSS) > > > > Alia Atlas has entered the following ballot position for > > draft-ietf-bess-virtual-subnet-06: Discuss > > > > When responding, please keep the subject line intact and reply to all > email > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thank you for a clear and well-written document. I have one point that > is > > peripheral to most of the draft. > > > > In Section 4.3, it says: > > > > " In addition, for any other > > applications that generate intra-subnet traffic with TTL set to 1, > > these applications may not work properly in the Virtual Subnet > > context, unless special TTL processing for such context has been > > implemented (e.g., if the source and destination addresses of a > > packet whose TTL is set to 1 belong to the same extended subnet, > > neither ingress nor egress PE routers should decrement the TTL of > > such packet. Furthermore, the TTL of such packet should not be > > copied into the TTL of the transport tunnel and vice versa)." > > > > The idea of not decrementing TTL is quite concerning. I can conjecture > cases > > where there is a routing loop between the relevant PEs - during > reconvergence > > when a host moves from one datacenter to another is a trivial case. > > > > One approach may be to ask why a packet would have a TTL of 1 and > determine > > if this case must be resolved. Another might detecting a loop back to an > > out-of-datacenter PE and dropping the packet. I'm sure you can develop > other > > good ideas and solutions. > > How about doing the following text change: > > " In addition, for any other > applications that generate intra-subnet traffic with TTL set to 1, > these applications may not work properly in the Virtual Subnet > context, unless special TTL processing and loop-prevention mechanisms > for such context have been > implemented. Details about such special TTL processing and > loop-prevention mechanisms are outside the scope of this document." > > Best regards, > Xiaohu > > > > > > > --089e013cba485a6bef0525f69e7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That works for me.

Thanks,
Alia

On Dec 2, 2015 11:08 PM, "Xuxiaohu" &l= t;xuxiaohu@huawei.com> wrote:=
Hi Alia,

> -----Original Message-----
> From: Alia Atlas [mailto:akatlas@= gmail.com]
> Sent: Thursday, December 03, 2015 11:07 AM
> To: The IESG
> Cc: draft-i= etf-bess-virtual-subnet@ietf.org; = aretana@cisco.com;
> bess-chairs@ietf.org; martin.vigoureux@alcatel= -lucent.com; bess@ietf.org
> Subject: Alia Atlas' Discuss on draft-ietf-bess-virtual-subnet-06:= (with DISCUSS)
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-bess-virtual-subnet-06: Discuss
>
> When responding, please keep the subject line intact and reply to all = email
> addresses included in the To and CC lines. (Feel free to cut this intr= oductory
> paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/do= c/draft-ietf-bess-virtual-subnet/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Thank you for a clear and well-written document.=C2=A0 I have one poin= t that is
> peripheral to most of the draft.
>
> In Section 4.3, it says:
>
>=C2=A0 " In addition, for any other
>=C2=A0 =C2=A0 applications that generate intra-subnet traffic with TTL = set to 1,
>=C2=A0 =C2=A0 these applications may not work properly in the Virtual S= ubnet
>=C2=A0 =C2=A0 context, unless special TTL processing for such context h= as been
>=C2=A0 =C2=A0 implemented (e.g., if the source and destination addresse= s of a
>=C2=A0 =C2=A0 packet whose TTL is set to 1 belong to the same extended = subnet,
>=C2=A0 =C2=A0 neither ingress nor egress PE routers should decrement th= e TTL of
>=C2=A0 =C2=A0 such packet.=C2=A0 Furthermore, the TTL of such packet sh= ould not be
>=C2=A0 =C2=A0 copied into the TTL of the transport tunnel and vice vers= a)."
>
> The idea of not decrementing TTL is quite concerning.=C2=A0 I can conj= ecture cases
> where there is a routing loop between the relevant PEs - during reconv= ergence
> when a host moves from one datacenter to another is a trivial case. >
> One approach may be to ask why a packet would have a TTL of 1 and dete= rmine
> if this case must be resolved.=C2=A0 Another might detecting a loop ba= ck to an
> out-of-datacenter PE and dropping the packet.=C2=A0 I'm sure you c= an develop other
> good ideas and solutions.

How about doing the following text change:

" In addition, for any other
=C2=A0 =C2=A0 applications that generate intra-subnet traffic with TTL set = to 1,
=C2=A0 =C2=A0 these applications may not work properly in the Virtual Subne= t
=C2=A0 =C2=A0 context, unless special TTL processing and loop-prevention me= chanisms for such context have been
=C2=A0 =C2=A0 implemented. Details about such special TTL processing and lo= op-prevention mechanisms are outside the scope of this document."

Best regards,
Xiaohu

>
>

--089e013cba485a6bef0525f69e7a-- From nobody Thu Dec 3 05:15:11 2015 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 B79AC1A700F; Thu, 3 Dec 2015 05:15:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151203131510.16050.11822.idtracker@ietfa.amsl.com> Date: Thu, 03 Dec 2015 05:15:10 -0800 Archived-At: Cc: draft-ietf-bess-virtual-subnet@ietf.org, bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org, aretana@cisco.com Subject: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-virtual-subnet-06: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 13:15:10 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-bess-virtual-subnet-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Alia's Discuss. I see that there's proposed text to resolve that position. I will remain a No-Objection if that proposed text is adopted, but I would be more comfortable if the proposed text was more specific than "may not work properly" - is there anything else that can go wrong, besides unbounded looping? From nobody Thu Dec 3 06:26:01 2015 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 068EF1A88B3; Thu, 3 Dec 2015 06:26:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> Date: Thu, 03 Dec 2015 06:26:01 -0800 Archived-At: Cc: draft-ietf-bess-virtual-subnet@ietf.org, bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org, aretana@cisco.com Subject: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 14:26:01 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-bess-virtual-subnet-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) Surely extending a subnet from one to many data centres should only be done if inter-data-centre traffic is all encrypted and authenticated? I don't get why there isn't a MUST-like statement here for such protection, and going a bit further, why some interoperable form of protection for such traffic (e.g. IPsec, MACsec) isn't recommended as being MTI in such cases. The huge variety of potentially and actually sensitive traffic being handled by VMs these days and which ought not be, and probably is not, understood by folks doing routing seems to very strongly imply that such protection should in fact be turned on all of the time. (But stating that would be going beyond current IETF consenus on MTI security as expressed in BCP61. It'd still be a good idea I think though.) (2) I'm guessing one reaction to the above discuss point could be "sure, but this is the wrong document." In that case, please show me the right document and then tell me why a reference to that is not needed here. Note: none of the above is about RFC2119 MUST/SHOULD etc terms even though I use them above. Just normal english that makes the point would be fine. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The secdir-review [1] raised a similar issue, but I don't think the response to that is sufficient really. (The secdir reviewer did think so.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06217.html From nobody Thu Dec 3 06:58:42 2015 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 E2D631A89B5; Thu, 3 Dec 2015 06:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, USER_IN_WHITELIST=-100] 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 XEFpo2z-8RYY; Thu, 3 Dec 2015 06:58:31 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFECF1A8A04; Thu, 3 Dec 2015 06:58:25 -0800 (PST) Received: by oiww189 with SMTP id w189so50126965oiw.3; Thu, 03 Dec 2015 06:58:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dqUQXXEqMP40IgCFIzeI4gpZgZZdj2MReQ0g6hNZ7Wg=; b=0RBRYSu7ZxyYSPRuOx8Rrfo5qmpW9PLNh+UmqDx00ShWbf+10l0H27NY0H9HpT2ApF Y8rvejB/UpZWR6H1e/BVhU/5oC4QjC0+05xG1Yb88yf4ol/s0VALLV/oY04N6SpUYN1B xlX1MooyYIuS75Eeh0FyY3aorzlnVyV2Dm1f1HDfEnzWfsGoLpsrIoKea/ZM+GeSF+/t 9gBX6IkRDNgiypm7Jt+kKzSJE1NttHBHMOnrlwn+kDwoIe4SRWWPe5Pz2798AJqJ/0Nu Xn/UE6F6Qip0sdo4Nu8ClzWlMCLPmvUxSbYdAcGDovEsjd29qUPybWXl6knumE46DBaw t9Ug== MIME-Version: 1.0 X-Received: by 10.202.104.211 with SMTP id o80mr7940757oik.126.1449154705464; Thu, 03 Dec 2015 06:58:25 -0800 (PST) Received: by 10.60.177.103 with HTTP; Thu, 3 Dec 2015 06:58:25 -0800 (PST) In-Reply-To: <20151203131510.16050.11822.idtracker@ietfa.amsl.com> References: <20151203131510.16050.11822.idtracker@ietfa.amsl.com> Date: Thu, 3 Dec 2015 09:58:25 -0500 Message-ID: From: Alia Atlas To: Spencer Dawkins Content-Type: multipart/alternative; boundary=001a1141014871a7c10525ff9fcf Archived-At: Cc: draft-ietf-bess-virtual-subnet@ietf.org, The IESG , Alvaro Retana , bess-chairs@ietf.org, Martin Vigoureux , bess@ietf.org Subject: Re: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-virtual-subnet-06: (with 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: Thu, 03 Dec 2015 14:58:35 -0000 --001a1141014871a7c10525ff9fcf Content-Type: text/plain; charset=UTF-8 Hi Spencer, I think that the "may not work properly" means that the packet would be dropped by the local PE. The looping issue would happen if the TTL weren't decremented and that language is being removed. Regards, Alia On Thu, Dec 3, 2015 at 8:15 AM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-bess-virtual-subnet-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Alia's Discuss. I see that there's proposed text to resolve > that position. > > I will remain a No-Objection if that proposed text is adopted, but I > would be more comfortable if the proposed text was more specific than > "may not work properly" - is there anything else that can go wrong, > besides unbounded looping? > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > --001a1141014871a7c10525ff9fcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Spencer,

I think that the "may = not work properly" means that the packet would be dropped
by= the local PE.=C2=A0 The looping issue would happen if the TTL weren't = decremented
and that language is being removed.

Regards,
Alia

<= div class=3D"gmail_quote">On Thu, Dec 3, 2015 at 8:15 AM, Spencer Dawkins <= span dir=3D"ltr"><spencerdawkins.ietf@gmail.com> wrote:
Spencer Dawkins has entered the following ballot po= sition for
draft-ietf-bess-virtual-subnet-06: No Objection

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-bess-virtual-subnet/



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

I support Alia's Discuss. I see that there's proposed text to resol= ve
that position.

I will remain a No-Objection if that proposed text is adopted, but I
would be more comfortable if the proposed text was more specific than
"may not work properly" - is there anything else that can go wron= g,
besides unbounded looping?


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

--001a1141014871a7c10525ff9fcf-- From nobody Thu Dec 3 07:02:27 2015 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 C1F551A8A09; Thu, 3 Dec 2015 07:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 wYpn4DkOyhq6; Thu, 3 Dec 2015 07:02:23 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0763.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::763]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF141A89F6; Thu, 3 Dec 2015 07:02:19 -0800 (PST) Received: from DB4PR03MB0847.eurprd03.prod.outlook.com (10.161.15.150) by DB4PR03MB0782.eurprd03.prod.outlook.com (10.161.14.28) with Microsoft SMTP Server (TLS) id 15.1.331.20; Thu, 3 Dec 2015 15:02:03 +0000 Received: from DB4PR03MB0847.eurprd03.prod.outlook.com ([10.161.15.150]) by DB4PR03MB0847.eurprd03.prod.outlook.com ([10.161.15.150]) with mapi id 15.01.0331.023; Thu, 3 Dec 2015 15:02:03 +0000 From: Rotem Cohen To: "draft-xie-l3sm-l2vpn-service-model@ietf.org" , "draft-shah-bess-l2vpn-yang@ietf.org" Thread-Topic: Sync between l2vpn service models Thread-Index: AdEt2cFrispCuULJQOi6AA1PNhNLGQ== Date: Thu, 3 Dec 2015 15:02:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Rotem.Cohen@ecitele.com; x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; DB4PR03MB0782; 5:UnNXX1gY53KI2THx8kPP7fOGfXFrVXydzu0XC6ZPJoy9XxABuWjATEbQjVJvXm9hln+i/gNwaaaxBVuNVxgUiOFPnbRUx1jqdGMMKkaUv8r8hbPx0zNkq2OiCjyGV17M1cf3ekn739INL7cSQwQylg==; 24:1LzUIrUdXaUBVuv9FvpzS73ea0VW0vPs3ghD2Rc7LdfwGNOe/ozIePq/x/ice5LuYWwBYMTnVB7m2Papfs2rN6jLMWJcBC8I6n1kWrthRzQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR03MB0782; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(279101305709854)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB4PR03MB0782; BCL:0; PCL:0; RULEID:; SRVR:DB4PR03MB0782; x-forefront-prvs: 077929D941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(106356001)(5001770100001)(2900100001)(105586002)(450100001)(74316001)(189998001)(5001960100002)(54356999)(50986999)(19580395003)(19580405001)(87936001)(19609705001)(229853001)(101416001)(66066001)(97736004)(77096005)(81156007)(5003600100002)(19300405004)(19617315012)(19627595001)(15975445007)(33656002)(5002640100001)(10400500002)(19625215002)(40100003)(122556002)(102836003)(76576001)(99936001)(3846002)(2501003)(18206015028)(11100500001)(6116002)(790700001)(5008740100001)(1220700001)(86362001)(5004730100002)(1096002)(16236675004)(586003)(17760045003)(92566002)(7099028)(170073001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR03MB0782; H:DB4PR03MB0847.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_DB4PR03MB0847F084AB14E7A1A78D3466E20D0DB4PR03MB0847eurp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2015 15:02:03.0194 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR03MB0782 Archived-At: Cc: "l3sm@ietf.org" , Alexander Vainshtein , Hai Balas , "bess@ietf.org" Subject: [bess] Sync between l2vpn service models 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: Thu, 03 Dec 2015 15:02:25 -0000 --_004_DB4PR03MB0847F084AB14E7A1A78D3466E20D0DB4PR03MB0847eurp_ Content-Type: multipart/alternative; boundary="_000_DB4PR03MB0847F084AB14E7A1A78D3466E20D0DB4PR03MB0847eurp_" --_000_DB4PR03MB0847F084AB14E7A1A78D3466E20D0DB4PR03MB0847eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors of L2VPN service model drafts, Can you clarify please the relation between draft-shah-bess-l2vpn-yang and draft-xie-l3sm-l= 2vpn-service-model-00? There are fundamental differences between L2VPN and L3VPN services and it d= oes not seem right to derive one model from the other. draft-xie-l3sm-l2vpn= -service-model-00 made the effort to explain these differences but if the starting = point had not been the L3VPN service model then it would not be necessary t= o do so. VPLS and VPWS are widely deployed in MPLS-TP networks which do not assume a= ny IP routing/forwarding capabilities and therefore using L3VPN constructs = to define L2VPN services is not natural for these applications. Relating to the conclusion section, the structure of L2VPN service is quite= clear and modelling it without relying on L3VPN should not be regarded as = reinventing a new wheel. Thanks & regards, Rotem Cohen PTS System Architecture Group Manager T: +972.3.926.8247 M: +972.54.926.8247 E: Rotem.Cohen@ecitele.com www.ecitele.com [cid:image002.png@01D12DEC.53A52A40] --_000_DB4PR03MB0847F084AB14E7A1A78D3466E20D0DB4PR03MB0847eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear authors of L2VPN service model drafts,

 

Can you clarify please the relation between draft-shah-bess-l2vpn-yang and draft-xie-l3sm-l2vpn-service-model-00?

 

There are fundamental differences between L2VPN and = L3VPN services and it does not seem right to derive one model from the othe= r. draft-xie-l3sm-l2vpn-service-model-00 made the effort to explain the= se differences but if the starting point had not been the L3VPN service mod= el then it would not be necessary to do so.

VPLS and VPWS are widely deployed in MPLS-TP network= s which do not assume any IP routing/forwarding capabilities and therefore = using L3VPN constructs to define L2VPN services is not natural for these ap= plications.

 

Relating to the conclusion section, the structure of= L2VPN service is quite clear and modelling it without relying on L3VPN sho= uld not be regarded as reinventing a new wheel.

 

Thanks & regards,

 

Rotem Cohen=

PTS System Architecture Group Manager<= /b>

T:

+972.3.926.8247

M:

+972.54.926.8247

E:

Rot= em.Cohen@ecitele.com

 

www.ecitele.com<= /b>

<= /b>

 

 

--_000_DB4PR03MB0847F084AB14E7A1A78D3466E20D0DB4PR03MB0847eurp_-- --_004_DB4PR03MB0847F084AB14E7A1A78D3466E20D0DB4PR03MB0847eurp_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=4903; creation-date="Thu, 03 Dec 2015 15:02:02 GMT"; modification-date="Thu, 03 Dec 2015 15:02:02 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAKkAAAAiCAYAAAAkovk0AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABKnSURBVHhe 7Vx7eBRVlj/3VnWSNkQTIYOsuuiIIC9Bgusiyvj4ZgTRJg7DsiuMYWTUWQ18EXZXmZUUFRidN/lI llnRYXT4UMEHEF1xhNHxiaziY3goCIioLBKggRDy6Kp793eq353upLPy16bvR9HVVfeee+85v/Os 6pi2bVO2zdpd3Zscuhz9x5GmkTguwdGL8B8JcRTXPyGTtuDzTWqnd+1hNSezpZ3rl+NAJg6Y2bDG +qR6HPrdAyzeQD46yxujIgfwCYTyv1IyaBBJmsSYBVgPWbuq16DfUvuSmr9mM0+uT44D6TjQKUit bdUXAZQPAYBTADqiEI72DIxkYDJwo82gbwG0d+Ha7dbO6mUYa8GyHsmJIceB7nIgI0itHdX/CIDW A5y9PWC2dZO0i/58SFDxwQoTfQ+gvx1AfbOblHLdezgH0oLU2vHAvwJYv/QsY3fBmcpQptGKw0cX 49gI8N9mD6lZ3cP5ntt+NzjQAaQA0b9QHgDqpLjvbhBN25VDBYPycazCHA6A+tw3JZkb3zM4kARS gGcKrN2vTjtAo7xk9294x0q4/qvg+rkSkGs5DnTKgRhIUV7qjwTpES8zT0yATjcDGag+KkCsusJ6 o3q0fXXNqdM9RY7e/y8OxC1pG/0G0DnrG8eg2fCHXX8BDUZKdh/OrGyG5Pr0XA54IIXrHQPrNrlD ecmrgaZpKIt2aFELzPdkwt1EGonjwqWse2HBH7YH1BzouSLI7bwrDoQtqdBzyASCUjP5TMmTLwGI HBq04MA1nx+lVKbBDvwMHBx/stVkoDJweVwUtDwun4qoVd2JswVdLTR3v+dywIQVPRsAGu+BKdoY SADob24nGn5+HFfR23P/SLRtbwR4iDGnf4/otmuI+vchOnScaMNWoroXiIJ4KFr7Y6Kh5xGteZdo 6doIeKOEOD4V8p+sTdUP2mNqMj0m6LnSye3c44AJgF6BklOvDq4elu66oUQjL+jIqXOKAVKGFCzj skqiO66P9xnYj+iqS4j+8BeANEh0/TCiYQD6vkb0SVQEHhIu9g+EPR2BM8A43KyHVpXIQn8AN6Eu Dg4p0c9RDj1nVwVaFta/OFKRM0I5wWfsqopme0nDLd642YE14fENfWShvNHTNImxREesysDz6WS+ sL5hPLZ6DimlSJqGJPX6/MrAHsvaZsjS3VMw5rhVWb4+7djahsvBwSD67069761JygHIQj9WJU0b 7GnT2hbWNlyiTDmGlMM7x9p4PrlrfuWNb1mWJWRp2T/gajPWChWPN6u+4VJs4jsYcEo56k/gwZep 84H2EMck064MeI+g8X2MMmkgeLYG/U9YtQ1nSFMFSMn88FillZJr+R54UIbNX5q0LkftnF8VeBv3 RikyR+Y5TS/Pq5r6Jb4Pdxzaj3HH7fqGieDb2epI8yrbnuYZGczjl3nyB0i+e2OtL6Pfjphcax/v Jc0SyBWP0KUMquNqvT0vwMjwGtZ8OfgzFONYzidA/1astxnuXo2DNUsnAzrJRXi0rfthCd+B9+bg AFHBpwfxCcBNnxAH6Ju7iJ7Ds6SLAcgWLPcLZmMexWjwNR6b1Nhicwig6Er8HwOpWeS/UIu8xzwb zn0E4gbNcs2DTaavSDvThfTNJSp5Dd+bhaBlEXvvgZT85iAh9eMksAAe67Z9javnpNskRPWQMApG IuTx+ip16p/Rbw8N/MgUR3s9qUlvx/e0IFWGflQo/QHuz0ikvXDJ2geFkT/P46sOkRksGoj7nypT 3SIM/4NhRrDu5WNbp1h5ILjxhtCHVuDOPnyPgRSCmmKQXA1Ae+sz9anFuD8ndS9K0jWGFvOs2scH Q3FPakNVCpF/K2Kvzeh7AlLpLXTBk2EhsrwxvwoN4Xta67uEL/8Or/TIzcC6VMs6nJVDgcuE4VvW rvJn43ud0vpxKcVCnK8RWj+DrcB3fvtJHgaAnmmaer3WxpXMT8PUMCgN34USv+XRNXv1xeWV3l4w 0OilvgIwJ0IZPuLb2qA7hTDge5s3Yt9XQy4rNbXOQW85uquS09ufYgFLQIXjTN4f3nuSeM1kzsTw nj4AW6+fj8f6x/CF9ZQP4COrFgbu8MS+0NTdUjrlUqirtZBztQ4twP33qMQffvavdWsYtDH734Rr cRUwHfBWgtHOYtB4mYTJUXPGpt323STUbNJ5hnKkx7BIawLR5nQDrdpVfQ3DPxTCKLKsTaZtj/FE DEEVG4b8N63aP5JCwM+oy5ySZqg566JcLXXbTqz956B7rlZtd6LPx3H6ugnrjs3HHsXo5WcFPAp6 M3Cv0HVFzDIlrUuqIEn/eYY+qx7X0Vec9HhkxqQLngiX3NBmAZDhC7Q3+AXTEK6zRInQBqHdh3mc 1m33wv98xvekQ2/ocLIyAHsrMkzjMkHuOJy/gvMCUu5T0b1LU9+nZcGVQrVUoz/GGa9ACMusTZtG 2GM8/ihgU0M5noa4Vgkpn9XS5b6Tvb1oZDeauxWdic9fkNP6lTpcWmdi0MWe2+2klRQS9bkAHQrC zvcYoDIIjmzE34YHPfJnoAX6RGd7ywg3toCZqgOJc4X7w/7GG5t6fFtn178QEkLMVaHQertq8n93 WGLIzGe3bPQGQHnziQ3mlZTY6hzuvTHKxLRbFMKERTjmNvbdQPSSi1cXE+mweU27C2nmXwfwGwDC hWZp40jQfi9MPwhuFp+CRejtOM2f21VTY+8qwBXvQYc9NfXr7sVq+1iVN61MWTMMd3wfssj/XZJ5 xdpprbJmlacNV5LGw7eT9FXY9WtXSyGPplk4p7IHncbSJJ7Mr5q8Dde31dQ1/FYLHbTuvunZKF0n WLrb6PP1IQB7EIAbYCuoXHccPq5mT6Gl8wb35XDF7DOqXLttJ5zDzb9g9499rtXCdwttbhxAY/Aa p9cgUdL7q2cHnqupW/ulJlGWtAettCHV3ZhnKIzTrSw7Exaod0c/nCzO7/8d0c2/B+Yg9y1ImMbB 0XKS5EV7aJ77Z8vpuebI2GwAGp1G05lpAUQK6gG+Sh9sd0IT7JjgLgpC71DBHgf7PkcrilsYBysx XFzWy43S4PKaunXLqmdNuivdHADocYBtrFF6JES67CAsxKCIkqRfUuQqtom4K3QAkxQrUmwJPJDC 1TYhHr1PSGOpYRZuX7ikoXz+7MArKcQ8fwfXXMgxdcaJFF59FLC/UnpA6LqFLYPQ4g/A+k6MTZGC PoH1fp/3atet+9iaNYndvdcAMmn0GQXUcXwUbwwSgHcTcDIG4Coktz0IlPWHhbybTRZi6ohyjjcU HWIz9UU0PmWZCEPcgs0WxykChQi9OIyBfTgPovRCBW6Ql4vpYXD0PbDuW6tnl3v3IlFm59s3AUYJ EEpIpoBjSLS8hK3w/aysZqZp0tVdO10SqwsbOfoQH1zwGo8lJDIXG+UuGgxU+7UQEUamJeoDwwFU vRF3D4NoanrXYRCDyzCKbwAcfiu0uhQzTYWQfxq1wkjgfgdr1iLIXA4pNiDRG4XkCFF7dxu7GY85 yUqalgxLh92JuxQnFYhfr4aVD6XkAZCeRk3a3YTPz7NdjdbqdeQAkzDmW5qcmdCbmWT4JpDrfO4c ObkzmQ52HGlAvBHRkriyIJYAkqbD00yHS9/nujIeX4OhnmJp2oswr79V/+KFduWNn3E0fhS3CjsD 2VqkNHMeAQpQB20NvyhCwQT971eCa12EDJ0yRBBisW401nZIwnXEVFi9Y7CUu7EzrC7SPNUDixxh WVU3vdgZZXCvF0S7tbpy0g/S9GOtjqYTcfKy5AotjUKhnApYniIoRIlZUjYYHXaw22OwoiLwmL3k WRiLXssVtXH94/8AUrk9rGwKlQp6vUsOeUUQsQ51ireEkCsB0hT1l34o7tPVswIVXdJK6CCVfEdz oUW7J9Xh5hWytOh8bAzJkfMBrGakuv6SK/WoRhiEi6zaWr9dVdWC8xFYO8Ffx98jRjaHa6uQoSLD EaMpWBqMTgWMQmjguFYL4YkeM1Qbx6s/YnHuxs7O7yx5agSEPmN9YRiwvUJi9FekAocROfaBo558 BUpOnAtyBh99Yx/xa1YtnOh2KKl0MTbKfA4TjrFzT+rPsDJ5y+4UxLX9wJAgrFuGt64EmCz6w/LN xCAuQb2KbBSpIjek5lqcB9eEjBNbc+hpLr3gegDChrrqgwDRIVit0SRDNzNIqd/YEijNMxDQKimN /mA4tEkdSlofW4x0MZaX/DEqww1g22i47V9rYd6HEAJJjixEJrM1Q0nMG4dKGmLd8iewhqlYF6oG iTE1u1MaDp6gAq5kfD+x1bFGdPBrYOd2Qys2Q38BKEPwDA1auwuw3FhFhhUTfHpKyPyfGXRBHdb7 vpDmBKFD79LhAV4SFm6oDWjnU0z/Xzovb5MsbfwhLj4a4TeMAiosbsuf8cLcE2TkzUD4NR+Jk/oQ 465NYmLKl37FKMiPAD4BPGbhbsSgx3GsQlnqHhTyJ15GNHc60Yo/IWX9G6KL+hI9w1FUMnTSTxFm SSSoTu0iYTHZe4RSa2RYN19S4dGsncktfN0wZ8CtzCDdxo9d04IUauuAGefDmj4aLkG1cewaBinH vsLXH5yDH4ElMZ3XYCmbELvdBjO9sXpWOVs4AiAAVPEj3PsVlZTlYd/DhfBd6/k41f6GUsfBmXgD DPI4curAECEKAP5YXcSrYS5Z+0MA/jGUgep5z8J1f41xHUtiCmYUKgbhe+Ndn/ixDKk3Eb1EQwVM qVys6zLQQYbB/HO4NASlizbwUXi1maTm1UTr1n2EPXo8dBo3f4gk6RMtxdbEjgD9YsNo/XvEhjPB s5lahXZgvbfb9rCon/XCMOynrxvcstnoU4bqib7fslb+MRzHiohc/Sa2ugC6fKthqkVInORrmOje DgxjGUegcdMoIj6ibdwC1BdgG+yniG4EQC8sJfr1NKIHyhEhI9Xhdi4s74H/gVwjNKK0OszDVk/i h3tpGuqKG0xHjgXjuVYZa44S/wG66yjYxCkb7xtWLMkAbBWEcfD3nmEQImNy4io505S6iMlwycY1 I255166QKC2bCGxC6BHr0tgE/4F4X+wtd5zWmHVAWega0/RqG0icAgdROhpoFvk4KdHO2Se32NMq kh44ow5TYToo6AX3RirRPPIlVzhXXAtFSOo7f3b5BtAbZhYVDcEz53ZoTVqFVnnqJdMRY928sILZ Pwk0wgrB+Pjw3A8t6BwSJf5xePyNikTMWu6LMhWWUKGmeYOLBaSVhfBNIcfx+O2FM7UN40EUMXy8 8YMWfAsglhwNYOW7Lr1vVU2Ol/+KTh4QTf6xjhBfh2k8O8Y0fUjBw82V5i/hAFfg9BC82SmsZzTA 4ecq2ttw0y0Aij/V5XP8GYroAIflHiBweDkj9K0RS5ywCI8778DTqWFxgO4FgIsRcRxAvxbQ4Ocr bem2zsFGCPW4Yno/HWPAaI5l3k69B2Zw3dGrPXLDhrakMItj3A7j0s5RFUiyBtE+LDScZ0i4hiXF h/GnKvwwBUKcN5XjrHABO01DKSoyZ7i/NyZc+upYZsuCnjceoMRH7OmNd60qEHtxJ5Jxc2E/YwMf MyaYSGBQ14k30M6YeKFvWjp2RQUrZUwuKCsmGR9OknA/pvxRuZp48bjR2l69EXn+zbHSOCMR9qNi KVEhwJhYyOBb+xk67BRgJXdiqdcvQDX+24hPYY/4KdU2RE8tbLsA1Ol1yEzg2A4zbFJzVA4HQmq1 fe6iBIvSGRtz93oiB9iWsXlcDCt6c/RpXeQafcHGPVqcT+RO9C0o1n2OrNBnK+eu0YoJR0WRUtX+ KA0GZOJbUBwGsAU35H/2RMbn9pw9BzyQ4vdGr+JtqPVw+BOSXteLAK1Lcgy4TNl8Io3E0jIDuVX9 zh68aF+X9HMdejQHwpY03KqQy34HmekZ36jmmQ07GbhteJFCHa/JpnuuT8/mQAykiE134Yd4sxCL /t5z2915rNkdHrLbV1ADlyrsYXUJ5Y/uEMn17UkcSLSk7PaXW9sfuIj88qee2z/dQOWwgEHaTndC Kbp+gtKTJJHba0YOJIGUe9lDF/07LKpE9n6/937hN3ncmTgtz8Sgb6efsDLkZJLjQLYc6ABSD6hD auYBqPtQYloM9+/P+PefspklUs4C4A8A8HeB9gvZDMv1yXEgyoG0II0A9WFk/JtRlvo5Skc3eOWp 6I/qsuEfu3ZOkNgat9MTOL/fHlSDCmqu5TjQPQ5kBKkH1GE1H+JjPP70I788cQ+Aeh0sK15ti4QB iQkWg5jjTQYnnzt4synkPWOutwfXZPk+ZPcWn+vdMzjQKUijLMDfF30e5897f+WkTV0FJI4DGMuQ pQ/GJ/+ohOPN43Dn23DtPVx7FYDdhN/TJ7/90zN4mtvlaebA/wIHYhq8vhA2RAAAAABJRU5ErkJg gg== --_004_DB4PR03MB0847F084AB14E7A1A78D3466E20D0DB4PR03MB0847eurp_-- From nobody Thu Dec 3 07:09:22 2015 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 A34FB1A89AA; Thu, 3 Dec 2015 07:09:17 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivm6yYqEIxxL; Thu, 3 Dec 2015 07:09:15 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559AA1A89A6; Thu, 3 Dec 2015 07:09:15 -0800 (PST) Received: by vkha189 with SMTP id a189so46846785vkh.2; Thu, 03 Dec 2015 07:09:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3Zxm4RO+svPJA72CKnxIX9G31gLEOrQafuCzVJqOCRw=; b=Nj8dDG8ENf0U6K19GzuRiRSLpKyfPGn1B0Igxy10ZEnziTY4F9/s3IntjGc98yvzPV iEot2aJ77OyhQwIM41OMeFwlrsPquO4/lYxq+WwlhiTUv3GO98L5wv54wjozcULPY7pY Xrc0jnNPcg/jvkKieIIDGSnTZHeOvtktRP5I2IPsktIa6qOEwB4whOLXEKzGHYeyEo+k D4/TMfx+sxmU1CLkN2ilbuWY5bowxPoj5LMu5QN6fG1T8gmnl/5BNC7X7u7GKPdeYhL5 mbUR81f7UnGAWNYrCyQouE/3rFI55XhLLcL8ery2WIvSZbbIpAfuO3mqcOatIe2YroP4 2NYw== MIME-Version: 1.0 X-Received: by 10.31.172.87 with SMTP id v84mr6029920vke.154.1449155354526; Thu, 03 Dec 2015 07:09:14 -0800 (PST) Received: by 10.31.149.79 with HTTP; Thu, 3 Dec 2015 07:09:14 -0800 (PST) In-Reply-To: References: <20151203131510.16050.11822.idtracker@ietfa.amsl.com> Date: Thu, 3 Dec 2015 09:09:14 -0600 Message-ID: From: Spencer Dawkins at IETF To: Alia Atlas Content-Type: multipart/alternative; boundary=001a114349f82187f60525ffc668 Archived-At: Cc: draft-ietf-bess-virtual-subnet@ietf.org, The IESG , Alvaro Retana , bess-chairs@ietf.org, Martin Vigoureux , bess@ietf.org Subject: Re: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-virtual-subnet-06: (with 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: Thu, 03 Dec 2015 15:09:17 -0000 --001a114349f82187f60525ffc668 Content-Type: text/plain; charset=UTF-8 Hi, Alia, On Thu, Dec 3, 2015 at 8:58 AM, Alia Atlas wrote: > Hi Spencer, > > I think that the "may not work properly" means that the packet would be > dropped > by the local PE. The looping issue would happen if the TTL weren't > decremented > and that language is being removed. > So, that's two different issues? It might be be great to call them out separately, if so ... Spencer > Regards, > Alia > > On Thu, Dec 3, 2015 at 8:15 AM, Spencer Dawkins < > spencerdawkins.ietf@gmail.com> wrote: > >> Spencer Dawkins has entered the following ballot position for >> draft-ietf-bess-virtual-subnet-06: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I support Alia's Discuss. I see that there's proposed text to resolve >> that position. >> >> I will remain a No-Objection if that proposed text is adopted, but I >> would be more comfortable if the proposed text was more specific than >> "may not work properly" - is there anything else that can go wrong, >> besides unbounded looping? >> >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > > --001a114349f82187f60525ffc668 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Alia,

On Thu, Dec 3, 2015 at 8:58 AM, Alia Atlas <<= a href=3D"mailto:akatlas@gmail.com" target=3D"_blank">akatlas@gmail.com= > wrote:
Hi Sp= encer,

I think that the "may not work properly"= ; means that the packet would be dropped
by the local PE.=C2=A0 T= he looping issue would happen if the TTL weren't decremented
= and that language is being removed.

=
So, that's two different issues? It might be be great to call them= out separately, if so ...

Spencer
=C2= =A0
Regards,
Alia

On Thu, Dec 3, 2015 at 8:15 AM, Spencer Dawkins= <spencerdawkins.ietf@gmail.com> wrote:
Spencer Dawkin= s has entered the following ballot position for
draft-ietf-bess-virtual-subnet-06: No Objection

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-bess-virtual-subnet/



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

I support Alia's Discuss. I see that there's proposed text to resol= ve
that position.

I will remain a No-Objection if that proposed text is adopted, but I
would be more comfortable if the proposed text was more specific than
"may not work properly" - is there anything else that can go wron= g,
besides unbounded looping?


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


--001a114349f82187f60525ffc668-- From nobody Thu Dec 3 07:10:24 2015 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 1F00F1A8A15; Thu, 3 Dec 2015 07:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, USER_IN_WHITELIST=-100] 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 BVWDbf6lB-2W; Thu, 3 Dec 2015 07:10:18 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262B11A89AA; Thu, 3 Dec 2015 07:10:18 -0800 (PST) Received: by oiww189 with SMTP id w189so50418649oiw.3; Thu, 03 Dec 2015 07:10: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:date:message-id:subject:from:to :cc:content-type; bh=h0x/PEKaTinTGYvFFRE790K2xIfwTX2Jbx1B/mqLPFs=; b=oN6SnFrsHjHEHwCjtcR/dsQrDfl2INeBVoPE/v8hSTGtyQff+bBCFA7mrAHvQ8dpRS fSRVTDaZxTPOHfW9x3UBoB5k2N4kuh3UYtZAMYCyiBHtW9z7Uav/CNAUVhWe0frsu5m6 xwYShPcQB0EIufKZrtTUqhgtb8CpauZlU8gnlWlWq6bFjSxJf3ZhlVORRQYxq/ErZ+yK xbE8ZSSHCeupBUCE93WpQT8Cg0U71HL+d2EqrtC8sPYWJN5nRqz3nfiww5uSzNwklFFB H60oD7ZExgdbhrLjHuktSvedfkswrVGAxgfgpNWQQTwSHnFyx4ZssYWvh3Qttf39V5R2 kU8g== MIME-Version: 1.0 X-Received: by 10.202.94.10 with SMTP id s10mr7180688oib.99.1449155417482; Thu, 03 Dec 2015 07:10:17 -0800 (PST) Received: by 10.60.177.103 with HTTP; Thu, 3 Dec 2015 07:10:17 -0800 (PST) In-Reply-To: References: <20151203131510.16050.11822.idtracker@ietfa.amsl.com> Date: Thu, 3 Dec 2015 10:10:17 -0500 Message-ID: From: Alia Atlas To: Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary=001a113d5cd2e244240525ffc9bd Archived-At: Cc: draft-ietf-bess-virtual-subnet@ietf.org, The IESG , Alvaro Retana , bess-chairs@ietf.org, Martin Vigoureux , bess@ietf.org Subject: Re: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-virtual-subnet-06: (with 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: Thu, 03 Dec 2015 15:10:20 -0000 --001a113d5cd2e244240525ffc9bd Content-Type: text/plain; charset=UTF-8 Typed too fast - looping wouldn't happen if the TTL is decremented. What would happen is that the packet would be dropped. I think the text change shows that but happy to poke more :-) Alia On Thu, Dec 3, 2015 at 10:09 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Alia, > > On Thu, Dec 3, 2015 at 8:58 AM, Alia Atlas wrote: > >> Hi Spencer, >> >> I think that the "may not work properly" means that the packet would be >> dropped >> by the local PE. The looping issue would happen if the TTL weren't >> decremented >> and that language is being removed. >> > > So, that's two different issues? It might be be great to call them out > separately, if so ... > > Spencer > > >> Regards, >> Alia >> >> On Thu, Dec 3, 2015 at 8:15 AM, Spencer Dawkins < >> spencerdawkins.ietf@gmail.com> wrote: >> >>> Spencer Dawkins has entered the following ballot position for >>> draft-ietf-bess-virtual-subnet-06: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I support Alia's Discuss. I see that there's proposed text to resolve >>> that position. >>> >>> I will remain a No-Objection if that proposed text is adopted, but I >>> would be more comfortable if the proposed text was more specific than >>> "may not work properly" - is there anything else that can go wrong, >>> besides unbounded looping? >>> >>> >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess >>> >> >> > --001a113d5cd2e244240525ffc9bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Typed too fast - looping wouldn't happen if the TTL is= decremented.=C2=A0 What would
happen is that the packet would be dropp= ed.=C2=A0 I think the text change shows that
but happy to poke mo= re :-)

Alia
=
On Thu, Dec 3, 2015 at 10:09 AM, Spencer Daw= kins at IETF <spencerdawkins.ietf@gmail.com> wro= te:
Hi, Alia,

On Thu, De= c 3, 2015 at 8:58 AM, Alia Atlas <akatlas@gmail.com> wrote:<= br>
Hi Spencer,

I think that the "may not work properly" means that the pa= cket would be dropped
by the local PE.=C2=A0 The looping issue wo= uld happen if the TTL weren't decremented
and that language i= s being removed.

So, tha= t's two different issues? It might be be great to call them out separat= ely, if so ...
Spencer
=C2=A0
Regards,
Alia

=
On Thu, Dec 3, 2015 at 8:15 AM, Spencer Dawkins <spe= ncerdawkins.ietf@gmail.com> wrote:
Spencer Dawkins has entered the following bal= lot position for
draft-ietf-bess-virtual-subnet-06: No Objection

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-bess-virtual-subnet/



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

I support Alia's Discuss. I see that there's proposed text to resol= ve
that position.

I will remain a No-Objection if that proposed text is adopted, but I
would be more comfortable if the proposed text was more specific than
"may not work properly" - is there anything else that can go wron= g,
besides unbounded looping?


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



--001a113d5cd2e244240525ffc9bd-- From nobody Thu Dec 3 07:12:39 2015 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 4EEB11A8A47; Thu, 3 Dec 2015 07:12:38 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-QdimOYlMhC; Thu, 3 Dec 2015 07:12:32 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819631A8A15; Thu, 3 Dec 2015 07:12:32 -0800 (PST) Received: by vkay187 with SMTP id y187so46959133vka.3; Thu, 03 Dec 2015 07:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AQxqH23IdQejep36Qh+SlOdVy90mGc4j8aLmoZz2lds=; b=bx9Qbkrxpkol2vVPNPt8Uv87fUF4FG9Gm5nVqlj6G4WPjGCD4eXUQAdHymGOCd7Jy3 0zWJRaBJEfl4l1Z2V1uxL0vIFYlDAt1LwYKbPoIV4Fij/GKD6VH8lQcsBPSvX79y2VbV HvmTiKhTmXOoqbgMHqQW4AGWA2YNq8wQJYmyw8mGs2h1BVtG02LFuouX6DmrYHUN8/z2 7OvUrJ84Ecpl5s6FUf8vtWZMGcPAVna6Z9bS50xtj8H0frGu0gM5BtERhoHV0xoZmL2o 6hunomj8Wo/18XEOsxcP/RYmDGjr9EZW2vc/ZiQrnr/OtXXR4akFaSJHM+PyGrrMQvAn p1Lg== MIME-Version: 1.0 X-Received: by 10.31.172.87 with SMTP id v84mr6042872vke.154.1449155551652; Thu, 03 Dec 2015 07:12:31 -0800 (PST) Received: by 10.31.149.79 with HTTP; Thu, 3 Dec 2015 07:12:31 -0800 (PST) In-Reply-To: References: <20151203131510.16050.11822.idtracker@ietfa.amsl.com> Date: Thu, 3 Dec 2015 09:12:31 -0600 Message-ID: From: Spencer Dawkins at IETF To: Alia Atlas Content-Type: multipart/alternative; boundary=001a114349f8e171d50525ffd15f Archived-At: Cc: draft-ietf-bess-virtual-subnet@ietf.org, The IESG , Alvaro Retana , bess-chairs@ietf.org, Martin Vigoureux , bess@ietf.org Subject: Re: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-virtual-subnet-06: (with 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: Thu, 03 Dec 2015 15:12:38 -0000 --001a114349f8e171d50525ffd15f Content-Type: text/plain; charset=UTF-8 Hi, Alia, On Thu, Dec 3, 2015 at 9:10 AM, Alia Atlas wrote: > Typed too fast - looping wouldn't happen if the TTL is decremented. What > would > happen is that the packet would be dropped. I think the text change shows > that > but happy to poke more :-) > Right, I'm talking about the problem where looping happens. Spencer > > Alia > > On Thu, Dec 3, 2015 at 10:09 AM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> Hi, Alia, >> >> On Thu, Dec 3, 2015 at 8:58 AM, Alia Atlas wrote: >> >>> Hi Spencer, >>> >>> I think that the "may not work properly" means that the packet would be >>> dropped >>> by the local PE. The looping issue would happen if the TTL weren't >>> decremented >>> and that language is being removed. >>> >> >> So, that's two different issues? It might be be great to call them out >> separately, if so ... >> >> Spencer >> >> >>> Regards, >>> Alia >>> >>> On Thu, Dec 3, 2015 at 8:15 AM, Spencer Dawkins < >>> spencerdawkins.ietf@gmail.com> wrote: >>> >>>> Spencer Dawkins has entered the following ballot position for >>>> draft-ietf-bess-virtual-subnet-06: No Objection >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> I support Alia's Discuss. I see that there's proposed text to resolve >>>> that position. >>>> >>>> I will remain a No-Objection if that proposed text is adopted, but I >>>> would be more comfortable if the proposed text was more specific than >>>> "may not work properly" - is there anything else that can go wrong, >>>> besides unbounded looping? >>>> >>>> >>>> _______________________________________________ >>>> BESS mailing list >>>> BESS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/bess >>>> >>> >>> >> > --001a114349f8e171d50525ffd15f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Alia,

On Thu, Dec 3, 2015 at 9:10 AM, Alia Atlas <<= a href=3D"mailto:akatlas@gmail.com" target=3D"_blank">akatlas@gmail.com= > wrote:
Typed= too fast - looping wouldn't happen if the TTL is decremented.=C2=A0 Wh= at would
happen is that the packet would be dropped.=C2=A0 I think the = text change shows that
but happy to poke more :-)

Right, I'm talking about the problem where= looping happens.

Spencer
=C2=A0

Alia

On Thu, Dec 3, 2015 at 10:09 AM, Spencer Dawkins at IETF <= span dir=3D"ltr"><spencerdawkins.ietf@gmail.com> wrote:
Hi, Alia,

On Thu, Dec 3, 2015 at 8:58 AM, Alia= Atlas <akatlas@gmail.com> wrote:
Hi Spencer,

I think that the &q= uot;may not work properly" means that the packet would be dropped
by the local PE.=C2=A0 The looping issue would happen if the TTL were= n't decremented
and that language is being removed.

So, that's two different issu= es? It might be be great to call them out separately, if so ...
=

Spencer
=C2=A0
Regards,
Alia

On Thu, Dec 3, 2015 at 8:15 AM, Spencer Dawkin= s <spencerdawkins.ietf@gmail.com> wrote:
Spencer Dawkins has entere= d the following ballot position for
draft-ietf-bess-virtual-subnet-06: No Objection

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-bess-virtual-subnet/



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

I support Alia's Discuss. I see that there's proposed text to resol= ve
that position.

I will remain a No-Objection if that proposed text is adopted, but I
would be more comfortable if the proposed text was more specific than
"may not work properly" - is there anything else that can go wron= g,
besides unbounded looping?


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




--001a114349f8e171d50525ffd15f-- From nobody Thu Dec 3 07:14:02 2015 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 D2BE81A8A63; Thu, 3 Dec 2015 07:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, USER_IN_WHITELIST=-100] 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 hJxkZErh1veE; Thu, 3 Dec 2015 07:13:55 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24701A8A51; Thu, 3 Dec 2015 07:13:55 -0800 (PST) Received: by obcse5 with SMTP id se5so51170501obc.3; Thu, 03 Dec 2015 07:13:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q3znoK4f+pI0SqgrqDls2XY5fvxOcc1T7VSksepXICo=; b=KtDRmlRng586tTxJF8TRsTQF8wUy+sKAUue8F+GLeaNxZxZCy2UKijrdDKpDyVmGKb z1HbJ348p6T9vSdF6mp7vX/3YC2cVNP8V9tUiz3X0DWKw7FxYt5aX7Nfv3ZK90wJD+ez 4Gp+UO1vvGQzBIrXIO7KVxKRZIcazT35DkqeiEixgHbmx4s2N8+HnKZWar60LRlUhoRI 1XnKqllnQH4LykMVrgv+vmLtBUQfFKcV15yG9Q9BczJ+/HZ6/i3xksjvtVm3K+Mo1Op0 Bb9gZNNBXwE9G4YPUFKZltGC72TRqaQW/Xx5nEqVjCOv/maHRykT1E4RumE8PNW+JYht f2HA== MIME-Version: 1.0 X-Received: by 10.60.34.69 with SMTP id x5mr8532734oei.35.1449155635206; Thu, 03 Dec 2015 07:13:55 -0800 (PST) Received: by 10.60.177.103 with HTTP; Thu, 3 Dec 2015 07:13:55 -0800 (PST) In-Reply-To: References: <20151203131510.16050.11822.idtracker@ietfa.amsl.com> Date: Thu, 3 Dec 2015 10:13:55 -0500 Message-ID: From: Alia Atlas To: Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary=089e01295300dc605d0525ffd6ff Archived-At: Cc: draft-ietf-bess-virtual-subnet@ietf.org, The IESG , Alvaro Retana , bess-chairs@ietf.org, Martin Vigoureux , bess@ietf.org Subject: Re: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-virtual-subnet-06: (with 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: Thu, 03 Dec 2015 15:13:58 -0000 --089e01295300dc605d0525ffd6ff Content-Type: text/plain; charset=UTF-8 Oh - looping can happen naturally as a result of routing reconvergence. That's what the TTL is for, in part, to make sure those packets don't loop forever. Micro-forwarding loops are common. Alia On Thu, Dec 3, 2015 at 10:12 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Alia, > > On Thu, Dec 3, 2015 at 9:10 AM, Alia Atlas wrote: > >> Typed too fast - looping wouldn't happen if the TTL is decremented. What >> would >> happen is that the packet would be dropped. I think the text change >> shows that >> but happy to poke more :-) >> > > Right, I'm talking about the problem where looping happens. > > Spencer > > >> >> Alia >> >> On Thu, Dec 3, 2015 at 10:09 AM, Spencer Dawkins at IETF < >> spencerdawkins.ietf@gmail.com> wrote: >> >>> Hi, Alia, >>> >>> On Thu, Dec 3, 2015 at 8:58 AM, Alia Atlas wrote: >>> >>>> Hi Spencer, >>>> >>>> I think that the "may not work properly" means that the packet would be >>>> dropped >>>> by the local PE. The looping issue would happen if the TTL weren't >>>> decremented >>>> and that language is being removed. >>>> >>> >>> So, that's two different issues? It might be be great to call them out >>> separately, if so ... >>> >>> Spencer >>> >>> >>>> Regards, >>>> Alia >>>> >>>> On Thu, Dec 3, 2015 at 8:15 AM, Spencer Dawkins < >>>> spencerdawkins.ietf@gmail.com> wrote: >>>> >>>>> Spencer Dawkins has entered the following ballot position for >>>>> draft-ietf-bess-virtual-subnet-06: No Objection >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> I support Alia's Discuss. I see that there's proposed text to resolve >>>>> that position. >>>>> >>>>> I will remain a No-Objection if that proposed text is adopted, but I >>>>> would be more comfortable if the proposed text was more specific than >>>>> "may not work properly" - is there anything else that can go wrong, >>>>> besides unbounded looping? >>>>> >>>>> >>>>> _______________________________________________ >>>>> BESS mailing list >>>>> BESS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/bess >>>>> >>>> >>>> >>> >> > --089e01295300dc605d0525ffd6ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oh - looping can happen naturally as a result of routing r= econvergence.
That's what the TTL is for, in part, to make sure tho= se packets don't loop
forever.

Micro= -forwarding loops are common.

Alia

On Thu, Dec 3, 2015 a= t 10:12 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail= .com> wrote:
Hi, Alia,

On Thu, Dec 3, 2015 at 9:10 AM, Alia Atlas &l= t;akatlas@gmail.com<= /a>> wrote:
Ty= ped too fast - looping wouldn't happen if the TTL is decremented.=C2=A0= What would
happen is that the packet would be dropped.=C2=A0 I think t= he text change shows that
but happy to poke more :-)
<= /blockquote>

Right, I'm talking about the pro= blem where looping happens.

Spencer
=
=C2=A0

Alia
=

On Thu, Dec = 3, 2015 at 10:09 AM, Spencer Dawkins at IETF <spencerdawkins.= ietf@gmail.com> wrote:
Hi, Alia,

On Thu, Dec 3, 2015 at 8:58 AM, Alia Atlas <= ;akatlas@gmail.com> wrote:
Hi = Spencer,

I think that the "may not work properly&qu= ot; means that the packet would be dropped
by the local PE.=C2=A0= The looping issue would happen if the TTL weren't decremented
and that language is being removed.
Regards,
Alia

Spencer Dawkins has entered the following ballot posit= ion for
draft-ietf-bess-virtual-subnet-06: No Objection

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-bess-virtual-subnet/



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

I support Alia's Discuss. I see that there's proposed text to resol= ve
that position.

I will remain a No-Objection if that proposed text is adopted, but I
would be more comfortable if the proposed text was more specific than
"may not work properly" - is there anything else that can go wron= g,
besides unbounded looping?


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





--089e01295300dc605d0525ffd6ff-- From nobody Thu Dec 3 07:15:49 2015 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 F05151A009D; Thu, 3 Dec 2015 07:15:45 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnbKKwjfYSsX; Thu, 3 Dec 2015 07:15:43 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09DD1A8A41; Thu, 3 Dec 2015 07:15:43 -0800 (PST) Received: by vkay187 with SMTP id y187so47025074vka.3; Thu, 03 Dec 2015 07:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tjPctTl3y3n+Ck6kUQwaV1P3AJ2pYp9PygZ+TU+mV8U=; b=Ez7Y/JBrJJYiiEWboG+U8d2yUa2umITK2Im8bXP7mJIZtJMWLuOM71L+bHx/feqGRI plBm1jyURWAoTYALKWLhYYNWdNGLqQIr9SSWJXjUigfUzC3mkoe2qabW1ZGhDeCkIsdJ 5RtGwXfL6JRWlQaybAbP968enyelwoe5j2Ft7oB11rutRFhUL13FcoG0eF8+pnYhxl3+ 6GXnxWfkrXwsufGTG/se8emSSV4fVGu/du+8pfg/coaFmaZCxaYVew0ACJvlqim9jRHK 7rf1eGRYJBTlT0pHLfRPMhI6u4BwgFlKQGWMH2fZLcGO7cqDVEpmJurxGim3cCsJSAdi Or5Q== MIME-Version: 1.0 X-Received: by 10.31.8.200 with SMTP id 191mr5827934vki.60.1449155742941; Thu, 03 Dec 2015 07:15:42 -0800 (PST) Received: by 10.31.149.79 with HTTP; Thu, 3 Dec 2015 07:15:42 -0800 (PST) In-Reply-To: References: <20151203131510.16050.11822.idtracker@ietfa.amsl.com> Date: Thu, 3 Dec 2015 09:15:42 -0600 Message-ID: From: Spencer Dawkins at IETF To: Alia Atlas Content-Type: multipart/alternative; boundary=001a1142e1e44845d20525ffddc8 Archived-At: Cc: draft-ietf-bess-virtual-subnet@ietf.org, The IESG , Alvaro Retana , bess-chairs@ietf.org, Martin Vigoureux , bess@ietf.org Subject: Re: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-virtual-subnet-06: (with 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: Thu, 03 Dec 2015 15:15:46 -0000 --001a1142e1e44845d20525ffddc8 Content-Type: text/plain; charset=UTF-8 I may be confused ... On Thu, Dec 3, 2015 at 9:13 AM, Alia Atlas wrote: > Oh - looping can happen naturally as a result of routing reconvergence. > That's what the TTL is for, in part, to make sure those packets don't loop > forever. > > Micro-forwarding loops are common. > Right. I thought we were talking about the case where the TTL isn't decremented. Spencer > Alia > > On Thu, Dec 3, 2015 at 10:12 AM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> Hi, Alia, >> >> On Thu, Dec 3, 2015 at 9:10 AM, Alia Atlas wrote: >> >>> Typed too fast - looping wouldn't happen if the TTL is decremented. >>> What would >>> happen is that the packet would be dropped. I think the text change >>> shows that >>> but happy to poke more :-) >>> >> >> Right, I'm talking about the problem where looping happens. >> >> Spencer >> >> >>> >>> Alia >>> >>> On Thu, Dec 3, 2015 at 10:09 AM, Spencer Dawkins at IETF < >>> spencerdawkins.ietf@gmail.com> wrote: >>> >>>> Hi, Alia, >>>> >>>> On Thu, Dec 3, 2015 at 8:58 AM, Alia Atlas wrote: >>>> >>>>> Hi Spencer, >>>>> >>>>> I think that the "may not work properly" means that the packet would >>>>> be dropped >>>>> by the local PE. The looping issue would happen if the TTL weren't >>>>> decremented >>>>> and that language is being removed. >>>>> >>>> >>>> So, that's two different issues? It might be be great to call them out >>>> separately, if so ... >>>> >>>> Spencer >>>> >>>> >>>>> Regards, >>>>> Alia >>>>> >>>>> On Thu, Dec 3, 2015 at 8:15 AM, Spencer Dawkins < >>>>> spencerdawkins.ietf@gmail.com> wrote: >>>>> >>>>>> Spencer Dawkins has entered the following ballot position for >>>>>> draft-ietf-bess-virtual-subnet-06: No Objection >>>>>> >>>>>> When responding, please keep the subject line intact and reply to all >>>>>> email addresses included in the To and CC lines. (Feel free to cut >>>>>> this >>>>>> introductory paragraph, however.) >>>>>> >>>>>> >>>>>> Please refer to >>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>> >>>>>> >>>>>> The document, along with other ballot positions, can be found here: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> I support Alia's Discuss. I see that there's proposed text to resolve >>>>>> that position. >>>>>> >>>>>> I will remain a No-Objection if that proposed text is adopted, but I >>>>>> would be more comfortable if the proposed text was more specific than >>>>>> "may not work properly" - is there anything else that can go wrong, >>>>>> besides unbounded looping? >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> BESS mailing list >>>>>> BESS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/bess >>>>>> >>>>> >>>>> >>>> >>> >> > --001a1142e1e44845d20525ffddc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I may be confused ...

On Thu, Dec 3, 2015 at 9:13 AM, Alia Atlas <akatlas= @gmail.com> wrote:
Oh - looping can happen naturally as a result of routing reconverg= ence.
That's what the TTL is for, in part, to make sure those packe= ts don't loop
forever.

Micro-forward= ing loops are common.

Right. I = thought we were talking about the case where the TTL isn't decremented.=

Spencer
=C2=A0
= Alia

On Thu, Dec 3, 2015 at 10:1= 2 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Hi,= Alia,

On Th= u, Dec 3, 2015 at 9:10 AM, Alia Atlas <akatlas@gmail.com> wr= ote:
Typed too fast - lo= oping wouldn't happen if the TTL is decremented.=C2=A0 What would
h= appen is that the packet would be dropped.=C2=A0 I think the text change sh= ows that
but happy to poke more :-)
=
Right, I'm talking about the problem where loopin= g happens.

Spencer
=C2=A0

Alia

On Thu, Dec 3, 2015 at 10:09 AM, Spencer Dawkins at IETF <= span dir=3D"ltr"><spencerdawkins.ietf@gmail.com> wrote:
Hi, Alia,

On Thu, Dec 3, 2015 at 8:58 AM, Alia= Atlas <akatlas@gmail.com> wrote:
Hi Spencer,

I think that the &q= uot;may not work properly" means that the packet would be dropped
by the local PE.=C2=A0 The looping issue would happen if the TTL were= n't decremented
and that language is being removed.

So, that's two different issu= es? It might be be great to call them out separately, if so ...
=

Spencer
=C2=A0
Regards,
Alia

On Thu, Dec 3, 2015 at 8:15 AM, Spencer Dawkin= s <spencerdawkins.ietf@gmail.com> wrote:
Spencer Dawkins has entere= d the following ballot position for
draft-ietf-bess-virtual-subnet-06: No Objection

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-bess-virtual-subnet/



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

I support Alia's Discuss. I see that there's proposed text to resol= ve
that position.

I will remain a No-Objection if that proposed text is adopted, but I
would be more comfortable if the proposed text was more specific than
"may not work properly" - is there anything else that can go wron= g,
besides unbounded looping?


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






--001a1142e1e44845d20525ffddc8-- From nobody Thu Dec 3 07:18:03 2015 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 809261A8A4D; Thu, 3 Dec 2015 07:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3mkLovbcveo; Thu, 3 Dec 2015 07:18:00 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24AE1A8A41; Thu, 3 Dec 2015 07:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5487; q=dns/txt; s=iport; t=1449155879; x=1450365479; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4XB2g1MFSIfPBtoPeOnGb3zBwyYJ4mROk/uIhnNdjU0=; b=XzAb6mwpbS7h8Jknp/4n184XC2wOcWSwP/qLeC6oGaRTvNnNaGxkOszy yTQ8W+GllQEoTJQ7RJLZkjgjsDkJUcQnNNWkMIXe1nNxz9GScofg2/9sw MljgQ93F120TzJLgULLtclkIlZOXm6/pa7MaNm8Fcoum5xj+V/ty1TQNW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQC6XGBW/51dJa1egm5MgUEGuyKCG?= =?us-ascii?q?gENgW6GDgKBSDgUAQEBAQEBAYEKhDUBAQR5EAIBCD8HIREUEQIEAQ0FiBoDEr1?= =?us-ascii?q?8DYRFAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZUAYR8glOGaAWSd4NqAYtEgXeVF?= =?us-ascii?q?IdYAR8BAUKCRIFAcoRogQcBAQE?= X-IronPort-AV: E=Sophos; i="5.20,378,1444694400"; d="scan'208,217"; a="50428360" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2015 15:17:37 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tB3FHbpQ013895 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2015 15:17:37 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 3 Dec 2015 09:17:37 -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.000; Thu, 3 Dec 2015 09:17:37 -0600 From: "Alvaro Retana (aretana)" To: Spencer Dawkins at IETF , Alia Atlas Thread-Topic: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-virtual-subnet-06: (with COMMENT) Thread-Index: AQHRLdsh66E5JEtk6EKgp0L5yVjRu565wgMAgAAAS4CAAACggIAAAGSAgAAAfwD//6yyAA== Date: Thu, 3 Dec 2015 15:17:37 +0000 Message-ID: References: <20151203131510.16050.11822.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.49.154] Content-Type: multipart/alternative; boundary="_000_D285C6F0ED209aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , The IESG , "bess@ietf.org" , Martin Vigoureux Subject: Re: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-virtual-subnet-06: (with 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: Thu, 03 Dec 2015 15:18:01 -0000 --_000_D285C6F0ED209aretanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 12/3/15, 10:15 AM, "Spencer Dawkins at IETF" > wrote: I may be confused ... On Thu, Dec 3, 2015 at 9:13 AM, Alia Atlas > wrote: Oh - looping can happen naturally as a result of routing reconvergence. That's what the TTL is for, in part, to make sure those packets don't loop forever. Micro-forwarding loops are common. Right. I thought we were talking about the case where the TTL isn't decreme= nted. Right. If we change the text in response to Alia's DISCUSS, then the text = won't talk about not decrementing the TTL anymore, so no loops would happen= then. Alvaro. --_000_D285C6F0ED209aretanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9893ADE7EE3413408723650B0B594116@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 12/3/15, 10:15 AM, "Spencer Dawkins at IETF" <spencerdawkins.ietf@gmail.com= > wrote:

I may be confused ...

On Thu, Dec 3, 2015 at 9:13 AM, Alia Atlas <akatlas@gmail.com> wrote:<= /span>
Oh - looping can happen naturally as a result of routing r= econvergence.
That's what the TTL is for, in part, to make sure those packets don't = loop
forever.

Micro-forwarding loops are common.

Right. I thought we were talking about the case where the TTL isn't decreme= nted.


Right.  If we change the text in response to Alia's DISCUSS, then= the text won't talk about not decrementing the TTL anymore, so no loops wo= uld happen then.

Alvaro.
--_000_D285C6F0ED209aretanaciscocom_-- From nobody Thu Dec 3 07:30:01 2015 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 3B79D1A00F3; Thu, 3 Dec 2015 07:29:58 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJQCFR95FdoO; Thu, 3 Dec 2015 07:29:56 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC9F1A037C; Thu, 3 Dec 2015 07:29:56 -0800 (PST) Received: by vkbs1 with SMTP id s1so47374244vkb.1; Thu, 03 Dec 2015 07:29:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=43RMQuNex1eiSqrShGDiAt7Jyc2+IMYa+qN/4VrRehg=; b=yFTXpZ819rdfGGo0VFfOeZCpC2OFMuWdCSruIuMfmABtBw+34EbureVmN+kX/WpuMs BH+QZBllBsRNMicHVRfzePW4Ci2QDuHx+XQYKi4Sbut/Hd1DhDJ47pWc7Fcs6AoJEhWE fZYCTwOPGtTBr9G0lzzsGxxbTxKF4AcYOZjjsWnSFPvU5QZa303WuKuvHi612dGp/y1P TC+fQeMffY2IL3vav+9turSFiZysBbHedvEAxAHpBoPFCsTCgTEk/ywj/Ypcqy/PHKMS xQZgYUvmVjwB1Jx/IkImCUsBy/NBWLXxaVNJitFGIeVS3md0K+x3UTKmL0xj/yiRZ2/C k8Yg== MIME-Version: 1.0 X-Received: by 10.31.12.77 with SMTP id 74mr5991487vkm.28.1449156595771; Thu, 03 Dec 2015 07:29:55 -0800 (PST) Received: by 10.31.149.79 with HTTP; Thu, 3 Dec 2015 07:29:55 -0800 (PST) In-Reply-To: References: <20151203131510.16050.11822.idtracker@ietfa.amsl.com> Date: Thu, 3 Dec 2015 09:29:55 -0600 Message-ID: From: Spencer Dawkins at IETF To: "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=001a114505861d6dc30526001025 Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , Alia Atlas , The IESG , "bess-chairs@ietf.org" , Martin Vigoureux , "bess@ietf.org" Subject: Re: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-virtual-subnet-06: (with 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: Thu, 03 Dec 2015 15:29:58 -0000 --001a114505861d6dc30526001025 Content-Type: text/plain; charset=UTF-8 Alvaro, On Thu, Dec 3, 2015 at 9:17 AM, Alvaro Retana (aretana) wrote: > On 12/3/15, 10:15 AM, "Spencer Dawkins at IETF" < > spencerdawkins.ietf@gmail.com> wrote: > > I may be confused ... > > On Thu, Dec 3, 2015 at 9:13 AM, Alia Atlas wrote: > >> Oh - looping can happen naturally as a result of routing reconvergence. >> That's what the TTL is for, in part, to make sure those packets don't loop >> forever. >> >> Micro-forwarding loops are common. >> > > Right. I thought we were talking about the case where the TTL isn't > decremented. > > > > Right. If we change the text in response to Alia's DISCUSS, then the text > won't talk about not decrementing the TTL anymore, so no loops would happen > then. > Perfect. Spencer --001a114505861d6dc30526001025 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alvaro,

On Thu, Dec 3, 2015 at 9:17 AM, Alvaro Retana (aretana) <aretana@ci= sco.com> wrote:
On 12/3/15, 10:15 AM, "Spencer Dawkins at IETF" <spencerdawkins.= ietf@gmail.com> wrote:

I may be confused ...

On Thu, Dec 3, 2015 at 9:13 AM, Alia Atlas=C2=A0<akatlas@gmail.com>=C2=A0wrote:
Oh - looping can happen naturally as a result of routing r= econvergence.
That's what the TTL is for, in part, to make sure those packets do= n't loop
forever.

Micro-forwarding loops are common.

Right. I thought we were talking about the case where the TTL isn't dec= remented.


Right.=C2=A0 If we change the text in response to Alia's DI= SCUSS, then the text won't talk about not decrementing the TTL anymore,= so no loops would happen then.

Perfect.

Spencer
--001a114505861d6dc30526001025-- From nobody Thu Dec 3 08:21:42 2015 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 860E01A8AEE; Thu, 3 Dec 2015 08:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdetWYz01hQb; Thu, 3 Dec 2015 08:21:38 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222601A8ADE; Thu, 3 Dec 2015 08:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25434; q=dns/txt; s=iport; t=1449159698; x=1450369298; h=from:to:cc:subject:date:message-id:mime-version; bh=L6pJkFWgN4Ylj/6jl/VtB8OkfjLwhhaIInxpfnPXcKQ=; b=TRYkAEOWXEWktCLSQ06fyyEm8gw7I8LBjhE1gaPZvnD9hMBXS6Io+bxL HCpw14JrcJAsyFBdp15nDnxVSqKnR6rF9MlK71cPtJ+P2vV1wuW2bSXWs ebAW6JKAM89n8CmRdA211RSKYg6KEQgvl04PHWQHnCj5glcPfZAdWzXxJ o=; X-Files: image002.png : 4903 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C/AgAIa2BW/5BdJa1bA4JuTFNuBr08D?= =?us-ascii?q?oFuI4VrAoFLOBQBAQEBAQEBgQqENAECBAUgCAE4AwEIBw4EAQgHCgECAQIGAQE?= =?us-ascii?q?BHwkVAQMLDBQDBgoEAQ0EAQYIiCENsxmPOwEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?Q8JBIEQhUCEfYQqEQEaCgEFAgkKAQwJAgIECYJogTEFlmEBgmCBYgFpiA+BW0m?= =?us-ascii?q?Deoc4jxYBHwFDghEdgVZyAYQmBxcjAYEGAQEB?= X-IronPort-AV: E=Sophos;i="5.20,378,1444694400"; d="png'150?scan'150,208,217,150";a="56038263" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2015 16:21:36 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tB3GLa4o012485 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2015 16:21:36 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 3 Dec 2015 11:21:36 -0500 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1104.000; Thu, 3 Dec 2015 11:21:35 -0500 From: "Patrice Brissette (pbrisset)" To: Rotem Cohen , "draft-xie-l3sm-l2vpn-service-model@ietf.org" , "draft-shah-bess-l2vpn-yang@ietf.org" Thread-Topic: [bess] Sync between l2vpn service models Thread-Index: AQHRLeauisULsIMRB0+1bScTPiROyQ== Date: Thu, 3 Dec 2015 16:21:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.168] Content-Type: multipart/mixed; boundary="_004_D285D5C27CB83pbrissetciscocom_" MIME-Version: 1.0 Archived-At: Cc: "l3sm@ietf.org" , Alexander Vainshtein , Hai Balas , "bess@ietf.org" Subject: Re: [bess] Sync between l2vpn service models 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: Thu, 03 Dec 2015 16:21:40 -0000 --_004_D285D5C27CB83pbrissetciscocom_ Content-Type: multipart/alternative; boundary="_000_D285D5C27CB83pbrissetciscocom_" --_000_D285D5C27CB83pbrissetciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rotem, These models are fundamentally different. draft-shah-bess-l2vpn-yang meant to be a generic L2 device model whereas draft-xie-l3sm-l2v= pn-service-model-00 models the service. The service model call various device models to enable the defined service. Regards, Patrice [http://www.cisco.com/web/europe/images/email/signature/est2014/logo_06.= png?ct=3D1406640631632] 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 [http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before = you print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. Please click here for Company Registration Information. From: BESS > on behalf = of Rotem Cohen > Date: Thursday, December 3, 2015 at 10:02 AM To: "draft-xie-l3sm-l2vpn-service-model@ietf.org" >, "draft-shah-bess-l2vpn-y= ang@ietf.org" > Cc: "l3sm@ietf.org" >, Alexander Vainshtein >, Hai Balas >, "bess@ietf.org" > Subject: [bess] Sync between l2vpn service models Dear authors of L2VPN service model drafts, Can you clarify please the relation between draft-shah-bess-l2vpn-yang and draft-xie-l3sm-l= 2vpn-service-model-00? There are fundamental differences between L2VPN and L3VPN services and it d= oes not seem right to derive one model from the other. draft-xie-l3sm-l2vpn= -service-model-00 made the effort to explain these differences but if the starting = point had not been the L3VPN service model then it would not be necessary t= o do so. VPLS and VPWS are widely deployed in MPLS-TP networks which do not assume a= ny IP routing/forwarding capabilities and therefore using L3VPN constructs = to define L2VPN services is not natural for these applications. Relating to the conclusion section, the structure of L2VPN service is quite= clear and modelling it without relying on L3VPN should not be regarded as = reinventing a new wheel. Thanks & regards, Rotem Cohen PTS System Architecture Group Manager T: +972.3.926.8247 M: +972.54.926.8247 E: Rotem.Cohen@ecitele.com www.ecitele.com [cid:image002.png@01D12DEC.53A52A40] --_000_D285D5C27CB83pbrissetciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <94215A81E251D845999FD945B3602F2C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Rotem,

These models are fundamentally different.

draft-shah-bess-l2vpn-yang meant to be = a generic L2 device model whereas draft-= xie-l3sm-l2vpn-service-model-00 models the service.
The service model call various device models to enable the defined ser= vice.

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 (o= r authorized to receive for the recipient), please contact the sender by reply email and delete all copies= of this message.

Please click here for Company Registration Information.


From: BESS <bess-bounces@ietf.org> on behalf of Rotem Cohen= <Rotem.Cohen@ecitele.com= >
Date: Thursday, December 3, 2015 at= 10:02 AM
To: "draft-xie-l3sm-l2vpn-service-model@ie= tf.org" <draft-xie-l3sm-l2vpn-service-model@ietf.org>, "draft-shah-be= ss-l2vpn-yang@ietf.org" <draft-shah-bess-l2vpn-yang@ietf.org>
Cc: "l3sm@ietf.org" <l3sm@i= etf.org>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Hai Balas <Hai.Balas@ecitele.com>, "bess@ietf.org" <= bess@ietf.org>
Subject: [bess] Sync between l2vpn = service models

Dear authors of L2VPN service model drafts,

 

Can you clarify please the relation between draft-shah-bess-l2vpn-yang and draft-xie-l3sm-l2vpn-service-model-00?

 

There are fundamental differences between L2VPN and = L3VPN services and it does not seem right to derive one model from the othe= r. draft-xie-l3sm-l2vpn-service-model-00 made the effort to explain the= se differences but if the starting point had not been the L3VPN service mod= el then it would not be necessary to do so.

VPLS and VPWS are widely deployed in MPLS-TP network= s which do not assume any IP routing/forwarding capabilities and therefore = using L3VPN constructs to define L2VPN services is not natural for these ap= plications.

 

Relating to the conclusion section, the structure of= L2VPN service is quite clear and modelling it without relying on L3VPN sho= uld not be regarded as reinventing a new wheel.

 

Thanks & regards,

 

Rotem Cohen

PTS System Architecture Group Manager

T:

+972.3.926.8247

M:

+972.54.926.8247

E:

Rot= em.Cohen@ecitele.com

 

www.ecitele.com

 

 

 --_000_D285D5C27CB83pbrissetciscocom_-- --_004_D285D5C27CB83pbrissetciscocom_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: attachment; filename="image002.png"; size=4903; creation-date="Thu, 03 Dec 2015 16:21:35 GMT"; modification-date="Thu, 03 Dec 2015 16:21:35 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAKkAAAAiCAYAAAAkovk0AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABKnSURBVHhe 7Vx7eBRVlj/3VnWSNkQTIYOsuuiIIC9Bgusiyvj4ZgTRJg7DsiuMYWTUWQ18EXZXmZUUFRidN/lI llnRYXT4UMEHEF1xhNHxiaziY3goCIioLBKggRDy6Kp793eq353upLPy16bvR9HVVfeee+85v/Os 6pi2bVO2zdpd3Zscuhz9x5GmkTguwdGL8B8JcRTXPyGTtuDzTWqnd+1hNSezpZ3rl+NAJg6Y2bDG +qR6HPrdAyzeQD46yxujIgfwCYTyv1IyaBBJmsSYBVgPWbuq16DfUvuSmr9mM0+uT44D6TjQKUit bdUXAZQPAYBTADqiEI72DIxkYDJwo82gbwG0d+Ha7dbO6mUYa8GyHsmJIceB7nIgI0itHdX/CIDW A5y9PWC2dZO0i/58SFDxwQoTfQ+gvx1AfbOblHLdezgH0oLU2vHAvwJYv/QsY3fBmcpQptGKw0cX 49gI8N9mD6lZ3cP5ntt+NzjQAaQA0b9QHgDqpLjvbhBN25VDBYPycazCHA6A+tw3JZkb3zM4kARS gGcKrN2vTjtAo7xk9294x0q4/qvg+rkSkGs5DnTKgRhIUV7qjwTpES8zT0yATjcDGag+KkCsusJ6 o3q0fXXNqdM9RY7e/y8OxC1pG/0G0DnrG8eg2fCHXX8BDUZKdh/OrGyG5Pr0XA54IIXrHQPrNrlD ecmrgaZpKIt2aFELzPdkwt1EGonjwqWse2HBH7YH1BzouSLI7bwrDoQtqdBzyASCUjP5TMmTLwGI HBq04MA1nx+lVKbBDvwMHBx/stVkoDJweVwUtDwun4qoVd2JswVdLTR3v+dywIQVPRsAGu+BKdoY SADob24nGn5+HFfR23P/SLRtbwR4iDGnf4/otmuI+vchOnScaMNWoroXiIJ4KFr7Y6Kh5xGteZdo 6doIeKOEOD4V8p+sTdUP2mNqMj0m6LnSye3c44AJgF6BklOvDq4elu66oUQjL+jIqXOKAVKGFCzj skqiO66P9xnYj+iqS4j+8BeANEh0/TCiYQD6vkb0SVQEHhIu9g+EPR2BM8A43KyHVpXIQn8AN6Eu Dg4p0c9RDj1nVwVaFta/OFKRM0I5wWfsqopme0nDLd642YE14fENfWShvNHTNImxREesysDz6WS+ sL5hPLZ6DimlSJqGJPX6/MrAHsvaZsjS3VMw5rhVWb4+7djahsvBwSD67069761JygHIQj9WJU0b 7GnT2hbWNlyiTDmGlMM7x9p4PrlrfuWNb1mWJWRp2T/gajPWChWPN6u+4VJs4jsYcEo56k/gwZep 84H2EMck064MeI+g8X2MMmkgeLYG/U9YtQ1nSFMFSMn88FillZJr+R54UIbNX5q0LkftnF8VeBv3 RikyR+Y5TS/Pq5r6Jb4Pdxzaj3HH7fqGieDb2epI8yrbnuYZGczjl3nyB0i+e2OtL6Pfjphcax/v Jc0SyBWP0KUMquNqvT0vwMjwGtZ8OfgzFONYzidA/1astxnuXo2DNUsnAzrJRXi0rfthCd+B9+bg AFHBpwfxCcBNnxAH6Ju7iJ7Ds6SLAcgWLPcLZmMexWjwNR6b1Nhicwig6Er8HwOpWeS/UIu8xzwb zn0E4gbNcs2DTaavSDvThfTNJSp5Dd+bhaBlEXvvgZT85iAh9eMksAAe67Z9javnpNskRPWQMApG IuTx+ip16p/Rbw8N/MgUR3s9qUlvx/e0IFWGflQo/QHuz0ikvXDJ2geFkT/P46sOkRksGoj7nypT 3SIM/4NhRrDu5WNbp1h5ILjxhtCHVuDOPnyPgRSCmmKQXA1Ae+sz9anFuD8ndS9K0jWGFvOs2scH Q3FPakNVCpF/K2Kvzeh7AlLpLXTBk2EhsrwxvwoN4Xta67uEL/8Or/TIzcC6VMs6nJVDgcuE4VvW rvJn43ud0vpxKcVCnK8RWj+DrcB3fvtJHgaAnmmaer3WxpXMT8PUMCgN34USv+XRNXv1xeWV3l4w 0OilvgIwJ0IZPuLb2qA7hTDge5s3Yt9XQy4rNbXOQW85uquS09ufYgFLQIXjTN4f3nuSeM1kzsTw nj4AW6+fj8f6x/CF9ZQP4COrFgbu8MS+0NTdUjrlUqirtZBztQ4twP33qMQffvavdWsYtDH734Rr cRUwHfBWgtHOYtB4mYTJUXPGpt323STUbNJ5hnKkx7BIawLR5nQDrdpVfQ3DPxTCKLKsTaZtj/FE DEEVG4b8N63aP5JCwM+oy5ySZqg566JcLXXbTqz956B7rlZtd6LPx3H6ugnrjs3HHsXo5WcFPAp6 M3Cv0HVFzDIlrUuqIEn/eYY+qx7X0Vec9HhkxqQLngiX3NBmAZDhC7Q3+AXTEK6zRInQBqHdh3mc 1m33wv98xvekQ2/ocLIyAHsrMkzjMkHuOJy/gvMCUu5T0b1LU9+nZcGVQrVUoz/GGa9ACMusTZtG 2GM8/ihgU0M5noa4Vgkpn9XS5b6Tvb1oZDeauxWdic9fkNP6lTpcWmdi0MWe2+2klRQS9bkAHQrC zvcYoDIIjmzE34YHPfJnoAX6RGd7ywg3toCZqgOJc4X7w/7GG5t6fFtn178QEkLMVaHQertq8n93 WGLIzGe3bPQGQHnziQ3mlZTY6hzuvTHKxLRbFMKERTjmNvbdQPSSi1cXE+mweU27C2nmXwfwGwDC hWZp40jQfi9MPwhuFp+CRejtOM2f21VTY+8qwBXvQYc9NfXr7sVq+1iVN61MWTMMd3wfssj/XZJ5 xdpprbJmlacNV5LGw7eT9FXY9WtXSyGPplk4p7IHncbSJJ7Mr5q8Dde31dQ1/FYLHbTuvunZKF0n WLrb6PP1IQB7EIAbYCuoXHccPq5mT6Gl8wb35XDF7DOqXLttJ5zDzb9g9499rtXCdwttbhxAY/Aa p9cgUdL7q2cHnqupW/ulJlGWtAettCHV3ZhnKIzTrSw7Exaod0c/nCzO7/8d0c2/B+Yg9y1ImMbB 0XKS5EV7aJ77Z8vpuebI2GwAGp1G05lpAUQK6gG+Sh9sd0IT7JjgLgpC71DBHgf7PkcrilsYBysx XFzWy43S4PKaunXLqmdNuivdHADocYBtrFF6JES67CAsxKCIkqRfUuQqtom4K3QAkxQrUmwJPJDC 1TYhHr1PSGOpYRZuX7ikoXz+7MArKcQ8fwfXXMgxdcaJFF59FLC/UnpA6LqFLYPQ4g/A+k6MTZGC PoH1fp/3atet+9iaNYndvdcAMmn0GQXUcXwUbwwSgHcTcDIG4Coktz0IlPWHhbybTRZi6ohyjjcU HWIz9UU0PmWZCEPcgs0WxykChQi9OIyBfTgPovRCBW6Ql4vpYXD0PbDuW6tnl3v3IlFm59s3AUYJ EEpIpoBjSLS8hK3w/aysZqZp0tVdO10SqwsbOfoQH1zwGo8lJDIXG+UuGgxU+7UQEUamJeoDwwFU vRF3D4NoanrXYRCDyzCKbwAcfiu0uhQzTYWQfxq1wkjgfgdr1iLIXA4pNiDRG4XkCFF7dxu7GY85 yUqalgxLh92JuxQnFYhfr4aVD6XkAZCeRk3a3YTPz7NdjdbqdeQAkzDmW5qcmdCbmWT4JpDrfO4c ObkzmQ52HGlAvBHRkriyIJYAkqbD00yHS9/nujIeX4OhnmJp2oswr79V/+KFduWNn3E0fhS3CjsD 2VqkNHMeAQpQB20NvyhCwQT971eCa12EDJ0yRBBisW401nZIwnXEVFi9Y7CUu7EzrC7SPNUDixxh WVU3vdgZZXCvF0S7tbpy0g/S9GOtjqYTcfKy5AotjUKhnApYniIoRIlZUjYYHXaw22OwoiLwmL3k WRiLXssVtXH94/8AUrk9rGwKlQp6vUsOeUUQsQ51ireEkCsB0hT1l34o7tPVswIVXdJK6CCVfEdz oUW7J9Xh5hWytOh8bAzJkfMBrGakuv6SK/WoRhiEi6zaWr9dVdWC8xFYO8Ffx98jRjaHa6uQoSLD EaMpWBqMTgWMQmjguFYL4YkeM1Qbx6s/YnHuxs7O7yx5agSEPmN9YRiwvUJi9FekAocROfaBo558 BUpOnAtyBh99Yx/xa1YtnOh2KKl0MTbKfA4TjrFzT+rPsDJ5y+4UxLX9wJAgrFuGt64EmCz6w/LN xCAuQb2KbBSpIjek5lqcB9eEjBNbc+hpLr3gegDChrrqgwDRIVit0SRDNzNIqd/YEijNMxDQKimN /mA4tEkdSlofW4x0MZaX/DEqww1g22i47V9rYd6HEAJJjixEJrM1Q0nMG4dKGmLd8iewhqlYF6oG iTE1u1MaDp6gAq5kfD+x1bFGdPBrYOd2Qys2Q38BKEPwDA1auwuw3FhFhhUTfHpKyPyfGXRBHdb7 vpDmBKFD79LhAV4SFm6oDWjnU0z/Xzovb5MsbfwhLj4a4TeMAiosbsuf8cLcE2TkzUD4NR+Jk/oQ 465NYmLKl37FKMiPAD4BPGbhbsSgx3GsQlnqHhTyJ15GNHc60Yo/IWX9G6KL+hI9w1FUMnTSTxFm SSSoTu0iYTHZe4RSa2RYN19S4dGsncktfN0wZ8CtzCDdxo9d04IUauuAGefDmj4aLkG1cewaBinH vsLXH5yDH4ElMZ3XYCmbELvdBjO9sXpWOVs4AiAAVPEj3PsVlZTlYd/DhfBd6/k41f6GUsfBmXgD DPI4curAECEKAP5YXcSrYS5Z+0MA/jGUgep5z8J1f41xHUtiCmYUKgbhe+Ndn/ixDKk3Eb1EQwVM qVys6zLQQYbB/HO4NASlizbwUXi1maTm1UTr1n2EPXo8dBo3f4gk6RMtxdbEjgD9YsNo/XvEhjPB s5lahXZgvbfb9rCon/XCMOynrxvcstnoU4bqib7fslb+MRzHiohc/Sa2ugC6fKthqkVInORrmOje DgxjGUegcdMoIj6ibdwC1BdgG+yniG4EQC8sJfr1NKIHyhEhI9Xhdi4s74H/gVwjNKK0OszDVk/i h3tpGuqKG0xHjgXjuVYZa44S/wG66yjYxCkb7xtWLMkAbBWEcfD3nmEQImNy4io505S6iMlwycY1 I255166QKC2bCGxC6BHr0tgE/4F4X+wtd5zWmHVAWega0/RqG0icAgdROhpoFvk4KdHO2Se32NMq kh44ow5TYToo6AX3RirRPPIlVzhXXAtFSOo7f3b5BtAbZhYVDcEz53ZoTVqFVnnqJdMRY928sILZ Pwk0wgrB+Pjw3A8t6BwSJf5xePyNikTMWu6LMhWWUKGmeYOLBaSVhfBNIcfx+O2FM7UN40EUMXy8 8YMWfAsglhwNYOW7Lr1vVU2Ol/+KTh4QTf6xjhBfh2k8O8Y0fUjBw82V5i/hAFfg9BC82SmsZzTA 4ecq2ttw0y0Aij/V5XP8GYroAIflHiBweDkj9K0RS5ywCI8778DTqWFxgO4FgIsRcRxAvxbQ4Ocr bem2zsFGCPW4Yno/HWPAaI5l3k69B2Zw3dGrPXLDhrakMItj3A7j0s5RFUiyBtE+LDScZ0i4hiXF h/GnKvwwBUKcN5XjrHABO01DKSoyZ7i/NyZc+upYZsuCnjceoMRH7OmNd60qEHtxJ5Jxc2E/YwMf MyaYSGBQ14k30M6YeKFvWjp2RQUrZUwuKCsmGR9OknA/pvxRuZp48bjR2l69EXn+zbHSOCMR9qNi KVEhwJhYyOBb+xk67BRgJXdiqdcvQDX+24hPYY/4KdU2RE8tbLsA1Ol1yEzg2A4zbFJzVA4HQmq1 fe6iBIvSGRtz93oiB9iWsXlcDCt6c/RpXeQafcHGPVqcT+RO9C0o1n2OrNBnK+eu0YoJR0WRUtX+ KA0GZOJbUBwGsAU35H/2RMbn9pw9BzyQ4vdGr+JtqPVw+BOSXteLAK1Lcgy4TNl8Io3E0jIDuVX9 zh68aF+X9HMdejQHwpY03KqQy34HmekZ36jmmQ07GbhteJFCHa/JpnuuT8/mQAykiE134Yd4sxCL /t5z2915rNkdHrLbV1ADlyrsYXUJ5Y/uEMn17UkcSLSk7PaXW9sfuIj88qee2z/dQOWwgEHaTndC Kbp+gtKTJJHba0YOJIGUe9lDF/07LKpE9n6/937hN3ncmTgtz8Sgb6efsDLkZJLjQLYc6ABSD6hD auYBqPtQYloM9+/P+PefspklUs4C4A8A8HeB9gvZDMv1yXEgyoG0II0A9WFk/JtRlvo5Skc3eOWp 6I/qsuEfu3ZOkNgat9MTOL/fHlSDCmqu5TjQPQ5kBKkH1GE1H+JjPP70I788cQ+Aeh0sK15ti4QB iQkWg5jjTQYnnzt4synkPWOutwfXZPk+ZPcWn+vdMzjQKUijLMDfF30e5897f+WkTV0FJI4DGMuQ pQ/GJ/+ohOPN43Dn23DtPVx7FYDdhN/TJ7/90zN4mtvlaebA/wIHYhq8vhA2RAAAAABJRU5ErkJg gg== --_004_D285D5C27CB83pbrissetciscocom_-- From nobody Thu Dec 3 18:08:44 2015 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 3AB911ADBF8; Thu, 3 Dec 2015 18:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfVisal2qpEA; Thu, 3 Dec 2015 18:08:40 -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 52DDA1AD36A; Thu, 3 Dec 2015 18:08:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEZ37464; Fri, 04 Dec 2015 02:08:36 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Dec 2015 02:08:35 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.64]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Fri, 4 Dec 2015 10:08:29 +0800 From: Xuxiaohu To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT) Thread-Index: AQHRLdaOLk8nhORYXUKrCN/X2riedp66D2jw Date: Fri, 4 Dec 2015 02:08:28 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53D79@NKGEML512-MBS.china.huawei.com> References: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> In-Reply-To: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5660F5A5.00BB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.64, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a31d151a71e39ce19f31b3d9f3ecb57d Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" , "aretana@cisco.com" Subject: Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-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: Fri, 04 Dec 2015 02:08:43 -0000 SGkgU3RlcGhlbiwNCg0KVGhhbmsgYSBsb3QgZm9yIHlvdXIgRElTQ1VTUy4gSSBmdWxseSBhZ3Jl ZSB3aXRoIHlvdSB0aGF0IHNlbnNpdGl2ZSB0cmFmZmljIGJlaW5nIGhhbmRsZWQgYnkgVk1zIHNo b3VsZCBiZSBlbmNyeXB0ZWQgd2hlbiB0cmF2ZXJzaW5nIGFjcm9zcyB0aGUgSW50ZXJuZXQgb3Ig ZXZlbiBTUCBuZXR3b3Jrcy4gU2ltaWxhcmx5LCBJIHRoaW5rIHlvdSB3b3VsZCBhbHNvIGFncmVl IHRoYXQgc2Vuc2l0aXZlIHRyYWZmaWMgb2YgVlBOIGNsaWVudHMgc2hvdWxkIGJlIGVuY3J5cHRl ZCBhcyB3ZWxsIGluIHRoZSBleGlzdGluZyBNUExTL0JHUCBJUCBWUE4gW1JGQzQzNjRdIHNjZW5h cmlvLiBIZW5jZSwgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50IHNob3VsZCBiZSB0aGUgc2FtZSBm b3IgUkZDNDM2NCBhbmQgdGhpcyBkcmFmdCwgSU1ITy4gVGhlcmVmb3JlLCBpbiB0aGUgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbiBzZWN0aW9uIG9mIHRoaXMgZHJhZnQsIGl0IHNhaWQgIiBTaW5jZSB0 aGUgQkdQL01QTFMgSVAgVlBOIHNpZ25hbGluZyBpcyByZXVzZWQgd2l0aG91dCBhbnkgY2hhbmdl LCB0aG9zZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhcyBkZXNjcmliZWQgaW4gW1JGQzQzNjRd IGFyZSBhcHBsaWNhYmxlIHRvIHRoaXMgZG9jdW1lbnQuICIgDQoNCkFueSBmdXJ0aGVyIGNvbW1l bnRzIGFyZSBtb3JlIHRoYW4gd2VsY29tZS4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWls dG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0NCj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVy IDAzLCAyMDE1IDEwOjI2IFBNDQo+IFRvOiBUaGUgSUVTRw0KPiBDYzogZHJhZnQtaWV0Zi1iZXNz LXZpcnR1YWwtc3VibmV0QGlldGYub3JnOyBhcmV0YW5hQGNpc2NvLmNvbTsNCj4gYmVzcy1jaGFp cnNAaWV0Zi5vcmc7IG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQuY29tOyBiZXNzQGll dGYub3JnDQo+IFN1YmplY3Q6IFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0 Zi1iZXNzLXZpcnR1YWwtc3VibmV0LTA2OiAod2l0aA0KPiBESVNDVVNTIGFuZCBDT01NRU5UKQ0K PiANCj4gU3RlcGhlbiBGYXJyZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWJlc3MtdmlydHVhbC1zdWJuZXQtMDY6IERpc2N1c3MN Cj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRh Y3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRv IGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFy YWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMs IGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWJlc3MtdmlydHVhbC1zdWJuZXQvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo+ICgxKSBTdXJlbHkgZXh0 ZW5kaW5nIGEgc3VibmV0IGZyb20gb25lIHRvIG1hbnkgZGF0YSBjZW50cmVzIHNob3VsZCBvbmx5 IGJlDQo+IGRvbmUgaWYgaW50ZXItZGF0YS1jZW50cmUgdHJhZmZpYyBpcyBhbGwgZW5jcnlwdGVk IGFuZCBhdXRoZW50aWNhdGVkPyBJIGRvbid0IGdldA0KPiB3aHkgdGhlcmUgaXNuJ3QgYSBNVVNU LWxpa2Ugc3RhdGVtZW50IGhlcmUgZm9yIHN1Y2ggcHJvdGVjdGlvbiwgYW5kIGdvaW5nIGEgYml0 DQo+IGZ1cnRoZXIsIHdoeSBzb21lIGludGVyb3BlcmFibGUgZm9ybSBvZiBwcm90ZWN0aW9uIGZv ciBzdWNoIHRyYWZmaWMgKGUuZy4gSVBzZWMsDQo+IE1BQ3NlYykgaXNuJ3QgcmVjb21tZW5kZWQg YXMgYmVpbmcgTVRJIGluIHN1Y2ggY2FzZXMuIFRoZSBodWdlIHZhcmlldHkgb2YNCj4gcG90ZW50 aWFsbHkgYW5kIGFjdHVhbGx5IHNlbnNpdGl2ZSB0cmFmZmljIGJlaW5nIGhhbmRsZWQgYnkgVk1z IHRoZXNlIGRheXMgYW5kDQo+IHdoaWNoIG91Z2h0IG5vdCBiZSwgYW5kIHByb2JhYmx5IGlzIG5v dCwgdW5kZXJzdG9vZCBieSBmb2xrcyBkb2luZyByb3V0aW5nDQo+IHNlZW1zIHRvIHZlcnkgc3Ry b25nbHkgaW1wbHkgdGhhdCBzdWNoIHByb3RlY3Rpb24gc2hvdWxkIGluIGZhY3QgYmUgdHVybmVk IG9uIGFsbA0KPiBvZiB0aGUgdGltZS4gKEJ1dCBzdGF0aW5nIHRoYXQgd291bGQgYmUgZ29pbmcg YmV5b25kIGN1cnJlbnQgSUVURiBjb25zZW51cyBvbg0KPiBNVEkgc2VjdXJpdHkgYXMgZXhwcmVz c2VkIGluIEJDUDYxLiAgSXQnZCBzdGlsbCBiZSBhIGdvb2QgaWRlYSBJIHRoaW5rDQo+IHRob3Vn aC4pDQo+IA0KPiAoMikgSSdtIGd1ZXNzaW5nIG9uZSByZWFjdGlvbiB0byB0aGUgYWJvdmUgZGlz Y3VzcyBwb2ludCBjb3VsZCBiZSAic3VyZSwgYnV0IHRoaXMNCj4gaXMgdGhlIHdyb25nIGRvY3Vt ZW50LiIgSW4gdGhhdCBjYXNlLCBwbGVhc2Ugc2hvdyBtZSB0aGUgcmlnaHQgZG9jdW1lbnQgYW5k DQo+IHRoZW4gdGVsbCBtZSB3aHkgYSByZWZlcmVuY2UgdG8gdGhhdCBpcyBub3QgbmVlZGVkIGhl cmUuDQo+IA0KPiBOb3RlOiBub25lIG9mIHRoZSBhYm92ZSBpcyBhYm91dCBSRkMyMTE5IE1VU1Qv U0hPVUxEIGV0YyB0ZXJtcyBldmVuDQo+IHRob3VnaCBJIHVzZSB0aGVtIGFib3ZlLiBKdXN0IG5v cm1hbCBlbmdsaXNoIHRoYXQgbWFrZXMgdGhlIHBvaW50IHdvdWxkIGJlDQo+IGZpbmUuDQo+IA0K PiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAN Cj4gVGhlIHNlY2Rpci1yZXZpZXcgWzFdIHJhaXNlZCBhIHNpbWlsYXIgaXNzdWUsIGJ1dCBJIGRv bid0IHRoaW5rDQo+IHRoZSByZXNwb25zZSB0byB0aGF0IGlzIHN1ZmZpY2llbnQgcmVhbGx5LiAo VGhlIHNlY2RpciByZXZpZXdlcg0KPiBkaWQgdGhpbmsgc28uKQ0KPiANCj4gICAgWzFdIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2VjZGlyL2N1cnJlbnQvbXNnMDYyMTcu aHRtbA0KPiANCg0K From nobody Fri Dec 4 03:40:41 2015 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 C420A1B307A; Fri, 4 Dec 2015 03:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KIuPd2RKsgH; Fri, 4 Dec 2015 03:40:38 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283991B3078; Fri, 4 Dec 2015 03:40:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6EECABE3E; Fri, 4 Dec 2015 11:40:35 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M65qmIpM-ydt; Fri, 4 Dec 2015 11:40:32 +0000 (GMT) Received: from [10.87.48.95] (unknown [86.46.20.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 236C6BE38; Fri, 4 Dec 2015 11:40:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449229232; bh=dTu8BFLpqYaDrEYtLcPZSzj/emIJKBEWQsg45J4yKLM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gxGJhF2wnRT0SkWDgw2yBC7WmIq+94KfxnGqph+GtOux9VVp+It5gUsWpzc8bKoSV G0zmoF/z319EKC7OIM9ZW/D4XuIIExLnBP/Ea0OH/mb5PsutBnTYmUTZ8RGPyuWjy9 ajwemSKgTpIBrsxMXtCV7itZiSj/yBaNIV3yfaKk= To: Xuxiaohu , The IESG References: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53D79@NKGEML512-MBS.china.huawei.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56617BAD.6070906@cs.tcd.ie> Date: Fri, 4 Dec 2015 11:40:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53D79@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" , "aretana@cisco.com" Subject: Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-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: Fri, 04 Dec 2015 11:40:40 -0000 Hiya, On 04/12/15 02:08, Xuxiaohu wrote: > Hi Stephen, > > Thank a lot for your DISCUSS. I fully agree with you that sensitive > traffic being handled by VMs should be encrypted when traversing > across the Internet or even SP networks. Similarly, I think you would > also agree that sensitive traffic of VPN clients should be encrypted > as well in the existing MPLS/BGP IP VPN [RFC4364] scenario. Hence, > the security requirement should be the same for RFC4364 and this > draft, IMHO. Therefore, in the Security Consideration section of this > draft, it said " Since the BGP/MPLS IP VPN signaling is reused > without any change, those security considerations as described in > [RFC4364] are applicable to this document. " > > Any further comments are more than welcome. Well, my further comment is that the above doesn't seem adequate at this point in time (to me:-) In 2006, the security considerations of RFC4364 said: " Cryptographic privacy is not provided by this architecture, nor by Frame Relay or ATM VPNs. These architectures are all compatible with the use of cryptography on a CE-CE basis, if that is desired. The use of cryptography on a PE-PE basis is for further study." In 2015, we know that people, can, should, and do, turn on crypto between data centres. Today's situation is not 2006's and that I think needs to be stated and this document seems like a fine place to do that. I would still think that were the statement clearly made elsewhere. Cheers, S. > > Best regards, Xiaohu > >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, December 03, >> 2015 10:26 PM To: The IESG Cc: >> draft-ietf-bess-virtual-subnet@ietf.org; aretana@cisco.com; >> bess-chairs@ietf.org; martin.vigoureux@alcatel-lucent.com; >> bess@ietf.org Subject: Stephen Farrell's Discuss on >> draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT) >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-bess-virtual-subnet-06: Discuss >> >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found >> here: >> https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ >> >> >> >> ---------------------------------------------------------------------- >> >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> >> (1) Surely extending a subnet from one to many data centres should only be >> done if inter-data-centre traffic is all encrypted and >> authenticated? I don't get why there isn't a MUST-like statement >> here for such protection, and going a bit further, why some >> interoperable form of protection for such traffic (e.g. IPsec, >> MACsec) isn't recommended as being MTI in such cases. The huge >> variety of potentially and actually sensitive traffic being handled >> by VMs these days and which ought not be, and probably is not, >> understood by folks doing routing seems to very strongly imply that >> such protection should in fact be turned on all of the time. (But >> stating that would be going beyond current IETF consenus on MTI >> security as expressed in BCP61. It'd still be a good idea I think >> though.) >> >> (2) I'm guessing one reaction to the above discuss point could be >> "sure, but this is the wrong document." In that case, please show >> me the right document and then tell me why a reference to that is >> not needed here. >> >> Note: none of the above is about RFC2119 MUST/SHOULD etc terms >> even though I use them above. Just normal english that makes the >> point would be fine. >> >> >> ---------------------------------------------------------------------- >> >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> >> The secdir-review [1] raised a similar issue, but I don't think >> the response to that is sufficient really. (The secdir reviewer did >> think so.) >> >> [1] >> https://www.ietf.org/mail-archive/web/secdir/current/msg06217.html >> > From nobody Sun Dec 6 19:15:49 2015 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 7B7111B2C2D; Sun, 6 Dec 2015 19:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGyVF-JW6FsQ; Sun, 6 Dec 2015 19:15:42 -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 132C41B2C0B; Sun, 6 Dec 2015 19:15:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBG47897; Mon, 07 Dec 2015 03:15:37 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 7 Dec 2015 03:15:35 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.64]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Mon, 7 Dec 2015 11:15:30 +0800 From: Xuxiaohu To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT) Thread-Index: AQHRLdaOLk8nhORYXUKrCN/X2riedp66D2jwgAAf9ICABKhN0A== Date: Mon, 7 Dec 2015 03:15:29 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB54209@NKGEML512-MBS.china.huawei.com> References: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53D79@NKGEML512-MBS.china.huawei.com> <56617BAD.6070906@cs.tcd.ie> In-Reply-To: <56617BAD.6070906@cs.tcd.ie> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5664F9DA.012A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.64, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 636d13f7260e6fc54f0a0d46d7fffea7 Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" , "aretana@cisco.com" Subject: Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-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: Mon, 07 Dec 2015 03:15:45 -0000 SGkgU3RlcGhlbiwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGVw aGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXQ0KPiBTZW50OiBG cmlkYXksIERlY2VtYmVyIDA0LCAyMDE1IDc6NDAgUE0NCj4gVG86IFh1eGlhb2h1OyBUaGUgSUVT Rw0KPiBDYzogZHJhZnQtaWV0Zi1iZXNzLXZpcnR1YWwtc3VibmV0QGlldGYub3JnOyBiZXNzLWNo YWlyc0BpZXRmLm9yZzsNCj4gbWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb207IGJl c3NAaWV0Zi5vcmc7IGFyZXRhbmFAY2lzY28uY29tDQo+IFN1YmplY3Q6IFJlOiBTdGVwaGVuIEZh cnJlbGwncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtYmVzcy12aXJ0dWFsLXN1Ym5ldC0wNjogKHdp dGgNCj4gRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IA0KPiBIaXlhLA0KPiANCj4gT24gMDQv MTIvMTUgMDI6MDgsIFh1eGlhb2h1IHdyb3RlOg0KPiA+IEhpIFN0ZXBoZW4sDQo+ID4NCj4gPiBU aGFuayBhIGxvdCBmb3IgeW91ciBESVNDVVNTLiBJIGZ1bGx5IGFncmVlIHdpdGggeW91IHRoYXQg c2Vuc2l0aXZlDQo+ID4gdHJhZmZpYyBiZWluZyBoYW5kbGVkIGJ5IFZNcyBzaG91bGQgYmUgZW5j cnlwdGVkIHdoZW4gdHJhdmVyc2luZw0KPiA+IGFjcm9zcyB0aGUgSW50ZXJuZXQgb3IgZXZlbiBT UCBuZXR3b3Jrcy4gU2ltaWxhcmx5LCBJIHRoaW5rIHlvdSB3b3VsZA0KPiA+IGFsc28gYWdyZWUg dGhhdCBzZW5zaXRpdmUgdHJhZmZpYyBvZiBWUE4gY2xpZW50cyBzaG91bGQgYmUgZW5jcnlwdGVk DQo+ID4gYXMgd2VsbCBpbiB0aGUgZXhpc3RpbmcgTVBMUy9CR1AgSVAgVlBOIFtSRkM0MzY0XSBz Y2VuYXJpby4gSGVuY2UsIHRoZQ0KPiA+IHNlY3VyaXR5IHJlcXVpcmVtZW50IHNob3VsZCBiZSB0 aGUgc2FtZSBmb3IgUkZDNDM2NCBhbmQgdGhpcyBkcmFmdCwNCj4gPiBJTUhPLiBUaGVyZWZvcmUs IGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9uIHNlY3Rpb24gb2YgdGhpcyBkcmFmdCwNCj4g PiBpdCBzYWlkICIgU2luY2UgdGhlIEJHUC9NUExTIElQIFZQTiBzaWduYWxpbmcgaXMgcmV1c2Vk IHdpdGhvdXQgYW55DQo+ID4gY2hhbmdlLCB0aG9zZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBh cyBkZXNjcmliZWQgaW4gW1JGQzQzNjRdIGFyZQ0KPiA+IGFwcGxpY2FibGUgdG8gdGhpcyBkb2N1 bWVudC4gIg0KPiA+DQo+ID4gQW55IGZ1cnRoZXIgY29tbWVudHMgYXJlIG1vcmUgdGhhbiB3ZWxj b21lLg0KPiANCj4gV2VsbCwgbXkgZnVydGhlciBjb21tZW50IGlzIHRoYXQgdGhlIGFib3ZlIGRv ZXNuJ3Qgc2VlbSBhZGVxdWF0ZSBhdCB0aGlzIHBvaW50DQo+IGluIHRpbWUgKHRvIG1lOi0pDQo+ IA0KPiBJbiAyMDA2LCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgb2YgUkZDNDM2NCBzYWlk Og0KPiANCj4gIiBDcnlwdG9ncmFwaGljIHByaXZhY3kgaXMgbm90IHByb3ZpZGVkIGJ5IHRoaXMg YXJjaGl0ZWN0dXJlLCBub3IgYnkNCj4gICAgRnJhbWUgUmVsYXkgb3IgQVRNIFZQTnMuICBUaGVz ZSBhcmNoaXRlY3R1cmVzIGFyZSBhbGwgY29tcGF0aWJsZSB3aXRoDQo+ICAgIHRoZSB1c2Ugb2Yg Y3J5cHRvZ3JhcGh5IG9uIGEgQ0UtQ0UgYmFzaXMsIGlmIHRoYXQgaXMgZGVzaXJlZC4NCj4gDQo+ ICAgIFRoZSB1c2Ugb2YgY3J5cHRvZ3JhcGh5IG9uIGEgUEUtUEUgYmFzaXMgaXMgZm9yIGZ1cnRo ZXIgc3R1ZHkuIg0KPiANCj4gSW4gMjAxNSwgd2Uga25vdyB0aGF0IHBlb3BsZSwgY2FuLCBzaG91 bGQsIGFuZCBkbywgdHVybiBvbiBjcnlwdG8gYmV0d2Vlbg0KPiBkYXRhIGNlbnRyZXMuDQo+IA0K PiBUb2RheSdzIHNpdHVhdGlvbiBpcyBub3QgMjAwNidzIGFuZCB0aGF0IEkgdGhpbmsgbmVlZHMg dG8gYmUgc3RhdGVkIGFuZCB0aGlzDQo+IGRvY3VtZW50IHNlZW1zIGxpa2UgYSBmaW5lIHBsYWNl IHRvIGRvIHRoYXQuIEkgd291bGQgc3RpbGwgdGhpbmsgdGhhdCB3ZXJlIHRoZQ0KPiBzdGF0ZW1l bnQgY2xlYXJseSBtYWRlIGVsc2V3aGVyZS4NCg0KSG93IGFib3V0IGFkZGluZyB0aGUgZm9sbG93 aW5nIHRleHQgaW50byB0aGUgY3VycmVudCBzZWN1cml0eSBjb25zaWRlcmF0aW9uOg0KDQoiVGhl IHVzZSBvZiBjcnlwdG9ncmFwaHkgb24gYSBQRS1QRSBiYXNpcyBpcyByZWxhdGVkIHRvIHRoZSBz cGVjaWZpYyB0dW5uZWwgdGVjaG5vbG9neSB3aGljaCBpcyB1c2VkIGJldHdlZW4gUEVzLiBGb3Ig aW5zdGFuY2UsIGlmIE1QTFMgTFNQcyBhcmUgdXNlZCBiZXR3ZWVuIFBFIHJvdXRlcnMsIHRoZSBh cHByb2FjaCBhcyBkZXNjcmliZWQgaW4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW1wbHMtb3Bwb3J0dW5pc3RpYy1lbmNyeXB0LTAwKSBzaG91bGQgYmUgY29uc2lkZXJl ZCwgYW5kIGlmIElQLWJhc2UgdHVubmVscyBmb3IgdHJhbnNwb3J0aW5nIE1QTFMgYXJlIHVzZWQg YmV0d2VlbiBQRSByb3V0ZXJzLCB0aG9zZSBJUC1iYXNlZCB0dW5uZWxzIHNob3VsZCBiZSBzZWN1 cmVkIHdpdGggSVBzZWMgb3IgRFRMUyAoZm9yIG1vcmUgZGV0YWlscywgcGxlYXNlIHJlZmVyIHRv IHRoZSBjb3JyZXNwb25kaW5nIHNwZWNpZmljYXRpb24gb2YgYSBwYXJ0aWN1bGFyIElQLWJhc2Vk IHR1bm5lbCB0ZWNobm9sb2d5KS4gT2YgY291cnNlLCBpZiB0aGUgZGF0YSB0cmFmZmljIGhhcyBi ZWVuIGVuY3J5cHRlZCBiZWZvcmUgYXJyaXZpbmcgYXQgdGhlIGluZ3Jlc3MgUEUsIHRoZSB1c2Ug b2YgY3J5cHRvZ3JhcGh5IG9uIGEgUEUtUEUgYmFzaXMgbWF5IG5vdCBiZSBuZWNlc3NhcnkgYW55 IG1vcmUuIg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBDaGVlcnMsDQo+IFMuDQo+IA0K PiANCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywgWGlhb2h1DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0gRnJvbTogU3RlcGhlbiBGYXJyZWxsDQo+ID4+IFttYWlsdG86c3RlcGhl bi5mYXJyZWxsQGNzLnRjZC5pZV0gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDAzLA0KPiA+PiAy MDE1IDEwOjI2IFBNIFRvOiBUaGUgSUVTRyBDYzoNCj4gPj4gZHJhZnQtaWV0Zi1iZXNzLXZpcnR1 YWwtc3VibmV0QGlldGYub3JnOyBhcmV0YW5hQGNpc2NvLmNvbTsNCj4gPj4gYmVzcy1jaGFpcnNA aWV0Zi5vcmc7IG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQuY29tOw0KPiA+PiBiZXNz QGlldGYub3JnIFN1YmplY3Q6IFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1c3Mgb24NCj4gPj4gZHJh ZnQtaWV0Zi1iZXNzLXZpcnR1YWwtc3VibmV0LTA2OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5U KQ0KPiA+Pg0KPiA+PiBTdGVwaGVuIEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBi YWxsb3QgcG9zaXRpb24gZm9yDQo+ID4+IGRyYWZ0LWlldGYtYmVzcy12aXJ0dWFsLXN1Ym5ldC0w NjogRGlzY3Vzcw0KPiA+Pg0KPiA+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBz dWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gPj4gZW1haWwgYWRkcmVzc2Vz IGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0DQo+ID4+ IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ID4+DQo+ID4+DQo+ID4+ IFBsZWFzZSByZWZlciB0bw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVu dC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwgZm9yIG1vcmUNCj4gPj4gaW5mb3JtYXRpb24gYWJvdXQg SUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gPj4NCj4gPj4NCj4gPj4gVGhl IGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3Vu ZA0KPiA+PiBoZXJlOg0KPiA+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWJlc3MtdmlydHVhbC1zdWJuZXQvDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+PiAtDQo+ID4+DQo+ID4+DQo+IERJU0NVU1M6DQo+ID4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+PiAtDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ICgxKSBTdXJlbHkgZXh0ZW5kaW5n IGEgc3VibmV0IGZyb20gb25lIHRvIG1hbnkgZGF0YSBjZW50cmVzIHNob3VsZCBvbmx5IGJlDQo+ ID4+IGRvbmUgaWYgaW50ZXItZGF0YS1jZW50cmUgdHJhZmZpYyBpcyBhbGwgZW5jcnlwdGVkIGFu ZCBhdXRoZW50aWNhdGVkPw0KPiA+PiBJIGRvbid0IGdldCB3aHkgdGhlcmUgaXNuJ3QgYSBNVVNU LWxpa2Ugc3RhdGVtZW50IGhlcmUgZm9yIHN1Y2gNCj4gPj4gcHJvdGVjdGlvbiwgYW5kIGdvaW5n IGEgYml0IGZ1cnRoZXIsIHdoeSBzb21lIGludGVyb3BlcmFibGUgZm9ybSBvZg0KPiA+PiBwcm90 ZWN0aW9uIGZvciBzdWNoIHRyYWZmaWMgKGUuZy4gSVBzZWMsDQo+ID4+IE1BQ3NlYykgaXNuJ3Qg cmVjb21tZW5kZWQgYXMgYmVpbmcgTVRJIGluIHN1Y2ggY2FzZXMuIFRoZSBodWdlDQo+ID4+IHZh cmlldHkgb2YgcG90ZW50aWFsbHkgYW5kIGFjdHVhbGx5IHNlbnNpdGl2ZSB0cmFmZmljIGJlaW5n IGhhbmRsZWQNCj4gPj4gYnkgVk1zIHRoZXNlIGRheXMgYW5kIHdoaWNoIG91Z2h0IG5vdCBiZSwg YW5kIHByb2JhYmx5IGlzIG5vdCwNCj4gPj4gdW5kZXJzdG9vZCBieSBmb2xrcyBkb2luZyByb3V0 aW5nIHNlZW1zIHRvIHZlcnkgc3Ryb25nbHkgaW1wbHkgdGhhdA0KPiA+PiBzdWNoIHByb3RlY3Rp b24gc2hvdWxkIGluIGZhY3QgYmUgdHVybmVkIG9uIGFsbCBvZiB0aGUgdGltZS4gKEJ1dA0KPiA+ PiBzdGF0aW5nIHRoYXQgd291bGQgYmUgZ29pbmcgYmV5b25kIGN1cnJlbnQgSUVURiBjb25zZW51 cyBvbiBNVEkNCj4gPj4gc2VjdXJpdHkgYXMgZXhwcmVzc2VkIGluIEJDUDYxLiAgSXQnZCBzdGls bCBiZSBhIGdvb2QgaWRlYSBJIHRoaW5rDQo+ID4+IHRob3VnaC4pDQo+ID4+DQo+ID4+ICgyKSBJ J20gZ3Vlc3Npbmcgb25lIHJlYWN0aW9uIHRvIHRoZSBhYm92ZSBkaXNjdXNzIHBvaW50IGNvdWxk IGJlDQo+ID4+ICJzdXJlLCBidXQgdGhpcyBpcyB0aGUgd3JvbmcgZG9jdW1lbnQuIiBJbiB0aGF0 IGNhc2UsIHBsZWFzZSBzaG93IG1lDQo+ID4+IHRoZSByaWdodCBkb2N1bWVudCBhbmQgdGhlbiB0 ZWxsIG1lIHdoeSBhIHJlZmVyZW5jZSB0byB0aGF0IGlzIG5vdA0KPiA+PiBuZWVkZWQgaGVyZS4N Cj4gPj4NCj4gPj4gTm90ZTogbm9uZSBvZiB0aGUgYWJvdmUgaXMgYWJvdXQgUkZDMjExOSBNVVNU L1NIT1VMRCBldGMgdGVybXMgZXZlbg0KPiA+PiB0aG91Z2ggSSB1c2UgdGhlbSBhYm92ZS4gSnVz dCBub3JtYWwgZW5nbGlzaCB0aGF0IG1ha2VzIHRoZSBwb2ludA0KPiA+PiB3b3VsZCBiZSBmaW5l Lg0KPiA+Pg0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gLQ0KPiA+Pg0KPiA+Pg0KPiBD T01NRU5UOg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gLQ0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+ Pg0KPiBUaGUgc2VjZGlyLXJldmlldyBbMV0gcmFpc2VkIGEgc2ltaWxhciBpc3N1ZSwgYnV0IEkg ZG9uJ3QgdGhpbmsNCj4gPj4gdGhlIHJlc3BvbnNlIHRvIHRoYXQgaXMgc3VmZmljaWVudCByZWFs bHkuIChUaGUgc2VjZGlyIHJldmlld2VyIGRpZA0KPiA+PiB0aGluayBzby4pDQo+ID4+DQo+ID4+ IFsxXQ0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NlY2Rpci9j dXJyZW50L21zZzA2MjE3Lmh0bWwNCj4gPj4NCj4gPg0K From nobody Mon Dec 7 03:01:05 2015 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 AF9981A1BFE; Mon, 7 Dec 2015 03:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.005 X-Spam-Level: * X-Spam-Status: No, score=1.005 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qr8AdX3tJmhq; Mon, 7 Dec 2015 03:01:03 -0800 (PST) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 8972A1A1B63; Mon, 7 Dec 2015 03:01:03 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A5A17E3008C; Mon, 7 Dec 2015 12:01:02 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 99F1DE3008A; Mon, 7 Dec 2015 12:01:02 +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.224.2; Mon, 7 Dec 2015 12:01:01 +0100 To: BESS From: Thomas Morin Organization: Orange Message-ID: <566566EE.30003@orange.com> Date: Mon, 7 Dec 2015 12:01:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-hao-bess-inter-nvo3-vpn-optionc@ietf.org, BESS Chairs Subject: [bess] Closing the call for adoption on draft-hao-bess-inter-nvo3-vpn-optionc 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 Dec 2015 11:01:04 -0000 Hi working group, Based on this long discussion following the call for adoption, we consider that there is no consensus at this point to adopt draft-hao-bess-inter-nvo3-vpn-optionc as a working group document. Our understanding is that the problem to address and the different alternatives solution are worth exploring, and we consider that the question of documenting a solution can be raised again in the future. We identify that the following will be helpful in this perspective: - documenting the different alternatives and their pros and cons ; we encourage people having raised their voice in this discussion to work together to this - having consolidated information about what encapsulation the typical ToR hardware chipsets will support in the mid/long term ; it will be an important input to help the WG decide what solution should be documented Thank you, Martin & Thomas From nobody Mon Dec 7 03:18:16 2015 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 35B211A8969; Mon, 7 Dec 2015 03:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y10rKXKdylC8; Mon, 7 Dec 2015 03:18:14 -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 709191A8958; Mon, 7 Dec 2015 03:18:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFC57983; Mon, 07 Dec 2015 11:18:10 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 7 Dec 2015 11:18:10 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.12]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 7 Dec 2015 19:18:03 +0800 From: Haoweiguo To: Thomas Morin , BESS Thread-Topic: [bess] Closing the call for adoption on draft-hao-bess-inter-nvo3-vpn-optionc Thread-Index: AQHRMN6bqT+hAsqWV0S6wt0+vSjfb56/XXXD Date: Mon, 7 Dec 2015 11:18:03 +0000 Message-ID: References: <566566EE.30003@orange.com> In-Reply-To: <566566EE.30003@orange.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.203.198.15] 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.0A020201.56656AF3.0087, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.12, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3cc90e345090a5991b2cce33026e7142 Archived-At: Cc: "draft-hao-bess-inter-nvo3-vpn-optionc@ietf.org" , BESS Chairs Subject: Re: [bess] Closing the call for adoption on draft-hao-bess-inter-nvo3-vpn-optionc 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 Dec 2015 11:18:16 -0000 Hi, I think the WG had better form a team to explore the problem and possilbe s= olutions ASAP. Those voiced different opinions should join the team to work= together. Thanks, weiguo ________________________________________ From: BESS [bess-bounces@ietf.org] on behalf of Thomas Morin [thomas.morin@= orange.com] Sent: Monday, December 07, 2015 19:01 To: BESS Cc: draft-hao-bess-inter-nvo3-vpn-optionc@ietf.org; BESS Chairs Subject: [bess] Closing the call for adoption on draft-hao-bess-inte= r-nvo3-vpn-optionc Hi working group, Based on this long discussion following the call for adoption, we consider that there is no consensus at this point to adopt draft-hao-bess-inter-nvo3-vpn-optionc as a working group document. Our understanding is that the problem to address and the different alternatives solution are worth exploring, and we consider that the question of documenting a solution can be raised again in the future. We identify that the following will be helpful in this perspective: - documenting the different alternatives and their pros and cons ; we encourage people having raised their voice in this discussion to work together to this - having consolidated information about what encapsulation the typical ToR hardware chipsets will support in the mid/long term ; it will be an important input to help the WG decide what solution should be documented Thank you, Martin & Thomas _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess= From nobody Mon Dec 7 04:00:37 2015 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 E1CB41A3B9B; Mon, 7 Dec 2015 04:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOzDP1YaryTb; Mon, 7 Dec 2015 04:00:29 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9599B1A8AB4; Mon, 7 Dec 2015 04:00:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7C6A7BE32; Mon, 7 Dec 2015 12:00:27 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqEBExPiGyBS; Mon, 7 Dec 2015 12:00:27 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9421BBE2F; Mon, 7 Dec 2015 12:00:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449489627; bh=+3bqL+vtM5p5rPRKs3Sg3YeBqLlmmT3X8VcQ3vuWiFY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=nnbp6y9TCpHt7anseI/xubUJopR4Z1vvMCa4OD5rLOUOyXcQzVCyDO8g7Cqku01tW FeCVBfvb0oGICmr5fdYZGTIP5s7WTmZbMzCQJsTrB3LUBGNJK8tClBlxATLF5G0lV4 khx98vWKmsShoyEl08357z33cvQVvD8OFfNlqbKs= To: Xuxiaohu , The IESG References: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53D79@NKGEML512-MBS.china.huawei.com> <56617BAD.6070906@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB54209@NKGEML512-MBS.china.huawei.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <566574D9.6030202@cs.tcd.ie> Date: Mon, 7 Dec 2015 12:00:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB54209@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" , "aretana@cisco.com" Subject: Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-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: Mon, 07 Dec 2015 12:00:33 -0000 Hiya, On 07/12/15 03:15, Xuxiaohu wrote: > Hi Stephen, > >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Friday, December 04, 2015 >> 7:40 PM To: Xuxiaohu; The IESG Cc: >> draft-ietf-bess-virtual-subnet@ietf.org; bess-chairs@ietf.org; >> martin.vigoureux@alcatel-lucent.com; bess@ietf.org; >> aretana@cisco.com Subject: Re: Stephen Farrell's Discuss on >> draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT) >> >> >> Hiya, >> >> On 04/12/15 02:08, Xuxiaohu wrote: >>> Hi Stephen, >>> >>> Thank a lot for your DISCUSS. I fully agree with you that >>> sensitive traffic being handled by VMs should be encrypted when >>> traversing across the Internet or even SP networks. Similarly, I >>> think you would also agree that sensitive traffic of VPN clients >>> should be encrypted as well in the existing MPLS/BGP IP VPN >>> [RFC4364] scenario. Hence, the security requirement should be the >>> same for RFC4364 and this draft, IMHO. Therefore, in the Security >>> Consideration section of this draft, it said " Since the BGP/MPLS >>> IP VPN signaling is reused without any change, those security >>> considerations as described in [RFC4364] are applicable to this >>> document. " >>> >>> Any further comments are more than welcome. >> >> Well, my further comment is that the above doesn't seem adequate at >> this point in time (to me:-) >> >> In 2006, the security considerations of RFC4364 said: >> >> " Cryptographic privacy is not provided by this architecture, nor >> by Frame Relay or ATM VPNs. These architectures are all compatible >> with the use of cryptography on a CE-CE basis, if that is desired. >> >> The use of cryptography on a PE-PE basis is for further study." >> >> In 2015, we know that people, can, should, and do, turn on crypto >> between data centres. >> >> Today's situation is not 2006's and that I think needs to be stated >> and this document seems like a fine place to do that. I would still >> think that were the statement clearly made elsewhere. > > How about adding the following text into the current security > consideration: > > "The use of cryptography on a PE-PE basis is related to the specific > tunnel technology which is used between PEs. For instance, if MPLS > LSPs are used between PE routers, the approach as described in > (https://tools.ietf.org/html/draft-ietf-mpls-opportunistic-encrypt-00) > should be considered, and if IP-base tunnels for transporting MPLS > are used between PE routers, those IP-based tunnels should be secured > with IPsec or DTLS (for more details, please refer to the > corresponding specification of a particular IP-based tunnel > technology). Of course, if the data traffic has been encrypted before > arriving at the ingress PE, the use of cryptography on a PE-PE basis > may not be necessary any more." That's definitely along the right lines but I think needs a few tweaks... First, even though I'm an author I think you're putting too much emphasis on the MPLS-OS stuff - we don't honestly know (yet) if that is something that'll see real deployment. And I'm told MACsec is also used for DC-DC security so referencing it as well as IPsec would be good. I'm not sure what DTLS based mechanism can be referenced here though one could of course exist or be defined in future. I'd say if there's no good reference for such, then maybe that's best omitted for now. If there's a goohttps://tools.ietf.org/html/rfc7258d reference then adding it would be good. And your text also avoids recommending securing traffic between data centres, which I think is needed, and is the main point for this text (for this informational document). So maybe something more like: "Inter data-centre traffic often carries highly sensitive information at higher layers that is not directly understood (parsed) within an egress or ingress PE. For example, migrating a VM will often mean moving private keys and other sensitive configuration information. For this reason inter data-centre traffic SHOULD always be protected for both confidentiality and integrity using a strong security mechanism such as IPsec [1] or MACsec [2] In future it may be feasible to protect that traffic within the MPLS layer [3] though at the time of writing the mechanism for that is not sufficiently mature to recommend. Exactly how such security mechanisms are deployed will vary from case to case, so securing the inter data-centre traffic may or may not involve deploying security mechanisms on the ingress/egress PEs or further "inside" the data centres concerned. Note though that if security is not deployed on the egress/ingress PEs there is a substantial risk that some sensitive traffic may be sent in clear and therefore be vulnerable to pervasive monitoring [4] or other attacks." [1] https://tools.ietf.org/html/rfc4301 [2] http://www.ieee802.org/1/pages/802.1ae.html [3] https://tools.ietf.org/html/draft-ietf-mpls-opportunistic-encrypt [4] https://tools.ietf.org/html/rfc7258 Note - I'm not sure if [2] is the best reference for MACsec, but I bet some of you will know better. If you want to s/SHOULD/MUST/ above I'd be fine with that. And if this document isn't using 2119 terminology (I forget) that's also fine just s/SHOULD/should/ (or "must":-). Cheers, S. > > Best regards, Xiaohu > >> Cheers, S. >> >> >>> >>> Best regards, Xiaohu >>> >>>> -----Original Message----- From: Stephen Farrell >>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, December >>>> 03, 2015 10:26 PM To: The IESG Cc: >>>> draft-ietf-bess-virtual-subnet@ietf.org; aretana@cisco.com; >>>> bess-chairs@ietf.org; martin.vigoureux@alcatel-lucent.com; >>>> bess@ietf.org Subject: Stephen Farrell's Discuss on >>>> draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT) >>>> >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-bess-virtual-subnet-06: Discuss >>>> >>>> When responding, please keep the subject line intact and reply >>>> to all email addresses included in the To and CC lines. (Feel >>>> free to cut this introductory paragraph, however.) >>>> >>>> >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for >>>> more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found >>>> here: >>>> https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> - >>>> >>>> >> DISCUSS: >>>> --------------------------------------------------------------------- >>>> >>>> - >>>> >>>> >>>> >>>> >> (1) Surely extending a subnet from one to many data centres should >> only be >>>> done if inter-data-centre traffic is all encrypted and >>>> authenticated? I don't get why there isn't a MUST-like >>>> statement here for such protection, and going a bit further, >>>> why some interoperable form of protection for such traffic >>>> (e.g. IPsec, MACsec) isn't recommended as being MTI in such >>>> cases. The huge variety of potentially and actually sensitive >>>> traffic being handled by VMs these days and which ought not be, >>>> and probably is not, understood by folks doing routing seems to >>>> very strongly imply that such protection should in fact be >>>> turned on all of the time. (But stating that would be going >>>> beyond current IETF consenus on MTI security as expressed in >>>> BCP61. It'd still be a good idea I think though.) >>>> >>>> (2) I'm guessing one reaction to the above discuss point could >>>> be "sure, but this is the wrong document." In that case, please >>>> show me the right document and then tell me why a reference to >>>> that is not needed here. >>>> >>>> Note: none of the above is about RFC2119 MUST/SHOULD etc terms >>>> even though I use them above. Just normal english that makes >>>> the point would be fine. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> >>>> - >>>> >>>> >> COMMENT: >>>> --------------------------------------------------------------------- >>>> >>>> - >>>> >>>> >>>> >>>> >> The secdir-review [1] raised a similar issue, but I don't think >>>> the response to that is sufficient really. (The secdir reviewer >>>> did think so.) >>>> >>>> [1] >>>> https://www.ietf.org/mail-archive/web/secdir/current/msg06217.html >>>> >>> From nobody Tue Dec 8 01:20:12 2015 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 BA1BF1A9238 for ; Tue, 8 Dec 2015 01:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrPMhurENPSp for ; Tue, 8 Dec 2015 01:19:56 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC1591A9173 for ; Tue, 8 Dec 2015 01:19:55 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id AC9E23CEE7CDF for ; Tue, 8 Dec 2015 09:19:51 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id tB89JqGK028468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Dec 2015 10:19:52 +0100 Received: from [135.224.196.116] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 8 Dec 2015 10:19:52 +0100 Message-ID: <5666A0B7.7050408@alcatel-lucent.com> Date: Tue, 8 Dec 2015 10:19:51 +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: <560E5C8E.8000002@alcatel-lucent.com> In-Reply-To: <560E5C8E.8000002@alcatel-lucent.com> 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-morin-bess-mvpn-fast-failover 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, 08 Dec 2015 09:19:57 -0000 WG, we have received all feedbacks regarding IPR on that draft and there is support to adopt it. Authors, please resubmit it as draft-ietf-bess-mvpn-fast-failover-00 Thank you Martin Le 02/10/2015 12:29, Martin Vigoureux a crit : > Hello working group, > > This email starts a two-week poll on adopting > draft-morin-bess-mvpn-fast-failover [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 the *16th of October*. > > Currently there is no IPR disclosed against this document. > > *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-morin-bess-mvpn-fast-failover > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > From nobody Tue Dec 8 01:27:40 2015 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 436141A92BB for ; Tue, 8 Dec 2015 01:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OP2gl8G65Eo for ; Tue, 8 Dec 2015 01:27:36 -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 943BE1A92B4 for ; Tue, 8 Dec 2015 01:27:36 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id EE95FCE3DFEC9 for ; Tue, 8 Dec 2015 09:27:32 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id tB89RQD6005573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Dec 2015 10:27:34 +0100 Received: from [135.224.196.116] (135.239.27.40) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 8 Dec 2015 10:27:30 +0100 Message-ID: <5666A27C.8030103@alcatel-lucent.com> Date: Tue, 8 Dec 2015 10:27:24 +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: <561D09B4.6040800@alcatel-lucent.com> <564FBAE2.1060909@alcatel-lucent.com> In-Reply-To: <564FBAE2.1060909@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] Need reviews of bess-multicast-damping [Was: Re: WG Last Call for draft-ietf-bess-multicast-damping-01] 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, 08 Dec 2015 09:27:38 -0000 WG, we are reiterating the request below; we would highly appreciate reviews from the WG before moving forward. Thank you M&T Le 21/11/2015 01:29, Martin Vigoureux a crit : > WG > > This WG LC has ended some time ago but without any comment on the draft. > It might not have any flaw but I'd like to have the evidence that the > document has been reviewed. > Please take a moment to read it and get back to this list to share your > views. > > Thanks > -m > > > Le 13/10/2015 15:40, Martin Vigoureux a crit : >> Hello Working Group, >> >> This email starts a Working Group Last Call on >> draft-ietf-bess-multicast-damping-01 [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, and send your comments to the list, no later than >> *27th of October*. >> >> *Coincidentally*, we are also polling for knowledge of any IPR that >> applies to draft-ietf-bess-multicast-damping, 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-multicast-damping-01 please respond to this email and >> indicate whether or not you are aware of any relevant IPR. >> >> Thank you, >> M&T >> >> [1] https://tools.ietf.org/html/draft-ietf-bess-multicast-damping-01 >> >> _______________________________________________ >> 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 Dec 8 02:33:32 2015 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 C98C81ACD59 for ; Tue, 8 Dec 2015 02:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVswTlfLcC8G for ; Tue, 8 Dec 2015 02:33:29 -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 55CD51ACD53 for ; Tue, 8 Dec 2015 02:33:29 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 22C5EA7800C88 for ; Tue, 8 Dec 2015 10:33:25 +0000 (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 tB8AXQ4V029206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Dec 2015 11:33:26 +0100 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.12]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 8 Dec 2015 11:33:26 +0100 From: "VAN DE VELDE, Gunter (Gunter)" To: "VIGOUREUX, MARTIN (MARTIN)" , "bess@ietf.org" Thread-Topic: [bess] Need reviews of bess-multicast-damping [Was: Re: WG Last Call for draft-ietf-bess-multicast-damping-01] Thread-Index: AQHRMZq0bpRTauwOhU2L9RGv1DTD+p7A5IKA Date: Tue, 8 Dec 2015 10:33:25 +0000 Message-ID: References: <561D09B4.6040800@alcatel-lucent.com> <564FBAE2.1060909@alcatel-lucent.com> <5666A27C.8030103@alcatel-lucent.com> In-Reply-To: <5666A27C.8030103@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Need reviews of bess-multicast-damping [Was: Re: WG Last Call for draft-ietf-bess-multicast-damping-01] 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, 08 Dec 2015 10:33:31 -0000 SGksDQoNCkkgaGFkIGhhZCBhIHJlYWQgdGhyb3VnaCB0aGUgZG9jdW1lbnQuIEkgdGhpbmsgaXQg aXMgYSBuaWNlIGNsZWFyIGRvY3VtZW50IHdoaWNoIGlzIHdlbGwgd3JpdHRlbiBhbmQgaXMgdG8g bWUgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLiBCZWxvdyBhcmUgYSBmZXcgdG9waWNzIHRoYXQgY3Jv c3NlZCBteSBtaW5kIHdoZW4gZGlnZ2luZyB0aHJvdWdoIHRoZSB0ZXh0LiBJIGxlYXZlIGl0IHRv IHRoZSBhdXRob3JzL1dHIHRvIGlkZW50aWZ5IGlmIHRoZXkgYXJlIGlkbml0cyBvciBtb3JlIHNl cmlvdXMgY29uc2lkZXJhdGlvbnMgd2hpY2ggbmVlZCBtb3JlIHRleHQgYmVmb3JlIHN1Ym1pdHRp bmcuDQoNClNlY3Rpb24gMy4NClRoZSBwcm9jZWR1cmVzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3Vt ZW50IGFsbG93cyB0aGUgbmV0d29yayBvcGVyYXRvcg0KICAgdG8gY29uZmlndXJlIG11bHRpY2Fz dCBWUE4gUEVzIHNvIHRoYXQgdGhleSBjYW4gZGVsYXkgdGhlIHByb3BhZ2F0aW9uDQogICBvZiBt dWx0aWNhc3Qgc3RhdGUgcHJ1bmUgbWVzc2FnZXMsIHdoZW4gZmFjZWQgd2l0aCBhIHJhdGUgb2YN CiAgIG11bHRpY2FzdCBzdGF0ZSBkeW5hbWljaXR5IGV4Y2VlZGluZyBhIGNlcnRhaW4gY29uZmln dXJhYmxlDQogICB0aHJlc2hvbGQuDQoNCg0KR1Y+IFRoaXMgaXMgdGhlIGRlbGF5IG9mIFBydW5l IHRvd2FyZHMgdGhlIFNQIHNpZGUgYW5kIHRoZSBjdXN0b21lciBzaWRlPyBNYXliZSBpbnRlcmVz dGluZyB0byBwb2ludCBvdXQgaWYgaXRzIGRhbXBlbmluZyB0b3dhcmRzIHRoZSBD4oCZc2lkZSBv ciB0aGUgUOKAmXNpZGUgb2YgdGhlIFBFLg0KDQogICBUbyBiZSBwcmFjdGljYWwsIHN1Y2ggYSBt ZWNoYW5pc20gcmVxdWlyZXMgY29uZmlndXJhYmlsaXR5LCBpbg0KICAgcGFydGljdWxhciwgbmVl ZHMgdG8gb2ZmZXIgbWVhbnMgdG8gY29udHJvbCB3aGVuIGRhbXBpbmcgaXMNCiAgIHRyaWdnZXJl ZCwgYW5kIHRvIGFsbG93IGRlbGF5aW5nIGEgbXVsdGljYXN0IHN0YXRlIFBydW5lIGZvciBhIHRp bWUNCiAgIGluY3JlYXNpbmcgd2l0aCB0aGUgY2h1cm4gb2YgdGhpcyBtdWx0aWNhc3Qgc3RhdGUu DQoNCg0KR1Y+IFdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gc3BlbGwgb3V0IHRoZSBleGFjdCB0cmFk ZS1vZmYgdGhhdCBpcyBtYWRlIGhlcmU/IER5bmFtaWNpdHkgdnMgU1Agc3RhdGUtc3RhYmlsaXR5 Pw0KDQpTZWN0aW9uIDQuMjoNClRoZXNlIG1lY2hhbmlzbXMgYXJlIG5vdCBjb25zaWRlcmVkIHN1 aXRhYmxlIHRvIG1lZXQgdGhlIGdvYWxzDQogICBzcGVsbGVkIG91dCBpbiBTZWN0aW9uIDEgPGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJlc3MtbXVsdGljYXN0LWRhbXBp bmctMDEjc2VjdGlvbi0xPiwgdGhlIG1haW4gcmVhc29ucyBiZWluZyB0aGF0Og0KDQoNCkdWPiBX aGF0IGFib3V0IGFkZGluZyBhIGxpbmUgc3BlY2lmeWluZyB0aGF0IGZpZGRsaW5nIHdpdGggdGhl c2UgdGltZXJzIGRvZXMgTm90IGdpdmUgaW5kZXBlbmRlbnQgY29udHJvbCB0byB0aGUgU1AgdG8g Y29udHJvbCBCYWNrYm9uZSBzdGF0ZSBkeW5hbWljaXR5Pw0KDQpTZWN0aW9uNS4xOg0KRmlndXJl LW9mLW1lcml0OiDigKYuDQoNCkdWPiBNYXliZSBhbiBleHBsYW5hdGlvbiB3aHkgZXhwb25lbnRp YWwgYmFjayBvZmYgaXMgdXNlZCBjb21wYXJlZCB0byBhIHNpbXBsZSBsaW5lYXIgdHJpZ2dlciB3 b3VsZCBiZSBpbnRlcmVzdGluZy4gV2hpbGUgSSBrbm93IGV4cG9uZW50aWFsIGJhY2sgb2ZmIGFs dG/igJlzIGFyZSB1c2VkIGEgbG90IGFuZCBzZWUgdGhlIGJlbmVmaXQgb2YgYWRhcHRpdmUgYmFj ay1vZmYsIGl0IGlzIG1heWJlIGludGVyZXN0aW5nIHRvIGRvY3VtZW50IGluIHRoZSBkcmFmdCBv ciBtYWtlIGEgcmVmZXJlbmNlIHRvIGEgZGVzY3JpcHRpb24gd2h5IGV4cG9uZW50aWFsIGJhY2sg b2ZmIGlzIHNlbGVjdGVkPw0KDQpTZWN0aW9uIDYuMjoNCkdWPiBJbiB0aGUgcmVhbG0gb2YgU0RO IGFuZCBFVlBOIEkgc2VlIG1hbnkgb2YgdGhlc2UgRVZQTuKAmXMgYmUgZHluYW1pYyBpbiBsb2Nh dGlvbiBhbmQgZXhpc3RlbmNlIChzcGlu4oCZZCB1cCBvbi1kZW1hbmQpIGluIHRoZSBEQ+KApiBU aGVyZSBhcmUgZXZlbiBkcmFmdHMgdG8gbWFrZSBhbiBFdGhlcm5ldCBmdWxseSB2aXJ0dWFsIGJ5 IG1lYW5zIG9mIFZpcnR1YWwgRXRoZXJuZXQgU2VnbWVudHPigKYgSSB3YXMgd29uZGVyaW5nIGhv dyB0aGlzIHByb3Bvc2FsIGltcGFjdHMgdGhlIG9wZXJhdGlvbiB3aXRoaW4gdGhpcyB0ZWNobm9s b2d5IHJlYWxtLiBNeSBmaXJzdCBndWVzcyB3aWxsIGJlIG1vcmUgYXMgYWRkaXRpb25hbCAobW9y ZSBhcyBhdmVyYWdlKSBCVyBjb25zdW1wdGlvbiBhdCB0aGUgYmVuZWZpdCBvZiBsZXNzIHN0YXRl IGR5bmFtaWNpdHkgaW5zaWRlIHRoZSBjb3Jl4oCmIE1heWJlIGRpZmZlcmVudCBzZXQgb2YgY29u ZmlndXJlZCBwYXJhbWV0ZXJzIGZvciB0aGlzIGVudmlyb25tZW50IGNhbiBiZSBzdWdnZXN0ZWQ/ DQoNClNlY3Rpb24gNy4xOg0KICAgSW4gdGhlIGNvbnRleHQgb2YgbXVsdGljYXN0IFZQTnMsIHRo ZXNlIHByb2NlZHVyZXMgd291bGQgYmUgZW5hYmxlZA0KICAgb24gUEUgcm91dGVycy4gIEFkZGl0 aW9uYWxseSBpbiB0aGUgY2FzZSBvZiBDLW11bHRpY2FzdCByb3V0aW5nIGJhc2VkDQogICBvbiBC R1AgZXh0ZW5zaW9ucyAoW1JGQzY1MTQgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2 NTE0Pl0pIHRoZXNlIHByb2NlZHVyZXMgY2FuIGJlIGVuYWJsZWQgb24NCkFTQlJzLCBhbmQgcG9z c2libHkgUm91dGUgUmVmbGVjdG9ycyBhcyB3ZWxsLg0KDQpHVj4gV2hhdCBkb2VzIOKAnHBvc3Np Ymx54oCdIG1lYW4/IENhbiBpdCBiZSB1c2VkPyBPciBjYW4gaXQgbm90IGJlIHVzZWQ/IERvZXMg dGhlIHBvc3NpYmxlIG1lYW5zIHRoYXQgdGhlcmUgYXJlIHNvbWUgY29uc2lkZXJhdGlvbnM/DQoN ClNlY3Rpb24gOTogU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIA0KR1Y+IEkgYWdyZWUgd2l0aCB0 aGUgdGV4dC4uIE9uZSBpdGVtIGlzIHRoYXQgY2FzdCBtYXkgc3RyZWFtIGxvbmdlciB0byBwb2lu dHMgaW4gdGhlIG5ldHdvcmsgaXQgaXMgbm90LWRlc2lyZWQuIElzIHRoZXJlIHBvdGVudGlhbCBm b3IgbGVha2VkIG11bHRpY2FzdCBzdHJlYW1zIGR1ZSB0byBoaWdobHkgZHluYW1pYyBzZXJ2aWNl IFZQTnMgd2hpY2ggbWF5IG9mIGNvbnZlcmdlZCBmYXN0ZXIgYXMgdGhlIE11bHRpY2FzdCBwcnVu aW5nIGR1ZSB0byBkYW1wZW5pbmc/DQoNCkJlIHdlbGwsDQpHLw0KDQoNCg0KDQpPbiAwOC8xMi8x NSAxMDoyNywgIkJFU1Mgb24gYmVoYWxmIG9mIE1hcnRpbiBWaWdvdXJldXgiIDxiZXNzLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQu Y29tPiB3cm90ZToNCg0KPldHLA0KPg0KPndlIGFyZSByZWl0ZXJhdGluZyB0aGUgcmVxdWVzdCBi ZWxvdzsgd2Ugd291bGQgaGlnaGx5IGFwcHJlY2lhdGUgcmV2aWV3cyANCj5mcm9tIHRoZSBXRyBi ZWZvcmUgbW92aW5nIGZvcndhcmQuDQo+DQo+VGhhbmsgeW91DQo+TSZUDQo+DQo+TGUgMjEvMTEv MjAxNSAwMToyOSwgTWFydGluIFZpZ291cmV1eCBhIMOpY3JpdCA6DQo+PiBXRw0KPj4NCj4+IFRo aXMgV0cgTEMgaGFzIGVuZGVkIHNvbWUgdGltZSBhZ28gYnV0IHdpdGhvdXQgYW55IGNvbW1lbnQg b24gdGhlIGRyYWZ0Lg0KPj4gSXQgbWlnaHQgbm90IGhhdmUgYW55IGZsYXcgYnV0IEknZCBsaWtl IHRvIGhhdmUgdGhlIGV2aWRlbmNlIHRoYXQgdGhlDQo+PiBkb2N1bWVudCBoYXMgYmVlbiByZXZp ZXdlZC4NCj4+IFBsZWFzZSB0YWtlIGEgbW9tZW50IHRvIHJlYWQgaXQgYW5kIGdldCBiYWNrIHRv IHRoaXMgbGlzdCB0byBzaGFyZSB5b3VyDQo+PiB2aWV3cy4NCj4+DQo+PiBUaGFua3MNCj4+IC1t DQo+Pg0KPj4NCj4+IExlIDEzLzEwLzIwMTUgMTU6NDAsIE1hcnRpbiBWaWdvdXJldXggYSDDqWNy aXQgOg0KPj4+IEhlbGxvIFdvcmtpbmcgR3JvdXAsDQo+Pj4NCj4+PiBUaGlzIGVtYWlsIHN0YXJ0 cyBhIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uDQo+Pj4gZHJhZnQtaWV0Zi1iZXNzLW11bHRp Y2FzdC1kYW1waW5nLTAxIFsxXSB3aGljaCBpcyBjb25zaWRlcmVkIG1hdHVyZSBhbmQNCj4+PiBy ZWFkeSBmb3IgYSBmaW5hbCB3b3JraW5nIGdyb3VwIHJldmlldy4NCj4+Pg0KPj4+IFBsZWFzZSBy ZWFkIHRoZSBkb2N1bWVudCBpZiB5b3UgaGF2ZW4ndCByZWFkIHRoZSBtb3N0IHJlY2VudA0KPj4+ IHZlcnNpb24geWV0LCBhbmQgc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBubyBsYXRl ciB0aGFuDQo+Pj4gKjI3dGggb2YgT2N0b2JlciouDQo+Pj4NCj4+PiAqQ29pbmNpZGVudGFsbHkq LCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0DQo+Pj4g YXBwbGllcyB0byBkcmFmdC1pZXRmLWJlc3MtbXVsdGljYXN0LWRhbXBpbmcsIHRvIGVuc3VyZSB0 aGF0IElQUiBoYXMNCj4+PiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJ UFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksDQo+Pj4gMzY2OSBhbmQgNTM3OCBmb3IgbW9y ZSBkZXRhaWxzKS4NCj4+Pg0KPj4+ICpJZiogeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBh dXRob3Igb3IgY29udHJpYnV0b3Igb2YNCj4+PiBkcmFmdC1pZXRmLWJlc3MtbXVsdGljYXN0LWRh bXBpbmctMDEgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCBhbmQNCj4+PiBpbmRpY2F0ZSB3 aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuDQo+Pj4NCj4+ PiBUaGFuayB5b3UsDQo+Pj4gTSZUDQo+Pj4NCj4+PiBbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYmVzcy1tdWx0aWNhc3QtZGFtcGluZy0wMQ0KPj4+DQo+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBCRVNTIG1h aWxpbmcgbGlzdA0KPj4+IEJFU1NAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2Jlc3MNCj4+Pg0KPj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEJFU1MgbWFpbGluZyBsaXN0DQo+PiBC RVNTQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jl c3MNCj4+DQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+QkVTUyBtYWlsaW5nIGxpc3QNCj5CRVNTQGlldGYub3JnDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZXNzDQo= From nobody Tue Dec 8 23:48:08 2015 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 D9D7A1AD272; Tue, 8 Dec 2015 23:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5GteNaugO1u; Tue, 8 Dec 2015 23:48:02 -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 2F5561AD289; Tue, 8 Dec 2015 23:48:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFE84175; Wed, 09 Dec 2015 07:47:58 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Dec 2015 07:47:57 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.64]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Wed, 9 Dec 2015 15:47:49 +0800 From: Xuxiaohu To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT) Thread-Index: AQHRLdaOLk8nhORYXUKrCN/X2riedp66D2jwgAAf9ICABKhN0IAAFESAgANffzA= Date: Wed, 9 Dec 2015 07:47:48 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB547A7@NKGEML512-MBS.china.huawei.com> References: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53D79@NKGEML512-MBS.china.huawei.com> <56617BAD.6070906@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB54209@NKGEML512-MBS.china.huawei.com> <566574D9.6030202@cs.tcd.ie> In-Reply-To: <566574D9.6030202@cs.tcd.ie> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5667DCAF.0016, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.64, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a31d151a71e39ce19f31b3d9f3ecb57d Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" , "aretana@cisco.com" Subject: Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-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: Wed, 09 Dec 2015 07:48:07 -0000 SGkgU3RlcGhlbiwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGVw aGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXQ0KPiBTZW50OiBN b25kYXksIERlY2VtYmVyIDA3LCAyMDE1IDg6MDAgUE0NCj4gVG86IFh1eGlhb2h1OyBUaGUgSUVT Rw0KPiBDYzogZHJhZnQtaWV0Zi1iZXNzLXZpcnR1YWwtc3VibmV0QGlldGYub3JnOyBiZXNzLWNo YWlyc0BpZXRmLm9yZzsNCj4gbWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb207IGJl c3NAaWV0Zi5vcmc7IGFyZXRhbmFAY2lzY28uY29tDQo+IFN1YmplY3Q6IFJlOiBTdGVwaGVuIEZh cnJlbGwncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtYmVzcy12aXJ0dWFsLXN1Ym5ldC0wNjogKHdp dGgNCj4gRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IA0KPiBIaXlhLA0KPiANCj4gT24gMDcv MTIvMTUgMDM6MTUsIFh1eGlhb2h1IHdyb3RlOg0KPiA+IEhpIFN0ZXBoZW4sDQo+ID4NCj4gPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogU3RlcGhlbiBGYXJyZWxsDQo+ID4+IFtt YWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0gU2VudDogRnJpZGF5LCBEZWNlbWJlciAw NCwgMjAxNQ0KPiA+PiA3OjQwIFBNIFRvOiBYdXhpYW9odTsgVGhlIElFU0cgQ2M6DQo+ID4+IGRy YWZ0LWlldGYtYmVzcy12aXJ0dWFsLXN1Ym5ldEBpZXRmLm9yZzsgYmVzcy1jaGFpcnNAaWV0Zi5v cmc7DQo+ID4+IG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQuY29tOyBiZXNzQGlldGYu b3JnOyBhcmV0YW5hQGNpc2NvLmNvbQ0KPiA+PiBTdWJqZWN0OiBSZTogU3RlcGhlbiBGYXJyZWxs J3MgRGlzY3VzcyBvbg0KPiA+PiBkcmFmdC1pZXRmLWJlc3MtdmlydHVhbC1zdWJuZXQtMDY6ICh3 aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4+DQo+ID4+DQo+ID4+IEhpeWEsDQo+ID4+DQo+ ID4+IE9uIDA0LzEyLzE1IDAyOjA4LCBYdXhpYW9odSB3cm90ZToNCj4gPj4+IEhpIFN0ZXBoZW4s DQo+ID4+Pg0KPiA+Pj4gVGhhbmsgYSBsb3QgZm9yIHlvdXIgRElTQ1VTUy4gSSBmdWxseSBhZ3Jl ZSB3aXRoIHlvdSB0aGF0IHNlbnNpdGl2ZQ0KPiA+Pj4gdHJhZmZpYyBiZWluZyBoYW5kbGVkIGJ5 IFZNcyBzaG91bGQgYmUgZW5jcnlwdGVkIHdoZW4gdHJhdmVyc2luZw0KPiA+Pj4gYWNyb3NzIHRo ZSBJbnRlcm5ldCBvciBldmVuIFNQIG5ldHdvcmtzLiBTaW1pbGFybHksIEkgdGhpbmsgeW91DQo+ ID4+PiB3b3VsZCBhbHNvIGFncmVlIHRoYXQgc2Vuc2l0aXZlIHRyYWZmaWMgb2YgVlBOIGNsaWVu dHMgc2hvdWxkIGJlDQo+ID4+PiBlbmNyeXB0ZWQgYXMgd2VsbCBpbiB0aGUgZXhpc3RpbmcgTVBM Uy9CR1AgSVAgVlBOIFtSRkM0MzY0XQ0KPiA+Pj4gc2NlbmFyaW8uIEhlbmNlLCB0aGUgc2VjdXJp dHkgcmVxdWlyZW1lbnQgc2hvdWxkIGJlIHRoZSBzYW1lIGZvcg0KPiA+Pj4gUkZDNDM2NCBhbmQg dGhpcyBkcmFmdCwgSU1ITy4gVGhlcmVmb3JlLCBpbiB0aGUgU2VjdXJpdHkNCj4gPj4+IENvbnNp ZGVyYXRpb24gc2VjdGlvbiBvZiB0aGlzIGRyYWZ0LCBpdCBzYWlkICIgU2luY2UgdGhlIEJHUC9N UExTIElQDQo+ID4+PiBWUE4gc2lnbmFsaW5nIGlzIHJldXNlZCB3aXRob3V0IGFueSBjaGFuZ2Us IHRob3NlIHNlY3VyaXR5DQo+ID4+PiBjb25zaWRlcmF0aW9ucyBhcyBkZXNjcmliZWQgaW4gW1JG QzQzNjRdIGFyZSBhcHBsaWNhYmxlIHRvIHRoaXMNCj4gPj4+IGRvY3VtZW50LiAiDQo+ID4+Pg0K PiA+Pj4gQW55IGZ1cnRoZXIgY29tbWVudHMgYXJlIG1vcmUgdGhhbiB3ZWxjb21lLg0KPiA+Pg0K PiA+PiBXZWxsLCBteSBmdXJ0aGVyIGNvbW1lbnQgaXMgdGhhdCB0aGUgYWJvdmUgZG9lc24ndCBz ZWVtIGFkZXF1YXRlIGF0DQo+ID4+IHRoaXMgcG9pbnQgaW4gdGltZSAodG8gbWU6LSkNCj4gPj4N Cj4gPj4gSW4gMjAwNiwgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG9mIFJGQzQzNjQgc2Fp ZDoNCj4gPj4NCj4gPj4gIiBDcnlwdG9ncmFwaGljIHByaXZhY3kgaXMgbm90IHByb3ZpZGVkIGJ5 IHRoaXMgYXJjaGl0ZWN0dXJlLCBub3IgYnkNCj4gPj4gRnJhbWUgUmVsYXkgb3IgQVRNIFZQTnMu ICBUaGVzZSBhcmNoaXRlY3R1cmVzIGFyZSBhbGwgY29tcGF0aWJsZSB3aXRoDQo+ID4+IHRoZSB1 c2Ugb2YgY3J5cHRvZ3JhcGh5IG9uIGEgQ0UtQ0UgYmFzaXMsIGlmIHRoYXQgaXMgZGVzaXJlZC4N Cj4gPj4NCj4gPj4gVGhlIHVzZSBvZiBjcnlwdG9ncmFwaHkgb24gYSBQRS1QRSBiYXNpcyBpcyBm b3IgZnVydGhlciBzdHVkeS4iDQo+ID4+DQo+ID4+IEluIDIwMTUsIHdlIGtub3cgdGhhdCBwZW9w bGUsIGNhbiwgc2hvdWxkLCBhbmQgZG8sIHR1cm4gb24gY3J5cHRvDQo+ID4+IGJldHdlZW4gZGF0 YSBjZW50cmVzLg0KPiA+Pg0KPiA+PiBUb2RheSdzIHNpdHVhdGlvbiBpcyBub3QgMjAwNidzIGFu ZCB0aGF0IEkgdGhpbmsgbmVlZHMgdG8gYmUgc3RhdGVkDQo+ID4+IGFuZCB0aGlzIGRvY3VtZW50 IHNlZW1zIGxpa2UgYSBmaW5lIHBsYWNlIHRvIGRvIHRoYXQuIEkgd291bGQgc3RpbGwNCj4gPj4g dGhpbmsgdGhhdCB3ZXJlIHRoZSBzdGF0ZW1lbnQgY2xlYXJseSBtYWRlIGVsc2V3aGVyZS4NCj4g Pg0KPiA+IEhvdyBhYm91dCBhZGRpbmcgdGhlIGZvbGxvd2luZyB0ZXh0IGludG8gdGhlIGN1cnJl bnQgc2VjdXJpdHkNCj4gPiBjb25zaWRlcmF0aW9uOg0KPiA+DQo+ID4gIlRoZSB1c2Ugb2YgY3J5 cHRvZ3JhcGh5IG9uIGEgUEUtUEUgYmFzaXMgaXMgcmVsYXRlZCB0byB0aGUgc3BlY2lmaWMNCj4g PiB0dW5uZWwgdGVjaG5vbG9neSB3aGljaCBpcyB1c2VkIGJldHdlZW4gUEVzLiBGb3IgaW5zdGFu Y2UsIGlmIE1QTFMNCj4gPiBMU1BzIGFyZSB1c2VkIGJldHdlZW4gUEUgcm91dGVycywgdGhlIGFw cHJvYWNoIGFzIGRlc2NyaWJlZCBpbg0KPiA+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1tcGxzLW9wcG9ydHVuaXN0aWMtZW5jcnlwdC0wMCkNCj4gPiBzaG91bGQgYmUg Y29uc2lkZXJlZCwgYW5kIGlmIElQLWJhc2UgdHVubmVscyBmb3IgdHJhbnNwb3J0aW5nIE1QTFMg YXJlDQo+ID4gdXNlZCBiZXR3ZWVuIFBFIHJvdXRlcnMsIHRob3NlIElQLWJhc2VkIHR1bm5lbHMg c2hvdWxkIGJlIHNlY3VyZWQgd2l0aA0KPiA+IElQc2VjIG9yIERUTFMgKGZvciBtb3JlIGRldGFp bHMsIHBsZWFzZSByZWZlciB0byB0aGUgY29ycmVzcG9uZGluZw0KPiA+IHNwZWNpZmljYXRpb24g b2YgYSBwYXJ0aWN1bGFyIElQLWJhc2VkIHR1bm5lbCB0ZWNobm9sb2d5KS4gT2YgY291cnNlLA0K PiA+IGlmIHRoZSBkYXRhIHRyYWZmaWMgaGFzIGJlZW4gZW5jcnlwdGVkIGJlZm9yZSBhcnJpdmlu ZyBhdCB0aGUgaW5ncmVzcw0KPiA+IFBFLCB0aGUgdXNlIG9mIGNyeXB0b2dyYXBoeSBvbiBhIFBF LVBFIGJhc2lzIG1heSBub3QgYmUgbmVjZXNzYXJ5IGFueQ0KPiA+IG1vcmUuIg0KPiANCj4gVGhh dCdzIGRlZmluaXRlbHkgYWxvbmcgdGhlIHJpZ2h0IGxpbmVzIGJ1dCBJIHRoaW5rIG5lZWRzIGEg ZmV3IHR3ZWFrcy4uLg0KPiANCj4gRmlyc3QsIGV2ZW4gdGhvdWdoIEknbSBhbiBhdXRob3IgSSB0 aGluayB5b3UncmUgcHV0dGluZyB0b28gbXVjaCBlbXBoYXNpcyBvbg0KPiB0aGUgTVBMUy1PUyBz dHVmZiAtIHdlIGRvbid0IGhvbmVzdGx5IGtub3cgKHlldCkgaWYgdGhhdCBpcyBzb21ldGhpbmcg dGhhdCdsbCBzZWUNCj4gcmVhbCBkZXBsb3ltZW50LiBBbmQgSSdtIHRvbGQgTUFDc2VjIGlzIGFs c28gdXNlZCBmb3IgREMtREMgc2VjdXJpdHkgc28NCj4gcmVmZXJlbmNpbmcgaXQgYXMgd2VsbCBh cyBJUHNlYyB3b3VsZCBiZSBnb29kLg0KPiANCj4gSSdtIG5vdCBzdXJlIHdoYXQgRFRMUyBiYXNl ZCBtZWNoYW5pc20gY2FuIGJlIHJlZmVyZW5jZWQgaGVyZSB0aG91Z2ggb25lDQo+IGNvdWxkIG9m IGNvdXJzZSBleGlzdCBvciBiZSBkZWZpbmVkIGluIGZ1dHVyZS4gSSdkIHNheSBpZiB0aGVyZSdz IG5vIGdvb2QgcmVmZXJlbmNlDQo+IGZvciBzdWNoLCB0aGVuIG1heWJlIHRoYXQncyBiZXN0IG9t aXR0ZWQgZm9yIG5vdy4gSWYgdGhlcmUncyBhDQo+IGdvb2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM3MjU4ZCByZWZlcmVuY2UgdGhlbiBhZGRpbmcgaXQgd291bGQgYmUNCj4gZ29vZC4N Cj4gDQo+IEFuZCB5b3VyIHRleHQgYWxzbyBhdm9pZHMgcmVjb21tZW5kaW5nIHNlY3VyaW5nIHRy YWZmaWMgYmV0d2VlbiBkYXRhIGNlbnRyZXMsDQo+IHdoaWNoIEkgdGhpbmsgaXMgbmVlZGVkLCBh bmQgaXMgdGhlIG1haW4gcG9pbnQgZm9yIHRoaXMgdGV4dCAoZm9yIHRoaXMgaW5mb3JtYXRpb25h bA0KPiBkb2N1bWVudCkuDQo+IA0KPiBTbyBtYXliZSBzb21ldGhpbmcgbW9yZSBsaWtlOg0KPiAN Cj4gIkludGVyIGRhdGEtY2VudHJlIHRyYWZmaWMgb2Z0ZW4gY2FycmllcyBoaWdobHkgc2Vuc2l0 aXZlIGluZm9ybWF0aW9uIGF0IGhpZ2hlcg0KPiBsYXllcnMgdGhhdCBpcyBub3QgZGlyZWN0bHkg dW5kZXJzdG9vZA0KPiAocGFyc2VkKSB3aXRoaW4gYW4gZWdyZXNzIG9yIGluZ3Jlc3MgUEUuIEZv ciBleGFtcGxlLCBtaWdyYXRpbmcgYSBWTSB3aWxsIG9mdGVuDQo+IG1lYW4gbW92aW5nIHByaXZh dGUga2V5cyBhbmQgb3RoZXIgc2Vuc2l0aXZlIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24uIEZv cg0KPiB0aGlzIHJlYXNvbiBpbnRlciBkYXRhLWNlbnRyZSB0cmFmZmljIFNIT1VMRCBhbHdheXMg YmUgcHJvdGVjdGVkIGZvciBib3RoDQo+IGNvbmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IHVz aW5nIGEgc3Ryb25nIHNlY3VyaXR5IG1lY2hhbmlzbSBzdWNoIGFzIElQc2VjIFsxXQ0KPiBvciBN QUNzZWMgWzJdIEluIGZ1dHVyZSBpdCBtYXkgYmUgZmVhc2libGUgdG8gcHJvdGVjdCB0aGF0IHRy YWZmaWMgd2l0aGluIHRoZSBNUExTDQo+IGxheWVyIFszXSB0aG91Z2ggYXQgdGhlIHRpbWUgb2Yg d3JpdGluZyB0aGUgbWVjaGFuaXNtIGZvciB0aGF0IGlzIG5vdCBzdWZmaWNpZW50bHkNCj4gbWF0 dXJlIHRvIHJlY29tbWVuZC4gRXhhY3RseSBob3cgc3VjaCBzZWN1cml0eSBtZWNoYW5pc21zIGFy ZSBkZXBsb3llZCB3aWxsDQo+IHZhcnkgZnJvbSBjYXNlIHRvIGNhc2UsIHNvIHNlY3VyaW5nIHRo ZSBpbnRlciBkYXRhLWNlbnRyZSB0cmFmZmljIG1heSBvciBtYXkgbm90DQo+IGludm9sdmUgZGVw bG95aW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMgb24gdGhlIGluZ3Jlc3MvZWdyZXNzIFBFcyBvciBm dXJ0aGVyDQo+ICJpbnNpZGUiIHRoZSBkYXRhIGNlbnRyZXMgY29uY2VybmVkLiBOb3RlIHRob3Vn aCB0aGF0IGlmIHNlY3VyaXR5IGlzIG5vdCBkZXBsb3llZA0KPiBvbiB0aGUgZWdyZXNzL2luZ3Jl c3MgUEVzIHRoZXJlIGlzIGEgc3Vic3RhbnRpYWwgcmlzayB0aGF0IHNvbWUgc2Vuc2l0aXZlIHRy YWZmaWMNCj4gbWF5IGJlIHNlbnQgaW4gY2xlYXIgYW5kIHRoZXJlZm9yZSBiZSB2dWxuZXJhYmxl IHRvIHBlcnZhc2l2ZSBtb25pdG9yaW5nIFs0XSBvcg0KPiBvdGhlciBhdHRhY2tzLiINCg0KVGhh bmtzIGEgbG90IGZvciB5b3VyIHN1Z2dlc3RlZCB0ZXh0LiBJZiBub2JvZHkgb2JqZWN0IHRoZSBh Ym92ZSB0ZXh0LCBJIHdpbGwgYWRkIGl0IGluIHRoZSBuZXh0IHJldmlzaW9uLg0KDQpCZXN0IHJl Z2FyZHMsDQpYaWFvaHUNCg0KPiANCj4gWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM0MzAxDQo+IFsyXSBodHRwOi8vd3d3LmllZWU4MDIub3JnLzEvcGFnZXMvODAyLjFhZS5odG1s DQo+IFszXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tcGxzLW9wcG9y dHVuaXN0aWMtZW5jcnlwdA0KPiBbNF0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcy NTgNCj4gDQo+IE5vdGUgLSBJJ20gbm90IHN1cmUgaWYgWzJdIGlzIHRoZSBiZXN0IHJlZmVyZW5j ZSBmb3IgTUFDc2VjLCBidXQgSSBiZXQgc29tZSBvZiB5b3UNCj4gd2lsbCBrbm93IGJldHRlci4N Cj4gDQo+IElmIHlvdSB3YW50IHRvIHMvU0hPVUxEL01VU1QvIGFib3ZlIEknZCBiZSBmaW5lIHdp dGggdGhhdC4NCj4gQW5kIGlmIHRoaXMgZG9jdW1lbnQgaXNuJ3QgdXNpbmcgMjExOSB0ZXJtaW5v bG9neSAoSSBmb3JnZXQpIHRoYXQncyBhbHNvIGZpbmUganVzdA0KPiBzL1NIT1VMRC9zaG91bGQv IChvciAibXVzdCI6LSkuDQo+IA0KPiBDaGVlcnMsDQo+IFMuDQo+IA0KPiANCj4gDQo+IA0KPiA+ DQo+ID4gQmVzdCByZWdhcmRzLCBYaWFvaHUNCj4gPg0KPiA+PiBDaGVlcnMsIFMuDQo+ID4+DQo+ ID4+DQo+ID4+Pg0KPiA+Pj4gQmVzdCByZWdhcmRzLCBYaWFvaHUNCj4gPj4+DQo+ID4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogU3RlcGhlbiBGYXJyZWxsDQo+ID4+Pj4gW21h aWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXSBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIg MDMsDQo+ID4+Pj4gMjAxNSAxMDoyNiBQTSBUbzogVGhlIElFU0cgQ2M6DQo+ID4+Pj4gZHJhZnQt aWV0Zi1iZXNzLXZpcnR1YWwtc3VibmV0QGlldGYub3JnOyBhcmV0YW5hQGNpc2NvLmNvbTsNCj4g Pj4+PiBiZXNzLWNoYWlyc0BpZXRmLm9yZzsgbWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2Vu dC5jb207DQo+ID4+Pj4gYmVzc0BpZXRmLm9yZyBTdWJqZWN0OiBTdGVwaGVuIEZhcnJlbGwncyBE aXNjdXNzIG9uDQo+ID4+Pj4gZHJhZnQtaWV0Zi1iZXNzLXZpcnR1YWwtc3VibmV0LTA2OiAod2l0 aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+Pj4+DQo+ID4+Pj4gU3RlcGhlbiBGYXJyZWxsIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+Pj4+IGRyYWZ0 LWlldGYtYmVzcy12aXJ0dWFsLXN1Ym5ldC0wNjogRGlzY3Vzcw0KPiA+Pj4+DQo+ID4+Pj4gV2hl biByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVw bHkgdG8NCj4gPj4+PiBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuIChGZWVsIGZyZWUgdG8NCj4gPj4+PiBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFy YWdyYXBoLCBob3dldmVyLikNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gUGxlYXNlIHJlZmVyIHRv DQo+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0 ZXJpYS5odG1sIGZvciBtb3JlDQo+ID4+Pj4gaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNT IGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gVGhlIGRvY3Vt ZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZA0KPiA+ Pj4+IGhlcmU6DQo+ID4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1iZXNzLXZpcnR1YWwtc3VibmV0Lw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+ DQo+ID4+Pj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4gLQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4g RElTQ1VTUzoNCj4gPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4gLS0NCj4gPj4+Pg0KPiA+Pj4+DQo+ IC0NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+PiAoMSkgU3VyZWx5IGV4dGVu ZGluZyBhIHN1Ym5ldCBmcm9tIG9uZSB0byBtYW55IGRhdGEgY2VudHJlcyBzaG91bGQNCj4gPj4g b25seSBiZQ0KPiA+Pj4+IGRvbmUgaWYgaW50ZXItZGF0YS1jZW50cmUgdHJhZmZpYyBpcyBhbGwg ZW5jcnlwdGVkIGFuZA0KPiA+Pj4+IGF1dGhlbnRpY2F0ZWQ/IEkgZG9uJ3QgZ2V0IHdoeSB0aGVy ZSBpc24ndCBhIE1VU1QtbGlrZSBzdGF0ZW1lbnQNCj4gPj4+PiBoZXJlIGZvciBzdWNoIHByb3Rl Y3Rpb24sIGFuZCBnb2luZyBhIGJpdCBmdXJ0aGVyLCB3aHkgc29tZQ0KPiA+Pj4+IGludGVyb3Bl cmFibGUgZm9ybSBvZiBwcm90ZWN0aW9uIGZvciBzdWNoIHRyYWZmaWMgKGUuZy4gSVBzZWMsDQo+ ID4+Pj4gTUFDc2VjKSBpc24ndCByZWNvbW1lbmRlZCBhcyBiZWluZyBNVEkgaW4gc3VjaCBjYXNl cy4gVGhlIGh1Z2UNCj4gPj4+PiB2YXJpZXR5IG9mIHBvdGVudGlhbGx5IGFuZCBhY3R1YWxseSBz ZW5zaXRpdmUgdHJhZmZpYyBiZWluZyBoYW5kbGVkDQo+ID4+Pj4gYnkgVk1zIHRoZXNlIGRheXMg YW5kIHdoaWNoIG91Z2h0IG5vdCBiZSwgYW5kIHByb2JhYmx5IGlzIG5vdCwNCj4gPj4+PiB1bmRl cnN0b29kIGJ5IGZvbGtzIGRvaW5nIHJvdXRpbmcgc2VlbXMgdG8gdmVyeSBzdHJvbmdseSBpbXBs eSB0aGF0DQo+ID4+Pj4gc3VjaCBwcm90ZWN0aW9uIHNob3VsZCBpbiBmYWN0IGJlIHR1cm5lZCBv biBhbGwgb2YgdGhlIHRpbWUuIChCdXQNCj4gPj4+PiBzdGF0aW5nIHRoYXQgd291bGQgYmUgZ29p bmcgYmV5b25kIGN1cnJlbnQgSUVURiBjb25zZW51cyBvbiBNVEkNCj4gPj4+PiBzZWN1cml0eSBh cyBleHByZXNzZWQgaW4gQkNQNjEuICBJdCdkIHN0aWxsIGJlIGEgZ29vZCBpZGVhIEkgdGhpbmsN Cj4gPj4+PiB0aG91Z2guKQ0KPiA+Pj4+DQo+ID4+Pj4gKDIpIEknbSBndWVzc2luZyBvbmUgcmVh Y3Rpb24gdG8gdGhlIGFib3ZlIGRpc2N1c3MgcG9pbnQgY291bGQgYmUNCj4gPj4+PiAic3VyZSwg YnV0IHRoaXMgaXMgdGhlIHdyb25nIGRvY3VtZW50LiIgSW4gdGhhdCBjYXNlLCBwbGVhc2Ugc2hv dw0KPiA+Pj4+IG1lIHRoZSByaWdodCBkb2N1bWVudCBhbmQgdGhlbiB0ZWxsIG1lIHdoeSBhIHJl ZmVyZW5jZSB0byB0aGF0IGlzDQo+ID4+Pj4gbm90IG5lZWRlZCBoZXJlLg0KPiA+Pj4+DQo+ID4+ Pj4gTm90ZTogbm9uZSBvZiB0aGUgYWJvdmUgaXMgYWJvdXQgUkZDMjExOSBNVVNUL1NIT1VMRCBl dGMgdGVybXMgZXZlbg0KPiA+Pj4+IHRob3VnaCBJIHVzZSB0aGVtIGFib3ZlLiBKdXN0IG5vcm1h bCBlbmdsaXNoIHRoYXQgbWFrZXMgdGhlIHBvaW50DQo+ID4+Pj4gd291bGQgYmUgZmluZS4NCj4g Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+IC0tDQo+ID4+Pj4NCj4gPj4+ Pg0KPiAtDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+PiBDT01NRU5UOg0KPiA+Pj4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPj4+PiAtLQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gLQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0K PiA+Pj4+DQo+ID4+IFRoZSBzZWNkaXItcmV2aWV3IFsxXSByYWlzZWQgYSBzaW1pbGFyIGlzc3Vl LCBidXQgSSBkb24ndCB0aGluaw0KPiA+Pj4+IHRoZSByZXNwb25zZSB0byB0aGF0IGlzIHN1ZmZp Y2llbnQgcmVhbGx5LiAoVGhlIHNlY2RpciByZXZpZXdlciBkaWQNCj4gPj4+PiB0aGluayBzby4p DQo+ID4+Pj4NCj4gPj4+PiBbMV0NCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL3NlY2Rpci9jdXJyZW50L21zZzA2MjE3Lmh0bWwNCj4gPj4+Pg0KPiA+Pj4NCg== From nobody Wed Dec 9 22:53:44 2015 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 981F81B31DC; Wed, 9 Dec 2015 22:53:42 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151210065342.12225.39868.idtracker@ietfa.amsl.com> Date: Wed, 09 Dec 2015 22:53:42 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-virtual-subnet-07.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 06:53:42 -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 Working Group of the IETF. Title : Virtual Subnet: A BGP/MPLS IP VPN-based Subnet Extension Solution Authors : Xiaohu Xu Christian Jacquenet Robert Raszuk Truman Boyes Brendan Fee Filename : draft-ietf-bess-virtual-subnet-07.txt Pages : 15 Date : 2015-12-09 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-virtual-subnet-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-virtual-subnet-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 9 23:15:26 2015 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 AF41D1B322D; Wed, 9 Dec 2015 23:15:22 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151210071522.23757.17672.idtracker@ietfa.amsl.com> Date: Wed, 09 Dec 2015 23:15:22 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-mvpn-fast-failover-00.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 07:15:22 -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 Working Group of the IETF. Title : Multicast VPN fast upstream failover Authors : Thomas Morin Robert Kebler Filename : draft-ietf-bess-mvpn-fast-failover-00.txt Pages : 17 Date : 2015-12-09 Abstract: This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the upstream PE for a VPN multicast flow, and extending BGP MVPN routing so that a C-multicast route can be advertized toward a standby upstream PE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-mvpn-fast-failover-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 10 02:05:52 2015 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 7ED131A890F; Thu, 10 Dec 2015 02:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 wcgaoDfrNumT; Thu, 10 Dec 2015 02:05:45 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A473C1A88BC; Thu, 10 Dec 2015 02:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2Rz7qjaFz6nb+B3tzsW2yd+rMI2MKnoKnrenjJ76BKk=; b=aDBYccvUINT8FAuSxGeLXbNC9zh3CHhExaQGlpRWq7lngSnyBvnxEZUOa7yl0lTWAQryMuoLOU8F1WsMqXgEjh9Ju/exoS+rILBLIOOZkejJqVeSmPqxOP8AikcfpAqOPEXWfBfBZbm5IwQ/6SA0zQKru89pIl1uy5SwCG/tU48= Received: from DB4PR03MB0847.eurprd03.prod.outlook.com (10.161.15.150) by DB4PR03MB0781.eurprd03.prod.outlook.com (10.161.14.27) with Microsoft SMTP Server (TLS) id 15.1.337.19; Thu, 10 Dec 2015 10:05:22 +0000 Received: from DB4PR03MB0847.eurprd03.prod.outlook.com ([10.161.15.150]) by DB4PR03MB0847.eurprd03.prod.outlook.com ([10.161.15.150]) with mapi id 15.01.0337.015; Thu, 10 Dec 2015 10:05:22 +0000 From: Rotem Cohen To: "Patrice Brissette (pbrisset)" , "draft-xie-l3sm-l2vpn-service-model@ietf.org" , "draft-shah-bess-l2vpn-yang@ietf.org" Thread-Topic: [bess] Sync between l2vpn service models Thread-Index: AQHRLeauisULsIMRB0+1bScTPiROyZ6/T+jw Date: Thu, 10 Dec 2015 10:05:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Rotem.Cohen@ecitele.com; x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; DB4PR03MB0781; 5:QSWdPzdBceVbhoZmKqNLKMeC9ShSTsMORjgJzPWf7pcpX4QL/3qM8VfxElzzn79hv66OwtL9kVctzrsu6RsUTDKTvP0P3t6fth8fLWTiw01dzJcMTT8X34naHUvT/ROnJc3j+q+zPyrwTKOc6M/p1Q==; 24:0nFBNlvNpGQCwNK7rQGCx9G5eAHQd0ebg6ZElhexzrdMIdCSGVsrgp51G6OplZQ4KbTuQAo0aecHxbpIu5JF4h1/lAQgIvul2wtO92IgRxY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR03MB0781; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB4PR03MB0781; BCL:0; PCL:0; RULEID:; SRVR:DB4PR03MB0781; x-forefront-prvs: 078693968A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(377454003)(50854003)(199003)(36304003)(122556002)(2900100001)(11100500001)(15975445007)(54356999)(19625215002)(2950100001)(19627405001)(77096005)(19627595001)(5002640100001)(5004730100002)(2501003)(5890100001)(97736004)(50986999)(81156007)(2201001)(86362001)(66066001)(16236675004)(87936001)(17760045003)(5001770100001)(19617315012)(5001960100002)(74316001)(106116001)(106356001)(19580395003)(40100003)(10400500002)(18206015028)(189998001)(76176999)(19580405001)(33656002)(101416001)(790700001)(19300405004)(1220700001)(92566002)(19609705001)(76576001)(102836003)(5003600100002)(105586002)(1096002)(6116002)(19273905006)(586003)(3846002)(99936001)(5008740100001)(7099028)(170073001)(16866105001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR03MB0781; H:DB4PR03MB0847.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_006_DB4PR03MB08471440F31A085A0896076BE2E90DB4PR03MB0847eurp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2015 10:05:22.0804 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR03MB0781 Archived-At: Cc: "l3sm@ietf.org" , Alexander Vainshtein , Hai Balas , "bess@ietf.org" Subject: Re: [bess] Sync between l2vpn service models 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: Thu, 10 Dec 2015 10:05:50 -0000 --_006_DB4PR03MB08471440F31A085A0896076BE2E90DB4PR03MB0847eurp_ Content-Type: multipart/alternative; boundary="_000_DB4PR03MB08471440F31A085A0896076BE2E90DB4PR03MB0847eurp_" --_000_DB4PR03MB08471440F31A085A0896076BE2E90DB4PR03MB0847eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Patrice, draft-shah-bess-l2vpn-yang "describes a YANG data model for Layer 2 VPN services over MPLS= networks" according to its abstract. What did you mean by L2 device model? There are some overlaps between the models, for example the Service paramet= ers on the attachment. The ac-template approach taken in draft-shah-bess-l2= vpn-yang seems m= ore robust and prevents partial definition in the root service model. Regarding the OAM container that defines BFD for the l2-connection. An Eth= ernet service that is implemented as VPWS or VPLS will mostly use Y.1731 OA= M tools and not BFD that runs in the IP or MPLS layers. Maybe the service m= odel can hold a basic OAM container or point to an oam-template instead spe= cifically calling for BFD. custom-qos-profile container includes a rate-limit leaf. Ethernet services = that conform to MEF CE2.0 service definition use a more complicated profile= that defined CIR, CBS, EIR, EMB color awareness, coupling and more. Is ra= te-limit leaf meant as a one-parameter abstraction for more detailed MEF Qo= S profile? Regardless of the origin of the model, it seems highly preferable to have a= single model covering all aspects of a L2VPN service. Regards, Rotem From: Patrice Brissette (pbrisset) [mailto:pbrisset@cisco.com] Sent: Thursday, December 03, 2015 6:22 PM To: Rotem Cohen; draft-xie-l3sm-l2vpn-service-model@ietf.org; draft-shah-be= ss-l2vpn-yang@ietf.org Cc: l3sm@ietf.org; Alexander Vainshtein; Hai Balas; bess@ietf.org Subject: Re: [bess] Sync between l2vpn service models Rotem, These models are fundamentally different. draft-shah-bess-l2vpn-yang meant to be a generic L2 device model whereas draft-xie-l3sm-l2v= pn-service-model-00 models the service. The service model call various device models to enable the defined service. Regards, Patrice [http://www.cisco.com/web/europe/images/email/signature/est2014/logo_06.= png?ct=3D1406640631632] 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 [http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before y= ou print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. Please click here for Company Registration Information. From: BESS > on behalf = of Rotem Cohen > Date: Thursday, December 3, 2015 at 10:02 AM To: "draft-xie-l3sm-l2vpn-service-model@ietf.org" >, "draft-shah-bess-l2vpn-y= ang@ietf.org" > Cc: "l3sm@ietf.org" >, Alexander Vainshtein >, Hai Balas >, "bess@ietf.org" > Subject: [bess] Sync between l2vpn service models Dear authors of L2VPN service model drafts, Can you clarify please the relation between draft-shah-bess-l2vpn-yang and draft-xie-l3sm-l= 2vpn-service-model-00? There are fundamental differences between L2VPN and L3VPN services and it d= oes not seem right to derive one model from the other. draft-xie-l3sm-l2vpn= -service-model-00 made the effort to explain these differences but if the starting = point had not been the L3VPN service model then it would not be necessary t= o do so. VPLS and VPWS are widely deployed in MPLS-TP networks which do not assume a= ny IP routing/forwarding capabilities and therefore using L3VPN constructs = to define L2VPN services is not natural for these applications. Relating to the conclusion section, the structure of L2VPN service is quite= clear and modelling it without relying on L3VPN should not be regarded as = reinventing a new wheel. Thanks & regards, Rotem Cohen PTS System Architecture Group Manager T: +972.3.926.8247 M: +972.54.926.8247 E: Rotem.Cohen@ecitele.com www.ecitele.com [cid:image001.png@01D130E6.A4648F00] --_000_DB4PR03MB08471440F31A085A0896076BE2E90DB4PR03MB0847eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Patrice,=

 

draft-shah-bess-l2vpn-yang  "describes a YANG data model for Layer 2 VPN services over MPLS networks" according to its a= bstract. What did you mean by L2 device model?

 

There are some overlap= s between the models, for example the Service parameters on the attachment.= The ac-template approach taken in draft-shah-bess-l2vpn-yang seems more robust and prevents partial definition in the root service model.

 

Regarding the OAM cont= ainer that defines BFD for the l2-connection.  An Ethernet service tha= t is implemented as VPWS or VPLS will mostly use Y.1731 OAM tools and not B= FD that runs in the IP or MPLS layers. Maybe the service model can hold a basic OAM container or point to an oam-templa= te instead specifically calling for BFD.

 

custom-qos-profile con= tainer includes a rate-limit leaf. Ethernet services that conform to MEF CE= 2.0 service definition use a more complicated profile that defined CIR, CBS= , EIR, EMB color awareness, coupling and more.  Is rate-limit leaf meant as a one-parameter abstraction fo= r more detailed MEF QoS profile?

 

Regardless of the orig= in of the model, it seems highly preferable to have a single model covering= all aspects of a L2VPN service.

 

Regards,

Rotem

 

From: Patrice = Brissette (pbrisset) [mailto:pbrisset@cisco.com]
Sent: Thursday, December 03, 2015 6:22 PM
To: Rotem Cohen; draft-xie-l3sm-l2vpn-service-model@ietf.org; draft-= shah-bess-l2vpn-yang@ietf.org
Cc: l3sm@ietf.org; Alexander Vainshtein; Hai Balas; bess@ietf.org Subject: Re: [bess] Sync between l2vpn service models

 

Rotem,<= o:p>

&n= bsp;

These m= odels are fundamentally different.

&n= bsp;

draft-shah-bess-l2vpn-ya= ng meant to be= a generic L2 device model whereas draft-xie-l3sm-l2vpn-service-model-00 models the service.

The ser= vice model call various device models to enable the defined service.

&n= bsp;

Regards= ,

&n= bsp;

Patrice

   =3D"http://www.cisco.com/web/europe/images/email/signature/est2014/logo_06.==

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

 

3D"http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif"Think before you print.

This email may contain confidential and privileg= ed material for the sole use of the intended recipient. Any review, use, di= stribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the re= cipient), please contact the sender by reply email and delete all copies of= this message.

Please click here for Company Registration Information.


&n= bsp;

From: BESS <bess-bounces@ietf.org> on behalf o= f Rotem Cohen <Rotem.C= ohen@ecitele.com>
Date: Thursday, December 3, 2015 at 10:02 AM
To: "draft-xie-l3sm-l2vpn-service-model@ietf.org" <draft-xie-l3sm-l2vpn-service-model@ietf.org>, "draft-= shah-bess-l2vpn-yang@ietf.org" <draft-shah-bess-= l2vpn-yang@ietf.org>
Cc: "l3sm@ietf.org<= span style=3D"color:black">" <l3sm@ietf.org>, Alexander Vainshtein = <Alexander.Va= inshtein@ecitele.com>, Hai Balas <Hai.Balas@ec= itele.com>, "bess@ietf.org" <<= /span>bess@ietf.org>
Subject: [bess] Sync between l2vpn service models<= /p>

&n= bsp;

Dear authors of L2VPN se= rvice model drafts,

 =

Can you clarify please t= he relation between draft-shah-bess-l2vpn-yang and draft-xie-l3sm-l2vpn-service-model-00?

 =

There are fundamental di= fferences between L2VPN and L3VPN services and it does not seem right to de= rive one model from the other. draft-xie-l3sm-l2vpn-service-model-00 made the effort to explain these differences but if the starting point= had not been the L3VPN service model then it would not be necessary to do so.

VPLS and VPWS are widely= deployed in MPLS-TP networks which do not assume any IP routing/forwarding= capabilities and therefore using L3VPN constructs to define L2VPN services= is not natural for these applications.

 =

Relating to the conclusi= on section, the structure of L2VPN service is quite clear and modelling it = without relying on L3VPN should not be regarded as reinventing a new wheel.=

 =

Thanks & regards,

 =

Rotem Cohen

PTS System Architecture Group Manager

T:

+972.3.926.8247

M:

+972.54.926.8247

E:

Rotem.Cohen@ecitele.com=

 

www.ecitele.com

3D"cid:image001=

 =

 =

--_000_DB4PR03MB08471440F31A085A0896076BE2E90DB4PR03MB0847eurp_-- --_006_DB4PR03MB08471440F31A085A0896076BE2E90DB4PR03MB0847eurp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4903; creation-date="Thu, 10 Dec 2015 10:05:21 GMT"; modification-date="Thu, 10 Dec 2015 10:05:21 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAKkAAAAiCAYAAAAkovk0AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABKnSURBVHhe 7Vx7eBRVlj/3VnWSNkQTIYOsuuiIIC9Bgusiyvj4ZgTRJg7DsiuMYWTUWQ18EXZXmZUUFRidN/lI llnRYXT4UMEHEF1xhNHxiaziY3goCIioLBKggRDy6Kp793eq353upLPy16bvR9HVVfeee+85v/Os 6pi2bVO2zdpd3Zscuhz9x5GmkTguwdGL8B8JcRTXPyGTtuDzTWqnd+1hNSezpZ3rl+NAJg6Y2bDG +qR6HPrdAyzeQD46yxujIgfwCYTyv1IyaBBJmsSYBVgPWbuq16DfUvuSmr9mM0+uT44D6TjQKUit bdUXAZQPAYBTADqiEI72DIxkYDJwo82gbwG0d+Ha7dbO6mUYa8GyHsmJIceB7nIgI0itHdX/CIDW A5y9PWC2dZO0i/58SFDxwQoTfQ+gvx1AfbOblHLdezgH0oLU2vHAvwJYv/QsY3fBmcpQptGKw0cX 49gI8N9mD6lZ3cP5ntt+NzjQAaQA0b9QHgDqpLjvbhBN25VDBYPycazCHA6A+tw3JZkb3zM4kARS gGcKrN2vTjtAo7xk9294x0q4/qvg+rkSkGs5DnTKgRhIUV7qjwTpES8zT0yATjcDGag+KkCsusJ6 o3q0fXXNqdM9RY7e/y8OxC1pG/0G0DnrG8eg2fCHXX8BDUZKdh/OrGyG5Pr0XA54IIXrHQPrNrlD ecmrgaZpKIt2aFELzPdkwt1EGonjwqWse2HBH7YH1BzouSLI7bwrDoQtqdBzyASCUjP5TMmTLwGI HBq04MA1nx+lVKbBDvwMHBx/stVkoDJweVwUtDwun4qoVd2JswVdLTR3v+dywIQVPRsAGu+BKdoY SADob24nGn5+HFfR23P/SLRtbwR4iDGnf4/otmuI+vchOnScaMNWoroXiIJ4KFr7Y6Kh5xGteZdo 6doIeKOEOD4V8p+sTdUP2mNqMj0m6LnSye3c44AJgF6BklOvDq4elu66oUQjL+jIqXOKAVKGFCzj skqiO66P9xnYj+iqS4j+8BeANEh0/TCiYQD6vkb0SVQEHhIu9g+EPR2BM8A43KyHVpXIQn8AN6Eu Dg4p0c9RDj1nVwVaFta/OFKRM0I5wWfsqopme0nDLd642YE14fENfWShvNHTNImxREesysDz6WS+ sL5hPLZ6DimlSJqGJPX6/MrAHsvaZsjS3VMw5rhVWb4+7djahsvBwSD67069761JygHIQj9WJU0b 7GnT2hbWNlyiTDmGlMM7x9p4PrlrfuWNb1mWJWRp2T/gajPWChWPN6u+4VJs4jsYcEo56k/gwZep 84H2EMck064MeI+g8X2MMmkgeLYG/U9YtQ1nSFMFSMn88FillZJr+R54UIbNX5q0LkftnF8VeBv3 RikyR+Y5TS/Pq5r6Jb4Pdxzaj3HH7fqGieDb2epI8yrbnuYZGczjl3nyB0i+e2OtL6Pfjphcax/v Jc0SyBWP0KUMquNqvT0vwMjwGtZ8OfgzFONYzidA/1astxnuXo2DNUsnAzrJRXi0rfthCd+B9+bg AFHBpwfxCcBNnxAH6Ju7iJ7Ds6SLAcgWLPcLZmMexWjwNR6b1Nhicwig6Er8HwOpWeS/UIu8xzwb zn0E4gbNcs2DTaavSDvThfTNJSp5Dd+bhaBlEXvvgZT85iAh9eMksAAe67Z9javnpNskRPWQMApG IuTx+ip16p/Rbw8N/MgUR3s9qUlvx/e0IFWGflQo/QHuz0ikvXDJ2geFkT/P46sOkRksGoj7nypT 3SIM/4NhRrDu5WNbp1h5ILjxhtCHVuDOPnyPgRSCmmKQXA1Ae+sz9anFuD8ndS9K0jWGFvOs2scH Q3FPakNVCpF/K2Kvzeh7AlLpLXTBk2EhsrwxvwoN4Xta67uEL/8Or/TIzcC6VMs6nJVDgcuE4VvW rvJn43ud0vpxKcVCnK8RWj+DrcB3fvtJHgaAnmmaer3WxpXMT8PUMCgN34USv+XRNXv1xeWV3l4w 0OilvgIwJ0IZPuLb2qA7hTDge5s3Yt9XQy4rNbXOQW85uquS09ufYgFLQIXjTN4f3nuSeM1kzsTw nj4AW6+fj8f6x/CF9ZQP4COrFgbu8MS+0NTdUjrlUqirtZBztQ4twP33qMQffvavdWsYtDH734Rr cRUwHfBWgtHOYtB4mYTJUXPGpt323STUbNJ5hnKkx7BIawLR5nQDrdpVfQ3DPxTCKLKsTaZtj/FE DEEVG4b8N63aP5JCwM+oy5ySZqg566JcLXXbTqz956B7rlZtd6LPx3H6ugnrjs3HHsXo5WcFPAp6 M3Cv0HVFzDIlrUuqIEn/eYY+qx7X0Vec9HhkxqQLngiX3NBmAZDhC7Q3+AXTEK6zRInQBqHdh3mc 1m33wv98xvekQ2/ocLIyAHsrMkzjMkHuOJy/gvMCUu5T0b1LU9+nZcGVQrVUoz/GGa9ACMusTZtG 2GM8/ihgU0M5noa4Vgkpn9XS5b6Tvb1oZDeauxWdic9fkNP6lTpcWmdi0MWe2+2klRQS9bkAHQrC zvcYoDIIjmzE34YHPfJnoAX6RGd7ywg3toCZqgOJc4X7w/7GG5t6fFtn178QEkLMVaHQertq8n93 WGLIzGe3bPQGQHnziQ3mlZTY6hzuvTHKxLRbFMKERTjmNvbdQPSSi1cXE+mweU27C2nmXwfwGwDC hWZp40jQfi9MPwhuFp+CRejtOM2f21VTY+8qwBXvQYc9NfXr7sVq+1iVN61MWTMMd3wfssj/XZJ5 xdpprbJmlacNV5LGw7eT9FXY9WtXSyGPplk4p7IHncbSJJ7Mr5q8Dde31dQ1/FYLHbTuvunZKF0n WLrb6PP1IQB7EIAbYCuoXHccPq5mT6Gl8wb35XDF7DOqXLttJ5zDzb9g9499rtXCdwttbhxAY/Aa p9cgUdL7q2cHnqupW/ulJlGWtAettCHV3ZhnKIzTrSw7Exaod0c/nCzO7/8d0c2/B+Yg9y1ImMbB 0XKS5EV7aJ77Z8vpuebI2GwAGp1G05lpAUQK6gG+Sh9sd0IT7JjgLgpC71DBHgf7PkcrilsYBysx XFzWy43S4PKaunXLqmdNuivdHADocYBtrFF6JES67CAsxKCIkqRfUuQqtom4K3QAkxQrUmwJPJDC 1TYhHr1PSGOpYRZuX7ikoXz+7MArKcQ8fwfXXMgxdcaJFF59FLC/UnpA6LqFLYPQ4g/A+k6MTZGC PoH1fp/3atet+9iaNYndvdcAMmn0GQXUcXwUbwwSgHcTcDIG4Coktz0IlPWHhbybTRZi6ohyjjcU HWIz9UU0PmWZCEPcgs0WxykChQi9OIyBfTgPovRCBW6Ql4vpYXD0PbDuW6tnl3v3IlFm59s3AUYJ EEpIpoBjSLS8hK3w/aysZqZp0tVdO10SqwsbOfoQH1zwGo8lJDIXG+UuGgxU+7UQEUamJeoDwwFU vRF3D4NoanrXYRCDyzCKbwAcfiu0uhQzTYWQfxq1wkjgfgdr1iLIXA4pNiDRG4XkCFF7dxu7GY85 yUqalgxLh92JuxQnFYhfr4aVD6XkAZCeRk3a3YTPz7NdjdbqdeQAkzDmW5qcmdCbmWT4JpDrfO4c ObkzmQ52HGlAvBHRkriyIJYAkqbD00yHS9/nujIeX4OhnmJp2oswr79V/+KFduWNn3E0fhS3CjsD 2VqkNHMeAQpQB20NvyhCwQT971eCa12EDJ0yRBBisW401nZIwnXEVFi9Y7CUu7EzrC7SPNUDixxh WVU3vdgZZXCvF0S7tbpy0g/S9GOtjqYTcfKy5AotjUKhnApYniIoRIlZUjYYHXaw22OwoiLwmL3k WRiLXssVtXH94/8AUrk9rGwKlQp6vUsOeUUQsQ51ireEkCsB0hT1l34o7tPVswIVXdJK6CCVfEdz oUW7J9Xh5hWytOh8bAzJkfMBrGakuv6SK/WoRhiEi6zaWr9dVdWC8xFYO8Ffx98jRjaHa6uQoSLD EaMpWBqMTgWMQmjguFYL4YkeM1Qbx6s/YnHuxs7O7yx5agSEPmN9YRiwvUJi9FekAocROfaBo558 BUpOnAtyBh99Yx/xa1YtnOh2KKl0MTbKfA4TjrFzT+rPsDJ5y+4UxLX9wJAgrFuGt64EmCz6w/LN xCAuQb2KbBSpIjek5lqcB9eEjBNbc+hpLr3gegDChrrqgwDRIVit0SRDNzNIqd/YEijNMxDQKimN /mA4tEkdSlofW4x0MZaX/DEqww1g22i47V9rYd6HEAJJjixEJrM1Q0nMG4dKGmLd8iewhqlYF6oG iTE1u1MaDp6gAq5kfD+x1bFGdPBrYOd2Qys2Q38BKEPwDA1auwuw3FhFhhUTfHpKyPyfGXRBHdb7 vpDmBKFD79LhAV4SFm6oDWjnU0z/Xzovb5MsbfwhLj4a4TeMAiosbsuf8cLcE2TkzUD4NR+Jk/oQ 465NYmLKl37FKMiPAD4BPGbhbsSgx3GsQlnqHhTyJ15GNHc60Yo/IWX9G6KL+hI9w1FUMnTSTxFm SSSoTu0iYTHZe4RSa2RYN19S4dGsncktfN0wZ8CtzCDdxo9d04IUauuAGefDmj4aLkG1cewaBinH vsLXH5yDH4ElMZ3XYCmbELvdBjO9sXpWOVs4AiAAVPEj3PsVlZTlYd/DhfBd6/k41f6GUsfBmXgD DPI4curAECEKAP5YXcSrYS5Z+0MA/jGUgep5z8J1f41xHUtiCmYUKgbhe+Ndn/ixDKk3Eb1EQwVM qVys6zLQQYbB/HO4NASlizbwUXi1maTm1UTr1n2EPXo8dBo3f4gk6RMtxdbEjgD9YsNo/XvEhjPB s5lahXZgvbfb9rCon/XCMOynrxvcstnoU4bqib7fslb+MRzHiohc/Sa2ugC6fKthqkVInORrmOje DgxjGUegcdMoIj6ibdwC1BdgG+yniG4EQC8sJfr1NKIHyhEhI9Xhdi4s74H/gVwjNKK0OszDVk/i h3tpGuqKG0xHjgXjuVYZa44S/wG66yjYxCkb7xtWLMkAbBWEcfD3nmEQImNy4io505S6iMlwycY1 I255166QKC2bCGxC6BHr0tgE/4F4X+wtd5zWmHVAWega0/RqG0icAgdROhpoFvk4KdHO2Se32NMq kh44ow5TYToo6AX3RirRPPIlVzhXXAtFSOo7f3b5BtAbZhYVDcEz53ZoTVqFVnnqJdMRY928sILZ Pwk0wgrB+Pjw3A8t6BwSJf5xePyNikTMWu6LMhWWUKGmeYOLBaSVhfBNIcfx+O2FM7UN40EUMXy8 8YMWfAsglhwNYOW7Lr1vVU2Ol/+KTh4QTf6xjhBfh2k8O8Y0fUjBw82V5i/hAFfg9BC82SmsZzTA 4ecq2ttw0y0Aij/V5XP8GYroAIflHiBweDkj9K0RS5ywCI8778DTqWFxgO4FgIsRcRxAvxbQ4Ocr bem2zsFGCPW4Yno/HWPAaI5l3k69B2Zw3dGrPXLDhrakMItj3A7j0s5RFUiyBtE+LDScZ0i4hiXF h/GnKvwwBUKcN5XjrHABO01DKSoyZ7i/NyZc+upYZsuCnjceoMRH7OmNd60qEHtxJ5Jxc2E/YwMf MyaYSGBQ14k30M6YeKFvWjp2RQUrZUwuKCsmGR9OknA/pvxRuZp48bjR2l69EXn+zbHSOCMR9qNi KVEhwJhYyOBb+xk67BRgJXdiqdcvQDX+24hPYY/4KdU2RE8tbLsA1Ol1yEzg2A4zbFJzVA4HQmq1 fe6iBIvSGRtz93oiB9iWsXlcDCt6c/RpXeQafcHGPVqcT+RO9C0o1n2OrNBnK+eu0YoJR0WRUtX+ KA0GZOJbUBwGsAU35H/2RMbn9pw9BzyQ4vdGr+JtqPVw+BOSXteLAK1Lcgy4TNl8Io3E0jIDuVX9 zh68aF+X9HMdejQHwpY03KqQy34HmekZ36jmmQ07GbhteJFCHa/JpnuuT8/mQAykiE134Yd4sxCL /t5z2915rNkdHrLbV1ADlyrsYXUJ5Y/uEMn17UkcSLSk7PaXW9sfuIj88qee2z/dQOWwgEHaTndC Kbp+gtKTJJHba0YOJIGUe9lDF/07LKpE9n6/937hN3ncmTgtz8Sgb6efsDLkZJLjQLYc6ABSD6hD auYBqPtQYloM9+/P+PefspklUs4C4A8A8HeB9gvZDMv1yXEgyoG0II0A9WFk/JtRlvo5Skc3eOWp 6I/qsuEfu3ZOkNgat9MTOL/fHlSDCmqu5TjQPQ5kBKkH1GE1H+JjPP70I788cQ+Aeh0sK15ti4QB iQkWg5jjTQYnnzt4synkPWOutwfXZPk+ZPcWn+vdMzjQKUijLMDfF30e5897f+WkTV0FJI4DGMuQ pQ/GJ/+ohOPN43Dn23DtPVx7FYDdhN/TJ7/90zN4mtvlaebA/wIHYhq8vhA2RAAAAABJRU5ErkJg gg== --_006_DB4PR03MB08471440F31A085A0896076BE2E90DB4PR03MB0847eurp_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=2637; creation-date="Thu, 10 Dec 2015 10:05:21 GMT"; modification-date="Thu, 10 Dec 2015 10:05:21 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAG4AAABJCAYAAADc8hN1AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAAAyJpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdp bj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6 eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2LjE0 NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJo dHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAv IiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RS ZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpD cmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNiAoV2luZG93cykiIHhtcE1NOkluc3RhbmNl SUQ9InhtcC5paWQ6M0E3NDdDRDVCQTU1MTFFM0FBMEZGQjNBQjlBQzg4ODgiIHhtcE1NOkRvY3Vt ZW50SUQ9InhtcC5kaWQ6M0E3NDdDRDZCQTU1MTFFM0FBMEZGQjNBQjlBQzg4ODgiPiA8eG1wTU06 RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDozQTc0N0NEM0JBNTUxMUUzQUEw RkZCM0FCOUFDODg4OCIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDozQTc0N0NENEJBNTUxMUUz QUEwRkZCM0FCOUFDODg4OCIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1w bWV0YT4gPD94cGFja2V0IGVuZD0iciI/PpWUmb0AAAbBSURBVHja7FxrbBRVFL6l2wpYwIpGERCL aJv4QK31EXygWItA0DTGVxTfQRMTjESlvhOIjx8aYqIhMeAzKgoKChGV4CtKLKL4ALGEVq1gUMRH pdXS7npO5kw4Pd7Z3c7O7sws50u+dGZ35s6Z+9177rnn3m1JKpUyivihRIVT4RQqnEKFU+EUKpxC hVPhFCqcQoVTqHAqnEKFU6hwKpxinxFu+NjJQdhSDlwAbAR+BLwS+GeIdTMM+ALwTOBrwJuA3bkW +lvrqkCMGxChRlQFvJYqbBqwLmR76siOYWRXVZR6XJSEKxctuixke/jzu8k+Fc6CFJGfh22Pl20q nCIewg0MqJxBRWpPJIVrAn4BXATc32cZpcC5wC+BT+Yw7uB984EbgA8BEz7Lwfd4iux5oBiFO4Iq vIYitNN8ljMOeDfwKODNwFN8loP3zQJWA+cAj/RZDr7HDWTPPfSeRSXcUGCvaPF+e8oeUa5fe4KI GPl9vTnYE1nhkgFFjDK6S+ZgTxARo3ynZNyEG0OZhQkRCbqOAc4EHhsRe04le8YEVWAioHIwJXQS sNM4KaLPQ6ykkUDMK40CtlMGZEeI9hwPXA2soHqpjVKPq6G/g4MyLMeKGkXHo+k87N5WIeopMsLt CWDcyUfGI0ivksv4bqunyAUnJVl+li+UmGghL/YEJVx5BkOT4prSHCqhPIP9/4rzngyVWZ5DPZRm McVJBjANyptwG+jvTuDHlu9bKbuA+BW41edzfgK20DEGHt9YrvkKuIWOtzDb5DU/smu2+7RnK72P W+b3lmvWUr0YD1tCjSovBk6mqGmT5fsu46xtNQDXATf7fM7vwAuA5wHfZ5XPgZU0BXgucA2rWI5t VMZEivh2+rQH32MSRa5vA/+2XPMtsJ6i7lVBCRelFfDxwM9YY0KhV4Y4Nk0FrmDu9mTmNXyjGFfA sdXvZufbQ7annR3vzqFX5gWJCNmC7usK4IXAD42zkhAmcMzCfS9nAZeTfdEJVSPkKvcJFKOrVKhw KpwioggrOBnCGs0/lmxHf1HBshiYD+zM8r5BLJvRI6LadNmSCpYV6Sj2HoeNZAbwDcp+/EDEudtd 4lrc04i7mt8Bvgu81aPM042z23gzKw+jwVdM+o1AuG64iDIZ7n0bga8CR3jcc4hxtjlgxNtK97TQ +8ww/tN4kY4qDwc+AzzH43usjLPZ+X5Uke5eEBTnKssEGQUabCkPe8Jw4B+W3oKbg2anabQnWCba E6khVad5R2xgN5KgeY8qC+EqK4HLgCemucaWCO5ix9KVorCPCNEwtfUL8LA0z3kQeHsGe3vFOdr9 OvCADPfVU4+dVAj3WQjh5gjRUKTFwE/ovJZa/wCT/VpelWj9zwNvIbGHUE/tEvfgRPoO8RkmxJca 58clY42T35T187gQDTM6LxonT4ppsMvN3u3qdeTW58ZduKHCxWEgcjW5ONmDUv20my/NHEyusQ24 iyhxvTjHfZmzRG9PCDvOILrABPp003d142XgEtb70V3Oz3evy3dwMl4M9kstormusD/CtZm+KwM4 yH4NfJMChYSlYfBf/+DyUJPFRfcIVzlBjJtN5v9LUm8Bn2bno+m9Yx1VDrEEIUEAw/bbqAe7wF3F uKLwrHFyi5XsO4wwR7JzjDz/yuI5fFcWTjHWely3RpwfFHfhUhbXGRSWUU9bbnFLU8QUA3tLtw87 OoQbrfS47kBx3h134dqFO7rMBPs7sw+AFwGPIzfGx7ZGNpfrFC6ujoKVTNgkeu01lmvKKEDhorXF XTicGDez81qKKKvphcvIHdX3M1CSduPc6WHjrIpz15lgIf4KMeY9Z5zV9IE0v6skV3uomJtxl4ru +U4KhLAM/M3ASyIa/dTs3V4R6wn4VFFpCFzi/46Oca/hOnr5FKtYzKi4O5EXGufHFS6OBj5qnG0B 7Wy+dSmL7t4zzvaEJMt8NFMyQDYu7KnjaGyqNX33hswzzg9NOH7GuTQ1OjmON1DGJ/YT8JU0r7mX fVZh+m6c7bGMhyUex67bmkb0wgIxL9xBrm6JGJNqxORbTsDnkSuezj4b4ZEam51OtDi5Shf3UaW1 ZJmtcHsdH0dkSssLGOrP9Jh2YC883zgbe3o9gilZNkaul1DWZZfHM1tonHusQPVZ0NUBDNM3UiXU skbTQZkIKeRicmulYuwylNp6gnpLqahATDutTmPHeuB1xtmZ1sBcaze57G0e88z7ydU2Cne7nhpJ cwHrUv9BTVyhwqlwChVOocKpcAoVTqHCqXAKFU6hwilUOBVOocIpVDgVTqHCKfKH/wQYAFYt0bWk E7ZUAAAAAElFTkSuQmCC --_006_DB4PR03MB08471440F31A085A0896076BE2E90DB4PR03MB0847eurp_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=1476; creation-date="Thu, 10 Dec 2015 10:05:21 GMT"; modification-date="Thu, 10 Dec 2015 10:05:21 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAVESURBVFjD xVdbTFNZFD2gBIxBUSGogCgPRVGUxMoHauKHGv9M9MMEE/nw8YHGGD/UGA0fig/UGUGgLWWAAlJo ZSiIL6A8BhBmHIEII4/hIUIVpbyUgfJac885V7AIlRlg5pDFaXtv7l7n7LXXPpfgfx5kNh9W31OP mJoYyMvlSGtKQ7ex+78hMDA8gA/9H3D15VU4Kh2xLHwZtqVtg7pBjS5jF4ZGhuaWQPH7YpwsOgmP BA+QHwnITQERBH5qP4SUh6C5t3luCWS3ZuPAswNwiXUBiRKC3yOwkdrAK9ELZ0rOoL67fm4JtP/V jqL3RTiWfwzz5fNBbhO4Jroi5PcQVHRU4PPg57kl0DvYizx9HgJzAzmBOwSrElYh+NdglHeUz50I h0aH8GnwE1R/qrBdux1L5EtgIbVgabCKsoJjjCMCcgNQ1l6GvqE+jI6Ozi6Buu46XHl5BX6pfizv 5K4AqQA5FyEV5ELZQuzL2ofYmthJy3JGBCoNlThacBRu8W6wklpxAcpEUCLCd1uZLbxV3rhWfg2G AcPsEqA1XtpeigvPL2C5cjlIuBhYJu6AgK2arYioikB1ZzWMI8bZJTAq/FGRXSy9iBXKFZMSkGgk kFZL0djbOHsipGKi7kcN6OCzg3BQOMAi0mLSFFhHWsNJ6YRzpefQ8qkFgyODMyfwsf8jol9HY3fG bpAwIdA1wmqfrVomipASCBdd8TqBndwOgXmBeNTyCCOjIzMj0DnQiUu/XcKWlC3wue8DH7UPNms2 Y2XCSljIhJ2IFJxQYQO3ZDf2+6bUTfBJ8oG/1h8JdQmzowFaAVnNWdC91aHwXSHy9fk48csJzI/m Trj6/mrcrLjJrhXqC5H9JhuPWx6zNJgQ0DZrWddS1ikRVxuH+Np4pDakgv4+FTLfZDL/p0EL9AUM ujYdJyAfJ3Cj/MbYdXovdcsnb5+YPIt4JHtgrWot1qesh1eKF/vsnuzOHjAV1txfg3WqddiQusEE DvEOPPcRPAX0PpoeBg2faRwa8wsICSVwTnJGUFEQzj4/iyN5R7A0bikX1hUuoGnjluiGUaII73E3 NAvyA8Geh3uQ25bLuho1l8svLsMz2ROeSgGqqUFF5pLkAqdEJwb62TnRGdYKa14R4SKJe2KFRI2X 5xjoRXelOw7rDkPXqmPC0PfpkdOag5yWHD5PRBvH07dPkd6UDk2jhkHdqGbluUO7g+8ELc0wERFf mdTXYP/EG/Y/2c8eSEVT8r4EJe0lfJ6IdwL0JawZTRzDI8OQ/iHF3od7sTddQBYH1RUtTxO3HCMQ yQnY/mTLhOir8YUkTQLJzxI+T4RagEqC44XHUdtdO6lRUe+vNlTzWQBNK9NWGDF1zDHn+uLfd6eB O1xwixWL2SkoozmDacfcqOqsYuZFW7elzHLcNU3yMVEg34OYukM5h9DQ0zCtk9P5svPcrL6cHb4R xXRBd02oIHKDYGfGTtR01UzLQUMrQ2GlsOIl+K8IRIorF1ZgGWGJjaqNCH4RjLbPbWYD08rKbc1F QHYA5snnjYvRbDDpFBCPX94p3oh5HYOm3iYYh41mCTxofIBdmbvgqHAcOzd+qwHZJO30ruhYt/l3 2t2CCoJwKv8UwqvC0THQMa2tV9QouEHdEndRbo6AEJw2lUWxi2Afbw/7OAFye7gmueJ6xXUY+g3o Mfawk+73Bj2G0fZNG5NdrB1fzDdl+DXENxtqqaeLT0PxWsFRpWAdk76A/pPxyvCKacRf448F0Qv4 6qXmCETyLfd94Ivid8UzfmnRNmlZs6NNj9W+3DTe34tP3LVtVE+BAAAAAElFTkSuQmCC --_006_DB4PR03MB08471440F31A085A0896076BE2E90DB4PR03MB0847eurp_-- From nobody Thu Dec 10 14:35:44 2015 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 9FBC91B2CC7; Thu, 10 Dec 2015 14:35:40 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rUNF8nWDm2s; Thu, 10 Dec 2015 14:35:39 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBDC1B2CBE; Thu, 10 Dec 2015 14:35:37 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D0BDD18000F; Thu, 10 Dec 2015 14:33:27 -0800 (PST) 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: <20151210223327.D0BDD18000F@rfc-editor.org> Date: Thu, 10 Dec 2015 14:33:27 -0800 (PST) Archived-At: Cc: bess@ietf.org, rfc-editor@rfc-editor.org Subject: [bess] RFC 7716 on Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures 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: Thu, 10 Dec 2015 22:35:40 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7716 Title: Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures Author: J. Zhang, L. Giuliano, E. Rosen, Ed., K. Subramanian, D. Pacella Status: Standards Track Stream: IETF Date: December 2015 Mailbox: zzhang@juniper.net, lenny@juniper.net, erosen@juniper.net, kartsubr@cisco.com, dante.j.pacella@verizonbusiness.com Pages: 22 Characters: 52951 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-bess-mvpn-global-table-mcast-03.txt URL: https://www.rfc-editor.org/info/rfc7716 DOI: http://dx.doi.org/10.17487/RFC7716 RFCs 6513, 6514, and others describe protocols and procedures that a Service Provider (SP) may deploy in order to offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers. Some of these procedures use BGP to distribute VPN-specific multicast routing information across a backbone network. With a small number of relatively minor modifications, the same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN. Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as "Internet multicast". In this document, we describe the modifications that are needed to use the BGP-MVPN procedures for Global Table Multicast. This document is a product of the BGP Enabled Services Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. 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/rfc.html 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 Mon Dec 14 01:28:44 2015 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 2F9811A8BAF for ; Mon, 14 Dec 2015 01:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.511 X-Spam-Level: X-Spam-Status: No, score=-5.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZzfLoBD-9ye for ; Mon, 14 Dec 2015 01:28:41 -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 EE5E31A8AFB for ; Mon, 14 Dec 2015 01:28:40 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 20D47E23F6DEC for ; Mon, 14 Dec 2015 09:28:36 +0000 (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 tBE9SRfc031210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 14 Dec 2015 10:28:38 +0100 Received: from [135.224.221.134] (135.239.27.39) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 14 Dec 2015 10:28:32 +0100 Message-ID: <566E8BBF.5060204@alcatel-lucent.com> Date: Mon, 14 Dec 2015 10:28:31 +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: <565427E1.9070803@orange.com> In-Reply-To: <565427E1.9070803@orange.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.39] Archived-At: Subject: Re: [bess] Introducing a one-implementation requirement before WG last calls 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, 14 Dec 2015 09:28:43 -0000 WG, we have reviewed the different comments posted on the list in response to our initial proposal. After thinking further about that, we'd like to propose the following as a way forward: At the same time we issue a Working Group Last Call we would ask for knowledge of existing implementations, and the more details provided at that time, the better. In the situation where an implementation would exist we would proceed with submission to IESG. In the opposite situation (no implementation exists), we would systematically ask the WG for reasoned opinions regarding whether we should nevertheless proceed with submission to IESG. We will gauge consensus on that aspect. In case consensus is in favour of proceeding with submission to IESG we will do so. In the opposite case, we will put the document in a "Waiting for implementation" state until information on an existing implementation is brought to our knowledge or of the WG. Please share your views on that. Thank you M&T Le 24/11/2015 10:03, Thomas Morin a crit : > Hello everyone, > > Following the positive feedback received during BESS meeting in Yokohama > about introducing a one-implementation requirement in BESS, we propose > to do the following for future WG last calls: > > As a prerequisite before doing a working group last call on a document, > the chairs will ask the working group for known implementations of the > specifications; a relatively detailed level of information will be > required (e.g. "release x.y of solution z shipping date d", "all > features implemented", "partial implementation only", etc.) and everyone > will be invited to reply (not only co-authors of the specifications); > the chairs will then do the working group last call if satisfying > information was provided on at least one implementation. > > We are open for comments on this proposal until December 7th. > > Martin & Thomas > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > From nobody Mon Dec 14 05:32:28 2015 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 D72A71A006F; Mon, 14 Dec 2015 05:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy8TDDmI1Ntl; Mon, 14 Dec 2015 05:32:22 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6555A1A0025; Mon, 14 Dec 2015 05:32:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9975; q=dns/txt; s=iport; t=1450099942; x=1451309542; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Qz2SXQqYpblJmLUKOl+KZwsrOse2fWA3wjs1/DhcIV8=; b=YpxLeF38Z/RjsUrZYkVRjfOvuSzKcCLfOanf/NouVpOaB+ULQJ9mex8h xvjIH/irzLX+hZ2dR0A/dPHaTqtdhgLsNvzAfHu6b/0HPrkVwJRs3wOFx 4Jk5L4QG2dskfyHVbzdNbb8WqhKseha/JXKgpXZXiFIg5vOO92PaiCKUF 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgCbxG5W/5NdJa1egm5MU24GuxiCG?= =?us-ascii?q?QENgWMhhW0CgSE4FAEBAQEBAQGBCoQ0AQEBBHkMBAIBCA4DBAEBKAchERQJCAI?= =?us-ascii?q?EAQ0FG4d/AxINuDgNhD0BAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZWAYR8glOBV?= =?us-ascii?q?xEBTIQ4BYdZiyqDcwGFNIYXgXiBW4RFjhKBB4Nng3MBHwEBQoQEcgGDQzqBCAE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos; i="5.20,427,1444694400"; d="scan'208,217"; a="53323486" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2015 13:32:21 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tBEDWLKd017431 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Dec 2015 13:32:21 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 14 Dec 2015 07:32:20 -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; Mon, 14 Dec 2015 07:32:20 -0600 From: "Alvaro Retana (aretana)" To: Alia Atlas , Xuxiaohu Thread-Topic: Alia Atlas' Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS) Thread-Index: AQHRNnPbf4VN9CCktESkPVUzUqkCgg== Date: Mon, 14 Dec 2015 13:32:20 +0000 Message-ID: References: <20151203030635.7958.76303.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB5398E@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: multipart/alternative; boundary="_000_D2942EEAF0936aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , Martin Vigoureux , "bess@ietf.org" , The IESG Subject: Re: [bess] Alia Atlas' Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS) 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, 14 Dec 2015 13:32:25 -0000 --_000_D2942EEAF0936aretanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alia: Hi! Xiaohu posted an update which I think should address your concerns. Please= take a look. Thanks! Alvaro. On 12/2/15, 11:13 PM, "Alia Atlas" > wrote: That works for me. Thanks, Alia On Dec 2, 2015 11:08 PM, "Xuxiaohu" > wrote: Hi Alia, > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Thursday, December 03, 2015 11:07 AM > To: The IESG > Cc: draft-ietf-bess-virtual-subnet@ietf.org; aretana@cisco.com; > bess-chairs@ietf.org; martin.vigoureux@alcat= el-lucent.com; bess@ietf.org > Subject: Alia Atlas' Discuss on draft-ietf-bess-virtual-subnet-06: (with = DISCUSS) > > Alia Atlas has entered the following ballot position for > draft-ietf-bess-virtual-subnet-06: Discuss > > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for a clear and well-written document. I have one point that i= s > peripheral to most of the draft. > > In Section 4.3, it says: > > " In addition, for any other > applications that generate intra-subnet traffic with TTL set to 1, > these applications may not work properly in the Virtual Subnet > context, unless special TTL processing for such context has been > implemented (e.g., if the source and destination addresses of a > packet whose TTL is set to 1 belong to the same extended subnet, > neither ingress nor egress PE routers should decrement the TTL of > such packet. Furthermore, the TTL of such packet should not be > copied into the TTL of the transport tunnel and vice versa)." > > The idea of not decrementing TTL is quite concerning. I can conjecture c= ases > where there is a routing loop between the relevant PEs - during reconverg= ence > when a host moves from one datacenter to another is a trivial case. > > One approach may be to ask why a packet would have a TTL of 1 and determi= ne > if this case must be resolved. Another might detecting a loop back to an > out-of-datacenter PE and dropping the packet. I'm sure you can develop o= ther > good ideas and solutions. How about doing the following text change: " In addition, for any other applications that generate intra-subnet traffic with TTL set to 1, these applications may not work properly in the Virtual Subnet context, unless special TTL processing and loop-prevention mechanisms f= or such context have been implemented. Details about such special TTL processing and loop-prevent= ion mechanisms are outside the scope of this document." Best regards, Xiaohu > > --_000_D2942EEAF0936aretanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Alia:

Hi!

Xiaohu posted an update which I= think should address your concerns.  Please take a look.

Thanks!

Alvaro.

On 12/2/15, 11:13 PM, "Alia Atlas" <akatlas@gmail.com> wrote:

That works for me.

Thanks,
Alia

On Dec 2, 2015 11:08 PM, "Xuxiaohu" &l= t;xuxiaohu@huawei.com> wrote:=
Hi Alia,

> -----Original Message-----
> From: Alia Atlas [mailto:akatlas@= gmail.com]
> Sent: Thursday, December 03, 2015 11:07 AM
> To: The IESG
> Cc: draft-i= etf-bess-virtual-subnet@ietf.org; aretana@cisco.com;
> bess-chairs@ietf.org; martin.vigoureux@alcatel-lucent.com; b= ess@ietf.org
> Subject: Alia Atlas' Discuss on draft-ietf-bess-virtual-subnet-06: (wi= th DISCUSS)
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-bess-virtual-subnet-06: Discuss
>
> When responding, please keep the subject line intact and reply to all = email
> addresses included in the To and CC lines. (Feel free to cut this intr= oductory
> paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Thank you for a clear and well-written document.  I have one poin= t that is
> peripheral to most of the draft.
>
> In Section 4.3, it says:
>
>  " In addition, for any other
>    applications that generate intra-subnet traffic with TTL = set to 1,
>    these applications may not work properly in the Virtual S= ubnet
>    context, unless special TTL processing for such context h= as been
>    implemented (e.g., if the source and destination addresse= s of a
>    packet whose TTL is set to 1 belong to the same extended = subnet,
>    neither ingress nor egress PE routers should decrement th= e TTL of
>    such packet.  Furthermore, the TTL of such packet sh= ould not be
>    copied into the TTL of the transport tunnel and vice vers= a)."
>
> The idea of not decrementing TTL is quite concerning.  I can conj= ecture cases
> where there is a routing loop between the relevant PEs - during reconv= ergence
> when a host moves from one datacenter to another is a trivial case. >
> One approach may be to ask why a packet would have a TTL of 1 and dete= rmine
> if this case must be resolved.  Another might detecting a loop ba= ck to an
> out-of-datacenter PE and dropping the packet.  I'm sure you can d= evelop other
> good ideas and solutions.

How about doing the following text change:

" In addition, for any other
    applications that generate intra-subnet traffic with TTL set = to 1,
    these applications may not work properly in the Virtual Subne= t
    context, unless special TTL processing and loop-prevention me= chanisms for such context have been
    implemented. Details about such special TTL processing and lo= op-prevention mechanisms are outside the scope of this document."

Best regards,
Xiaohu

>
>

 --_000_D2942EEAF0936aretanaciscocom_-- From nobody Mon Dec 14 05:34:04 2015 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 2A13B1A00CF; Mon, 14 Dec 2015 05:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxaUgktb39KK; Mon, 14 Dec 2015 05:34:02 -0800 (PST) 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 0F5911A006F; Mon, 14 Dec 2015 05:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=128; q=dns/txt; s=iport; t=1450100042; x=1451309642; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QR6rn6vyNqtnrg7dMDEAynNUrb3+CqNbmxVBk3BnoUQ=; b=c769yH8+6DcrmZzYwhvNhQGKqG7ZvzoPt0ryniwC1ca1vZ1KqCVzK4H7 ajHq6rQgkRXBlD5tWbeSPsp90wndMKPeaLbS+GbY80GhwzlYh26S/P6Mo 5DXWPlhs3+jG8HEatrfDbB57lovh7ZqXxJValVy0HeiQZSRk4Oum83RQZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgAVxW5W/5BdJa1egzqBR7sYghkBD?= =?us-ascii?q?YFjhg4CgSE4FAEBAQEBAQGBCoQ1AQEEOj8QAgEINhAyJQIEAQ2INL0RAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBGIZWAYR8iUABBJMDg3MBjUOBW5JXhG6DcwEfAQFCg?= =?us-ascii?q?kSBQIRwgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,427,1444694400"; d="scan'208";a="53169310" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2015 13:34:01 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tBEDY1NW013966 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Dec 2015 13:34:01 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 14 Dec 2015 07:34:00 -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; Mon, 14 Dec 2015 07:34:00 -0600 From: "Alvaro Retana (aretana)" To: Stephen Farrell , Xuxiaohu , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT) Thread-Index: AQHRNnQXisFXtnUoWkG3o0ZkYHd1Kg== Date: Mon, 14 Dec 2015 13:34:00 +0000 Message-ID: References: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53D79@NKGEML512-MBS.china.huawei.com> <56617BAD.6070906@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB54209@NKGEML512-MBS.china.huawei.com> <566574D9.6030202@cs.tcd.ie> In-Reply-To: <566574D9.6030202@cs.tcd.ie> 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.117.15.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <3F91FC1825D0D14FB2FF58B38C3130FE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" Subject: Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-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: Mon, 14 Dec 2015 13:34:03 -0000 Stephen: Hi! Xiaohu posted an update that we hope addresses your concerns. Pelase take a look. Thanks! Alvaro. From nobody Mon Dec 14 05:47:00 2015 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 965FB1A032D; Mon, 14 Dec 2015 05:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGjHkGvzqg8h; Mon, 14 Dec 2015 05:46:57 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D831A0263; Mon, 14 Dec 2015 05:46:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0A0EBBE33; Mon, 14 Dec 2015 13:46:55 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaXHrv-MNwM3; Mon, 14 Dec 2015 13:46:54 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 372CFBE35; Mon, 14 Dec 2015 13:46:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450100814; bh=Nh/cy3xYdEoeMbwsDYlA4Hm2sgLjz/ELwsN9b7O5D1k=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=N/n/BP6pYk2iBj6VKwsCfLqEvhErafqGWV7YbX7q4Cly3J4E8f3njjTfJFC+wtPXh WRyDGdmyg3yiDFqGHLkUiI6kLR5MBTiWub9S+9GXy0H7QFCcvPRzMJkkRwS+Bq9aVT nj5dgcaYd+C9ztH1qzYI3eaa4kqgfvMb+FvjURuY= To: "Alvaro Retana (aretana)" , Xuxiaohu , The IESG References: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53D79@NKGEML512-MBS.china.huawei.com> <56617BAD.6070906@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB54209@NKGEML512-MBS.china.huawei.com> <566574D9.6030202@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <566EC84E.7070600@cs.tcd.ie> Date: Mon, 14 Dec 2015 13:46:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" Subject: Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-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: Mon, 14 Dec 2015 13:46:59 -0000 Hi, Can someone say why the mention of MACsec wasn't included? As I understand it, MACsec is what's mostly usable for inter-DC security so omitting it seems like a bad idea (or perhaps I'm misinformed) Thanks, S. On 14/12/15 13:34, Alvaro Retana (aretana) wrote: > Stephen: > > Hi! > > Xiaohu posted an update that we hope addresses your concerns. Pelase take > a look. > > > Thanks! > > Alvaro. > > From nobody Mon Dec 14 05:49:05 2015 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 6BE221A0363; Mon, 14 Dec 2015 05:49:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151214134904.14014.81569.idtracker@ietfa.amsl.com> Date: Mon, 14 Dec 2015 05:49:04 -0800 Archived-At: Cc: draft-ietf-bess-virtual-subnet@ietf.org, bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org, aretana@cisco.com Subject: [bess] Alia Atlas' No Objection on draft-ietf-bess-virtual-subnet-07: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 13:49:04 -0000 Alia Atlas has entered the following ballot position for draft-ietf-bess-virtual-subnet-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my concerns on ttl handling and loop. From nobody Mon Dec 14 07:16:39 2015 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 0605D1A6FAE for ; Mon, 14 Dec 2015 07:16:38 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmZeKW11YNnR for ; Mon, 14 Dec 2015 07:16:36 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0605A1A6FE8 for ; Mon, 14 Dec 2015 07:15:28 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id p66so66813122wmp.1 for ; Mon, 14 Dec 2015 07:15:27 -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:content-type; bh=l9RNjLxUK6muJ/LniaU4mwT9vjZwj+gDllWv/v3mT+M=; b=RcgolewSzHef4DCe/m02DRut9xcQJDlZv9nnNKl93YGR6EfSnefpLayM/POBkN1qKt 2g13BhICK8o+fSWyISkjv4W1sjbBU97E8iC51P7C+FJMlk9YTMX0UAZ1ihpSJrdB4SQZ 4rSKINY5TH9E7E1oX/dBVE/lQ+0IVM4Ygj8wytujlC1KbEYgEIJ/YqlcFf9io0g3cAcH hiUGdndQL92UiacyJvuYBNvtrGdFXNeTZfn3KxNkqrvgIPrmbto/NmhE07FHg/4rXaW8 gnLDD+9awENWeB7eqf36TcXzpOkiBHJi7Bya02Ybnoy3d2g1AjkIxy2sPorOa0aDTjzq OwKg== X-Received: by 10.194.201.134 with SMTP id ka6mr38631946wjc.116.1450106111143; Mon, 14 Dec 2015 07:15:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.15.198 with HTTP; Mon, 14 Dec 2015 07:14:51 -0800 (PST) In-Reply-To: <566E8BBF.5060204@alcatel-lucent.com> References: <565427E1.9070803@orange.com> <566E8BBF.5060204@alcatel-lucent.com> From: "Andrew G. Malis" Date: Mon, 14 Dec 2015 10:14:51 -0500 Message-ID: To: Martin Vigoureux Content-Type: multipart/alternative; boundary=047d7ba97e64a434c20526dd230f Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] Introducing a one-implementation requirement before WG last calls 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, 14 Dec 2015 15:16:38 -0000 --047d7ba97e64a434c20526dd230f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin, That sounds reasonable to me. Cheers, Andy On Mon, Dec 14, 2015 at 4:28 AM, Martin Vigoureux < martin.vigoureux@alcatel-lucent.com> wrote: > WG, > > we have reviewed the different comments posted on the list in response to > our initial proposal. > After thinking further about that, we'd like to propose the following as = a > way forward: > > At the same time we issue a Working Group Last Call we would ask for > knowledge of existing implementations, and the more details provided at > that time, the better. > In the situation where an implementation would exist we would proceed wit= h > submission to IESG. > In the opposite situation (no implementation exists), we would > systematically ask the WG for reasoned opinions regarding whether we shou= ld > nevertheless proceed with submission to IESG. > We will gauge consensus on that aspect. In case consensus is in favour of > proceeding with submission to IESG we will do so. In the opposite case, w= e > will put the document in a "Waiting for implementation" state until > information on an existing implementation is brought to our knowledge or = of > the WG. > > Please share your views on that. > > Thank you > > M&T > > > > Le 24/11/2015 10:03, Thomas Morin a =C3=A9crit : > >> Hello everyone, >> >> Following the positive feedback received during BESS meeting in Yokohama >> about introducing a one-implementation requirement in BESS, we propose >> to do the following for future WG last calls: >> >> As a prerequisite before doing a working group last call on a document, >> the chairs will ask the working group for known implementations of the >> specifications; a relatively detailed level of information will be >> required (e.g. "release x.y of solution z shipping date d", "all >> features implemented", "partial implementation only", etc.) and everyone >> will be invited to reply (not only co-authors of the specifications); >> the chairs will then do the working group last call if satisfying >> information was provided on at least one implementation. >> >> We are open for comments on this proposal until December 7th. >> >> Martin & Thomas >> >> _______________________________________________ >> 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 > --047d7ba97e64a434c20526dd230f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin,

That sounds reasonable to me.

Cheers,
Andy

On Mon, Dec 14, 2015 at 4:28 AM, M= artin Vigoureux <martin.vigoureux@alcatel-lucent.com= > wrote:
WG,

we have reviewed the different comments posted on the list in response to o= ur initial proposal.
After thinking further about that, we'd like to propose the following a= s a way forward:

At the same time we issue a Working Group Last Call we would ask for knowle= dge of existing implementations, and the more details provided at that time= , the better.
In the situation where an implementation would exist we would proceed with = submission to IESG.
In the opposite situation (no implementation exists), we would systematical= ly ask the WG for reasoned opinions regarding whether we should nevertheles= s proceed with submission to IESG.
We will gauge consensus on that aspect. In case consensus is in favour of p= roceeding with submission to IESG we will do so. In the opposite case, we w= ill put the document in a "Waiting for implementation" state unti= l information on an existing implementation is brought to our knowledge or = of the WG.

Please share your views on that.

Thank you

M&T



Le 24/11/2015 10:03, Thomas Morin a =C3=A9crit :
Hello everyone,

Following the positive feedback received during BESS meeting in Yokohama about introducing a one-implementation requirement in BESS, we propose
to do the following for future WG last calls:

As a prerequisite before doing a working group last call on a document,
the chairs will ask the working group for known implementations of the
specifications; a relatively detailed level of information will be
required (e.g. "release x.y of solution z shipping date d", "= ;all
features implemented", "partial implementation only", etc.) = and everyone
will be invited to reply (not only co-authors of the specifications);
the chairs will then do the working group last call if satisfying
information was provided on at least one implementation.

We are open for comments on this proposal until December 7th.

Martin & Thomas

_______________________________________________
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

--047d7ba97e64a434c20526dd230f-- From nobody Mon Dec 14 09:48:01 2015 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 AD44E1ACEA8 for ; Mon, 14 Dec 2015 09:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4impckwuJCv for ; Mon, 14 Dec 2015 09:47:57 -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 168D31ACEA1 for ; Mon, 14 Dec 2015 09:47:55 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 74B0F7AB8255B for ; Mon, 14 Dec 2015 17:47:49 +0000 (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 tBEHlrFK007181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 14 Dec 2015 18:47:53 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.17]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 14 Dec 2015 18:47:53 +0100 From: "Henderickx, Wim (Wim)" To: "VIGOUREUX, MARTIN (MARTIN)" , "bess@ietf.org" Thread-Topic: [bess] Introducing a one-implementation requirement before WG last calls Thread-Index: AQHRNlHeBrAEEyS4YES32VdmTcZnm57KwnwA Date: Mon, 14 Dec 2015 17:47:51 +0000 Message-ID: <0A399AC7-DA1D-4495-B343-11CA09FDD601@alcatel-lucent.com> References: <565427E1.9070803@orange.com> <566E8BBF.5060204@alcatel-lucent.com> In-Reply-To: <566E8BBF.5060204@alcatel-lucent.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: <5FD9A284BB721345BBD9C9D4080F174E@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Introducing a one-implementation requirement before WG last calls 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, 14 Dec 2015 17:47:59 -0000 TWFydGluLCBmb3IgbWUgdGhpcyBzZWVtcyBhIHJlYXNvbmFibGUgd2F5IGZvcndhcmQNCg0KDQoN Cg0KT24gMTQvMTIvMTUgMTA6MjgsICJCRVNTIG9uIGJlaGFsZiBvZiBNYXJ0aW4gVmlnb3VyZXV4 IiA8YmVzcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYXJ0aW4udmlnb3VyZXV4QGFs Y2F0ZWwtbHVjZW50LmNvbT4gd3JvdGU6DQoNCj5XRywNCj4NCj53ZSBoYXZlIHJldmlld2VkIHRo ZSBkaWZmZXJlbnQgY29tbWVudHMgcG9zdGVkIG9uIHRoZSBsaXN0IGluIHJlc3BvbnNlIA0KPnRv IG91ciBpbml0aWFsIHByb3Bvc2FsLg0KPkFmdGVyIHRoaW5raW5nIGZ1cnRoZXIgYWJvdXQgdGhh dCwgd2UnZCBsaWtlIHRvIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBhcyANCj5hIHdheSBmb3J3YXJk Og0KPg0KPkF0IHRoZSBzYW1lIHRpbWUgd2UgaXNzdWUgYSBXb3JraW5nIEdyb3VwIExhc3QgQ2Fs bCB3ZSB3b3VsZCBhc2sgZm9yIA0KPmtub3dsZWRnZSBvZiBleGlzdGluZyBpbXBsZW1lbnRhdGlv bnMsIGFuZCB0aGUgbW9yZSBkZXRhaWxzIHByb3ZpZGVkIGF0IA0KPnRoYXQgdGltZSwgdGhlIGJl dHRlci4NCj5JbiB0aGUgc2l0dWF0aW9uIHdoZXJlIGFuIGltcGxlbWVudGF0aW9uIHdvdWxkIGV4 aXN0IHdlIHdvdWxkIHByb2NlZWQgDQo+d2l0aCBzdWJtaXNzaW9uIHRvIElFU0cuDQo+SW4gdGhl IG9wcG9zaXRlIHNpdHVhdGlvbiAobm8gaW1wbGVtZW50YXRpb24gZXhpc3RzKSwgd2Ugd291bGQg DQo+c3lzdGVtYXRpY2FsbHkgYXNrIHRoZSBXRyBmb3IgcmVhc29uZWQgb3BpbmlvbnMgcmVnYXJk aW5nIHdoZXRoZXIgd2UgDQo+c2hvdWxkIG5ldmVydGhlbGVzcyBwcm9jZWVkIHdpdGggc3VibWlz c2lvbiB0byBJRVNHLg0KPldlIHdpbGwgZ2F1Z2UgY29uc2Vuc3VzIG9uIHRoYXQgYXNwZWN0LiBJ biBjYXNlIGNvbnNlbnN1cyBpcyBpbiBmYXZvdXIgDQo+b2YgcHJvY2VlZGluZyB3aXRoIHN1Ym1p c3Npb24gdG8gSUVTRyB3ZSB3aWxsIGRvIHNvLiBJbiB0aGUgb3Bwb3NpdGUgDQo+Y2FzZSwgd2Ug d2lsbCBwdXQgdGhlIGRvY3VtZW50IGluIGEgIldhaXRpbmcgZm9yIGltcGxlbWVudGF0aW9uIiBz dGF0ZSANCj51bnRpbCBpbmZvcm1hdGlvbiBvbiBhbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiBp cyBicm91Z2h0IHRvIG91ciANCj5rbm93bGVkZ2Ugb3Igb2YgdGhlIFdHLg0KPg0KPlBsZWFzZSBz aGFyZSB5b3VyIHZpZXdzIG9uIHRoYXQuDQo+DQo+VGhhbmsgeW91DQo+DQo+TSZUDQo+DQo+DQo+ TGUgMjQvMTEvMjAxNSAxMDowMywgVGhvbWFzIE1vcmluIGEgw6ljcml0IDoNCj4+IEhlbGxvIGV2 ZXJ5b25lLA0KPj4NCj4+IEZvbGxvd2luZyB0aGUgcG9zaXRpdmUgZmVlZGJhY2sgcmVjZWl2ZWQg ZHVyaW5nIEJFU1MgbWVldGluZyBpbiBZb2tvaGFtYQ0KPj4gYWJvdXQgaW50cm9kdWNpbmcgYSBv bmUtaW1wbGVtZW50YXRpb24gcmVxdWlyZW1lbnQgaW4gQkVTUywgd2UgcHJvcG9zZQ0KPj4gdG8g ZG8gdGhlIGZvbGxvd2luZyBmb3IgZnV0dXJlIFdHIGxhc3QgY2FsbHM6DQo+Pg0KPj4gQXMgYSBw cmVyZXF1aXNpdGUgYmVmb3JlIGRvaW5nIGEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gYSBk b2N1bWVudCwNCj4+IHRoZSBjaGFpcnMgd2lsbCBhc2sgdGhlIHdvcmtpbmcgZ3JvdXAgZm9yIGtu b3duIGltcGxlbWVudGF0aW9ucyBvZiB0aGUNCj4+IHNwZWNpZmljYXRpb25zOyBhIHJlbGF0aXZl bHkgZGV0YWlsZWQgbGV2ZWwgb2YgaW5mb3JtYXRpb24gd2lsbCBiZQ0KPj4gcmVxdWlyZWQgKGUu Zy4gInJlbGVhc2UgeC55IG9mIHNvbHV0aW9uIHogc2hpcHBpbmcgZGF0ZSBkIiwgImFsbA0KPj4g ZmVhdHVyZXMgaW1wbGVtZW50ZWQiLCAicGFydGlhbCBpbXBsZW1lbnRhdGlvbiBvbmx5IiwgZXRj LikgYW5kIGV2ZXJ5b25lDQo+PiB3aWxsIGJlIGludml0ZWQgdG8gcmVwbHkgKG5vdCBvbmx5IGNv LWF1dGhvcnMgb2YgdGhlIHNwZWNpZmljYXRpb25zKTsNCj4+IHRoZSBjaGFpcnMgd2lsbCB0aGVu IGRvIHRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBpZiBzYXRpc2Z5aW5nDQo+PiBpbmZvcm1h dGlvbiB3YXMgcHJvdmlkZWQgb24gYXQgbGVhc3Qgb25lIGltcGxlbWVudGF0aW9uLg0KPj4NCj4+ IFdlIGFyZSBvcGVuIGZvciBjb21tZW50cyBvbiB0aGlzIHByb3Bvc2FsIHVudGlsIERlY2VtYmVy IDd0aC4NCj4+DQo+PiBNYXJ0aW4gJiBUaG9tYXMNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gQkVTUyBtYWlsaW5nIGxpc3QNCj4+IEJF U1NAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVz cw0KPj4NCj4+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj5CRVNTIG1haWxpbmcgbGlzdA0KPkJFU1NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3MNCg== From nobody Mon Dec 14 10:05:40 2015 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 591D11AD23D for ; Mon, 14 Dec 2015 10:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 mJ3ZNBfG82TU for ; Mon, 14 Dec 2015 10:05:37 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4211AD0CB for ; Mon, 14 Dec 2015 10:05:37 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-f3-566f04e93f6e Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id B4.17.32102.9E40F665; Mon, 14 Dec 2015 19:05:30 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Mon, 14 Dec 2015 13:05:35 -0500 From: Jeff Tantsura To: Martin Vigoureux Thread-Topic: [bess] Introducing a one-implementation requirement before WG last calls Thread-Index: AQHRNlHXqo0xZrkkcEWHtAnZ2SeQfp7Kx2t9 Date: Mon, 14 Dec 2015 18:05:34 +0000 Message-ID: <7A15C067-2139-4189-99CE-071F7E65A5C2@ericsson.com> References: <565427E1.9070803@orange.com>, <566E8BBF.5060204@alcatel-lucent.com> In-Reply-To: <566E8BBF.5060204@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPgu4rlvwwg/5ubosVx2cyW9zZ9YXV gcmj9dleVo8lS34yBTBFcdmkpOZklqUW6dslcGVc2rmJueCMcMX0vscsDYz/+LsYOTkkBEwk Nl5axARhi0lcuLeerYuRi0NI4AijxOIvm9ghnOWMEi9+HGIFqWITMJD4/+04C4gtImAlcaTr ITuIzSygLHF4/nkwW1ggXKL5SS/QJA6gmgiJj1d9IEwjictz40EqWARUJRbfuw82hVfAXuLt 4zPsICVCAv4S82ZKg4Q5garnbetiA7EZgU77fmoNE8QicYlbT+ZDnSwgsWTPeWYIW1Ti5eN/ rBA1ehI3pk5hg7C1JZYtfM0MsUpQ4uTMJywTGEVnIRk1C0nLLCQts5C0LGBkWcXIUVpckJOb bmS4iREYCcck2Bx3MO7t9TzEKMDBqMTDa3AgN0yINbGsuDL3EKMEB7OSCC8rMI6EeFMSK6tS i/Lji0pzUosPMUpzsCiJ8zIyMDAICaQnlqRmp6YWpBbBZJk4OKUaGC0XWb+IuaTTHsuW+F/q 15q+uddvH/cqsHbOy5L9pRuuuT3o4Y3i0M/OO8285v3ePkvk4iyVlXu+sVeer15zLuXQ8hlB t9tmMi2Y93y9oWvV72tVN4Ik1nDrOBSsPLD9qwsn+7NIqwe7d07Tuehfpe+aHhGXEXlM6ox7 1bKVU25u4lo/qaf8uqMSS3FGoqEWc1FxIgAZAmvQgAIAAA== Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] Introducing a one-implementation requirement before WG last calls 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, 14 Dec 2015 18:05:39 -0000 Martin, Sounds like solid and reasonable approach! Regards, Jeff > On Dec 14, 2015, at 1:28 PM, Martin Vigoureux wrote: >=20 > WG, >=20 > we have reviewed the different comments posted on the list in response to= our initial proposal. > After thinking further about that, we'd like to propose the following as = a way forward: >=20 > At the same time we issue a Working Group Last Call we would ask for know= ledge of existing implementations, and the more details provided at that ti= me, the better. > In the situation where an implementation would exist we would proceed wit= h submission to IESG. > In the opposite situation (no implementation exists), we would systematic= ally ask the WG for reasoned opinions regarding whether we should neverthel= ess proceed with submission to IESG. > We will gauge consensus on that aspect. In case consensus is in favour of= proceeding with submission to IESG we will do so. In the opposite case, we= will put the document in a "Waiting for implementation" state until inform= ation on an existing implementation is brought to our knowledge or of the W= G. >=20 > Please share your views on that. >=20 > Thank you >=20 > M&T >=20 >=20 > Le 24/11/2015 10:03, Thomas Morin a =E9crit : >> Hello everyone, >>=20 >> Following the positive feedback received during BESS meeting in Yokohama >> about introducing a one-implementation requirement in BESS, we propose >> to do the following for future WG last calls: >>=20 >> As a prerequisite before doing a working group last call on a document, >> the chairs will ask the working group for known implementations of the >> specifications; a relatively detailed level of information will be >> required (e.g. "release x.y of solution z shipping date d", "all >> features implemented", "partial implementation only", etc.) and everyone >> will be invited to reply (not only co-authors of the specifications); >> the chairs will then do the working group last call if satisfying >> information was provided on at least one implementation. >>=20 >> We are open for comments on this proposal until December 7th. >>=20 >> Martin & Thomas >>=20 >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Mon Dec 14 10:21:41 2015 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 52A1F1B2CA9 for ; Mon, 14 Dec 2015 10:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 DFzbxCvIs6h9 for ; Mon, 14 Dec 2015 10:21:38 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9C41B2C99 for ; Mon, 14 Dec 2015 10:21:38 -0800 (PST) X-AuditID: c618062d-f79d16d000001b1c-6b-566f07fffe04 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 15.5E.06940.FF70F665; Mon, 14 Dec 2015 19:18:39 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Mon, 14 Dec 2015 13:21:37 -0500 From: Antoni Przygienda To: Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] Introducing a one-implementation requirement before WG last calls Thread-Index: AQHRNlHXQpVbrNgKyEW18WXMblc8aJ7Kx7IQ Date: Mon, 14 Dec 2015 18:21:35 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F180EB48F9C@eusaamb103.ericsson.se> References: <565427E1.9070803@orange.com> <566E8BBF.5060204@alcatel-lucent.com> In-Reply-To: <566E8BBF.5060204@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPgu5/9vwwg7718hYrjs9ktriz6wur A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYdGoRa8FX8Yq+s0oNjEuEuxg5OSQETCQu HL3KBGGLSVy4t56ti5GLQ0jgCKPEt7tXGCGc5YwSc0+cYwepYhOwkLj87SlzFyMHh4hArMSv 9jCQsLBAuMTWu7egwhESH6/6QJhGEpcf1oJUsAioSiz9v4ENxOYV8JXYf/c4M4gtJBAoMfF1 JyOIzQlUPm9bF1gNI9A530+tATuNWUBc4taT+VBnCkgs2XOeGcIWlXj5+B8rhK0kMWnpOVaI ej2JG1OnsEHY2hLLFr5mhtgrKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxi5CgtLsjJTTcy 2MQIjINjEmy6OxjvT/c8xCjAwajEw2twIDdMiDWxrLgy9xCjBAezkgjvPWAUCfGmJFZWpRbl xxeV5qQWH2KU5mBREudlZGBgEBJITyxJzU5NLUgtgskycXBKNTDqhQsymB0NElw9bXp05H1u L7Gz2rcLLpWzbdtmJ71Yc6n+e5OzZf+X5yfw7fBsqj7xoIthYw+Xapqs3kW1CUkRmyx/SQYe /Wm+/W9sYfaPw0vClWQTU3gmdsyceUzbPDcl1Ur+6IpooeD3U0Jq3I7Nfeq6eoZI2uUlfpbi ZQ8lSqYxzM7aF6HEUpyRaKjFXFScCADXrfZZfwIAAA== Archived-At: Subject: Re: [bess] Introducing a one-implementation requirement before WG last calls 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, 14 Dec 2015 18:21:40 -0000 If that's what can be agreed on, I'm for it ... That puts at least somethin= g in terms of reality check between things being paper and going into STD t= racks ... =20 thanks=20 --- tony _____________________________________________ "Simple, clear purpose and principles give rise to complex and intelligent = behavior. Complex rules and regulations give rise to simple and stupid beha= vior."=20 --- Dee Hock=20 > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Martin Vigoureux > Sent: Monday, December 14, 2015 1:29 AM > To: bess@ietf.org > Subject: Re: [bess] Introducing a one-implementation requirement before > WG last calls >=20 > WG, >=20 > we have reviewed the different comments posted on the list in response to > our initial proposal. > After thinking further about that, we'd like to propose the following as = a way > forward: >=20 > At the same time we issue a Working Group Last Call we would ask for > knowledge of existing implementations, and the more details provided at > that time, the better. > In the situation where an implementation would exist we would proceed > with submission to IESG. > In the opposite situation (no implementation exists), we would systematic= ally > ask the WG for reasoned opinions regarding whether we should nevertheless > proceed with submission to IESG. > We will gauge consensus on that aspect. In case consensus is in favour of > proceeding with submission to IESG we will do so. In the opposite case, w= e > will put the document in a "Waiting for implementation" state until > information on an existing implementation is brought to our knowledge or = of > the WG. >=20 > Please share your views on that. >=20 > Thank you >=20 > M&T >=20 >=20 > Le 24/11/2015 10:03, Thomas Morin a =E9crit : > > Hello everyone, > > > > Following the positive feedback received during BESS meeting in > > Yokohama about introducing a one-implementation requirement in BESS, > > we propose to do the following for future WG last calls: > > > > As a prerequisite before doing a working group last call on a > > document, the chairs will ask the working group for known > > implementations of the specifications; a relatively detailed level of > > information will be required (e.g. "release x.y of solution z shipping > > date d", "all features implemented", "partial implementation only", > > etc.) and everyone will be invited to reply (not only co-authors of > > the specifications); the chairs will then do the working group last > > call if satisfying information was provided on at least one implementat= ion. > > > > We are open for comments on this proposal until December 7th. > > > > Martin & Thomas > > > > _______________________________________________ > > BESS mailing list > > BESS@ietf.org > > https://www.ietf.org/mailman/listinfo/bess > > > > >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Mon Dec 14 11:33:31 2015 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 B97071B2DF5 for ; Mon, 14 Dec 2015 11:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 vybqX8JO4pOz for ; Mon, 14 Dec 2015 11:33:24 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C2E1B2DF2 for ; Mon, 14 Dec 2015 11:33:22 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.35.68] (66.129.241.14) by CY1PR0501MB2009.namprd05.prod.outlook.com (10.164.2.27) with Microsoft SMTP Server (TLS) id 15.1.355.16; Mon, 14 Dec 2015 19:33:03 +0000 To: Martin Vigoureux , References: <565427E1.9070803@orange.com> <566E8BBF.5060204@alcatel-lucent.com> From: Eric Rosen Message-ID: <566F194D.5060803@juniper.net> Date: Mon, 14 Dec 2015 14:32:29 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <566E8BBF.5060204@alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BY1PR17CA0004.namprd17.prod.outlook.com (25.162.18.142) To CY1PR0501MB2009.namprd05.prod.outlook.com (25.164.2.27) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2009; 2:q/5at9TJYcbbS2a3fkkaaL48LqJOm0LrYs0WLU/3fF54R9eXPxi33tpdw3L0dpPYAnEytDqrcHN1pVhtuedJO+a+inLbQE7LSQa7nk2aPItHkyPT1kr/zpwJYaLwkH1mAlkkMfc0euyAiamr068p6w==; 3:wO2I05SLzfYVM1MAtDTgcYlvCQPb9O017XBT42Jk88CIwmbbi+bdlQFJAT+YbyOOOfdfuanbQYsSat6QcTE+6IorLmgMPliNzeR7dg7cFiLpwjOMryi6XM17881+VuZq; 25:Z/4YOT9g5TJI87S4Et93urs6WZgrNxeJJUfD27N4O2kvU6ouEg+fBnNAQ2rEePLoxcrG8Cqe0PDqqx7kBiuE+PZw+utgU/U8L0FlBQFGNKcl4zJr4Ocgy+xT3bQydO7NU/6XZuyYmVpFTk5/ujMf53FbIDj/G94RV0vCigFXlTNaL/OqGzA2lC2rAYz9VwzTwUgD+8SHIQHKwpvHBvD5rMrWNUM6Wq8ghzWHDZ/RbaGA1F4BTPUHf28qjdDc7du8Sz6nO+9Ub1K+SgbvKVnzCQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB2009; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2009; 20:dgidDGQQDYZYFLLthyJgu5dlGYc81fm8wLe6SSBHffSYL+XFMZqk4UHQj0S8bek8/5erVrS7rMcDRnfMl2HU/StJYB26w9LEeZFFsyijx98aLzAPSWJqZcSOm/UKnk+KNiEykoUorMffCz22x8CkjjNWNYNEQ7wmfB+VwCQ2zIwX13G2eLV8i/gpvTG7OC5+CZoBEHD+aaHfrLTxjOZ2pgFL+kRpQQRiJ7vtQglsbPysRrGCVg4hjMFtIbt19g6NN/oV0WOo4Ko3AKzqlmHWFPyQiJ6vcbNLfm0ZUDtURjtBxG/87l0IaerfDLJu4eSuiEj9pZRORxnlkH5MKgHsb4a0J4hSVFg8yfCwu0jPUJfvW7Sv/bqbtTGMc6SBULSsGdqCXYWPx9Udnv0gMyEfoOTUzBqyklHYtELyyotKo2pNiH4+y1/gWp4e7chsoDCP+nFpaFHAUd21qCh1bhOXVjqvSOwMobR3037cIBvem2OlbKKcBhiGDzus6KRrc6xA; 4:fjP5m8rR4V2fuB/0la+uHnP93sQMEbKzZ9ID917alSQFdNDiM2b1GF+f4YAJdaeo2TanIhziFPU+qoea5gmf09QdcRqtTPyv8p9KfUAx/izg4ZHnab0/r/qlNEpejfWaIWvhchBQiwsqwOw/JGgOuOac6Uk1kDkjd7E/Egz/Zf+2jl6nRv+BM7lDb6E/mQY4LPSrJxbuM1Sbcr4NAxInWHDIAkQmhjFkp/LQEl2FRRVkKFUB6/vW6tuxWvXfOE7mY3E35MtdIxFow1Lt2y9ge/08aIrKrG7IVK2+GX2TCI0qoVrrRSkTw7zf/7ji8gUvjTrtb66LtiC4kyQ89BdPczi6EcGDFqma+Uun3a6+09dHdmnfC3LbZODvAwdSqYQ5 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:CY1PR0501MB2009; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB2009; X-Forefront-PRVS: 0790FB1F33 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(377454003)(53754006)(189002)(24454002)(36564002)(199003)(479174004)(1096002)(59896002)(83506001)(54356999)(87266999)(5008740100001)(87976001)(5001770100001)(6116002)(107886002)(76176999)(15975445007)(586003)(33656002)(3846002)(80316001)(2950100001)(65816999)(561944003)(19580395003)(50466002)(101416001)(19580405001)(97736004)(66066001)(64126003)(189998001)(47776003)(77096005)(92566002)(50986999)(42186005)(5001960100002)(81156007)(4001350100001)(65806001)(5004730100002)(36756003)(105586002)(122386002)(23746002)(86362001)(65956001)(106356001)(40100003)(3076002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2009; H:[172.29.35.68]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY1PR0501MB2009; 23:yFeyM/u01lvr/DiEup7qUTpVWj4Skx9szce?= =?Windows-1252?Q?A71h2UZXMhhpDmyZvhK8AiX/YxKdwGBPslipc8sqzb+ej7NeyxUaigLV?= =?Windows-1252?Q?Kpy9mBmeiMmqCm54qaD0fcVY/JtKm4YcEPZmRi/5LqNBafoIpCJDcTRN?= =?Windows-1252?Q?dVAkAHJwYcvlvrfvuLjd3pSDO8C3P9yOFZjEUoiUAcCxiuztyPtRK8sb?= =?Windows-1252?Q?AQyIrgeMi6EvcHsTnQaag+U8B3+QNWDcZuyqxAH3v7OyWFewFdoGHty7?= =?Windows-1252?Q?XoWEGEtmpsorVowyXUz6V8lxqtHSy8Ew85J15c0nXNEXuyVaHIhGJ/Yq?= =?Windows-1252?Q?3J4GT19pyuqxhu8i+xoU750FtmZ/Q6Wl1Vnm6wc3A/19AOoMFadBVSp6?= =?Windows-1252?Q?1H2D/HmQgZddTXHNTKec1V2V3weSPfNmMfXpo27BKGjnZLR5ltOo2UgP?= =?Windows-1252?Q?amhvpMn++OhCmKLNrP0qWQl1WZsXUR5GBuriXilakeG7TQ5Cq9ey+Wf7?= =?Windows-1252?Q?7lKN/Q6S1vNxvYWpH7oQSi3wViXSIGx75KJnLEE046NJ20vctKAYb1Pm?= =?Windows-1252?Q?ShjpaQwiJH/He2YloGQrgqqrRrcS/P76r9dYQk4XYD3PlHhQh8cUc0AC?= =?Windows-1252?Q?hS4jrNCGLssZRqqxE13f8+bDkKFG93GCil+5EjltgvfAVCjZpQjyWPyX?= =?Windows-1252?Q?E6pSbc9Akl7ierd/A3WXLaPQrD9650N+OPxG6PQErnXWQN4nCuZXhrp5?= =?Windows-1252?Q?a+NLUbC8/G4dKctx0mhG8n39/jnqwF60IunIbuROu86I7wVpbvMo12ax?= =?Windows-1252?Q?HZ9GW/Ibq16IOaosMg+aIC8Z64hBeM9mMhFEjyt2wpVOMq9wnFMRzgwi?= =?Windows-1252?Q?c99tIHSneyF3uy57sZXjN8A+xMOaBTEHvesMjwnMbRe+PGXFp1TDS4MP?= =?Windows-1252?Q?YUlOERmzX2WAQbmVMqveGWAeULtkNOr50CfBZdZPgDlsDgOKWnhb0LfK?= =?Windows-1252?Q?2iD4XFMkX11rTiincWjD5+vj/5wQWUqxlzI663yozcX4PJzSg+6TbkHB?= =?Windows-1252?Q?Mv7SO5/92JcJPoPdxYZ5MvMAFggVLrOr3QkEymbL57EpGZoQbfr5mpkA?= =?Windows-1252?Q?mLyWjKDSjVpWXx1AHgeyZyOT6n/E+8dMPizRcbiMbQ7i0McIc24Xjiz8?= =?Windows-1252?Q?CtLuJdwL7qtuO/3aR6eCdBansYpIo6V38UVHm+FSHiRm5JWjPkHaem/r?= =?Windows-1252?Q?5M+ZBknOoBdvyaFFTekxzDhFN7YlU9hBSN+ILtS149zSSbv7CQdH6dCi?= =?Windows-1252?Q?RQoFT50O1PNnA6RfCsKeAbpWgt9d1fdYiRpjmoT3LTe96ckozj1fLK1r?= =?Windows-1252?Q?Mj90dKUxIP9a6FiUroYSiPhyE1vWV3cReat79KoRj157+PMzYLO+Al2w?= =?Windows-1252?Q?bjl8bi71finSABqBTtRz+7qFBEm2wqZIntfbZiIuHfqkUqWr7GSedTQd?= =?Windows-1252?Q?5Kh8h0ysEwgWzWgj5uS0gNvetppoL?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2009; 5:zz1FaK0ayxcT/kWHjmFkgrAjAC6FrxKsYicuhqz/GfURNct4Oo5cAx80t+zjIpfQFGk3V09J756rcZJEiLLTaCLYRnrF7Zdm9Q9tnKZBqHLkyAsxPuUtIKMRyuKlM2rWi4GB5i1mY2PcGMNAcLBp4w==; 24:/i4UUzC7ZcUTW/UtZo1lri/flX/tNlje1aqj9gY64aRX1ShDaaYiZ+2brHmXomNAtiVg+gdteiq0Xdw+Mun/DhJ9MsmTVo+ZyB3emKBtScM= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2015 19:33:03.5391 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2009 Archived-At: Subject: Re: [bess] Introducing a one-implementation requirement before WG last calls 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, 14 Dec 2015 19:33:29 -0000 My opinion is unchanged; there is no need to impose any implementation requirement, nor is there any need to add more process hurdles that further slow down the progress of a document towards publication. Certainly there is no need to gather details about implementations, vendor releases, etc. The process is already slow enough and has enough useless overhead. If folks object to the progression of a document, they are already free to make those objections during last call. On 12/14/2015 4:28 AM, Martin Vigoureux wrote: > WG, > > we have reviewed the different comments posted on the list in response > to our initial proposal. > After thinking further about that, we'd like to propose the following > as a way forward: > > At the same time we issue a Working Group Last Call we would ask for > knowledge of existing implementations, and the more details provided > at that time, the better. > In the situation where an implementation would exist we would proceed > with submission to IESG. > In the opposite situation (no implementation exists), we would > systematically ask the WG for reasoned opinions regarding whether we > should nevertheless proceed with submission to IESG. > We will gauge consensus on that aspect. In case consensus is in favour > of proceeding with submission to IESG we will do so. In the opposite > case, we will put the document in a "Waiting for implementation" state > until information on an existing implementation is brought to our > knowledge or of the WG. > > Please share your views on that. > > Thank you > > M&T > > > Le 24/11/2015 10:03, Thomas Morin a crit : >> Hello everyone, >> >> Following the positive feedback received during BESS meeting in Yokohama >> about introducing a one-implementation requirement in BESS, we propose >> to do the following for future WG last calls: >> >> As a prerequisite before doing a working group last call on a document, >> the chairs will ask the working group for known implementations of the >> specifications; a relatively detailed level of information will be >> required (e.g. "release x.y of solution z shipping date d", "all >> features implemented", "partial implementation only", etc.) and everyone >> will be invited to reply (not only co-authors of the specifications); >> the chairs will then do the working group last call if satisfying >> information was provided on at least one implementation. >> >> We are open for comments on this proposal until December 7th. >> >> Martin & Thomas >> >> _______________________________________________ >> 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 Mon Dec 14 16:08:54 2015 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 28FFE1A87D9 for ; Mon, 14 Dec 2015 16:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSxSzg_9HUcl for ; Mon, 14 Dec 2015 16:08:50 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 7F0761A87CB for ; Mon, 14 Dec 2015 16:08:50 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id A1652279D14A6 for ; Tue, 15 Dec 2015 00:08:45 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id tBF08kq5005229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 15 Dec 2015 00:08:47 GMT Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.242]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 14 Dec 2015 19:08:47 -0500 From: "Dolganow, Andrew (Andrew)" To: "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: [bess] Introducing a one-implementation requirement before WG last calls Thread-Index: AQHRNlHXH9khWLvpvk6vr7sR+/X18p7LLOUk Date: Tue, 15 Dec 2015 00:08:46 +0000 Message-ID: <674C1E23-B302-4CE4-9397-E8F8CFBA6021@alcatel-lucent.com> References: <565427E1.9070803@orange.com>, <566E8BBF.5060204@alcatel-lucent.com> In-Reply-To: <566E8BBF.5060204@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] Introducing a one-implementation requirement before WG last calls 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, 15 Dec 2015 00:08:53 -0000 This is a more reasonable approach. I am OK with this.=20 Andrew Sent from my iPhone > On Dec 14, 2015, at 5:28 PM, Martin Vigoureux wrote: >=20 > WG, >=20 > we have reviewed the different comments posted on the list in response to= our initial proposal. > After thinking further about that, we'd like to propose the following as = a way forward: >=20 > At the same time we issue a Working Group Last Call we would ask for know= ledge of existing implementations, and the more details provided at that ti= me, the better. > In the situation where an implementation would exist we would proceed wit= h submission to IESG. > In the opposite situation (no implementation exists), we would systematic= ally ask the WG for reasoned opinions regarding whether we should neverthel= ess proceed with submission to IESG. > We will gauge consensus on that aspect. In case consensus is in favour of= proceeding with submission to IESG we will do so. In the opposite case, we= will put the document in a "Waiting for implementation" state until inform= ation on an existing implementation is brought to our knowledge or of the W= G. >=20 > Please share your views on that. >=20 > Thank you >=20 > M&T >=20 >=20 > Le 24/11/2015 10:03, Thomas Morin a =E9crit : >> Hello everyone, >>=20 >> Following the positive feedback received during BESS meeting in Yokohama >> about introducing a one-implementation requirement in BESS, we propose >> to do the following for future WG last calls: >>=20 >> As a prerequisite before doing a working group last call on a document, >> the chairs will ask the working group for known implementations of the >> specifications; a relatively detailed level of information will be >> required (e.g. "release x.y of solution z shipping date d", "all >> features implemented", "partial implementation only", etc.) and everyone >> will be invited to reply (not only co-authors of the specifications); >> the chairs will then do the working group last call if satisfying >> information was provided on at least one implementation. >>=20 >> We are open for comments on this proposal until December 7th. >>=20 >> Martin & Thomas >>=20 >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Mon Dec 14 17:19:23 2015 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 15E921ACF07; Mon, 14 Dec 2015 17:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j77AVKO9C977; Mon, 14 Dec 2015 17:19:20 -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 260BC1ACEFE; Mon, 14 Dec 2015 17:19:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBP07700; Tue, 15 Dec 2015 01:19:16 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 15 Dec 2015 01:19:16 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.64]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 15 Dec 2015 09:19:11 +0800 From: Xuxiaohu To: Stephen Farrell , "Alvaro Retana (aretana)" , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT) Thread-Index: AQHRLdaOLk8nhORYXUKrCN/X2riedp66D2jwgAAf9ICABKhN0IAAFESAgAsadwCAAAObAIABRkxQ Date: Tue, 15 Dec 2015 01:19:10 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB55473@NKGEML512-MBS.china.huawei.com> References: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53D79@NKGEML512-MBS.china.huawei.com> <56617BAD.6070906@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB54209@NKGEML512-MBS.china.huawei.com> <566574D9.6030202@cs.tcd.ie> <566EC84E.7070600@cs.tcd.ie> In-Reply-To: <566EC84E.7070600@cs.tcd.ie> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.566F6A95.0070, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.64, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 636d13f7260e6fc54f0a0d46d7fffea7 Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" Subject: Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-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, 15 Dec 2015 01:19:22 -0000 SGkgU3RlcGhlbiwNCg0KSXQgc2FpZCAiLi4udXNpbmcgYSBzdHJvbmcgc2VjdXJpdHkgbWVjaGFu aXNtIHN1Y2ggYXMgSVBzZWMgW1JGQzQzMDFdIi4gSGVyZSBJUHNlYyBpcyBqdXN0IG1lbnRpb25l ZCBhcyBhbiBleGFtcGxlIG9mIGEgc3Ryb25nIHNlY3VyaXR5IG1lY2hhbmlzbS4gVGhlcmVmb3Jl LCBpdCBkb2Vzbid0IGV4Y2x1ZGUgTUFDc2VjLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGVwaGVuIEZhcnJlbGwgW21h aWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXQ0KPiBTZW50OiBNb25kYXksIERlY2VtYmVy IDE0LCAyMDE1IDk6NDcgUE0NCj4gVG86IEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpOyBYdXhpYW9o dTsgVGhlIElFU0cNCj4gQ2M6IGRyYWZ0LWlldGYtYmVzcy12aXJ0dWFsLXN1Ym5ldEBpZXRmLm9y ZzsgYmVzcy1jaGFpcnNAaWV0Zi5vcmc7DQo+IG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNl bnQuY29tOyBiZXNzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBTdGVwaGVuIEZhcnJlbGwncyBE aXNjdXNzIG9uIGRyYWZ0LWlldGYtYmVzcy12aXJ0dWFsLXN1Ym5ldC0wNjogKHdpdGgNCj4gRElT Q1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IA0KPiBIaSwNCj4gDQo+IENhbiBzb21lb25lIHNheSB3 aHkgdGhlIG1lbnRpb24gb2YgTUFDc2VjIHdhc24ndCBpbmNsdWRlZD8NCj4gQXMgSSB1bmRlcnN0 YW5kIGl0LCBNQUNzZWMgaXMgd2hhdCdzIG1vc3RseSB1c2FibGUgZm9yIGludGVyLURDIHNlY3Vy aXR5IHNvDQo+IG9taXR0aW5nIGl0IHNlZW1zIGxpa2UgYSBiYWQgaWRlYSAob3IgcGVyaGFwcyBJ J20gbWlzaW5mb3JtZWQpDQo+IA0KPiBUaGFua3MsDQo+IFMuDQo+IA0KPiBPbiAxNC8xMi8xNSAx MzozNCwgQWx2YXJvIFJldGFuYSAoYXJldGFuYSkgd3JvdGU6DQo+ID4gU3RlcGhlbjoNCj4gPg0K PiA+IEhpIQ0KPiA+DQo+ID4gWGlhb2h1IHBvc3RlZCBhbiB1cGRhdGUgdGhhdCB3ZSBob3BlIGFk ZHJlc3NlcyB5b3VyIGNvbmNlcm5zLiAgUGVsYXNlDQo+ID4gdGFrZSBhIGxvb2suDQo+ID4NCj4g Pg0KPiA+IFRoYW5rcyENCj4gPg0KPiA+IEFsdmFyby4NCj4gPg0KPiA+DQo= From nobody Mon Dec 14 20:21:06 2015 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 3FAAB1B2A86 for ; Mon, 14 Dec 2015 20:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzm230dRRluR for ; Mon, 14 Dec 2015 20:21:03 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F0C1B2A80 for ; Mon, 14 Dec 2015 20:21:03 -0800 (PST) Received: from [192.168.1.13] (unknown [112.205.79.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id EE36018013CB for ; Tue, 15 Dec 2015 05:21:00 +0100 (CET) To: bess@ietf.org References: <565427E1.9070803@orange.com> <566E8BBF.5060204@alcatel-lucent.com> <566F194D.5060803@juniper.net> From: Loa Andersson Message-ID: <566F9526.2090008@pi.nu> Date: Tue, 15 Dec 2015 12:20:54 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <566F194D.5060803@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [bess] Introducing a one-implementation requirement before WG last calls 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, 15 Dec 2015 04:21:05 -0000 Folks, I'm mostly on the same page as Eric, if for no other reason that we have an implementation hurdle in the shepherds write-up. No need to raise it higher it already serve the purpose. /Loa On 2015-12-15 03:32, Eric Rosen wrote: > My opinion is unchanged; there is no need to impose any implementation > requirement, nor is there any need to add more process hurdles that > further slow down the progress of a document towards publication. > Certainly there is no need to gather details about implementations, > vendor releases, etc. The process is already slow enough and has enough > useless overhead. > > If folks object to the progression of a document, they are already free > to make those objections during last call. > > > > On 12/14/2015 4:28 AM, Martin Vigoureux wrote: >> WG, >> >> we have reviewed the different comments posted on the list in response >> to our initial proposal. >> After thinking further about that, we'd like to propose the following >> as a way forward: >> >> At the same time we issue a Working Group Last Call we would ask for >> knowledge of existing implementations, and the more details provided >> at that time, the better. >> In the situation where an implementation would exist we would proceed >> with submission to IESG. >> In the opposite situation (no implementation exists), we would >> systematically ask the WG for reasoned opinions regarding whether we >> should nevertheless proceed with submission to IESG. >> We will gauge consensus on that aspect. In case consensus is in favour >> of proceeding with submission to IESG we will do so. In the opposite >> case, we will put the document in a "Waiting for implementation" state >> until information on an existing implementation is brought to our >> knowledge or of the WG. >> >> Please share your views on that. >> >> Thank you >> >> M&T >> >> >> Le 24/11/2015 10:03, Thomas Morin a crit : >>> Hello everyone, >>> >>> Following the positive feedback received during BESS meeting in Yokohama >>> about introducing a one-implementation requirement in BESS, we propose >>> to do the following for future WG last calls: >>> >>> As a prerequisite before doing a working group last call on a document, >>> the chairs will ask the working group for known implementations of the >>> specifications; a relatively detailed level of information will be >>> required (e.g. "release x.y of solution z shipping date d", "all >>> features implemented", "partial implementation only", etc.) and everyone >>> will be invited to reply (not only co-authors of the specifications); >>> the chairs will then do the working group last call if satisfying >>> information was provided on at least one implementation. >>> >>> We are open for comments on this proposal until December 7th. >>> >>> Martin & Thomas >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Tue Dec 15 00:59:57 2015 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 4AEC21A00FD; Tue, 15 Dec 2015 00:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWwpv86PGyzJ; Tue, 15 Dec 2015 00:59:49 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B42C71A00FC; Tue, 15 Dec 2015 00:59:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A49E3BE32; Tue, 15 Dec 2015 08:59:47 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IebxuEaNO87h; Tue, 15 Dec 2015 08:59:45 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.31.96]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9598EBE2C; Tue, 15 Dec 2015 08:59:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450169985; bh=1vd5XuWZ/+Y12QTtgVwoyl6xqWyW7D5roAAqXQ5ZTnw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=SacBjXk3od27bUWRYy+rj/DUJsB4v39LES6oPln8pWnDhYTqSVjMdjyzvy9GRELQf LTCx0i7NoqkmKteCOlAqXemZvDyltD0VtPjHPCjs0vFi7BfrVS0JTjzH9HV7KyFObt QKi+CnrFbcHnBtAAuZvWxNUdhcA4rjeWpJkFrbTg= To: Xuxiaohu , "Alvaro Retana (aretana)" , The IESG References: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53D79@NKGEML512-MBS.china.huawei.com> <56617BAD.6070906@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB54209@NKGEML512-MBS.china.huawei.com> <566574D9.6030202@cs.tcd.ie> <566EC84E.7070600@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB55473@NKGEML512-MBS.china.huawei.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <566FD680.2060901@cs.tcd.ie> Date: Tue, 15 Dec 2015 08:59:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB55473@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" Subject: Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-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, 15 Dec 2015 08:59:52 -0000 Hiya, On 15/12/15 01:19, Xuxiaohu wrote: > Hi Stephen, > > It said "...using a strong security mechanism such as IPsec > [RFC4301]". Here IPsec is just mentioned as an example of a strong > security mechanism. Therefore, it doesn't exclude MACsec. Sure, but... The text that I suggested and that you said seemed good did include MACsec. On 09/12/15 07:47, Xuxiaohu wrote: >> So maybe something more like: >> >> "Inter data-centre traffic often carries highly sensitive information at higher >> layers that is not directly understood >> (parsed) within an egress or ingress PE. For example, migrating a VM will often >> mean moving private keys and other sensitive configuration information. For >> this reason inter data-centre traffic SHOULD always be protected for both >> confidentiality and integrity using a strong security mechanism such as IPsec [1] >> or MACsec [2] In future it may be feasible to protect that traffic within the MPLS >> layer [3] though at the time of writing the mechanism for that is not sufficiently >> mature to recommend. Exactly how such security mechanisms are deployed will >> vary from case to case, so securing the inter data-centre traffic may or may not >> involve deploying security mechanisms on the ingress/egress PEs or further >> "inside" the data centres concerned. Note though that if security is not deployed >> on the egress/ingress PEs there is a substantial risk that some sensitive traffic >> may be sent in clear and therefore be vulnerable to pervasive monitoring [4] or >> other attacks." > > Thanks a lot for your suggested text. If nobody object the > above text, I will add it in the next revision. > And indeed you added it all except for MACsec. And my question is not whether MACsec is excluded but rather why it was omitted, when afaik, it is what is most used for securing this particular kind of inter-DC traffic. (At least I believe that MACsec is what's most used there. If not, I'd be glad to know that.) So, why not include MACsec? Did someone object? If so, why? (And can you send a pointer to the WG list where that objection was raised so I can understand it better.) Thanks, S. > > Best regards, Xiaohu > >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Monday, December 14, 2015 >> 9:47 PM To: Alvaro Retana (aretana); Xuxiaohu; The IESG Cc: >> draft-ietf-bess-virtual-subnet@ietf.org; bess-chairs@ietf.org; >> martin.vigoureux@alcatel-lucent.com; bess@ietf.org Subject: Re: >> Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: >> (with DISCUSS and COMMENT) >> >> >> Hi, >> >> Can someone say why the mention of MACsec wasn't included? As I >> understand it, MACsec is what's mostly usable for inter-DC security >> so omitting it seems like a bad idea (or perhaps I'm misinformed) >> >> Thanks, S. >> >> On 14/12/15 13:34, Alvaro Retana (aretana) wrote: >>> Stephen: >>> >>> Hi! >>> >>> Xiaohu posted an update that we hope addresses your concerns. >>> Pelase take a look. >>> >>> >>> Thanks! >>> >>> Alvaro. >>> >>> From nobody Tue Dec 15 17:33:15 2015 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 214691A066C; Tue, 15 Dec 2015 17:33:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216013314.14350.59643.idtracker@ietfa.amsl.com> Date: Tue, 15 Dec 2015 17:33:14 -0800 Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, draft-ietf-bess-mvpn-extranet@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: [bess] Alia Atlas' No Objection on draft-ietf-bess-mvpn-extranet-04: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 01:33:14 -0000 Alia Atlas has entered the following ballot position for draft-ietf-bess-mvpn-extranet-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is quite a detailed read and despite the clarity of each section, hard to truly put together into a larger understanding. I was hoping for a section that would be Applicability or a table that gave the different dimensions and the options for each. I think adding such a section early in the document would really help with understanding what the different trade-offs and likely sets of choices might be. I also realize that many readers will be more familiar with the base technology and be able to work through the details with repeated readings. From nobody Tue Dec 15 20:30:00 2015 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 DF5DC1A6FDA; Tue, 15 Dec 2015 20:29:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216042958.21109.31460.idtracker@ietfa.amsl.com> Date: Tue, 15 Dec 2015 20:29:58 -0800 Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, draft-ietf-bess-mvpn-extranet@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: [bess] Terry Manderson's No Objection on draft-ietf-bess-mvpn-extranet-04: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 04:29:59 -0000 Terry Manderson has entered the following ballot position for draft-ietf-bess-mvpn-extranet-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is a comprehensive document. Kudos for writing it. However, is there a WG rationale as to why this document is structured as it is? It struck me when reading it there are 4 distinct books here on the various aspects of extranet multicast VPNs. Being: Overview and overlap/ambiguity w/prevention, Transmission models, Route distribution and communities (where the IANA req for the 2 communities ,ight live), and Control Plane concerns. Would that make it easier to implementers to comprehend? I don't agree with the document shepherd in that "I found the document (relatively) not hard to follow, if you read it end-to-end" - for me it made review a marathon. That said, I'm not the style police, so balloting no objection. I only saw one typo along the way ie VRFS instead of VRFs (page 9 second para) From nobody Wed Dec 16 06:41:44 2015 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 90AA61B2DE0; Wed, 16 Dec 2015 06:41:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216144143.16643.65106.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 06:41:43 -0800 Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, draft-ietf-bess-mvpn-extranet@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: [bess] Brian Haberman's Abstain on draft-ietf-bess-mvpn-extranet-04: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 14:41:43 -0000 Brian Haberman has entered the following ballot position for draft-ietf-bess-mvpn-extranet-04: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have to assume that there are vendors shipping this functionality... and, presumably, customers using it in some limited fashion. However, I find that this work has managed to make inter-domain IP multicast look simple and easy. I don't see any justification for why this approach is preferable to using native IP multicast approaches for what appears to be pre-provisioned distribution of multicast content between a small set of independent networks. That being said, I am not going to stand in the way of the publication of this document. That horse is out of the barn. From nobody Wed Dec 16 10:50:48 2015 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 EFD821A8879; Wed, 16 Dec 2015 10:50:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216185046.24427.14009.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 10:50:46 -0800 Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, draft-ietf-bess-mvpn-extranet@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: [bess] Ben Campbell's No Objection on draft-ietf-bess-mvpn-extranet-04: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 18:50:47 -0000 Ben Campbell has entered the following ballot position for draft-ietf-bess-mvpn-extranet-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share some of the concerns that the draft organization makes it harder to understand than it needs to be. For example, the overview doesn't start until page 9, and has quite a bit of dense technical material ahead of it. (But, as others have already said, I am not the style police.) From nobody Wed Dec 16 14:56:31 2015 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 21B861A9035 for ; Wed, 16 Dec 2015 14:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-2rU6qHSfSP for ; Wed, 16 Dec 2015 14:56:28 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8195D1A907B for ; Wed, 16 Dec 2015 14:56:28 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Martin Vigoureux'" , References: <565427E1.9070803@orange.com> <566E8BBF.5060204@alcatel-lucent.com> In-Reply-To: <566E8BBF.5060204@alcatel-lucent.com> Date: Wed, 16 Dec 2015 17:56:31 -0500 Message-ID: <05d401d13855$015e2de0$041a89a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKwGmMq3Zuu8CZowvV2ymdmXMMhqQIVd0OFnP/GRMA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [bess] Introducing a one-implementation requirement before WG last calls 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: Wed, 16 Dec 2015 22:56:30 -0000 M&T:=20 You handling of this discussion has been excellent.=20 I think you are making a sensible choice to look for an implementations details, and then provide the details to the WG. Your choice of one implementation sending things to the WG provides the WG with more information. You allowing a draft to go forward based on input from the = WG. One other thought, we might bring the subject of IDR and BESS handling = of the implementation requirements to the NANOG, RIPE, LACNIC, APNIC, and *NOGs. If they can give both IDR and BESS a list of their concerns, it would be helpful to know what the operators as a whole want us to do. = What needs 2 implementations versus 1 implementation. In the past, NANOG = folks have encouraged me (as IDR chair) for 2 implementations for basic IDR mechanisms. It would be good to get more feedback for 2016's = operators. =20 Cheerily,=20 Sue Hares -----Original Message----- From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Martin Vigoureux Sent: Monday, December 14, 2015 4:29 AM To: bess@ietf.org Subject: Re: [bess] Introducing a one-implementation requirement before = WG last calls WG, we have reviewed the different comments posted on the list in response = to our initial proposal. After thinking further about that, we'd like to propose the following as = a way forward: At the same time we issue a Working Group Last Call we would ask for knowledge of existing implementations, and the more details provided at = that time, the better. In the situation where an implementation would exist we would proceed = with submission to IESG. In the opposite situation (no implementation exists), we would systematically ask the WG for reasoned opinions regarding whether we = should nevertheless proceed with submission to IESG. We will gauge consensus on that aspect. In case consensus is in favour = of proceeding with submission to IESG we will do so. In the opposite case, = we will put the document in a "Waiting for implementation" state until information on an existing implementation is brought to our knowledge or = of the WG. Please share your views on that. Thank you M&T Le 24/11/2015 10:03, Thomas Morin a =E9crit : > Hello everyone, > > Following the positive feedback received during BESS meeting in=20 > Yokohama about introducing a one-implementation requirement in BESS,=20 > we propose to do the following for future WG last calls: > > As a prerequisite before doing a working group last call on a=20 > document, the chairs will ask the working group for known=20 > implementations of the specifications; a relatively detailed level of=20 > information will be required (e.g. "release x.y of solution z shipping = > date d", "all features implemented", "partial implementation only",=20 > etc.) and everyone will be invited to reply (not only co-authors of=20 > the specifications); the chairs will then do the working group last=20 > call if satisfying information was provided on at least one implementation. > > We are open for comments on this proposal until December 7th. > > Martin & Thomas > > _______________________________________________ > 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 Dec 17 05:30:53 2015 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 733571A1BCD; Thu, 17 Dec 2015 05:30:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> Date: Thu, 17 Dec 2015 05:30:49 -0800 Archived-At: Cc: draft-ietf-bess-mvpn-extranet@ietf.org, shares@ndzh.com, aretana@cisco.com, bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: [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 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 Dec 2015 13:30:49 -0000 Benoit Claise has entered the following ballot position for draft-ietf-bess-mvpn-extranet-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- As mentioned in Sue Hares' OPS DIR, 3 major concerns. The last one is actually for the security ADs. 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 Please provide the type of detail as show in RFC 4360 sections 3.1, 3.2, and 3.3. 2) Why is there no Deployment considerations section? The whole draft is a set of rules for handling policy, BGP A-D routes, tunnel set-up, and PIM Join/leaves in the case of an intra net. Unless these rules are followed exactly, traffic may flow into a VPN it is not suppose to. If the customer and the SP must coordinate on setting up filters, the procedure is outside the document. An error in any of these set-ups is considered a “security violation”. Milo Medin stated “with enough trust” a rock can fly to the moon. However, the NASA flights were fragile and risky. In the journey to the moon, there was no other choice. Instrumentation has 4-5 backups. In this set-up, one has to ask “is there another choice” to this whole design that seem fragile addition of extranets to an intra-AS multicast design. If the design is not fragile, then there should be a deployment section indicating how to manage the RTs, RDs, and policy set-up. Perhaps experience with the Intra-As has shown deployment tips that would make this less fragile. If so, it would be good to include an operations consideration section. If a new class of tools provides monitoring or provisioning, mentioning these would be useful. If yang modules are being developed, that would be useful. Places that indicate issues with violated constraint: p. 11, 12, 19 (2.3.2 – a priori knowledge, inability to detect), , p. 25 last paragraph (violation of constraints will cause things to not work. However, only policy can control), p. 27 4.2.2 (1st paragraph, Route Reflector must not change), p. 31 (5.1, first paragraph), 3) Is security section really a security section? It seems more like “do this policy” or this will fail. It should get a stronger review from the security directorate ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial suggestions: Summary: In general the authors provide dense English text to describe this rules. In general the English text contains valid complex sentences. However, a few things should be suggested: 1) PTA – define it in a definition section or spell out the abbreviation 2) Phrases like “the RT RT-R” become overly dense. Use “Route Target RT-R”. 3) Breaking up section 6.2.1 – with subjection and subtitles would make it more readable, 4) P. 36 second paragraph. The reason for the “MUST” in 1st full paragraph is a bit vague. It seems logical, but the reasoning is just vague in the text. 5) paragraph 2 in page 47 (section 7.3.1) is awkward, please reword. 6) Paragraph 5 in page 47 (section 7.3.1) – does not explain why the condition should hold. The authors have done this in eac other case, so it seems inconsistent. 7) Page 53 – section 7.4.5 paragraph 3 “VRF route Import EC” – please spell out first usage and give abbreviation (VRF Route Import Extended Community (EC). From nobody Thu Dec 17 05:54:28 2015 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 2E8A11B2DE1; Thu, 17 Dec 2015 05:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRehBTK-d5B7; Thu, 17 Dec 2015 05:54:23 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F821B2DD4; Thu, 17 Dec 2015 05:54:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D94D2BEA4; Thu, 17 Dec 2015 13:54:21 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEv7RskA_KJt; Thu, 17 Dec 2015 13:54:20 +0000 (GMT) Received: from [10.87.48.95] (unknown [86.46.31.96]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EED22BE9C; Thu, 17 Dec 2015 13:54:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450360460; bh=6NyT3zoGk2Fl5NzeCQpnjTN85mFaRtlUMJOjiYokH64=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=PMRs+PJwQ2UoaHgMxxnCua5Y/TeAiGwDsfM6Jt4p5ESkCTu0GhRH81OMhSw/ggLhl BOiM9hd/IuL63vcE9vsZVvBwloL1RBth16NYM7WGkwbPbWvoySOwPOohYxGt3kHOSh mHOdPph5jGHdHoHEksh6GkD4JE9B9W7QZ1b/1Z48= To: Benoit Claise , The IESG References: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5672BE86.3090505@cs.tcd.ie> Date: Thu, 17 Dec 2015 13:54:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-bess-mvpn-extranet@ietf.org, bess@ietf.org, aretana@cisco.com, bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, shares@ndzh.com 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: Thu, 17 Dec 2015 13:54:25 -0000 On 17/12/15 13:30, Benoit Claise wrote: > 3) Is security section really a security section? It seems more like > “do this policy” or this will fail. It should get a stronger review from > the security directorate I've not posted a ballot for this one as my question is more "What does P really stand for in this kind of VPN?" and I don't really get what here is new that requires a PS. So any security discuss would likely be met by "not new, can't change" and is therefore perhaps not the best use of our time. It'd be better if we could get some folks to try to re-instate the P == Private in VPN. (But that is admittedly very hard if one really has to do multicast.) S. From nobody Thu Dec 17 06:00:47 2015 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 712411B2DED; Thu, 17 Dec 2015 06:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrosE5Vm2_Xw; Thu, 17 Dec 2015 06:00:41 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4E11B2D01; Thu, 17 Dec 2015 06:00:39 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Stephen Farrell'" , "'Benoit Claise'" , "'The IESG'" References: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> <5672BE86.3090505@cs.tcd.ie> In-Reply-To: <5672BE86.3090505@cs.tcd.ie> Date: Thu, 17 Dec 2015 09:00:40 -0500 Message-ID: <003001d138d3$50bf8a40$f23e9ec0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLS05QNmCOjnF9/ygy/QKz2M1D3eQIOAow0nLuOblA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, draft-ietf-bess-mvpn-extranet@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: Thu, 17 Dec 2015 14:00:45 -0000 Stephen:=20 They are adding 2 BGP Extended communities. They are modifying rules = for distribution of BGP routes and PIM trees in the case of MPLS VPNs = supporting multicast. The thing that worries me is they are stating = that "breaking any of the policy rules" is a security consideration. = However, as far as I can tell the specification lacks an indication of = how to trace or audit such rules. =20 P as to "Private" VPNS is simply an indication of overlay VPNS used for = a set of customers. Just one variant of routing technology specified, = IMHO.=20 Sue=20 -----Original Message----- From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, December 17, 2015 8:54 AM To: Benoit Claise; The IESG Cc: draft-ietf-bess-mvpn-extranet@ietf.org; bess@ietf.org; = aretana@cisco.com; bess-chairs@ietf.org; = martin.vigoureux@alcatel-lucent.com; shares@ndzh.com Subject: Re: [bess] Benoit Claise's Discuss on = draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT) On 17/12/15 13:30, Benoit Claise wrote: > 3) Is security section really a security section? It seems more = like > =E2=80=9Cdo this policy=E2=80=9D or this will fail. It should get a = stronger review=20 > from the security directorate I've not posted a ballot for this one as my question is more "What does = P really stand for in this kind of VPN?" and I don't really get what = here is new that requires a PS. So any security discuss would likely be = met by "not new, can't change" and is therefore perhaps not the best use = of our time. It'd be better if we could get some folks to try to = re-instate the P =3D=3D Private in VPN. (But that is admittedly very = hard if one really has to do multicast.) S. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess From nobody Thu Dec 17 17:47:11 2015 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 24B461B31ED; Thu, 17 Dec 2015 17:47:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151218014710.16763.71345.idtracker@ietfa.amsl.com> Date: Thu, 17 Dec 2015 17:47:10 -0800 Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, draft-ietf-bess-mvpn-extranet@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: [bess] Kathleen Moriarty's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 01:47:10 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-bess-mvpn-extranet-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I just have one question/request to improve the security consideration section. The only security mentioned in this draft is what's called a "security violation", where traffic may go to the incorrect "VPN" endpoint. If you are worried about traffic winding up in the wrong place, why is there no consideration for observing this traffic on the wire? Since there is no encryption, wouldn't this also be a security consideration to call out specifically? Mention of the possibility of active attacks that could alter or tamper with the traffic or passive attacks that could observe the traffic as a risk due to lack of encryption (confidentiality protection) would help or a reason why this doesn't matter. Thanks! From nobody Thu Dec 17 22:26:00 2015 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 115651B339F; Thu, 17 Dec 2015 22:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4nMVgOvlt8H; Thu, 17 Dec 2015 22:25:56 -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 2D3951B339D; Thu, 17 Dec 2015 22:25:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBS92951; Fri, 18 Dec 2015 06:25:52 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 18 Dec 2015 06:25:51 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.64]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Fri, 18 Dec 2015 14:25:43 +0800 From: Xuxiaohu To: Stephen Farrell , "Alvaro Retana (aretana)" , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT) Thread-Index: AQHRLdaOLk8nhORYXUKrCN/X2riedp66D2jwgAAf9ICABKhN0IAAFESAgAsadwCAAAObAIABRkxQ///7zQCABQwf4A== Date: Fri, 18 Dec 2015 06:25:43 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB56196@NKGEML512-MBS.china.huawei.com> References: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53D79@NKGEML512-MBS.china.huawei.com> <56617BAD.6070906@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB54209@NKGEML512-MBS.china.huawei.com> <566574D9.6030202@cs.tcd.ie> <566EC84E.7070600@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB55473@NKGEML512-MBS.china.huawei.com> <566FD680.2060901@cs.tcd.ie> In-Reply-To: <566FD680.2060901@cs.tcd.ie> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5673A6F0.012A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.64, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 636d13f7260e6fc54f0a0d46d7fffea7 Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" Subject: Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-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: Fri, 18 Dec 2015 06:25:59 -0000 SGkgU3RlcGhlbiwNCg0KU29ycnkgZm9yIG15IGxhdGUgcmVzcG9uc2UuIFRoZSByZWFzb24gdGhh dCBJIGhlc2l0YXRlZCB0byBhZGQgTUFDc2VjIGFzIGFuIGFkZGl0aW9uYWwgZXhhbXBsZSBvZiBh IHN0cm9uZyBzZWN1cml0eSBtZWNoYW5pc20gaXMgYXMgZm9sbG93czogTUFDc2VjIGlzIGEgbGF5 ZXIyIGVuY3J5cHRpb24gbWVjaGFuaXNtIGFuZCB0aGVyZWZvcmUgaXQgc2VlbXMgbm90IG11Y2gg c3VpdGFibGUgdG8gcHJvdGVjdCBJUCBlbmNhcHN1bGF0ZWQgdHJhZmZpYyBiZXR3ZWVuIFBFIHJv dXRlcnMsIHVubGVzcyB0aGVzZSBQRSByb3V0ZXJzIGFyZSBkaXJlY3RseSBjb25uZWN0ZWQgdG8g ZWFjaCBvdGhlciBhdCBMYXllcjIuIA0KDQpJZiBteSB1bmRlcnN0YW5kIGlzIHdyb25nLCB3b3Vs ZCB5b3UgcGxlYXNlIGV4cGxhaW4gaG93IHRvIHVzZSBNQUNzZWMgdG8gcHJvdGVjdCB0aGUgSVAg ZW5jYXBzdWxhdGVkIHRyYWZmaWMgYmV0d2VlbiBQRSByb3V0ZXJzIHdoaWNoIGFyZSBub3QgZGly ZWN0bHkgY29ubmVjdGVkPyBPciB3b3VsZCB5b3UgcGxlYXNlIHByb3ZpZGUgbWUgYSBsaW5rIHRv IHNvbWUgUkZDIHdoaWNoIHRhbGtzIGFib3V0IHRoaXMgdXNhZ2U/DQoNCkJlc3QgcmVnYXJkcywN ClhpYW9odQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFN0ZXBoZW4g RmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdDQo+IFNlbnQ6IFR1ZXNk YXksIERlY2VtYmVyIDE1LCAyMDE1IDU6MDAgUE0NCj4gVG86IFh1eGlhb2h1OyBBbHZhcm8gUmV0 YW5hIChhcmV0YW5hKTsgVGhlIElFU0cNCj4gQ2M6IGRyYWZ0LWlldGYtYmVzcy12aXJ0dWFsLXN1 Ym5ldEBpZXRmLm9yZzsgYmVzcy1jaGFpcnNAaWV0Zi5vcmc7DQo+IG1hcnRpbi52aWdvdXJldXhA YWxjYXRlbC1sdWNlbnQuY29tOyBiZXNzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBTdGVwaGVu IEZhcnJlbGwncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtYmVzcy12aXJ0dWFsLXN1Ym5ldC0wNjog KHdpdGgNCj4gRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IA0KPiBIaXlhLA0KPiANCj4gT24g MTUvMTIvMTUgMDE6MTksIFh1eGlhb2h1IHdyb3RlOg0KPiA+IEhpIFN0ZXBoZW4sDQo+ID4NCj4g PiBJdCBzYWlkICIuLi51c2luZyBhIHN0cm9uZyBzZWN1cml0eSBtZWNoYW5pc20gc3VjaCBhcyBJ UHNlYw0KPiA+IFtSRkM0MzAxXSIuIEhlcmUgSVBzZWMgaXMganVzdCBtZW50aW9uZWQgYXMgYW4g ZXhhbXBsZSBvZiBhIHN0cm9uZw0KPiA+IHNlY3VyaXR5IG1lY2hhbmlzbS4gVGhlcmVmb3JlLCBp dCBkb2Vzbid0IGV4Y2x1ZGUgTUFDc2VjLg0KPiANCj4gU3VyZSwgYnV0Li4uDQo+IA0KPiBUaGUg dGV4dCB0aGF0IEkgc3VnZ2VzdGVkIGFuZCB0aGF0IHlvdSBzYWlkIHNlZW1lZCBnb29kIGRpZCBp bmNsdWRlIE1BQ3NlYy4NCj4gDQo+IE9uIDA5LzEyLzE1IDA3OjQ3LCBYdXhpYW9odSB3cm90ZToN Cj4gPj4gU28gbWF5YmUgc29tZXRoaW5nIG1vcmUgbGlrZToNCj4gPj4NCj4gPj4gIkludGVyIGRh dGEtY2VudHJlIHRyYWZmaWMgb2Z0ZW4gY2FycmllcyBoaWdobHkgc2Vuc2l0aXZlIGluZm9ybWF0 aW9uDQo+IGF0IGhpZ2hlcg0KPiA+PiBsYXllcnMgdGhhdCBpcyBub3QgZGlyZWN0bHkgdW5kZXJz dG9vZA0KPiA+PiAocGFyc2VkKSB3aXRoaW4gYW4gZWdyZXNzIG9yIGluZ3Jlc3MgUEUuIEZvciBl eGFtcGxlLCBtaWdyYXRpbmcgYSBWTQ0KPiB3aWxsIG9mdGVuDQo+ID4+IG1lYW4gbW92aW5nIHBy aXZhdGUga2V5cyBhbmQgb3RoZXIgc2Vuc2l0aXZlIGNvbmZpZ3VyYXRpb24NCj4gaW5mb3JtYXRp b24uIEZvcg0KPiA+PiB0aGlzIHJlYXNvbiBpbnRlciBkYXRhLWNlbnRyZSB0cmFmZmljIFNIT1VM RCBhbHdheXMgYmUgcHJvdGVjdGVkIGZvcg0KPiA+PiBib3RoIGNvbmZpZGVudGlhbGl0eSBhbmQg aW50ZWdyaXR5IHVzaW5nIGEgc3Ryb25nIHNlY3VyaXR5IG1lY2hhbmlzbQ0KPiA+PiBzdWNoDQo+ IGFzIElQc2VjIFsxXQ0KPiA+PiBvciBNQUNzZWMgWzJdIEluIGZ1dHVyZSBpdCBtYXkgYmUgZmVh c2libGUgdG8gcHJvdGVjdCB0aGF0IHRyYWZmaWMNCj4gd2l0aGluIHRoZSBNUExTDQo+ID4+IGxh eWVyIFszXSB0aG91Z2ggYXQgdGhlIHRpbWUgb2Ygd3JpdGluZyB0aGUgbWVjaGFuaXNtIGZvciB0 aGF0IGlzIG5vdA0KPiBzdWZmaWNpZW50bHkNCj4gPj4gbWF0dXJlIHRvIHJlY29tbWVuZC4gRXhh Y3RseSBob3cgc3VjaCBzZWN1cml0eSBtZWNoYW5pc21zIGFyZQ0KPiBkZXBsb3llZCB3aWxsDQo+ ID4+IHZhcnkgZnJvbSBjYXNlIHRvIGNhc2UsIHNvIHNlY3VyaW5nIHRoZSBpbnRlciBkYXRhLWNl bnRyZSB0cmFmZmljIG1heQ0KPiBvciBtYXkgbm90DQo+ID4+IGludm9sdmUgZGVwbG95aW5nIHNl Y3VyaXR5IG1lY2hhbmlzbXMgb24gdGhlIGluZ3Jlc3MvZWdyZXNzIFBFcyBvcg0KPiBmdXJ0aGVy DQo+ID4+ICJpbnNpZGUiIHRoZSBkYXRhIGNlbnRyZXMgY29uY2VybmVkLiBOb3RlIHRob3VnaCB0 aGF0IGlmIHNlY3VyaXR5IGlzDQo+IG5vdCBkZXBsb3llZA0KPiA+PiBvbiB0aGUgZWdyZXNzL2lu Z3Jlc3MgUEVzIHRoZXJlIGlzIGEgc3Vic3RhbnRpYWwgcmlzayB0aGF0IHNvbWUNCj4gc2Vuc2l0 aXZlIHRyYWZmaWMNCj4gPj4gbWF5IGJlIHNlbnQgaW4gY2xlYXIgYW5kIHRoZXJlZm9yZSBiZSB2 dWxuZXJhYmxlIHRvIHBlcnZhc2l2ZQ0KPiBtb25pdG9yaW5nIFs0XSBvcg0KPiA+PiBvdGhlciBh dHRhY2tzLiINCj4gPg0KPiA+IFRoYW5rcyBhIGxvdCBmb3IgeW91ciBzdWdnZXN0ZWQgdGV4dC4g SWYgbm9ib2R5IG9iamVjdCB0aGUgYWJvdmUgdGV4dCwNCj4gPiBJIHdpbGwgYWRkIGl0IGluIHRo ZSBuZXh0IHJldmlzaW9uLg0KPiA+DQo+IA0KPiBBbmQgaW5kZWVkIHlvdSBhZGRlZCBpdCBhbGwg ZXhjZXB0IGZvciBNQUNzZWMuDQo+IA0KPiBBbmQgbXkgcXVlc3Rpb24gaXMgbm90IHdoZXRoZXIg TUFDc2VjIGlzIGV4Y2x1ZGVkIGJ1dCByYXRoZXIgd2h5IGl0IHdhcw0KPiBvbWl0dGVkLCB3aGVu IGFmYWlrLCBpdCBpcyB3aGF0IGlzIG1vc3QgdXNlZCBmb3Igc2VjdXJpbmcgdGhpcyBwYXJ0aWN1 bGFyIGtpbmQgb2YNCj4gaW50ZXItREMgdHJhZmZpYy4gKEF0IGxlYXN0IEkgYmVsaWV2ZSB0aGF0 IE1BQ3NlYyBpcyB3aGF0J3MgbW9zdCB1c2VkIHRoZXJlLiBJZiBub3QsDQo+IEknZCBiZSBnbGFk IHRvIGtub3cgdGhhdC4pDQo+IA0KPiBTbywgd2h5IG5vdCBpbmNsdWRlIE1BQ3NlYz8gRGlkIHNv bWVvbmUgb2JqZWN0PyBJZiBzbywgd2h5Pw0KPiAoQW5kIGNhbiB5b3Ugc2VuZCBhIHBvaW50ZXIg dG8gdGhlIFdHIGxpc3Qgd2hlcmUgdGhhdCBvYmplY3Rpb24gd2FzIHJhaXNlZCBzbyBJDQo+IGNh biB1bmRlcnN0YW5kIGl0IGJldHRlci4pDQo+IA0KPiBUaGFua3MsDQo+IFMuDQo+IA0KPiANCj4g Pg0KPiA+IEJlc3QgcmVnYXJkcywgWGlhb2h1DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0gRnJvbTogU3RlcGhlbiBGYXJyZWxsDQo+ID4+IFttYWlsdG86c3RlcGhlbi5mYXJy ZWxsQGNzLnRjZC5pZV0gU2VudDogTW9uZGF5LCBEZWNlbWJlciAxNCwgMjAxNQ0KPiA+PiA5OjQ3 IFBNIFRvOiBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKTsgWHV4aWFvaHU7IFRoZSBJRVNHIENjOg0K PiA+PiBkcmFmdC1pZXRmLWJlc3MtdmlydHVhbC1zdWJuZXRAaWV0Zi5vcmc7IGJlc3MtY2hhaXJz QGlldGYub3JnOw0KPiA+PiBtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbTsgYmVz c0BpZXRmLm9yZyBTdWJqZWN0OiBSZToNCj4gPj4gU3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3VzcyBv biBkcmFmdC1pZXRmLWJlc3MtdmlydHVhbC1zdWJuZXQtMDY6DQo+ID4+ICh3aXRoIERJU0NVU1Mg YW5kIENPTU1FTlQpDQo+ID4+DQo+ID4+DQo+ID4+IEhpLA0KPiA+Pg0KPiA+PiBDYW4gc29tZW9u ZSBzYXkgd2h5IHRoZSBtZW50aW9uIG9mIE1BQ3NlYyB3YXNuJ3QgaW5jbHVkZWQ/IEFzIEkNCj4g Pj4gdW5kZXJzdGFuZCBpdCwgTUFDc2VjIGlzIHdoYXQncyBtb3N0bHkgdXNhYmxlIGZvciBpbnRl ci1EQyBzZWN1cml0eQ0KPiA+PiBzbyBvbWl0dGluZyBpdCBzZWVtcyBsaWtlIGEgYmFkIGlkZWEg KG9yIHBlcmhhcHMgSSdtIG1pc2luZm9ybWVkKQ0KPiA+Pg0KPiA+PiBUaGFua3MsIFMuDQo+ID4+ DQo+ID4+IE9uIDE0LzEyLzE1IDEzOjM0LCBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSB3cm90ZToN Cj4gPj4+IFN0ZXBoZW46DQo+ID4+Pg0KPiA+Pj4gSGkhDQo+ID4+Pg0KPiA+Pj4gWGlhb2h1IHBv c3RlZCBhbiB1cGRhdGUgdGhhdCB3ZSBob3BlIGFkZHJlc3NlcyB5b3VyIGNvbmNlcm5zLg0KPiA+ Pj4gUGVsYXNlIHRha2UgYSBsb29rLg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBUaGFua3MhDQo+ID4+ Pg0KPiA+Pj4gQWx2YXJvLg0KPiA+Pj4NCj4gPj4+DQo= From nobody Thu Dec 17 23:20:49 2015 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 8AEDD1B330F; Thu, 17 Dec 2015 23:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y87Vba5t6ZWi; Thu, 17 Dec 2015 23:20:41 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4A41B2F62; Thu, 17 Dec 2015 23:20:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 25EE6BEC3; Fri, 18 Dec 2015 07:20:38 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHkfPkDZ4jwe; Fri, 18 Dec 2015 07:20:36 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.22.208]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CC975BEBB; Fri, 18 Dec 2015 07:20:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450423236; bh=lx0z2S8gP5E8nJvfbYG9MwFgw1oAiyjf1fHYMA54D2o=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=HSxQ4LMFLvQQu2M4K3rpm6SQrgbH61Zz2byJFuUF5suS+mvEL31iiAfGv/5ocfeMZ ZmzJu8WhnNUvv3PaSlRK5iVnjt4yWoSKqrPmI/k1EBVHYuE11sCab/jqZoBp+6Ne7W k5sVxn6EX7uX53ENa5BKHG1G5QWkokMo/7/4S7qo= To: Xuxiaohu , "Alvaro Retana (aretana)" , The IESG References: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53D79@NKGEML512-MBS.china.huawei.com> <56617BAD.6070906@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB54209@NKGEML512-MBS.china.huawei.com> <566574D9.6030202@cs.tcd.ie> <566EC84E.7070600@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB55473@NKGEML512-MBS.china.huawei.com> <566FD680.2060901@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB56196@NKGEML512-MBS.china.huawei.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5673B3C3.7020300@cs.tcd.ie> Date: Fri, 18 Dec 2015 07:20:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB56196@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" Subject: Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-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: Fri, 18 Dec 2015 07:20:44 -0000 On 18/12/15 06:25, Xuxiaohu wrote: > Hi Stephen, > > Sorry for my late response. The reason that I hesitated to add MACsec > as an additional example of a strong security mechanism is as > follows: MACsec is a layer2 encryption mechanism and therefore it > seems not much suitable to protect IP encapsulated traffic between PE > routers, unless these PE routers are directly connected to each other > at Layer2. My belief is that such a scenario can be the case for some inter-DC links. That's not based on real experience though so I'm open to correction. Hopefully, someone getting this mail knows the answer and can tell us if MACsec really is worth mentioning. (If not, I'm now curious enough to try go chase down the answer:-) > If my understand is wrong, would you please explain how to use MACsec > to protect the IP encapsulated traffic between PE routers which are > not directly connected? Or would you please provide me a link to some > RFC which talks about this usage? I don't believe there is. At that point you have to go up the stack to MPLS-OS maybe, or IPsec. But the text does already cover this. Cheers, S. > > Best regards, Xiaohu > >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Tuesday, December 15, 2015 >> 5:00 PM To: Xuxiaohu; Alvaro Retana (aretana); The IESG Cc: >> draft-ietf-bess-virtual-subnet@ietf.org; bess-chairs@ietf.org; >> martin.vigoureux@alcatel-lucent.com; bess@ietf.org Subject: Re: >> Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: >> (with DISCUSS and COMMENT) >> >> >> Hiya, >> >> On 15/12/15 01:19, Xuxiaohu wrote: >>> Hi Stephen, >>> >>> It said "...using a strong security mechanism such as IPsec >>> [RFC4301]". Here IPsec is just mentioned as an example of a >>> strong security mechanism. Therefore, it doesn't exclude MACsec. >> >> Sure, but... >> >> The text that I suggested and that you said seemed good did include >> MACsec. >> >> On 09/12/15 07:47, Xuxiaohu wrote: >>>> So maybe something more like: >>>> >>>> "Inter data-centre traffic often carries highly sensitive >>>> information >> at higher >>>> layers that is not directly understood (parsed) within an >>>> egress or ingress PE. For example, migrating a VM >> will often >>>> mean moving private keys and other sensitive configuration >> information. For >>>> this reason inter data-centre traffic SHOULD always be >>>> protected for both confidentiality and integrity using a strong >>>> security mechanism such >> as IPsec [1] >>>> or MACsec [2] In future it may be feasible to protect that >>>> traffic >> within the MPLS >>>> layer [3] though at the time of writing the mechanism for that >>>> is not >> sufficiently >>>> mature to recommend. Exactly how such security mechanisms are >> deployed will >>>> vary from case to case, so securing the inter data-centre >>>> traffic may >> or may not >>>> involve deploying security mechanisms on the ingress/egress PEs >>>> or >> further >>>> "inside" the data centres concerned. Note though that if >>>> security is >> not deployed >>>> on the egress/ingress PEs there is a substantial risk that >>>> some >> sensitive traffic >>>> may be sent in clear and therefore be vulnerable to pervasive >> monitoring [4] or >>>> other attacks." >>> >>> Thanks a lot for your suggested text. If nobody object the above >>> text, I will add it in the next revision. >>> >> >> And indeed you added it all except for MACsec. >> >> And my question is not whether MACsec is excluded but rather why it >> was omitted, when afaik, it is what is most used for securing this >> particular kind of inter-DC traffic. (At least I believe that >> MACsec is what's most used there. If not, I'd be glad to know >> that.) >> >> So, why not include MACsec? Did someone object? If so, why? (And >> can you send a pointer to the WG list where that objection was >> raised so I can understand it better.) >> >> Thanks, S. >> >> >>> >>> Best regards, Xiaohu >>> >>>> -----Original Message----- From: Stephen Farrell >>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Monday, December 14, >>>> 2015 9:47 PM To: Alvaro Retana (aretana); Xuxiaohu; The IESG >>>> Cc: draft-ietf-bess-virtual-subnet@ietf.org; >>>> bess-chairs@ietf.org; martin.vigoureux@alcatel-lucent.com; >>>> bess@ietf.org Subject: Re: Stephen Farrell's Discuss on >>>> draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT) >>>> >>>> >>>> Hi, >>>> >>>> Can someone say why the mention of MACsec wasn't included? As >>>> I understand it, MACsec is what's mostly usable for inter-DC >>>> security so omitting it seems like a bad idea (or perhaps I'm >>>> misinformed) >>>> >>>> Thanks, S. >>>> >>>> On 14/12/15 13:34, Alvaro Retana (aretana) wrote: >>>>> Stephen: >>>>> >>>>> Hi! >>>>> >>>>> Xiaohu posted an update that we hope addresses your >>>>> concerns. Pelase take a look. >>>>> >>>>> >>>>> Thanks! >>>>> >>>>> Alvaro. >>>>> >>>>> From nobody Fri Dec 18 01:26:50 2015 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 5BD501B34D7; Fri, 18 Dec 2015 01:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMxGd1OzUSQ4; Fri, 18 Dec 2015 01:26:44 -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 6376F1B34D8; Fri, 18 Dec 2015 01:26:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFP69632; Fri, 18 Dec 2015 09:26:39 +0000 (GMT) Received: from lhreml703-cah.china.huawei.com (10.201.5.104) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 18 Dec 2015 09:26:37 +0000 Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 18 Dec 2015 09:26:37 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.64]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 18 Dec 2015 17:26:32 +0800 From: Xuxiaohu To: Stephen Farrell , "Alvaro Retana (aretana)" , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT) Thread-Index: AQHRLdaOLk8nhORYXUKrCN/X2riedp66D2jwgAAf9ICABKhN0IAAFESAgAsadwCAAAObAIABRkxQ///7zQCABQwf4P//jyyAgACaRjA= Date: Fri, 18 Dec 2015 09:26:31 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB5622B@NKGEML512-MBS.china.huawei.com> References: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53D79@NKGEML512-MBS.china.huawei.com> <56617BAD.6070906@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB54209@NKGEML512-MBS.china.huawei.com> <566574D9.6030202@cs.tcd.ie> <566EC84E.7070600@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB55473@NKGEML512-MBS.china.huawei.com> <566FD680.2060901@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB56196@NKGEML512-MBS.china.huawei.com> <5673B3C3.7020300@cs.tcd.ie> In-Reply-To: <5673B3C3.7020300@cs.tcd.ie> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5673D151.0047, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.64, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a31d151a71e39ce19f31b3d9f3ecb57d Archived-At: Cc: "draft-ietf-bess-virtual-subnet@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" Subject: Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-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: Fri, 18 Dec 2015 09:26:47 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3RlcGhlbiBGYXJyZWxs IFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0NCj4gU2VudDogRnJpZGF5LCBEZWNl bWJlciAxOCwgMjAxNSAzOjIxIFBNDQo+IFRvOiBYdXhpYW9odTsgQWx2YXJvIFJldGFuYSAoYXJl dGFuYSk7IFRoZSBJRVNHDQo+IENjOiBkcmFmdC1pZXRmLWJlc3MtdmlydHVhbC1zdWJuZXRAaWV0 Zi5vcmc7IGJlc3MtY2hhaXJzQGlldGYub3JnOw0KPiBtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwt bHVjZW50LmNvbTsgYmVzc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogU3RlcGhlbiBGYXJyZWxs J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWJlc3MtdmlydHVhbC1zdWJuZXQtMDY6ICh3aXRoDQo+ IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiANCj4gDQo+IE9uIDE4LzEyLzE1IDA2OjI1LCBY dXhpYW9odSB3cm90ZToNCj4gPiBIaSBTdGVwaGVuLA0KPiA+DQo+ID4gU29ycnkgZm9yIG15IGxh dGUgcmVzcG9uc2UuIFRoZSByZWFzb24gdGhhdCBJIGhlc2l0YXRlZCB0byBhZGQgTUFDc2VjDQo+ ID4gYXMgYW4gYWRkaXRpb25hbCBleGFtcGxlIG9mIGEgc3Ryb25nIHNlY3VyaXR5IG1lY2hhbmlz bSBpcyBhcw0KPiA+IGZvbGxvd3M6IE1BQ3NlYyBpcyBhIGxheWVyMiBlbmNyeXB0aW9uIG1lY2hh bmlzbSBhbmQgdGhlcmVmb3JlIGl0DQo+ID4gc2VlbXMgbm90IG11Y2ggc3VpdGFibGUgdG8gcHJv dGVjdCBJUCBlbmNhcHN1bGF0ZWQgdHJhZmZpYyBiZXR3ZWVuIFBFDQo+ID4gcm91dGVycywgdW5s ZXNzIHRoZXNlIFBFIHJvdXRlcnMgYXJlIGRpcmVjdGx5IGNvbm5lY3RlZCB0byBlYWNoIG90aGVy DQo+ID4gYXQgTGF5ZXIyLg0KPiANCj4gTXkgYmVsaWVmIGlzIHRoYXQgc3VjaCBhIHNjZW5hcmlv IGNhbiBiZSB0aGUgY2FzZSBmb3Igc29tZSBpbnRlci1EQyBsaW5rcy4gVGhhdCdzDQo+IG5vdCBi YXNlZCBvbiByZWFsIGV4cGVyaWVuY2UgdGhvdWdoIHNvIEknbSBvcGVuIHRvIGNvcnJlY3Rpb24u IEhvcGVmdWxseSwNCj4gc29tZW9uZSBnZXR0aW5nIHRoaXMgbWFpbCBrbm93cyB0aGUgYW5zd2Vy IGFuZCBjYW4gdGVsbCB1cyBpZiBNQUNzZWMgcmVhbGx5IGlzDQo+IHdvcnRoIG1lbnRpb25pbmcu IChJZiBub3QsIEknbSBub3cgY3VyaW91cyBlbm91Z2ggdG8gdHJ5IGdvIGNoYXNlIGRvd24gdGhl DQo+IGFuc3dlcjotKQ0KPiANCg0KSGkgU3RlcGhlbiwNCg0KVGhlIGZvbGxvd2luZyBhcmUgc29t ZSBtYXRlcmlhbHMgcmVsYXRlZCB0byBNQUNzZWMgYW5kIE1QTFMgVlBOOg0KDQpodHRwczovL3d3 dy5icm9jYWRlLmNvbS9jb250ZW50L2RhbS9jb21tb24vZG9jdW1lbnRzL2NvbnRlbnQtdHlwZXMv ZmVhdHVyZS1ndWlkZS9icm9jYWRlLW1hY3NlYy1mZy5wZGYNCmh0dHA6Ly93d3cuanVuaXBlci5u ZXQvdGVjaHB1YnMvZW5fVVMvcmVsZWFzZS1pbmRlcGVuZGVudC9uY2UvaW5mb3JtYXRpb24tcHJv ZHVjdHMvcGF0aHdheS1wYWdlcy9uY2UvbmNlLTEzNy1tYWNzZWMtb3Zlci1tcGxzLWNjYy1jb25m aWd1cmluZy5wZGYNCg0KSXQgc2hvd3MgdGhhdCBNQUNzZWMgaXMgbWFpbmx5IGFwcGxpY2FibGUg dG8gTVBMUyBMMlZQTiBzY2VuYXJpb3Mgc3VjaCBhcyBWTEwgYW5kIFZQTFMgcmF0aGVyIHRoYW4g TVBMUyBMM1ZQTi4gIFNpbmNlIHRoaXMgZHJhZnQgaXMgYmFzZWQgb24gTVBMUyBMM1ZQTiAoaS5l LiwgTVBMUy9CR1AgSVAgVlBOKSwgaXQgc2VlbXMgdGhhdCB3ZSBkb24ndCBoYXZlIHRvIG1lbnRp b24gaXQgYXMgb25lIEFERElUSU9OQUwgZXhhbXBsZSBvZiBhIHN0cm9uZyBzZWN1cml0eSBtZWNo YW5pc20uIElzIGl0IGZpbmUgZm9yIHlvdT8NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4g PiBJZiBteSB1bmRlcnN0YW5kIGlzIHdyb25nLCB3b3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gaG93 IHRvIHVzZSBNQUNzZWMNCj4gPiB0byBwcm90ZWN0IHRoZSBJUCBlbmNhcHN1bGF0ZWQgdHJhZmZp YyBiZXR3ZWVuIFBFIHJvdXRlcnMgd2hpY2ggYXJlDQo+ID4gbm90IGRpcmVjdGx5IGNvbm5lY3Rl ZD8gT3Igd291bGQgeW91IHBsZWFzZSBwcm92aWRlIG1lIGEgbGluayB0byBzb21lDQo+ID4gUkZD IHdoaWNoIHRhbGtzIGFib3V0IHRoaXMgdXNhZ2U/DQo+IA0KPiBJIGRvbid0IGJlbGlldmUgdGhl cmUgaXMuIEF0IHRoYXQgcG9pbnQgeW91IGhhdmUgdG8gZ28gdXAgdGhlIHN0YWNrIHRvIE1QTFMt T1MNCj4gbWF5YmUsIG9yIElQc2VjLiBCdXQgdGhlIHRleHQgZG9lcyBhbHJlYWR5IGNvdmVyIHRo aXMuDQo+IA0KPiBDaGVlcnMsDQo+IFMuDQo+IA0KPiANCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywg WGlhb2h1DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogU3RlcGhl biBGYXJyZWxsDQo+ID4+IFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0gU2VudDog VHVlc2RheSwgRGVjZW1iZXIgMTUsIDIwMTUNCj4gPj4gNTowMCBQTSBUbzogWHV4aWFvaHU7IEFs dmFybyBSZXRhbmEgKGFyZXRhbmEpOyBUaGUgSUVTRyBDYzoNCj4gPj4gZHJhZnQtaWV0Zi1iZXNz LXZpcnR1YWwtc3VibmV0QGlldGYub3JnOyBiZXNzLWNoYWlyc0BpZXRmLm9yZzsNCj4gPj4gbWFy dGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb207IGJlc3NAaWV0Zi5vcmcgU3ViamVjdDog UmU6DQo+ID4+IFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1iZXNzLXZp cnR1YWwtc3VibmV0LTA2Og0KPiA+PiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+Pg0K PiA+Pg0KPiA+PiBIaXlhLA0KPiA+Pg0KPiA+PiBPbiAxNS8xMi8xNSAwMToxOSwgWHV4aWFvaHUg d3JvdGU6DQo+ID4+PiBIaSBTdGVwaGVuLA0KPiA+Pj4NCj4gPj4+IEl0IHNhaWQgIi4uLnVzaW5n IGEgc3Ryb25nIHNlY3VyaXR5IG1lY2hhbmlzbSBzdWNoIGFzIElQc2VjDQo+ID4+PiBbUkZDNDMw MV0iLiBIZXJlIElQc2VjIGlzIGp1c3QgbWVudGlvbmVkIGFzIGFuIGV4YW1wbGUgb2YgYSBzdHJv bmcNCj4gPj4+IHNlY3VyaXR5IG1lY2hhbmlzbS4gVGhlcmVmb3JlLCBpdCBkb2Vzbid0IGV4Y2x1 ZGUgTUFDc2VjLg0KPiA+Pg0KPiA+PiBTdXJlLCBidXQuLi4NCj4gPj4NCj4gPj4gVGhlIHRleHQg dGhhdCBJIHN1Z2dlc3RlZCBhbmQgdGhhdCB5b3Ugc2FpZCBzZWVtZWQgZ29vZCBkaWQgaW5jbHVk ZQ0KPiA+PiBNQUNzZWMuDQo+ID4+DQo+ID4+IE9uIDA5LzEyLzE1IDA3OjQ3LCBYdXhpYW9odSB3 cm90ZToNCj4gPj4+PiBTbyBtYXliZSBzb21ldGhpbmcgbW9yZSBsaWtlOg0KPiA+Pj4+DQo+ID4+ Pj4gIkludGVyIGRhdGEtY2VudHJlIHRyYWZmaWMgb2Z0ZW4gY2FycmllcyBoaWdobHkgc2Vuc2l0 aXZlDQo+ID4+Pj4gaW5mb3JtYXRpb24NCj4gPj4gYXQgaGlnaGVyDQo+ID4+Pj4gbGF5ZXJzIHRo YXQgaXMgbm90IGRpcmVjdGx5IHVuZGVyc3Rvb2QgKHBhcnNlZCkgd2l0aGluIGFuIGVncmVzcyBv cg0KPiA+Pj4+IGluZ3Jlc3MgUEUuIEZvciBleGFtcGxlLCBtaWdyYXRpbmcgYSBWTQ0KPiA+PiB3 aWxsIG9mdGVuDQo+ID4+Pj4gbWVhbiBtb3ZpbmcgcHJpdmF0ZSBrZXlzIGFuZCBvdGhlciBzZW5z aXRpdmUgY29uZmlndXJhdGlvbg0KPiA+PiBpbmZvcm1hdGlvbi4gRm9yDQo+ID4+Pj4gdGhpcyBy ZWFzb24gaW50ZXIgZGF0YS1jZW50cmUgdHJhZmZpYyBTSE9VTEQgYWx3YXlzIGJlIHByb3RlY3Rl ZA0KPiA+Pj4+IGZvciBib3RoIGNvbmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IHVzaW5nIGEg c3Ryb25nIHNlY3VyaXR5DQo+ID4+Pj4gbWVjaGFuaXNtIHN1Y2gNCj4gPj4gYXMgSVBzZWMgWzFd DQo+ID4+Pj4gb3IgTUFDc2VjIFsyXSBJbiBmdXR1cmUgaXQgbWF5IGJlIGZlYXNpYmxlIHRvIHBy b3RlY3QgdGhhdCB0cmFmZmljDQo+ID4+IHdpdGhpbiB0aGUgTVBMUw0KPiA+Pj4+IGxheWVyIFsz XSB0aG91Z2ggYXQgdGhlIHRpbWUgb2Ygd3JpdGluZyB0aGUgbWVjaGFuaXNtIGZvciB0aGF0IGlz DQo+ID4+Pj4gbm90DQo+ID4+IHN1ZmZpY2llbnRseQ0KPiA+Pj4+IG1hdHVyZSB0byByZWNvbW1l bmQuIEV4YWN0bHkgaG93IHN1Y2ggc2VjdXJpdHkgbWVjaGFuaXNtcyBhcmUNCj4gPj4gZGVwbG95 ZWQgd2lsbA0KPiA+Pj4+IHZhcnkgZnJvbSBjYXNlIHRvIGNhc2UsIHNvIHNlY3VyaW5nIHRoZSBp bnRlciBkYXRhLWNlbnRyZSB0cmFmZmljDQo+ID4+Pj4gbWF5DQo+ID4+IG9yIG1heSBub3QNCj4g Pj4+PiBpbnZvbHZlIGRlcGxveWluZyBzZWN1cml0eSBtZWNoYW5pc21zIG9uIHRoZSBpbmdyZXNz L2VncmVzcyBQRXMgb3INCj4gPj4gZnVydGhlcg0KPiA+Pj4+ICJpbnNpZGUiIHRoZSBkYXRhIGNl bnRyZXMgY29uY2VybmVkLiBOb3RlIHRob3VnaCB0aGF0IGlmIHNlY3VyaXR5DQo+ID4+Pj4gaXMN Cj4gPj4gbm90IGRlcGxveWVkDQo+ID4+Pj4gb24gdGhlIGVncmVzcy9pbmdyZXNzIFBFcyB0aGVy ZSBpcyBhIHN1YnN0YW50aWFsIHJpc2sgdGhhdCBzb21lDQo+ID4+IHNlbnNpdGl2ZSB0cmFmZmlj DQo+ID4+Pj4gbWF5IGJlIHNlbnQgaW4gY2xlYXIgYW5kIHRoZXJlZm9yZSBiZSB2dWxuZXJhYmxl IHRvIHBlcnZhc2l2ZQ0KPiA+PiBtb25pdG9yaW5nIFs0XSBvcg0KPiA+Pj4+IG90aGVyIGF0dGFj a3MuIg0KPiA+Pj4NCj4gPj4+IFRoYW5rcyBhIGxvdCBmb3IgeW91ciBzdWdnZXN0ZWQgdGV4dC4g SWYgbm9ib2R5IG9iamVjdCB0aGUgYWJvdmUNCj4gPj4+IHRleHQsIEkgd2lsbCBhZGQgaXQgaW4g dGhlIG5leHQgcmV2aXNpb24uDQo+ID4+Pg0KPiA+Pg0KPiA+PiBBbmQgaW5kZWVkIHlvdSBhZGRl ZCBpdCBhbGwgZXhjZXB0IGZvciBNQUNzZWMuDQo+ID4+DQo+ID4+IEFuZCBteSBxdWVzdGlvbiBp cyBub3Qgd2hldGhlciBNQUNzZWMgaXMgZXhjbHVkZWQgYnV0IHJhdGhlciB3aHkgaXQNCj4gPj4g d2FzIG9taXR0ZWQsIHdoZW4gYWZhaWssIGl0IGlzIHdoYXQgaXMgbW9zdCB1c2VkIGZvciBzZWN1 cmluZyB0aGlzDQo+ID4+IHBhcnRpY3VsYXIga2luZCBvZiBpbnRlci1EQyB0cmFmZmljLiAoQXQg bGVhc3QgSSBiZWxpZXZlIHRoYXQgTUFDc2VjDQo+ID4+IGlzIHdoYXQncyBtb3N0IHVzZWQgdGhl cmUuIElmIG5vdCwgSSdkIGJlIGdsYWQgdG8ga25vdw0KPiA+PiB0aGF0LikNCj4gPj4NCj4gPj4g U28sIHdoeSBub3QgaW5jbHVkZSBNQUNzZWM/IERpZCBzb21lb25lIG9iamVjdD8gSWYgc28sIHdo eT8gKEFuZCBjYW4NCj4gPj4geW91IHNlbmQgYSBwb2ludGVyIHRvIHRoZSBXRyBsaXN0IHdoZXJl IHRoYXQgb2JqZWN0aW9uIHdhcyByYWlzZWQgc28NCj4gPj4gSSBjYW4gdW5kZXJzdGFuZCBpdCBi ZXR0ZXIuKQ0KPiA+Pg0KPiA+PiBUaGFua3MsIFMuDQo+ID4+DQo+ID4+DQo+ID4+Pg0KPiA+Pj4g QmVzdCByZWdhcmRzLCBYaWFvaHUNCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0gRnJvbTogU3RlcGhlbiBGYXJyZWxsDQo+ID4+Pj4gW21haWx0bzpzdGVwaGVuLmZhcnJl bGxAY3MudGNkLmllXSBTZW50OiBNb25kYXksIERlY2VtYmVyIDE0LA0KPiA+Pj4+IDIwMTUgOTo0 NyBQTSBUbzogQWx2YXJvIFJldGFuYSAoYXJldGFuYSk7IFh1eGlhb2h1OyBUaGUgSUVTRw0KPiA+ Pj4+IENjOiBkcmFmdC1pZXRmLWJlc3MtdmlydHVhbC1zdWJuZXRAaWV0Zi5vcmc7DQo+ID4+Pj4g YmVzcy1jaGFpcnNAaWV0Zi5vcmc7IG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQuY29t Ow0KPiA+Pj4+IGJlc3NAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFN0ZXBoZW4gRmFycmVsbCdzIERp c2N1c3Mgb24NCj4gPj4+PiBkcmFmdC1pZXRmLWJlc3MtdmlydHVhbC1zdWJuZXQtMDY6ICh3aXRo IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IEhpLA0KPiA+Pj4+ DQo+ID4+Pj4gQ2FuIHNvbWVvbmUgc2F5IHdoeSB0aGUgbWVudGlvbiBvZiBNQUNzZWMgd2Fzbid0 IGluY2x1ZGVkPyBBcyBJDQo+ID4+Pj4gdW5kZXJzdGFuZCBpdCwgTUFDc2VjIGlzIHdoYXQncyBt b3N0bHkgdXNhYmxlIGZvciBpbnRlci1EQyBzZWN1cml0eQ0KPiA+Pj4+IHNvIG9taXR0aW5nIGl0 IHNlZW1zIGxpa2UgYSBiYWQgaWRlYSAob3IgcGVyaGFwcyBJJ20NCj4gPj4+PiBtaXNpbmZvcm1l ZCkNCj4gPj4+Pg0KPiA+Pj4+IFRoYW5rcywgUy4NCj4gPj4+Pg0KPiA+Pj4+IE9uIDE0LzEyLzE1 IDEzOjM0LCBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSB3cm90ZToNCj4gPj4+Pj4gU3RlcGhlbjoN Cj4gPj4+Pj4NCj4gPj4+Pj4gSGkhDQo+ID4+Pj4+DQo+ID4+Pj4+IFhpYW9odSBwb3N0ZWQgYW4g dXBkYXRlIHRoYXQgd2UgaG9wZSBhZGRyZXNzZXMgeW91ciBjb25jZXJucy4NCj4gPj4+Pj4gUGVs YXNlIHRha2UgYSBsb29rLg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGFua3MhDQo+ID4+ Pj4+DQo+ID4+Pj4+IEFsdmFyby4NCj4gPj4+Pj4NCj4gPj4+Pj4NCg== From nobody Fri Dec 18 06:30:24 2015 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 DA9581B2B58; Fri, 18 Dec 2015 06:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 xYFxKiFdNRY4; Fri, 18 Dec 2015 06:30:17 -0800 (PST) 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 7D9CD1B2C12; Fri, 18 Dec 2015 06:30:14 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.35.68] (66.129.241.14) by BY2PR0501MB2007.namprd05.prod.outlook.com (10.163.197.18) with Microsoft SMTP Server (TLS) id 15.1.355.16; Fri, 18 Dec 2015 14:30:09 +0000 To: Benoit Claise , The IESG References: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> From: Eric C Rosen Message-ID: <56741869.5020505@juniper.net> Date: Fri, 18 Dec 2015 09:30:01 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------040605010800010508050204" X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CO2PR20CA0015.namprd20.prod.outlook.com (25.163.96.25) To BY2PR0501MB2007.namprd05.prod.outlook.com (25.163.197.18) X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2007; 2:/FY3oXygpKVQJSZmk0U/UzJ769TLvKgG8BiyvZHC2xsD2hwNzVJRcmAtQ7DRgulH4D3BetMX9rMFeP1VWKKsZNAJpULsIuoqrfJUzQ6ORQ+cRCoLFmJDBH7Rb4CKObpH7WnHnKotSXo4wImufll2hg==; 3:iPLVGCUKGfxHt4OtOTHsm5vyXzznj3EqToyHvrKvqx4o+8+z7ZdpaSn3EkaznyaXPSu7R+Q9CCvjRI0kV+MyITnJ32cFnasXRwbDPAPn69YE585splAa2a31WVey3CWq; 25:DWt0ZDndj05k670F0OoEOPhddjAsuMrWnvxCF77LXIYz6fWiExbhZkBorKIAIG9Xgs8+mjr6y4SPvzNBglIgI+sfI4vuj0sZDNCPLh3knA96tePfOjs2zlP3Wg7bRtQatWDL3UALse7hFx6K/KIz2IYRHcSkDVhEnLxM5VlJea/eOZVln5s9t/B2XlctYaTXZMVpG7MfJHKd3r4rECudTayaYL64TNO5qRuSc7W1etHL6X0hW+fHeqw1kxb8IT/d X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB2007; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2007; 20:KMq79L9/P/bxkGFCW3QpgaJ2EUlqh1KfkjOWzr5xVex5DmOMRJI2xbelfoCaMWTnB0mI9br3Vd97D9J4wmfYiZo0KBsScHRxci6hdrTbvm4kR9WFWo0L3hMsQuXCxgrAvaagpecNlAIgxo+A1HO9i76jZELbcae6IK8Dhf7wDdDfIayxQzW0s8Oi+SR5Dod+UMK9KeJRDRDzUHEMU4o3XVgCLBG0xMb5uLaJPePg4TCbZDejnodtoXBGvdqq6vZHXBKMHO6U/c94B+QjGleFQO7TtURn2O8SstDJpQZpW0aKNRymgLNpbcqOvCQHqvvOpBX+7G/G5lAXwQSq4ZzUkBOGHXtYu9d2L34/EpT8LbP1cMSCao/BSbCT60/PvWIobaqaRjMQoxcBJB32ycAkrMOkGWhOtI4A6FzWjBWo3XBbgxLC43W8ZCDeLYbQogvsTFCEBwqlKuJtYYxluW+w05v5nEqgtFmfqrnCa6UKelzz8vUzXa5GqS8Buk/0HyG+; 4:wOquIDrufi3dXiPiOZu8afKn6H3sNQ5EkL9j4urF+XA9j6DcBQjTnPx9uHhSd8y/ebiqBoTCuGyVwlhwRlpQnNdmVwj0JiQAzJTgmAXVGVd+8DIwnq7ADHrbGXlrQFgTV/ZPY11nKuI117pbvHgP4BPbg1aTqtr2MKDtPlWiwqbPNKwFuVBa86tREqG9AjMDNNapUUN6nDxK6VUt4dDKr+6gbtvtuaRdMBpotcv6hubgjJtOtI+7mzE5i8cNsd84qKJrn3cd55dkwtFIIHFvj88VMU7yBdcHuAozJwldNk+TlQOm+fq5Wd3xFWzz3nw1THhm4DgpLJ8pGBlxDuqYbQYBaJaHgFYohl9EdQ6OZ4v88wC3A2Mz5I24ZqSoqyTC X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BY2PR0501MB2007; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB2007; X-Forefront-PRVS: 07943272E1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6049001)(6009001)(76104003)(199003)(24454002)(479174004)(377454003)(189002)(87976001)(65806001)(4001350100001)(117636001)(5008740100001)(83506001)(84326002)(5890100001)(586003)(5004730100002)(105586002)(19580395003)(6116002)(66066001)(1096002)(64126003)(87266999)(54356999)(3846002)(65956001)(92566002)(106356001)(101416001)(2950100001)(230783001)(189998001)(76176999)(86362001)(77096005)(122386002)(42186005)(81156007)(65816999)(50986999)(40100003)(5001960100002)(5001770100001)(97736004)(36756003)(512874002)(59896002)(99136001)(62816006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB2007; H:[172.29.35.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjA1MDFNQjIwMDc7MjM6QlVtV3NoUW11NklDdDBQUUtkUnFIL2NO?= =?utf-8?B?T2taQTl3U3VCckxJc200aU50RFdoOE5FZG80N1FaZ0pnNzFrZExoU1hmTmNU?= =?utf-8?B?aktjMTdPUUpxcGtOSGU1ZmJKUE1SNS9PcVdYSG9kKzI5S2Qyb1RMbkpxMG5k?= =?utf-8?B?aGwzRzVvakhrdGlCUkxjVzUxSm1ORzlVc001YktMZ09NNVZ5MmlqbStYRXNk?= =?utf-8?B?ZGtRUFhmT3pUajYvWkZhbUN6bGpEVVFMb1RVQThkbkZTYy9UdVFtaENEYVY3?= =?utf-8?B?NkF3VmNGNExMWXNLY2UzeFBvNnY0MlNXRllCMWlPL1NQZEpXN2tJdFR3WHFV?= =?utf-8?B?bDhMUW42WWhlN1hsUWRZRSs1c3IvOWd4YUlMeEFtZXJhSWhEM2xhb0VmT3V6?= =?utf-8?B?SVhFZ0pjWDJaZ1FKcmxzZGU4eEJ3dGloT2FwRlljSmxxbCtwYXh4Q0hmanQ5?= =?utf-8?B?aHl1QUIwbWZIbEo0NDl3OTBnamh0Yi9hRkg5bVgxZms0T1FNbDEzV1VPbHFH?= =?utf-8?B?aHJBcXl2NzdJSTd1cEUxemM0NnZWNExRdlN1NXdGVm9ya1lqcis3WEUrWUxw?= =?utf-8?B?d2NTMlVHZkNId2JFamppUVlXLzNVN0YzR1NuMDJrTGdUY0s4K2VvdG9FQzZW?= =?utf-8?B?NHZsd0tmNi9MS2xvSzAzRmRGV3dqUXU4UzdzVUpFU0F2VXpYSkJ5SXdSUzdi?= =?utf-8?B?bkVpNEFhbXlQMThlemtWKzVsK2tBaVZCbXJVTkJaaU45eTU5Y1FxS2l2WHBI?= =?utf-8?B?MENqd3NJUjkvZ3ZUdy8rUk0vMWtkTDhZUHM5TUJEZEtEVXpub3hWVHJHaldD?= =?utf-8?B?enQ5eU5Yb3NIMGtxSk95L2ZhNFhmREJKYmpFbkEreDM4WElXRGNreWQ2WDhj?= =?utf-8?B?MVQrL2wvTTJqSlYzcHYzVGxJdExZQ3RjMkVzNkVSTWhVZ3lZOXFRdTVsNzRR?= =?utf-8?B?czJUSHdzeUxqTGEvMElDNytSNThZemF5RHROQlk4ckZVbDZIODQ2YnJUSWhF?= =?utf-8?B?Q3Z1OWEybnROVUVPL3Z6a29BNHNpSjM2WDc2NkN0Zm1wM3QwRitEYWF3d0M0?= =?utf-8?B?UkV1RjdJL3R1MGhMcjdmS3loNnpMdTFzZm5vNDlOS2dVWk1LTnlVZXVuekRG?= =?utf-8?B?cEh1bGVNNWdGbks4R1RLZVNENVdaaTFaRWxTUWo4VmxlYlVWY3hJOVl0ck5h?= =?utf-8?B?d01JWVVaM3F2NFdnNy9ia3hiSWpkMmJPQXViVHlRSjBic2pZemR6VlNzTmpC?= =?utf-8?B?VExmTUJSa0REUkp4QVVueHF5TjJma0NERDd4VE9LK3lIdU1ZVUIwN1ZuUnRu?= =?utf-8?B?bURLbTlVTkprdWh6UU55S1pBZGJ5UnYxN05kVlAvazgvT2JtdFJuOWd3K0tr?= =?utf-8?B?WmUxcURNOUNkN1VqM3FBTlg3OUUwWWpMN213VWJEV2o2YVpEV3BzQzllRVFw?= =?utf-8?B?aU44V0tJakU0a0w5Zys1aEZEbm13bzR1ZUVaRFprOXBaQmxRZWlHcU9Hc2VU?= =?utf-8?B?MVRxVWYzZzY1eTJ4OHd5UThFeTAyblIzSDlTa0RjYVZBWkVjcHp0eU5BSnhl?= =?utf-8?B?d2tGUS80WXNUU3BSK1piWlZsaThLYlErNnBIZkF4QWNhci96TUJ1OHZRV2RP?= =?utf-8?B?cWhEMGw4NEZVcFkzVEthWGlKNmlzMzlzNmpQMDY3R3pTZmRyV0J6TDRJMEl3?= =?utf-8?B?dTJEamJRbWI4N2hBMDRGY3hQUjdiZ1N4cHp0NW9uenhOUlJ4eHlKazVKNy9p?= =?utf-8?B?dEkwVVI4Vk9aMHJ1Z2txNTZHSklIV0c3OGxVSllDcnhNWjdxNWtlcFl4OWRt?= =?utf-8?B?T2dBRlMxMmxZZGZ4aE4xeTRiTmxpYko5Nzd6L0Z0MHB2WU9VLzMybm5jekUv?= =?utf-8?B?SWtUWEVDOHNocEJnTG1Pc2RVZEVaa0ZTeUpJK2p6aWlUT3hWU2xNYVRmblV4?= =?utf-8?B?NHpFaVJodndRVEE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2007; 5:bb/LhwcEHlrDgy9mM2ClHnKeA+KlpPOqWk1fY9hvMuXRPUJinRa6zZ9EBtklEE4hmbyYAZT6ep2/G3TgjRGcGYucBmbl5b129HL6O5fMbC7K9vy9CYiMmMZven++XXHLggNJPY6e6+CSokTArkb6zQ==; 24:+8mMMwfKa6hTn80Q5mO3IPMoK2MhKAffZtd0Q8FTKs2v3PF//3Z8b5TfP1rjPiiHGqlX/x0IC/pGax0L/T1lAgJCUvLZU0zL2fnB3X74li4= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2015 14:30:09.5596 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB2007 Archived-At: Cc: draft-ietf-bess-mvpn-extranet@ietf.org, shares@ndzh.com, aretana@cisco.com, 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: Fri, 18 Dec 2015 14:30:22 -0000 --------------040605010800010508050204 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit I responded to Sue's review, but noticed that the response did not go to the BESS mailing list. So I am sending my response again; apologies to those who are getting it twice. On 12/17/2015 7:47 AM, Susan Hares wrote: > > Eric, Rahul, Yiqun, and Thomas: > > I have reviewed this document as part of the Operational directorate's > > ongoing effort to review all IETF documents being processed by the > IESG. These > > comments were written with the intent of improving the operational > aspects of the > > IETF drafts. Comments that are not addressed in last call may be > included in AD reviews > > during the IESG review. Document editors and WG chairs should treat > these comments > > just like any other last call comments. > > Please let me know if any of these comments are unclear. This is > interesting BESS work, and a clear deployable specification will help > with multicast traffic (video and other traffic). > > Sue Hares > > ====== > > 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 > > Please provide the type of detail as show in RFC 4360 sections 3.1, > 3.2, and 3.3. > It would not be correct to do so. As you may recall, RFC7153 reorganized the Extended Community registries, and Section 4 of RFC7153 provides instructions on how to request Extended Community codepoints from IANA. In fact, one of the main purposes of RFC7153 was to eliminate the need to provide IANA with the sort of detail that is indicated in RFC4360. I believe that the specification of the two ECs (and the request for codepoints for them) is in accord with RFC7153 and does not need revision. > 2)Why is there no Deployment considerations section? > There is no requirement for a Deployment Considerations section, so absence of one cannot be grounds for a DISCUSS. I will interpret this comment as meaning that there is insufficient discussion of deployment issues. However, I find the comment puzzling, as so much of the draft is about proper provisioning of the Route Targets, and Route Distinguishers. There is also quite a bit of discussion about corner cases, such as (a) the problem that may arise if a source host originates both extranet and non-extranet sources, and (b) the problem that may arise if a single address prefix is the best match for both an extranet source and a non-extranet source. In fact, you say yourself: > > The whole draft is a set of rules for handling policy, BGP A-D routes, > tunnel set-up, and PIM Join/leaves in the case of an intra net. > Unless these rules are followed exactly, traffic may flow into a VPN > it is not suppose to. > So I really don't understand what you think is missing. > > If the customer and the SP must coordinate on setting up filters, the > procedure is outside the document. > Yes, the interaction between the service provider and its customers is outside the scope of this document. > An error in any of these set-ups is considered a “security violation”. > Not quite; any error in these set-ups could result in a security violation, i.e., in delivery of data to hosts that aren't supposed to get it. > In this set-up, one has to ask “is there another choice” to this whole > design > Certainly the WG has had plenty of time to come up with up with a better alternative. > there should be a deployment section indicating how to manage the > RTs, RDs, and policy set-up. > I do not understand what you think is missing. This is covered quite extensively in sections 1.3, 4, and 5. > Perhaps experience with the Intra-As has shown deployment tips that > would make this less fragile. If so, it would be good to include an > operations consideration section. > I do not think there is any requirement to have "deployment tips" in this document, nor is there any requirement to have an "operations considerations" section. However, since so much of the document is devoted to the issue of how to properly provision the RTs and RDs, I don't quite understand what you think is not covered. > > If a new class of tools provides monitoring or provisioning, > mentioning these would be useful. If yang modules are being > developed, that would be useful. > It is not within the scope of this document to "mention" monitoring or provisioning tools. Yang models are also outside the scope of this document. > > Places that indicate issues with violated constraint: > > p. 11, 12, 19 (2.3.2 – a priori knowledge, inability to detect), , > I am not entirely sure what you are asking. As discussed in Section 2, the big problem in MVPN extranet is that an egress PE may receive two distinct multicast flows that happen to have the same IP source and IP group address, say (S,G). The procedures and policies specified in the draft prevent two such flows from traveling across the backbone on the same tunnel. However, the detailed examples in sections 2.1 and 2.2 show how a given egress VRF can end up listening to two tunnels, each of which is carrying an (S,G) flow. In this case, only one of the tunnels is carrying the (S,G) flow that needs to be delivered to the VRF, but the other tunnel is carrying other flows that need to be delivered to the VRF. The problem is how to prevent the "wrong" (S,G) flow from being delivered to a given VRF. Section 2.3 outlines two methods for preventing this: - Since the VRF "knows" the tunnel from which to expect the (S,G) flow, it can discard (S,G) packets coming from the other tunnel. However, not all deployed hardware platforms are able to do this at speed. Hence the other alternative: - Don't put more than one flow on a tunnel; then if (S,G) is flowing on two tunnels, a given egress VRF will only be listening to one of them. That eliminates the problematic situation in which "the other tunnel is carrying other flows that need to be delivered to the VRF". The actual constraint is a bit more complicated than 'don't put more than one flow on a tunnel', but this is detailed in Section 2.3. I think this is all explained in the draft. Are you saying that the explanation above is incomprehensible, or are you saying that the draft just doesn't make it clear and needs some additional text? Or are you saying something else? > p. 25 last paragraph (violation of constraints will cause things to > not work. However, only policy can control), > Again, not sure what you are asking. This page specifies a set of constraints on the way RTs are assigned. It points out that these constraints are presupposed by the procedures that are later specified for determining whether a given flow is expected to arrive from a given tunnel. It is explained elsewhere in the document that accepting a flow from other than the expected tunnel can result in misdelivery of data. What else needs to be added? > p. 27 4.2.2 (1^st paragraph, Route Reflector must not change), > That's section 4.4.2; the topic is the propagation of routes that carry the Extranet Source EC. Recall that a CE puts the Extranet Source EC on an IP route to indicate that the route represents an extranet source. The PE then translates the IP route to a VPN-IP route, and attaches a specific set of RTs to the VPN-IP route. The draft requires that the Extranet Source EC also be carried by the VPN-IP route, and that it not get stripped off while the VPN-IP route is being propagated. This rule is needed in order to support the scenario in which a VPN contains an "Option A" interconnect. At the Option A interconnect, the VPN-IP route gets translated back to an IP route, and the RTs are stripped off before the IP route is propagated. If the Extranet Source EC has also been stripped off, there is no way for the router at the other end of the Option A interconnect to know that the route represents an extranet source. Thus the technique of using the Extranet Source EC to dynamically signal that a particular route represents an extranet source will not work correctly across an Option A interconnect unless the rules of section 4.4.2 are followed. I can add some text about this to section 4.4.2. > p. 31 (5.1, first paragraph), > Section 5.1 specifies a set of constraints on the assignment of RTs, and explains the need for them. I'm not sure what more you think is necessary. > > 3)Is security section really a security section? It seems more like > “do this policy” or this will fail. It should get a stronger review > from the security directorate > The Security Considerations section mentions those things that are specific to MVPN Extranet and that need to be done properly in order to prevent misdelivery of data. That seems like an appropriate security section for this document. General issues of privacy/integrity/authentication are not specific to MVPN Extranet, and so are not mentioned here. > Editorial suggestions: > > Summary: In general the authors provide dense English text to describe > this rules. In general the English text contains valid complex > sentences. However, a few things should be suggested: > > 1)PTA – define it in a definition section or spell out the abbreviation > This acronym is expanded at first occurrence, but I will be happy to add it to the Terminology section as well. > 4)P. 36 second paragraph. The reason for the “MUST” in 1^st full > paragraph is a bit vague. It seems logical, but the reasoning is just > vague in the text. > Are you referring to the following: "the VPN-R VRF MUST also originate one or more additional Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra- AS I-PMSI A-D route for each Incoming Extranet RT with which it has been configured" * *At the beginning of section 6.2, it says: "if a VPN-S VRF has extranet multicast C-sources, and a VPN-R VRF has extranet multicast C-receivers allowed by policy to receive from the C-sources in the VPN-S VRF, then the VPN-R VRF joins the MI-PMSI that VPN-S uses for its non-extranet traffic." The former paragraph describes the mechanism that VPN-R uses to join the MI-PMSI into which VPN-S transmits. I can add a sentence to the paragraph on page 36 saying "This is the method that VPN-R uses to join the MI-PMSIs that may contain extranet flows that are of interest to it". > 7)Page 53 – section 7.4.5 paragraph 3 “VRF route Import EC” – please > spell out first usage and give abbreviation (VRF Route Import Extended > Community (EC). > I see only two occurrences of "EC" in the draft, so I'll just replace them with "Extended Community". --------------040605010800010508050204 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
I responded to Sue's review, but noticed that the response did not go to the BESS mailing list.  So I am sending my response again; apologies to those who are getting it twice.

On 12/17/2015 7:47 AM, Susan Hares wrote:

Eric, Rahul, Yiqun, and Thomas:

 

I have reviewed this document as part of the Operational directorate's

ongoing effort to review all IETF documents being processed by the IESG.  These

comments were written with the intent of improving the operational aspects of the

IETF drafts. Comments that are not addressed in last call may be included in AD reviews

during the IESG review.  Document editors and WG chairs should treat these comments

just like any other last call comments.

 

Please let me know if any of these comments are unclear.  This is interesting BESS work, and a clear deployable specification will help with multicast traffic (video and other traffic).

 

Sue Hares

 

======

 

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

 

Please provide the type of detail as show in RFC 4360 sections 3.1, 3.2, and 3.3. 

It would not be correct to do so.  As you may recall, RFC7153 reorganized the Extended Community registries, and Section 4 of RFC7153 provides instructions  on how to request Extended Community codepoints from IANA.   In fact, one of the main purposes of RFC7153 was to eliminate the need to provide IANA with the sort of detail that is indicated in RFC4360.  I believe that the specification of the two ECs (and the request for codepoints for them) is in accord with RFC7153 and does not need revision.

 

2)      Why is there no Deployment considerations section? 

There is no requirement for a Deployment Considerations section,  so absence of one cannot be grounds for a DISCUSS.  I will interpret this comment as meaning that there is insufficient discussion of deployment issues.  However, I find the comment puzzling, as so much of the draft is about proper provisioning of the Route Targets, and Route Distinguishers.  There is also quite a bit of discussion about corner cases, such as (a) the problem that may arise if a source host originates both extranet and non-extranet sources, and (b) the problem that may arise if a single address prefix is the best match for both an extranet source and a non-extranet source.   

In fact, you say yourself:

 

The whole draft is a set of rules for handling policy, BGP A-D routes, tunnel set-up, and PIM Join/leaves in the case of an intra net.  Unless these rules are followed exactly, traffic may flow into a VPN it is not suppose to.

So I really don't understand what you think is missing.

 

If the customer and the SP must coordinate on setting up filters, the procedure is outside the document.

Yes, the interaction between the service provider and its customers is outside the scope of this document.

An error in any of these set-ups is considered a “security violation”. 

Not quite; any error in these set-ups could result in a security violation, i.e., in delivery of data to hosts that aren't supposed to get it.

 

In this set-up, one has to ask “is there another choice” to this whole design

Certainly the WG has had plenty of time to come up with up with a better alternative. 

 there should be a deployment section indicating how to manage the RTs, RDs, and policy set-up. 

I do not understand what you think is missing.  This is covered quite extensively in sections 1.3, 4, and 5.

Perhaps experience with the Intra-As has shown deployment tips that would make this less fragile.  If so,  it would be good to include an operations consideration section.

I do not think there is any requirement to have "deployment tips" in this document, nor is there any requirement to have an "operations considerations" section.  However, since so much of the document is devoted to the issue of how to properly provision the RTs and RDs, I don't quite understand what you think is not covered.

 

If a new class of tools provides monitoring or provisioning, mentioning these would be useful.  If yang modules are being developed, that would be useful.


It is not within the scope of this document to "mention" monitoring or provisioning tools.  Yang models are also outside the scope of this document.

 

Places that indicate issues with violated constraint:

 

p. 11, 12, 19 (2.3.2 – a priori knowledge, inability to detect), ,

I am not entirely sure what you are asking.

As discussed in Section 2, the big problem in MVPN extranet is that an egress PE may receive two distinct multicast flows that happen to have the same IP source and IP group address, say (S,G).    The procedures and policies specified in the draft prevent two such flows from traveling across the backbone on the same tunnel.  However, the detailed examples in sections 2.1 and 2.2 show how a given egress VRF can end up listening to two tunnels, each of which is carrying an (S,G) flow.  In this case, only one of the tunnels is carrying the (S,G) flow that needs to be delivered to the VRF, but the other tunnel is carrying other flows that need to be delivered to the VRF.

The problem is how to prevent the "wrong" (S,G) flow from being delivered to a given VRF.  Section 2.3 outlines two methods for preventing this:

- Since the VRF "knows" the tunnel from which to expect the (S,G) flow, it can discard (S,G) packets coming from the other tunnel.  However, not all deployed hardware platforms are able to do this at speed.  Hence the other alternative:

- Don't put more than one flow on a tunnel; then if (S,G) is flowing on two tunnels, a given egress VRF will only be listening to one of them.  That eliminates the problematic situation in which "the other tunnel is carrying other flows that need to be delivered to the VRF".   The actual constraint is a bit more complicated than 'don't put more than one flow on a tunnel', but this is detailed in Section 2.3.

I think this is all explained in the draft.   Are you saying that the explanation above is incomprehensible, or are you saying that the draft just doesn't make it clear and needs some additional text?  Or are you saying something else?


p. 25 last paragraph (violation of constraints will cause things to not work.  However, only policy can control),


Again, not sure what you are asking.  This page specifies a set of constraints on the way RTs are assigned.  It points out that these constraints are presupposed by the procedures that are later specified for determining whether a given flow is expected to arrive from a given tunnel.  It is explained elsewhere in the document that accepting a flow from other than the expected tunnel can result in misdelivery of data.  What else needs to be added?

p. 27 4.2.2 (1st paragraph, Route Reflector must not change),


That's section 4.4.2;  the topic is the propagation of routes that carry the Extranet Source EC. 

Recall that a CE puts the Extranet Source EC on an IP route to  indicate that the route represents an extranet source.  The PE  then translates the IP route to a VPN-IP route, and attaches a specific set of RTs to the VPN-IP route.  The draft requires that the Extranet Source EC also be carried by the VPN-IP route, and that it not get stripped off while the VPN-IP route is being propagated.  This rule is needed in order to support the scenario in which a VPN contains an "Option A" interconnect.  At the Option A interconnect, the VPN-IP route gets translated back to an IP route, and the RTs are stripped off before the IP route is propagated.  If the Extranet Source EC has also been stripped off, there is no way for the router at the other end of the Option A interconnect to know that the route represents an extranet source.  Thus the technique of using the Extranet Source EC to dynamically signal that a particular route represents an extranet source will not work correctly across an Option A interconnect unless the rules of section 4.4.2 are followed.

I can add some text about this to section 4.4.2. 

p. 31 (5.1, first paragraph),


Section 5.1 specifies a set of constraints on the assignment of RTs, and explains the need for them.  I'm not sure what more you think is necessary.

 

3)      Is security section really a security section? It seems more like “do this policy” or this will fail.  It should get a stronger review from the security directorate

The Security Considerations section mentions those things that are  specific to MVPN Extranet and that need to be done properly in order to prevent misdelivery of data.  That seems like an appropriate security section for this document.  General issues of privacy/integrity/authentication are not specific to MVPN Extranet, and so are not  mentioned here.

 

Editorial suggestions:

 

Summary: In general the authors provide dense English text to describe this rules.   In general the English text contains valid complex sentences.  However, a few things should be suggested:

 

1)      PTA – define it in a definition section or spell out the abbreviation

This acronym is expanded at first occurrence, but I will be happy to add it to the Terminology section as well.

4)      P. 36 second paragraph.  The reason for the “MUST” in 1st full paragraph is a bit vague.  It seems logical, but the reasoning is just vague in the text.


Are you referring to the following:

   "the VPN-R VRF MUST also originate one or more additional
   Intra-AS I-PMSI A-D routes.  It MUST originate one additional Intra-
   AS I-PMSI A-D route for each Incoming Extranet RT with which it has
   been configured"

At the beginning of section 6.2, it says:

   "if a VPN-S VRF has extranet multicast C-sources, and a
   VPN-R VRF has extranet multicast C-receivers allowed by policy to
   receive from the C-sources in the VPN-S VRF, then the VPN-R VRF joins
   the MI-PMSI that VPN-S uses for its non-extranet traffic."

The former paragraph describes the mechanism that VPN-R uses to join the MI-PMSI into which VPN-S transmits.   I can add a sentence to the paragraph on page 36 saying "This is the method that VPN-R uses to join the MI-PMSIs that may contain extranet flows that are of interest to it".


7)      Page 53 – section 7.4.5 paragraph 3  “VRF route Import EC” – please spell out first usage and give abbreviation (VRF Route Import Extended Community (EC). 

 
I see only two occurrences of "EC" in the draft, so I'll just replace them with "Extended Community".
--------------040605010800010508050204-- From nobody Fri Dec 18 07:25:00 2015 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 31C051B2ED3; Fri, 18 Dec 2015 07:24:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 882hXFmkILcD; Fri, 18 Dec 2015 07:24:53 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECF81B358E; Fri, 18 Dec 2015 07:24:53 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.35.68] (66.129.241.14) by BLUPR0501MB2003.namprd05.prod.outlook.com (10.164.22.29) with Microsoft SMTP Server (TLS) id 15.1.361.13; Fri, 18 Dec 2015 15:24:43 +0000 To: Kathleen Moriarty , The IESG References: <20151218014710.16763.71345.idtracker@ietfa.amsl.com> From: Eric C Rosen Message-ID: <56742534.5080302@juniper.net> Date: Fri, 18 Dec 2015 10:24:36 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151218014710.16763.71345.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: DM2PR10CA0085.namprd10.prod.outlook.com (25.162.31.11) To BLUPR0501MB2003.namprd05.prod.outlook.com (25.164.22.29) X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2003; 2:4azxYF/TLzcZF9EPYXu5ZwhOvSQuZR4R6Hsito0ocujT8ew1OSv8i87HXctQBtKuhIYX5QFoyjEogdIHUHyFmTgxYoEfFbMrhjMIfTUaVHUS5IdejH0mjkWOq//iz70WS15cGRP8SPzzJ8hx8OnVCQ==; 3:xycgIj9+O6YEOgpfHvGccHCwYqPGv0Zf0d5Ax6tSP2KUQc3K3oHwjQHvlzBFObjSGuTkF6Vz3NQ/jF8VqSFjsbi7a6k67WdQ0hY8PkC+5BAvZshvcmLBz7Z5cr+WO3aX; 25:rQvJTp8jC5RDFAHCOg8b2B0/OtxKv/pkg8oa7uQNkbTtu7J9gH5+TCoMbNd6muR3k51U/8dNrLNYRLYmAw6YNGPgT4n2SsauDcWA8bBWblYicsnNIAMEsipqZYqtJUwTp6fqdgCgz4P31jhnfSsVRIeC1owj9GZvrmKupX6Ej0M49oHcMcd6MLBjOMSePd0S6PU1+jrnrJicAWk+q6nNwKfFFdh72aBGtQVkhEe4cVc2wxRDW+zGgBRWR8pMBsh0hfSXeoqXK9nzXCVMsUmj5g== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB2003; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2003; 20:JjIkcxbPmAg6vnVQUTCk7dboKVkpkVLAg1fOjzMraNKrgDkImw8R0ox0c4GOgqY3r8R1g7PEilO9Rvxisf+xcjCSdATe1xlf8p7i9s4Vc/+A+mpHzNONbpO/VRN1ugL8bUfiXS1Aoq1rV4YnC/nEmrtbqlbeBRFVGnD3xzHR3QP/MRuJv/aKIN4Gfe+bUGc/ZrzCRQim0Bob2VMVc8OIRpJoXMSE7k518fYHYiwfpkRvoAICC6RA+Xa880g7Bdj7HiGtuqmabyDzcWcq0OHBz+RiLpvuM+52p3xGpf/NifEBukYQYYGWuiPuU8h4eD7ThGmBFtnwZKvXcNU59tZTwxRPZ/PVfJ7ChnSyqNGC49FOlgazQgeHlUMczF4D1hmwehFcSErvbPP7zLjLzaTMF9scAXgEDcNgULbixesk7QcSWd5eUCu/7198qtuDZeWUYt/SFjJCXRIJ5E/QSKv14J+nlb+ChmSCGRLvolIfexOzii4bfarLPHn7EgE2YVA7; 4:vBP9XbDuANKRwPIAo4/RzVMSkbloqfRxNyIJvKhysWPhH5nLeaDNuB4FwjgGtnxFf/7VHA/Agnl+KUDjPCq4qu2ehmfI5X5ecBWIjB7vmwHMXxTdNPHb6dtlYb1r3bIFG40FSo0cdTXhw5Go75BYuhQOplttq87tLlFhiYp8p5ZJFNPVbgH/CpDG3iCba3ehDPqCd1vgD4EHoF+JI/SSj6gfi+idlgy/4js+O/ZW2d5ifCxsDytI6c/Wp5w7QrNOHayJi5KAtRJpg+abjqh/Jx8EbljxKO936NRDt8S2R/tseMTcFPG6oeKwM/q5X7z65EXY33K1w49UimBZaH2y7AVwEnIQYVnr6sBbdy9UfzREJW4bVDw5BKUQICZ2hbck 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)(520078)(3002001)(10201501046); SRVR:BLUPR0501MB2003; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2003; X-Forefront-PRVS: 07943272E1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(377454003)(479174004)(189002)(199003)(24454002)(6116002)(50986999)(3846002)(1096002)(76176999)(59896002)(99136001)(50466002)(42186005)(65816999)(36756003)(101416001)(87266999)(77096005)(5004730100002)(105586002)(106356001)(117636001)(586003)(5008740100001)(5001770100001)(47776003)(65956001)(87976001)(64126003)(81156007)(97736004)(65806001)(66066001)(5001960100002)(54356999)(122386002)(230783001)(4001350100001)(92566002)(86362001)(189998001)(23676002)(40100003)(2950100001)(230700001)(83506001)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2003; H:[172.29.35.68]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjA1MDFNQjIwMDM7MjM6VUJEVng5by9XTk9adm9oZVJSYXp4b2t4?= =?utf-8?B?bUtsUXRJZVZOTEZ0UElXWk80UWxveUlIQlFwZHNXdndZZk51ajd3WUdCcVJ5?= =?utf-8?B?UEhuZFdGRXZFeTcxTnhwWHJKWkRobzZZbzA4ejQ2TCtpSHZYcjVWZ2hkTS82?= =?utf-8?B?R2pLZEdobXQ1Z1RpdWl0UGZPRzl6OUdJaXRyYm1Od3lTUFN6NEV1TmtlTFlk?= =?utf-8?B?UUp5WUVjQUMxSFpaUlNwa2lhZ3c3N2p6aDlQOHdyTDFOVDVYVUxzVWh5RVRM?= =?utf-8?B?ZWVIYzNaY2lpdnhXWjNSZy9QdnJJTU00WXJkc1VaUi96amhZd1pheEdUT2kr?= =?utf-8?B?SzhPbEpIL0xja01uazBPazFSQVpNamtMTU1OZ3d1YXJuZmF4bm1LWFBuZlh1?= =?utf-8?B?akFJa3hld0dDSTNrMk1JckZ6RGNBdjFFMnBlWGluQm1LTWdETkVFU1MwOGEx?= =?utf-8?B?VFd0MFFDbFlIOGhhS0EzZFFUWjFnNnBLMFlveXBEVUZTZDV3U2tZVjQxMXZy?= =?utf-8?B?ekVrek93UU9laXQ4WWVHbm9CczIxbFpncVlQdVFmcGxOV29xRWhDQTg1cXhE?= =?utf-8?B?WWZkUTNMYm5KRVp3WjFPRUF2ZjRRZkVZYm54TjFvcXVyWWp1ZkN2RDZ2b2hO?= =?utf-8?B?Mzljbm8zZVUxbzZKdG1UcGEza1RDZHVJMXVxWncvVitlK3Y1OFlzWTRZSXZF?= =?utf-8?B?Vjg4eHp0bFRGQzNOekRJVFNXRG8wbFhHRk96djNqMnFlVHdxb0w4OENXZ3lI?= =?utf-8?B?MGo3VmtKd1h3NjV2OFNPOXZaNGlSKy9lMkUxZG14Z2RYNzNRaGMvYkhMZllM?= =?utf-8?B?VzFYSE1pcXZaQnkvSlUxN1AwRWZhTTUzWVdiMGZ6SHNMRTNFZVpERk5BMWhZ?= =?utf-8?B?eWF3cHJTV0M1NWdNY3ZhVlRrMm45OUx2UFhWZzFVWjNPOWtYSUJuem5kcmFB?= =?utf-8?B?UjdIQmF6WFpLVVA3SGpadmhFQkFDaWcrU0dQRU1wekJMYmdWaWFlck5SREJ5?= =?utf-8?B?amV1cmI0WTFoeW1BaFJPZ3hvL0xaeFVublVhUVc1QkhaTkVZcTlLb3hvb0hj?= =?utf-8?B?R2ZXR0RBSVlYWEkwTWljUU82YWVIWTQvOFRaaVJYY29CTkRSalpkMTdReGxa?= =?utf-8?B?RnpYU3pxL3YrM0J5dlRCYjlscFp4UnZuTUtrNEwwL0hPQ2FYTmZpcmRDUVR2?= =?utf-8?B?czdiSEVHZm1ja3MyRm1YaUl5eThGK2M2VkRMUHRQQkJGQTFxdDFpMk5qd0Iv?= =?utf-8?B?dnpnNm9IWVB5RmFQSjNpbDhwSENsVzg1RDJTQVFBTjlnRS9qVmVHNURVVUpl?= =?utf-8?B?RWVqcFBxbWZGUnhFUzVUVExNbUdpYmRQbGJRMGo5STZEM29Md0lTVklpZVIx?= =?utf-8?B?d3NDcGU3bnphMTl4TUJ1NUd4Y2t0OHVtVmU5ZGQyZHJUUkVXVDdOVXpPendo?= =?utf-8?B?N1ltOXhNR25WaDlsWkI3V3NIM0hSbVBZWG9IQlEycTZzc0NKNm5IdkJMQ29p?= =?utf-8?B?Yno5elhqanJ1Q3hkcXorbkN4SURlSWtCbDFtb0tyZE1MNVptRkhZdFlZdm8z?= =?utf-8?B?TW5Ca1RENzRQU3N1WFo3Q3EvRzZUNHgvK1pzbVVnMFZWcDZpeS8rWEVvdGMy?= =?utf-8?B?NjR1SlhHUG16d1VTVHEvN1BVcktXWmk4cE9LRXZ2S2tVZWxiTFh1aUxUK2N1?= =?utf-8?B?R2s4QlBENTdQY2RKeGpJNTZKZmh4QXRIN1hPM1NRWVk0T3JmU1lxdEJiODAy?= =?utf-8?B?bXJESlY3a3FsM0FJTk1hc2p3PT0=?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2003; 5:gIlil5nPwKF9BtP2BQKnnf1Ay3OKu53xeaWNqrQUDDG3TpeTA1qvSDSnREBCWRZdFWuJLkmt0aOqZTFTqBsoGN4JE9WstU/Po70yFtK4mxKkZD2q4wnjqnBt0q0HdiiPicv6O03b3RGbDr9Ea6vIOA==; 24:+5ZXj4nkPqzkMJAdIQN4gdMkKGe0WlpVHvp90jcHpakFElWRBmBSPAxKbe4M6Sj7JTIBEnLV1jrsQ2gbcF0elaTGW/mFWwDFErjs22iWAIE= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2015 15:24:43.4849 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2003 Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, draft-ietf-bess-mvpn-extranet@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: Re: [bess] Kathleen Moriarty's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS) 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: Fri, 18 Dec 2015 15:24:55 -0000 On 12/17/2015 8:47 PM, Kathleen Moriarty wrote: > I just have one question/request to improve the security consideration > section. The only security mentioned in this draft is what's called a > "security violation", where traffic may go to the incorrect "VPN" > endpoint. If you are worried about traffic winding up in the wrong > place, why is there no consideration for observing this traffic on the > wire? Since there is no encryption, wouldn't this also be a security > consideration to call out specifically? > > Mention of the possibility of active attacks that could alter or tamper > with the traffic or passive attacks that could observe the traffic as a > risk due to lack of encryption (confidentiality protection) would help or > a reason why this doesn't matter. The reason I didn't mention this in the Security Considerations section is that the issues are not specific to Extranet MVPN, which is the topic of this document. The Security Considerations section mentions those issues that could result in misdelivery of traffic if the procedures of the document are not properly executed; this set of issues is certainly within the scope of the document. I understand that there are issues having to do with the possibility of observing or altering the traffic on the wire. Certainly I could mention that the procedures of this document do not provide encryption, and hence do not by themselves ensure the privacy/integrity of the data against attacks on the backbone network. Would that be sufficient? I don't want to make any specific recommendations for mitigating those attacks, because: - Issues of how to provide privacy/integrity for multicast traffic in general would seem to be out of scope for this document; - Issues of how to provide privacy/integrity for various tunneling/encapsulation methods would seem to be out of scope for this document; - Issues of how to provide privacy/integrity for the base L3VPN technology would seem to be out of scope for this document; - Issues of how a Service Provider can protect its backbone network against various attacks would also seem to be out of scope for this document. From nobody Fri Dec 18 08:17:15 2015 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 0AF831B36E9 for ; Fri, 18 Dec 2015 08:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 Koq5Ifrdaf0a for ; Fri, 18 Dec 2015 08:17:10 -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 5CDEF1B36E3 for ; Fri, 18 Dec 2015 08:17:10 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id A9BD620185; Fri, 18 Dec 2015 17:17:08 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [xx.xx.1.183]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 8285B1A0051; Fri, 18 Dec 2015 17:17:08 +0100 (CET) Received: from [10.193.71.12] (10.197.38.6) by PEXCVZYH02.corporate.adroot.infra.ftgroup (10.114.1.183) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 18 Dec 2015 17:17:08 +0100 References: <561D09B4.6040800@alcatel-lucent.com> <564FBAE2.1060909@alcatel-lucent.com> <5666A27C.8030103@alcatel-lucent.com> From: Organization: Orange To: , BESS Message-ID: <30263_1450455428_56743184_30263_12998_1_56743183.6040400@orange.com> Date: Fri, 18 Dec 2015 17:17:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.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.197.38.6] Archived-At: Subject: Re: [bess] Need reviews of bess-multicast-damping [Was: Re: WG Last Call for draft-ietf-bess-multicast-damping-01] 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: Fri, 18 Dec 2015 16:17:14 -0000 Hi Gunter, all, VAN DE VELDE, Gunter (Gunter) : > I had had a read through the document. I think it is a nice clear document which is well written and is to me ready for publication. First thank you very much for this review. > Below are a few topics that crossed my mind when digging through the text. I leave it to the authors/WG to identify if they are idnits or more serious considerations which need more text before submitting. Answers below. > Section 3. > The procedures described in this document allows the network operator > to configure multicast VPN PEs so that they can delay the propagation > of multicast state prune messages, when faced with a rate of > multicast state dynamicity exceeding a certain configurable > threshold. > > GV> This is the delay of Prune towards the SP side and the customer side? Maybe interesting to point out if its dampening towards the C’side or the P’side of the PE. Ok, we can explain that the direction which is dampened it PE->PE. > > To be practical, such a mechanism requires configurability, in > particular, needs to offer means to control when damping is > triggered, and to allow delaying a multicast state Prune for a time > increasing with the churn of this multicast state. > > > GV> Would it make sense to spell out the exact trade-off that is made here? Dynamicity vs SP state-stability? I think the introduction already explain the kind of tradeoff that is implied: "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." I will add " This will allow control the tradeoff made between minimizing the dynamicity and reducing bandwidth consumption." to the paragraph of section 3 that you quote. > Section 4.2: > These mechanisms are not considered suitable to meet the goals > spelled out in Section 1 , the main reasons being that: > > > GV> What about adding a line specifying that fiddling with these timers does Not give independent control to the SP to control Backbone state dynamicity? I don't understand your suggestion (the control of state dynamicity would not be independent of what ?). > > Section5.1: > Figure-of-merit: …. > > GV> Maybe an explanation why exponential back off is used compared to a simple linear trigger would be interesting. While I know exponential back off algo’s are used a lot and see the benefit of adaptive back-off, it is maybe interesting to document in the draft or make a reference to a description why exponential back off is selected? Although we could make some guesses, and possibly end up guessing well, if we were to try to explain we would have to speculate what were the reasons for such an algo to be chosen for unicast BGP damping, beyond what RFC2439 already says ("An exponential decay function has the property that previous instability can be remembered for a fairly long time. "). > Section 6.2: > GV> In the realm of SDN and EVPN I see many of these EVPN’s be dynamic in location and existence (spin’d up on-demand) in the DC… There are even drafts to make an Ethernet fully virtual by means of Virtual Ethernet Segments… I was wondering how this proposal impacts the operation within this technology realm. My first guess will be more as additional (more as average) BW consumption at the benefit of less state dynamicity inside the core… Maybe different set of configured parameters for this environment can be suggested? The question of route dampening in these context is relevant I think (even for IP VPNs, not only E-VPNs), but this goes much beyond the scope of the document (which is focused on multicast) and applies to all type of routes (not only to P-tunnel related routes addressed in section 6.2). I don't think we can reasonably address the whole issue in this document. > > Section 7.1: > In the context of multicast VPNs, these procedures would be enabled > on PE routers. Additionally in the case of C-multicast routing based > on BGP extensions ([RFC6514 ]) these procedures can be enabled on > ASBRs, and possibly Route Reflectors as well. > > GV> What does “possibly” mean? Can it be used? Or can it not be used? Does the possible means that there are some considerations? I will remove "possibly", which does not add any information already present in the document. > > Section 9: Security Considerations > GV> I agree with the text.. One item is that cast may stream longer to points in the network it is not-desired. Is there potential for leaked multicast streams due to highly dynamic service VPNs which may of converged faster as the Multicast pruning due to dampening? I'm not sure I follow the scenario you describe, but I don't see a potential for traffic to leak beyond what is acceptable from an ACL standpoint. Best, -Thomas On 08/12/15 10:27, "BESS on behalf of Martin Vigoureux" wrote: >> WG, >> >> we are reiterating the request below; we would highly appreciate reviews > >from the WG before moving forward. >> Thank you >> M&T >> >> Le 21/11/2015 01:29, Martin Vigoureux a écrit : >>> WG >>> >>> This WG LC has ended some time ago but without any comment on the draft. >>> It might not have any flaw but I'd like to have the evidence that the >>> document has been reviewed. >>> Please take a moment to read it and get back to this list to share your >>> views. >>> >>> Thanks >>> -m >>> >>> >>> Le 13/10/2015 15:40, Martin Vigoureux a écrit : >>>> Hello Working Group, >>>> >>>> This email starts a Working Group Last Call on >>>> draft-ietf-bess-multicast-damping-01 [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, and send your comments to the list, no later than >>>> *27th of October*. >>>> >>>> *Coincidentally*, we are also polling for knowledge of any IPR that >>>> applies to draft-ietf-bess-multicast-damping, 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-multicast-damping-01 please respond to this email and >>>> indicate whether or not you are aware of any relevant IPR. >>>> >>>> Thank you, >>>> M&T >>>> >>>> [1] https://tools.ietf.org/html/draft-ietf-bess-multicast-damping-01 >>>> _________________________________________________________________________________________________________________________ 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 Fri Dec 18 08:20:00 2015 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 E551E1B36C5; Fri, 18 Dec 2015 08:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkKy5WILG8El; Fri, 18 Dec 2015 08:19:56 -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 330851B2EC5; Fri, 18 Dec 2015 08:19:56 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id p187so71421942wmp.0; Fri, 18 Dec 2015 08:19:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gqp0W0xXTF1b8DYgJ2xsur5veKeu+83ZPvv2MuuShZM=; b=C4xC1yyM+dw070CLnjfjJD8ObSFK+L30cbdYv4L6wxdEjNX7mB2UVAJjglilzhLHCT xhX+VqEnUjCf6mkXr6c/pDOj/GIPrF5GW0XO0OA1gAZyf7NFgMTIjXC5nZmKTGyr5cvJ CVgS6f4MPsHbbrS+FA6CAPutdBr5SC6NoqWEDDxi0fcXo+Pw+tT36+Yl/F/hJrsYoQz4 ACXNvrnoyRDLC4jXzVkB4rSKgj173Tx5Gbz5qC02j5sSXowWI1T4CG5sxgCqdQDcbDVU p6BDKtmX1SbZSTvlaE5Pj9rzwD+UkZSjBIFvOfGEbbv/uWF7WL9CRA0fkgmZShsXFb7p L1AQ== MIME-Version: 1.0 X-Received: by 10.28.133.8 with SMTP id h8mr4160565wmd.71.1450455594781; Fri, 18 Dec 2015 08:19:54 -0800 (PST) Received: by 10.28.52.130 with HTTP; Fri, 18 Dec 2015 08:19:54 -0800 (PST) In-Reply-To: <56742534.5080302@juniper.net> References: <20151218014710.16763.71345.idtracker@ietfa.amsl.com> <56742534.5080302@juniper.net> Date: Fri, 18 Dec 2015 11:19:54 -0500 Message-ID: From: Kathleen Moriarty To: Eric C Rosen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-bess-mvpn-extranet@ietf.org, The IESG , Alvaro , bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: Re: [bess] Kathleen Moriarty's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS) 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: Fri, 18 Dec 2015 16:19:58 -0000 Hi Eric, On Fri, Dec 18, 2015 at 10:24 AM, Eric C Rosen wrote: > On 12/17/2015 8:47 PM, Kathleen Moriarty wrote: >> >> I just have one question/request to improve the security consideration >> section. The only security mentioned in this draft is what's called a >> "security violation", where traffic may go to the incorrect "VPN" >> endpoint. If you are worried about traffic winding up in the wrong >> place, why is there no consideration for observing this traffic on the >> wire? Since there is no encryption, wouldn't this also be a security >> consideration to call out specifically? >> >> Mention of the possibility of active attacks that could alter or tamper >> with the traffic or passive attacks that could observe the traffic as a >> risk due to lack of encryption (confidentiality protection) would help or >> a reason why this doesn't matter. > > The reason I didn't mention this in the Security Considerations section is > that the issues are not specific to Extranet MVPN, which is the topic of > this document. The Security Considerations section mentions those issues > that could result in misdelivery of traffic if the procedures of the > document are not properly executed; this set of issues is certainly within > the scope of the document. > > I understand that there are issues having to do with the possibility of > observing or altering the traffic on the wire. Certainly I could mention > that the procedures of this document do not provide encryption, and hence do > not by themselves ensure the privacy/integrity of the data against attacks > on the backbone network. Would that be sufficient? Yes, just having that warning would go a long a way. I'm not asking you to solve it (although that would be nice), but rather to make sure it is included as a security consideration. Let me know when the text has been added and I'll clear. Thanks! Kathleen > > I don't want to make any specific recommendations for mitigating those > attacks, because: > > - Issues of how to provide privacy/integrity for multicast traffic in > general would seem to be out of scope for this document; > > - Issues of how to provide privacy/integrity for various > tunneling/encapsulation methods would seem to be out of scope for this > document; > > - Issues of how to provide privacy/integrity for the base L3VPN technology > would seem to be out of scope for this document; > > - Issues of how a Service Provider can protect its backbone network against > various attacks would also seem to be out of scope for this document. > > > > > > -- Best regards, Kathleen From nobody Fri Dec 18 08:24:38 2015 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 BC80E1B36EE; Fri, 18 Dec 2015 08:24:29 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151218162429.32646.76444.idtracker@ietfa.amsl.com> Date: Fri, 18 Dec 2015 08:24:29 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-multicast-damping-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 16:24:29 -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 Working Group 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-02.txt Pages : 15 Date : 2015-12-18 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 site. 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-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-multicast-damping-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 Fri Dec 18 11:02:14 2015 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 C83261B37C8; Fri, 18 Dec 2015 11:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rPAE_XN97pN; Fri, 18 Dec 2015 11:02:01 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E206E1B3831; Fri, 18 Dec 2015 11:02:00 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Eric C Rosen'" , "'Benoit Claise'" , "'The IESG'" References: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> <56741869.5020505@juniper.net> In-Reply-To: <56741869.5020505@juniper.net> Date: Fri, 18 Dec 2015 14:01:43 -0500 Message-ID: <00af01d139c6$898fb720$9caf2560$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01D1399C.A0C2D6E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLS05QNmCOjnF9/ygy/QKz2M1D3eQInyoXdnLyJZYA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, draft-ietf-bess-mvpn-extranet@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: Fri, 18 Dec 2015 19:02:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B0_01D1399C.A0C2D6E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eric:=20 =20 Detailed response to your comments below are in red for the current = comments (except in the template for Major point #1). For the 3 Major = comments, let me provide you a quick guide to resolving these points so = you can get past the DISCUSS quickly.=20 1) For BGP Extended community text =E2=80=93 I have provide = templates for sections that will resolve this point. If you send me = text back, I will confirm the changes ASAP, 2) For Deployment section =E2=80=93 As an OPS-DIR/NM reviewer, one = my reviewing points is whether the operational issues in deployments = are: a) fully specified, and b) summarized so operational people can get = the high-level picture. My major concern is that =E2=80=9Cb=E2=80=9D = does not exist, and you feel it is not a requirement. It is this point = we are sticking on. =20 To resolve (b) sticking: Please just try summarizing as you would in an = academic abstract the deployment issues. 3+ paragraphs should solve = this point. Given you have written 60 pages and deploy it, I suspect = you can quickly write a high-level overview. If you wish to send me a = deployment considerations overview, then I will be glad to read it. =20 My comments on the text were also to improve readability of the text so = I could tell if (a) =E2=80=9Cfully=E2=80=9D specified was there. = However, I believe that 90%-95% of all cases are specified. While I = tried to point out places where it was not clear, these are editorial = comments. You do not have to resolve these to remove the Major issue = #2. =20 3) Security considerations =E2=80=93 This was handed off to = Security Directorate, Kathleen and Stephen. If this group of security = people are happy, then Benoit will clear this point as part of the = DISCUSS. =20 Editorial points =E2=80=93 are just that. You can take them or leave = them. Thank you for considering these editorial issue.=20 =20 Sue=20 =20 From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Eric C Rosen Sent: Friday, December 18, 2015 9:30 AM To: Benoit Claise; The IESG Cc: draft-ietf-bess-mvpn-extranet@ietf.org; shares@ndzh.com; = aretana@cisco.com; 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) =20 I responded to Sue's review, but noticed that the response did not go to = the BESS mailing list. So I am sending my response again; apologies to = those who are getting it twice. On 12/17/2015 7:47 AM, Susan Hares wrote: Eric, Rahul, Yiqun, and Thomas:=20 =20 I have reviewed this document as part of the Operational directorate's=20 ongoing effort to review all IETF documents being processed by the IESG. = These=20 comments were written with the intent of improving the operational = aspects of the=20 IETF drafts. Comments that are not addressed in last call may be = included in AD reviews=20 during the IESG review. Document editors and WG chairs should treat = these comments=20 just like any other last call comments. =20 Please let me know if any of these comments are unclear. This is = interesting BESS work, and a clear deployable specification will help = with multicast traffic (video and other traffic).=20 =20 Sue Hares =20 =3D=3D=3D=3D=3D=3D =20 Status: Not ready, three major concerns and two editorial nits: =20 =20 Major concerns:=20 1) Specification of the Extranet Source Extended Community and = Extra Source extended Community Please provide the type of detail as show in RFC 4360 sections 3.1, 3.2, = and 3.3. =20 It would not be correct to do so. As you may recall, RFC7153 = reorganized the Extended Community registries, and Section 4 of RFC7153 = provides instructions on how to request Extended Community codepoints = from IANA. In fact, one of the main purposes of RFC7153 was to = eliminate the need to provide IANA with the sort of detail that is = indicated in RFC4360. I believe that the specification of the two ECs = (and the request for codepoints for them) is in accord with RFC7153 and = does not need revision. =20 I recall and I disagree with your assumptions that the IANA = specification is equivalent to the routing specification. The abstract = of RFC7153 states:=20 =20 This is done in order to remove interdependencies among the = registries, thus making it easier for IANA to determine which code points are = available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations and thus do not affect protocol implementations. The changes will, however, impact the "IANA Considerations" sections of future protocol specifications. This document updates RFC 4360 = and RFC 5701 . =20 =20 Your stating how the =E2=80=9CIANA=E2=80=9D portion should be requested = is not appropriate for this section. What you are referring to is:=20 When a codepoint is needed for a new Extended Community, the requester should first determine whether an existing Type can be used. If so, IANA should be asked to allocate a codepoint from the corresponding Sub-Type registry, if there is one. You have asked for an Opaque Transitive Extended Community.=20 =20 What I cannot tell from your description what fields exist or the values = in these two communities. If I, who have read many of these drafts, = cannot make sense of your text it is a fallacy to believe the = implementer will have a clear understanding.=20 =20 You state in 4.4.1=20 To facilitate this, we define a new Transitive Opaque Extended Community, the "Extranet Source" Extended Community. When a CE router advertises (via BGP) a route to a PE router, and the AFI/SAFI of the route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source Extended Community MAY be attached to the route. The value field of the Extended Community MUST be set to zero.=20 =20 This mixes the definition within the text rather than laying it = cleanly. =20 =20 To be proactive, here is a set of text to fix my concern with the text.=20 =20 4.4.1 Extranet Source Extended Community=20 =20 To facilitate this, we define a new Transitive Opaque Extended = Community, the "Extranet Source" Extended Community.=20 (high-type field is 0x43, sub-type: TBD). =20 =20 The value field of this extended community is all zeros. = =20 This value field MUST be set to zero upon origination, MUST be ignored = upon reception, and MUST be passed unchanged by intermediate routers. =20 [Sue Should the text in red be added to this community usage? If so, = it would be helpful to symmetrical. If not, please indicate where you = allow it to be reset in the text. ] =20 Restrictions on origination: ??=20 Restrictions on Adding/deleting this community: =20 A Route Reflector MUST NOT add/remove the Extranet Source Extended = Community from the VPN-IP routes reflected by the Route Reflector, = including the case where VPN-IP routes received via IBGP are reflected = to EBGP peers (inter-AS option (c), see [RFC6513] Section 10). =20 4.4.2 Extranet Separation Extended community=20 We define a new Transitive Opaque Extended Community, the "Extranet = Separation" Extended Community (high-type field is 0x43, sub-type: TBD). = This Extended Community is used only when extranet separation is = being used. =20 =20 Fields: Its value field MUST be set to zero upon origination, MUST be = ignored upon reception, and MUST be passed unchanged by intermediate routers. =20 =20 Restrictions on origination: ??=20 Restrictions on Adding/deleting this community: ?? =20 =20 2) 2) Why is there no Deployment considerations section? =20 There is no requirement for a Deployment Considerations section, so = absence of one cannot be grounds for a DISCUSS. I will interpret this = comment as meaning that there is insufficient discussion of deployment = issues. However, I find the comment puzzling, as so much of the draft = is about proper provisioning of the Route Targets, and Route = Distinguishers. There is also quite a bit of discussion about corner = cases, such as (a) the problem that may arise if a source host = originates both extranet and non-extranet sources, and (b) the problem = that may arise if a single address prefix is the best match for both an = extranet source and a non-extranet source. =20 In fact, you say yourself: The whole draft is a set of rules for handling policy, BGP A-D routes, = tunnel set-up, and PIM Join/leaves in the case of an intra net. Unless = these rules are followed exactly, traffic may flow into a VPN it is not = suppose to.=20 So I really don't understand what you think is missing. Sue-2: This is an OPS-DIR review of the document. One of the categories = we check is if there is sufficient information for operational = deployment in a summary form and in understandable detail. =20 =20 Your details presents problems in section 2, hypothetical cases (section = 3-7), and expects a general information to be intuited out of the draft. = Any variance from the prescribed rules is a =E2=80=9Csecurity = consideration=E2=80=9D. There is no debugging aid to make sure these = rules are followed. Surely, since your company plans to deploy this, = must have a set of deployment aids for debugging or some operational = guidance for your customer. =20 =20 My suggestion is to put in a 2-4 paragraphs in a section giving some = advice on how to deploy, how to debug (RT, RD, policy rules, filters, = erroneous filters), tips on how to go from Intra-AS M-VPN to extra. = It is a high-level =E2=80=9Cso-what=E2=80=9D that operators may as a = level setting for the Extra-Net case. =20 Extra words in defense from you on this case:=20 =C2=B7 Sue: If the customer and the SP must coordinate on = setting up filters, the procedure is outside the document.=20 =C2=B7 Eric: Yes, the interaction between the service provider = and its customers is outside the scope of this document. =C2=B7 =20 Sue: An error in any of these set-ups is considered a =E2=80=9Csecurity = violation=E2=80=9D. =20 =C2=B7 Eric: Not quite; any error in these set-ups could result = in a security violation, i.e., in delivery of data to hosts that aren't = supposed to get it. =C2=B7 Sue-2: Yes. Errors do result in security violations. = This says this protocol is more dangerous that other routing protocol = signaling. So, how are you going to help the user. Remember =E2=80=93 = this is a OPS-DIR/NM review.=20 Sue: In this set-up, one has to ask =E2=80=9Cis there another = choice=E2=80=9D to this whole design. Eric: Certainly the WG has had plenty of time to come up with up with a = better alternative.=20 Sue-2: The question is did you have other design choices that could = reduce the management overhead and the potential for error?=20 Sue: there should be a deployment section indicating how to manage the = RTs, RDs, and policy set-up.=20 Eric: I do not understand what you think is missing. This is covered = quite extensively in sections 1.3, 4, and 5. Sue-2: See comments above.=20 Sue: Perhaps experience with the Intra-As has shown deployment tips that = would make this less fragile. If so, it would be good to include an = operations consideration section. Eric: I do not think there is any requirement to have "deployment tips" = in this document, nor is there any requirement to have an "operations = considerations" section. However, since so much of the document is = devoted to the issue of how to properly provision the RTs and RDs, I = don't quite understand what you think is not covered. Sue-2: See comments above on the need for a deployment summary giving = these tips. OPS-DIR/NM reviews look to see if the operations people can = use it. IMO, you need a summary section to make this useable. My = suggestions is 3 paragraphs of tips would be sufficient. After 60 pages = of text, surely you can summarize in 3 paragraphs as you would in any = academic paper=E2=80=99s abstract. =20 Sue: If a new class of tools provides monitoring or provisioning, = mentioning these would be useful. If yang modules are being developed, = that would be useful.=20 Eric: It is not within the scope of this document to "mention" = monitoring or provisioning tools. Yang models are also outside the = scope of this document. Sue-2: Management of OAM overlays is a necessary part of understanding = a protocol which is based 50+ pages of rules. Do you believe this = protocol can operate without standard =E2=80=9Cmonitoring or = provisioning=E2=80=9D tools? If you need tools, simply say they are = needed. If you do not need tools, simply state that. To call it out of = scope for a 60 page document of rules, seems at best unwise from an = OPS/NM perspective. It would seem simply to add a paragraph in the = deployments summary to address this point.=20 =20 Out of context:=20 Sue-1: The reason why you needed debugging is that several places that = indicate issues with violated constraint: p. 11, p12, 19 (2.3.2 = =E2=80=93 a priori knowledge, inability to detect),=20 Eric: I am not entirely sure what you are asking. =20 Sue-2: I am indicated you indicate that if the rules/constraints in this = complex overlay of rules are violated (p. 11, 12, 19), and especially p. = 19 in section 2.3.2 which indicates =E2=80=9Ca priori knowledge, = inability to detect=E2=80=9D. The deployment section summary should = tell those deploying this protocol how to detected and debug issues with = =E2=80=9Cconstraint violations=E2=80=9D.=20 Sue-2: This whole section gives you a set of examples of text that could = cause conflicting operational issues as example on why you need a = OPS-DIR/NM deployment summary:=20 =20 Sue: As discussed in Section 2, the big problem in MVPN extranet is that = an egress PE may receive two distinct multicast flows that happen to = have the same IP source and IP group address, say (S,G). The = procedures and policies specified in the draft prevent two such flows = from traveling across the backbone on the same tunnel. However, the = detailed examples in sections 2.1 and 2.2 show how a given egress VRF = can end up listening to two tunnels, each of which is carrying an (S,G) = flow. In this case, only one of the tunnels is carrying the (S,G) flow = that needs to be delivered to the VRF, but the other tunnel is carrying = other flows that need to be delivered to the VRF. The problem is how to prevent the "wrong" (S,G) flow from being = delivered to a given VRF. Section 2.3 outlines two methods for = preventing this: - Since the VRF "knows" the tunnel from which to expect the (S,G) flow, = it can discard (S,G) packets coming from the other tunnel. However, not = all deployed hardware platforms are able to do this at speed. Hence the = other alternative: - Don't put more than one flow on a tunnel; then if (S,G) is flowing on = two tunnels, a given egress VRF will only be listening to one of them. = That eliminates the problematic situation in which "the other tunnel is = carrying other flows that need to be delivered to the VRF". The actual = constraint is a bit more complicated than 'don't put more than one flow = on a tunnel', but this is detailed in Section 2.3. p. 25 last paragraph (violation of constraints will cause things to not = work. However, only policy can control), p. 27 4.2.2 (1st paragraph, Route Reflector must not change),=20 Eric: Again, not sure what you are asking. This page specifies a set of = constraints on the way RTs are assigned. It points out that these = constraints are presupposed by the procedures that are later specified = for determining whether a given flow is expected to arrive from a given = tunnel. It is explained elsewhere in the document that accepting a flow = from other than the expected tunnel can result in mis-delivery of data. = What else needs to be added? Sue: p. 31 (5.1, first paragraph): This provides rules on the contraints = Eric: Section 5.1 specifies a set of constraints on the assignment of = RTs, and explains the need for them. I'm not sure what more you think = is necessary. Sue-2: What is necessary for the OPS/NM directorate review is a summary = deployment section to guide operations on deployment tools, tips, and = constraints. 3+ paragraphs in 1 section.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Eric: I think this is all explained in the draft. Are you saying that = the explanation above is incomprehensible, or are you saying that the = draft just doesn't make it clear and needs some additional text? Or are = you saying something else? Sue-2: For the major concern, I am saying that this system has = complexity that goes beyond many other systems. As such, it needs a = deployment summary section to guide the OPS/NM. I am pointing out the = complexity and varied assumptions so you can step outside of yourself, = and look at it from an operators viewpoint.=20 =20 My concern is that you sweep all of the errors that an operator in = deployment into the one pile of =E2=80=9Cif you make a mistake, then you = could send traffic where it should not go; these mistakes would cause a = security violation=E2=80=9D. I agree policy mistakes cause security = violations, but saying 50+ rules must be adhered to or you get security. = =20 For an editorial comment (and not a Major comment/DISCUSS), I find the = draft to be difficult to read. It seems to be a draft caught in the = middle of a compromise with varying styles of writing. A clear = revision of the draft with pictures and examples would make it easier to = read. With great effort, one can work through all the text.=20 =3D=3D=3D=3D=3D=3D=3D=3D Sue 2: These were pointing out the need for deployment section. = However, any editorial aid would be helpful. Sue: p. 27 4.2.2 (1st paragraph, Route Reflector must not change),=20 Eric: That's section 4.4.2; the topic is the propagation of routes = that carry the Extranet Source EC. =20 Recall that a CE puts the Extranet Source EC on an IP route to indicate = that the route represents an extranet source. The PE then translates = the IP route to a VPN-IP route, and attaches a specific set of RTs to = the VPN-IP route. The draft requires that the Extranet Source EC also = be carried by the VPN-IP route, and that it not get stripped off while = the VPN-IP route is being propagated. This rule is needed in order to = support the scenario in which a VPN contains an "Option A" interconnect. = At the Option A interconnect, the VPN-IP route gets translated back to = an IP route, and the RTs are stripped off before the IP route is = propagated. If the Extranet Source EC has also been stripped off, there = is no way for the router at the other end of the Option A interconnect = to know that the route represents an extranet source. Thus the = technique of using the Extranet Source EC to dynamically signal that a = particular route represents an extranet source will not work correctly = across an Option A interconnect unless the rules of section 4.4.2 are = followed. I can add some text about this to section 4.4.2. =20 Sue-02: That would be helpful.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D Major point 3) Is security section really a security section? It = seems more like =E2=80=9Cdo this policy=E2=80=9D or this will fail. It = should get a stronger review from the security directorate. =20 Sue-02: My goal as a OPS-DIR review is to flag anything I think should = be reviewed by other experts. I believe Kathleen has already taken care = of this issue. If Kathleen, Stephen and SEC-DIR is happy, then any of = these comments are editorial in nature.=20 =20 Eric: The Security Considerations section mentions those things that are = specific to MVPN Extranet and that need to be done properly in order to = prevent misdelivery of data. That seems like an appropriate security = section for this document. General issues of = privacy/integrity/authentication are not specific to MVPN Extranet, and = so are not mentioned here. Sue-2: I agree the key issue you are raising is that misconfiguration = of the 25+ rules can cause misdelivery of data. My point is that any = routing system that depends on 25+ rules to get right is a fragile = system. =20 =20 Your document does provide defaults. It would be good to highlight how = defaults can ease operational issues in the deployment, and in the = security section.=20 Editorial suggestions:=20 Summary: In general the authors provide dense English text to describe = this rules. In general the English text contains valid complex = sentences. However, a few things should be suggested: 1) Sue: PTA =E2=80=93 define it in a definition section or spell out = the abbreviation Eric: This acronym is expanded at first occurrence, but I will be happy = to add it to the Terminology section as well. Sue-2: Thank you.=20 4) P. 36 second paragraph. The reason for the = =E2=80=9CMUST=E2=80=9D in 1st full paragraph is a bit vague. It seems = logical, but the reasoning is just vague in the text. Are you referring to the following: "the VPN-R VRF MUST also originate one or more additional Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra- AS I-PMSI A-D route for each Incoming Extranet RT with which it has been configured" At the beginning of section 6.2, it says: "if a VPN-S VRF has extranet multicast C-sources, and a VPN-R VRF has extranet multicast C-receivers allowed by policy to receive from the C-sources in the VPN-S VRF, then the VPN-R VRF joins the MI-PMSI that VPN-S uses for its non-extranet traffic." Eric: The former paragraph describes the mechanism that VPN-R uses to = join the MI-PMSI into which VPN-S transmits. I can add a sentence to = the paragraph on page 36 saying "This is the method that VPN-R uses to = join the MI-PMSIs that may contain extranet flows that are of interest = to it". Sue-2: This is fine. Given the number of rules section pointers in the = above text are useful.=20 Sue: 7) Page 53 =E2=80=93 section 7.4.5 paragraph 3 =E2=80=9CVRF = route Import EC=E2=80=9D =E2=80=93 please spell out first usage and give = abbreviation (VRF Route Import Extended Community (EC). =20 Eric: I see only two occurrences of "EC" in the draft, so I'll just = replace them with "Extended Community". Sue-2: yes =E2=80=93 this is my point. I think this minor change will = aid readability.=20 ------=_NextPart_000_00B0_01D1399C.A0C2D6E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Eric:

 

Detailed response to your comments below are in red for the current = comments (except in the template for Major point #1). For the 3 Major = comments, let me provide you a quick guide to resolving these points so = you can get past the DISCUSS quickly.

1)      = For BGP Extended community text =E2=80=93 I have provide templates = for sections that will resolve this point.=C2=A0 If you send me text = back, I will confirm the changes ASAP,

2)      = For Deployment section =E2=80=93 As an OPS-DIR/NM reviewer, one my = reviewing points is whether the operational issues in deployments are: = a) fully specified, and b) summarized so operational people can get the = high-level picture.=C2=A0=C2=A0 My major concern is that = =E2=80=9Cb=E2=80=9D does not exist, and you feel it is not a = requirement.=C2=A0 It is this point we are sticking on. = =C2=A0

To resolve (b) sticking: Please just try summarizing as you would in = an academic abstract the deployment issues.=C2=A0 3+ paragraphs should = solve this point.=C2=A0 Given you have written 60 pages and deploy it, I = suspect you can quickly write a high-level overview. =C2=A0=C2=A0If you = wish to send me a deployment considerations overview, then I will be = glad to read it. =C2=A0

My comments on the text were also to improve readability of the text = so I could tell if (a) =E2=80=9Cfully=E2=80=9D specified was there. = However, I believe that 90%-95% of all cases are specified.=C2=A0 While = I tried to point out places where it was not clear, these are editorial = comments.=C2=A0 You do not have to resolve these to remove the Major = issue #2. =C2=A0=C2=A0

3)      = Security considerations =E2=80=93 This was handed off to Security = Directorate, Kathleen and Stephen.=C2=A0 If this group of security = people are happy, then Benoit will clear this point as part of the = DISCUSS. =C2=A0

Editorial points =E2=80=93 are just that.=C2=A0 You can take them or = leave them. Thank you for considering these editorial issue. =

 

Sue

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Eric C = Rosen
Sent: Friday, December 18, 2015 9:30 AM
To: = Benoit Claise; The IESG
Cc: = draft-ietf-bess-mvpn-extranet@ietf.org; shares@ndzh.com; = aretana@cisco.com; 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)

 

I = responded to Sue's review, but noticed that the response did not go to = the BESS mailing list.  So I am sending my response again; = apologies to those who are getting it twice.

On 12/17/2015 7:47 = AM, Susan Hares wrote:

Eric, = Rahul, Yiqun, and Thomas:

 <= /o:p>

I have = reviewed this document as part of the Operational directorate's =

ongoing = effort to review all IETF documents being processed by the IESG.  = These

comments = were written with the intent of improving the operational aspects of the =

IETF = drafts. Comments that are not addressed in last call may be included in = AD reviews

during the = IESG review.  Document editors and WG chairs should treat these = comments

just like = any other last call comments.

 <= /o:p>

Please let = me know if any of these comments are unclear.  This is interesting = BESS work, and a clear deployable specification will help with multicast = traffic (video and other traffic).

 <= /o:p>

Sue = Hares

 <= /o:p>

=3D=3D=3D=3D= =3D=3D

 <= /o:p>

Status: Not = ready,  three major concerns and two editorial nits: =  

 <= /o:p>

Major = concerns:

1)      = Specification of the Extranet Source Extended Community and Extra = Source extended Community

Please provide the type of detail as show in RFC 4360 sections = 3.1, 3.2, and 3.3. 

It = would not be correct to do so.  As you may recall, RFC7153 = reorganized the Extended Community registries, and Section 4 of RFC7153 = provides instructions  on how to request Extended Community = codepoints from IANA.   In fact, one of the main purposes of = RFC7153 was to eliminate the need to provide IANA with the sort of = detail that is indicated in RFC4360.  I believe that the = specification of the two ECs (and the request for codepoints for them) = is in accord with RFC7153 and does not need revision.

 

I recall and I disagree with your assumptions that the IANA = specification is equivalent to the routing specification.=C2=A0 The = abstract of RFC7153 states:

 

=C2=A0=C2=A0 This is done in order to remove =
interdependencies among the registries, =
thus
=C2=A0=C2=A0 making it easier for IANA to =
determine which code points are =
available
=C2=A0=C2=A0 for assignment in which =
registries.=C2=A0 This document also clarifies =
the
=C2=A0=C2=A0 =
information that must be provided to IANA when requesting =
an
=C2=A0=C2=A0 =
allocation from one or more of these registries.=C2=A0 These changes =
are
=C2=A0=C2=A0 =
compatible with the existing allocations and thus do not =
affect
=C2=A0=C2=A0 protocol implementations.=C2=A0 The =
changes will, however, impact the
=C2=A0=C2=A0 "IANA Considerations" =
sections of future protocol =
specifications.
=C2=A0=C2=A0 This document updates RFC 4360 and RFC =
5701.

 

 

Your stating how the =E2=80=9CIANA=E2=80=9D portion should be = requested is not appropriate for this section. =C2=A0What you are = referring to is: 


=C2=A0=C2=A0=C2=A0When a =
codepoint is needed for a new Extended Community, =
the
=C2=A0=C2=A0 requester should first determine =
whether an existing Type can be
=C2=A0=C2=A0 used.=C2=A0 If so, IANA should be =
asked to allocate a codepoint from the
=C2=A0=C2=A0 corresponding Sub-Type registry, if =
there is one.

You have asked for an Opaque Transitive Extended Community. =

 

What I cannot tell from your description what fields exist or the = values in these two communities.=C2=A0 If I, =C2=A0who have read many of = these drafts, =C2=A0cannot make sense of your text it is a fallacy to = believe the implementer will have a clear understanding. = 

=C2=A0
You state in =
4.4.1 

=C2=A0=C2=A0=C2=A0To facilitate this, we define a =
new Transitive Opaque Extended
=C2=A0=C2=A0 Community, the "Extranet =
Source" Extended Community.=C2=A0 When a =
CE
=C2=A0=C2=A0 router advertises (via BGP) a route =
to a PE router, and the AFI/SAFI
=C2=A0=C2=A0 of the route is 1/1, 1/2, 1/4, 2/1, =
2/2, or 2/4, the Extranet Source
=C2=A0=C2=A0 Extended Community MAY be attached to =
the route.=C2=A0 The value field of
=C2=A0=C2=A0 the Extended Community MUST be set to =
zero. 
 
This mixes the definition within the =C2=A0text rather than laying it =
cleanly. =C2=A0
 
To be proactive, here is a set of text to fix my concern with the text. =

 
4.4.1 Extranet Source Extended Community =

 
=C2=A0=C2=A0 To facilitate this, we define a new Transitive Opaque =
Extended=C2=A0 Community, the "Extranet Source" Extended =
Community. 
=C2=A0=C2=A0=C2=A0(high-type field is 0x43, sub-type: TBD). =
=C2=A0
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 The value field of this extended community is all zeros. =C2=
=A0=C2=A0=C2=A0
<=
o:p> 
T=
his value field MUST be set=C2=A0 to zero upon origination, MUST be =
ignored upon reception, and MUST =C2=A0be passed unchanged by =
intermediate routers.
 
=C2=
=A0 [Sue Should the text in red be added to this community usage?=C2=A0 =
If so, it would be helpful to symmetrical.=C2=A0 If not, please indicate =
where you allow it to be reset in the text. =
=C2=A0]
 
=C2=A0 Restrictions on origination: =C2=A0?? =

=C2=A0=C2=A0Restrictions on Adding/deleting this community: =
=C2=A0=C2=A0=C2=A0
=C2=A0A Route Reflector MUST NOT add/remove the Extranet Source =
Extended =C2=A0Community from the VPN-IP routes reflected by =C2=A0the =
Route Reflector,=C2=A0 including the case where VPN-IP routes received =
via IBGP are reflected to EBGP peers (inter-AS option (c), see =
[RFC6513]=C2=A0=C2=A0 Section 10).
 
4.4.2 Extranet Separation Extended community =

We define a new Transitive Opaque Extended Community, the =
"Extranet=C2=A0 Separation" Extended Community (high-type =
field is 0x43, sub-type: TBD).=C2=A0 =C2=A0This Extended Community is =
used only=C2=A0 when extranet separation is being used.=C2=A0 =

 
=C2=A0=C2=A0 Fields: Its value field MUST be set to zero upon =
origination, MUST be ignored upon reception, and MUST =
be
=C2=A0=C2=A0 passed unchanged by intermediate =
routers.
 
 
=C2=A0 Restrictions on origination: =C2=A0?? =

=C2=A0=C2=A0Restrictions on Adding/deleting this community: =
=C2=A0??=C2=A0 
=C2=A0

2)     = 2) Why is there no = Deployment considerations section?  =

There is no = requirement for a Deployment Considerations section,  so absence of = one cannot be grounds for a DISCUSS.  I will interpret this comment = as meaning that there is insufficient discussion of deployment = issues.  However, I find the comment puzzling, as so much of the = draft is about proper provisioning of the Route Targets, and Route = Distinguishers.  There is also quite a bit of discussion about = corner cases, such as (a) the problem that may arise if a source host = originates both extranet and non-extranet sources, and (b) the problem = that may arise if a single address prefix is the best match for both an = extranet source and a non-extranet source.   

In = fact, you say yourself:

The whole draft is a set of rules for handling policy, BGP A-D = routes, tunnel set-up, and PIM Join/leaves in the case of an intra = net.  Unless these rules are followed exactly, traffic may flow = into a VPN it is not suppose to.

So I really don't understand what you think is = missing.

S= ue-2: This is an OPS-DIR review of the document. = =C2=A0One of the categories we check is if there is sufficient = information for operational deployment in a summary form and in = understandable detail. =C2=A0

<= o:p> 

Y= our details presents problems in section 2, hypothetical cases (section = 3-7), and expects a general information to be intuited out of the = draft.=C2=A0=C2=A0 Any variance from the prescribed rules is a = =E2=80=9Csecurity consideration=E2=80=9D.=C2=A0 There is no debugging = aid to make sure these rules are followed.=C2=A0 =C2=A0Surely, since = your company plans to deploy this, must have a set of deployment aids = for debugging or some operational guidance for your customer. = =C2=A0

=C2=A0

M= y suggestion is to put in a 2-4 paragraphs in a section giving some = advice on how to deploy, how to debug (RT, RD, policy rules, filters, = erroneous filters), tips on how to go from Intra-AS M-VPN to extra. = =C2=A0=C2=A0=C2=A0It is a high-level =E2=80=9Cso-what=E2=80=9D that = operators may as a level setting for the Extra-Net case. = =C2=A0

 Extra words in defense from you on this case: =

=C2=B7         = Sue: If = the customer and the SP must coordinate on setting up filters, the = procedure is outside the document.

=C2=B7         = Eric: = Yes, the interaction between the service provider and its customers is = outside the scope of this document.

=C2=B7         =
Sue: An error in any of these set-ups is = considered a =E2=80=9Csecurity violation=E2=80=9D.  =

=C2=B7         = Eric: = Not quite; any error in these set-ups could result in a security = violation, i.e., in delivery of data to hosts that aren't supposed to = get it.

=C2=B7         = Sue-2: Yes. = Errors do result in security violations. =C2=A0This says this protocol = is more dangerous that other routing protocol signaling.=C2=A0 So, how = are you going to help the user.=C2=A0 Remember =E2=80=93 this is a = OPS-DIR/NM review.


Sue: In this = set-up, one has to ask =E2=80=9Cis there another choice=E2=80=9D to this = whole design.

Eric: Certainly the WG has had plenty of time to come up with = up with a better alternative. 


Sue-2: The question is = did you have other design choices that could reduce the management = overhead and the potential for error? =

Sue:  there should be a deployment section indicating how = to manage the RTs, RDs, and policy set-up. 

Eric: I do not understand what you think is missing.  = This is covered quite extensively in sections 1.3, 4, and 5.
Sue-2: See comments above. =

Sue: Perhaps experience with the Intra-As = has shown deployment tips that would make this less fragile.  If = so,  it would be good to include an operations consideration = section.

Eric: =C2=A0I do not think there is any requirement to have = "deployment tips" in this document, nor is there any = requirement to have an "operations considerations" = section.  However, since so much of the document is devoted to the = issue of how to properly provision the RTs and RDs, I don't quite = understand what you think is not covered.

S= ue-2: =C2=A0See comments above on the need for a deployment summary = giving these tips.=C2=A0 OPS-DIR/NM reviews look to see if the = operations people can use it.=C2=A0 IMO, you need a summary section to = make this useable.=C2=A0 My suggestions is 3 paragraphs of tips would be = sufficient.=C2=A0 After 60 pages of text, surely you can summarize in 3 = paragraphs as you would in any academic paper=E2=80=99s abstract. = =C2=A0

Sue: =C2=A0If a new class of tools = provides monitoring or provisioning, mentioning these would be useful. =  If yang modules are being developed, that would be useful. =

Eric: =C2=A0It is not within the scope of = this document to "mention" monitoring or provisioning = tools.  Yang models are also outside the scope of this = document.

S= ue-2: =C2=A0Management of OAM overlays is a necessary part of = understanding a protocol which is based 50+ pages of rules. =C2=A0Do you = believe this=C2=A0 protocol can operate without standard = =E2=80=9Cmonitoring or provisioning=E2=80=9D tools? If you need tools, = simply say they are needed. If you do not need tools, simply state that. = =C2=A0To call it out of scope for a 60 page document of rules, seems at = best unwise from an OPS/NM perspective.=C2=A0=C2=A0 It would seem simply = to add a paragraph in the deployments summary to address this point. =

 

Out of context:

Sue-1: The reason why you needed debugging is that several = places that indicate issues with violated constraint: =C2=A0p. 11, p12, 19 = (2.3.2 =E2=80=93 a priori knowledge, inability to detect),

Eric: I am not entirely sure what you are asking.

 

S= ue-2: I am indicated you indicate that if the rules/constraints in this = complex overlay of rules are violated (p. 11, 12, 19), and especially p. = 19 in section 2.3.2 which indicates =E2=80=9Ca priori knowledge, = inability to detect=E2=80=9D. =C2=A0=C2=A0The deployment section summary = should tell those deploying this protocol how to detected and debug = issues with =E2=80=9Cconstraint violations=E2=80=9D. =


Sue-2: This whole section gives you a set of = examples of text that could cause conflicting operational issues as = example on why you need a OPS-DIR/NM deployment summary:

 

Sue: As discussed = in Section 2, the big problem in MVPN extranet is that an egress PE may = receive two distinct multicast flows that happen to have the same IP = source and IP group address, say (S,G).    The procedures = and policies specified in the draft prevent two such flows from = traveling across the backbone on the same tunnel.  However, the = detailed examples in sections 2.1 and 2.2 show how a given egress VRF = can end up listening to two tunnels, each of which is carrying an (S,G) = flow.  In this case, only one of the tunnels is carrying the (S,G) = flow that needs to be delivered to the VRF, but the other tunnel is = carrying other flows that need to be delivered to the VRF.

The = problem is how to prevent the "wrong" (S,G) flow from being = delivered to a given VRF.  Section 2.3 outlines two methods for = preventing this:

- Since the VRF "knows" the tunnel = from which to expect the (S,G) flow, it can discard (S,G) packets coming = from the other tunnel.  However, not all deployed hardware = platforms are able to do this at speed.  Hence the other = alternative:

- Don't put more than one flow on a tunnel; then if = (S,G) is flowing on two tunnels, a given egress VRF will only be = listening to one of them.  That eliminates the problematic = situation in which "the other tunnel is carrying other flows that = need to be delivered to the VRF".   The actual constraint = is a bit more complicated than 'don't put more than one flow on a = tunnel', but this is detailed in Section 2.3.

p. 25 last = paragraph (violation of constraints will cause things to not work.  = However, only policy can control),

p. 27 4.2.2 = (1st paragraph, Route Reflector must not change), =

Eric: = Again, not sure what you are asking.  This page specifies a set = of constraints on the way RTs are assigned.  It points out that = these constraints are presupposed by the procedures that are later = specified for determining whether a given flow is expected to arrive = from a given tunnel.  It is explained elsewhere in the document = that accepting a flow from other than the expected tunnel can result in = mis-delivery of data.  What else needs to be = added?

Sue: p. 31 = (5.1, first paragraph): This provides rules on the contraints =

Eric: = Section 5.1 specifies a set of constraints on the assignment of RTs, and = explains the need for them.  I'm not sure what more you think is = necessary.

Sue-2: =C2=A0What is necessary for the OPS/NM = directorate review is a summary deployment section to guide operations = on deployment tools, tips, and constraints.=C2=A0 3+ paragraphs in 1 = section.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Eric: I think this is all explained in the draft.   = Are you saying that the explanation above is incomprehensible, or are = you saying that the draft just doesn't make it clear and needs some = additional text?  Or are you saying something else?

S= ue-2: For the major concern, I am saying that this system has complexity = that goes beyond many other systems. As such, it needs a deployment = summary section to guide the OPS/NM. =C2=A0I am pointing out the = complexity and varied assumptions so you can step outside of yourself, = and look at it from an operators viewpoint.

<= o:p> 

M= y concern is that you sweep all of the errors that an operator in = deployment into the one pile of =E2=80=9Cif you make a mistake, then you = could send traffic where it should not go;=C2=A0 these mistakes would = cause a security violation=E2=80=9D. =C2=A0I agree policy mistakes cause = security violations, but saying 50+ rules must be adhered to or you get = security.

<= o:p> 

F= or an editorial comment (and not a Major = comment/DISCUSS), = I find the draft to be difficult to read. =C2=A0It seems to be a draft = caught in the middle of a compromise with varying styles of = writing.=C2=A0=C2=A0 A clear revision of the draft with pictures and = examples would make it easier to read.=C2=A0 With great effort, one can = work through all the text.


=3D=3D=3D=3D=3D=3D=3D=3D

S= ue 2: These were pointing out the need for deployment section.=C2=A0 = However, any editorial aid would be = helpful.

Sue: p. 27 4.2.2 (1st = paragraph, Route Reflector must not change),

Eric: =C2=A0That's section 4.4.2;  the topic is the = propagation of routes that carry the Extranet Source EC.  =

Recall that a CE puts the Extranet Source EC on an IP route = to  indicate that the route represents an extranet source.  = The PE  then translates the IP route to a VPN-IP route, and = attaches a specific set of RTs to the VPN-IP route.  The draft = requires that the Extranet Source EC also be carried by the VPN-IP = route, and that it not get stripped off while the VPN-IP route is being = propagated.  This rule is needed in order to support the scenario = in which a VPN contains an "Option A" interconnect.  At = the Option A interconnect, the VPN-IP route gets translated back to an = IP route, and the RTs are stripped off before the IP route is = propagated.  If the Extranet Source EC has also been stripped off, = there is no way for the router at the other end of the Option A = interconnect to know that the route represents an extranet source.  = Thus the technique of using the Extranet Source EC to dynamically signal = that a particular route represents an extranet source will not work = correctly across an Option A interconnect unless the rules of section = 4.4.2 are followed.

I can add some text about this to section = 4.4.2. 

Sue-02: That would be = helpful.

=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

Major point = 3)      = Is security section really a security section? It seems more like = =E2=80=9Cdo this policy=E2=80=9D or this will fail.  It should get = a stronger review from the security directorate.

 

Sue-02: My goal as a OPS-DIR = review is to flag anything I think should be reviewed by other = experts.=C2=A0 I believe Kathleen has already taken care of this = issue.=C2=A0 If Kathleen, Stephen and SEC-DIR is happy, then any of = these comments are editorial in nature.

=C2=A0

Eric: The Security Considerations section = mentions those things that are  specific to MVPN Extranet and that = need to be done properly in order to prevent misdelivery of data.  = That seems like an appropriate security section for this document.  = General issues of privacy/integrity/authentication are not specific to = MVPN Extranet, and so are not  mentioned here.

S= ue-2:=C2=A0 I agree the key issue you are raising is that = misconfiguration of the 25+ rules can cause misdelivery of data.=C2=A0 = My point is that any routing system that depends on 25+ rules to get = right is a fragile system.=C2=A0

 

Y= our document does provide defaults.=C2=A0 It would be good to highlight = how defaults can ease operational issues in the deployment, and in the = security section.

Editorial = suggestions:

Summary: In = general the authors provide dense English text to describe this = rules.   In general the English text contains valid complex = sentences.  However, a few things should be = suggested:

1)     Sue: PTA =E2=80=93 define it in a = definition section or spell out the abbreviation

Eric: This = acronym is expanded at first occurrence, but I will be happy to add it = to the Terminology section as well.

S= ue-2: Thank you.


4)      P. 36 = second paragraph.  The reason for the =E2=80=9CMUST=E2=80=9D in = 1st full paragraph is a bit vague.  It seems logical, = but the reasoning is just vague in the text.


Are you referring to the = following:

   "the VPN-R VRF MUST also originate = one or more additional
   Intra-AS I-PMSI A-D routes.  = It MUST originate one additional Intra-
   AS I-PMSI A-D = route for each Incoming Extranet RT with which it has
   = been configured"

At the beginning of section 6.2, it = says:

   "if a VPN-S VRF has extranet multicast = C-sources, and a
   VPN-R VRF has extranet multicast = C-receivers allowed by policy to
   receive from the = C-sources in the VPN-S VRF, then the VPN-R VRF joins
   the = MI-PMSI that VPN-S uses for its non-extranet traffic."

Eric: =C2=A0The former paragraph describes the mechanism that = VPN-R uses to join the MI-PMSI into which VPN-S transmits.   I = can add a sentence to the paragraph on page 36 saying "This is the = method that VPN-R uses to join the MI-PMSIs that may contain extranet = flows that are of interest to it".

Sue-2: This is fine.=C2=A0=C2=A0 Given the number of = rules section pointers in the above text are useful. =

Sue: 7)      Page 53 = =E2=80=93 section 7.4.5 paragraph 3  =E2=80=9CVRF route Import = EC=E2=80=9D =E2=80=93 please spell out first usage and give abbreviation = (VRF Route Import Extended Community (EC). 


Eric: I see only two occurrences of = "EC" in the draft, so I'll just replace them with = "Extended Community".

S= ue-2: yes =E2=80=93 this is my point.=C2=A0 I think this minor change = will aid readability. =

------=_NextPart_000_00B0_01D1399C.A0C2D6E0-- From nobody Mon Dec 21 11:58:53 2015 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 955B31ACC7F; Mon, 21 Dec 2015 11:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, 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 4uSZgALEQHna; Mon, 21 Dec 2015 11:58:46 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7751ACC72; Mon, 21 Dec 2015 11:58:46 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.33.26] (66.129.241.10) by BLUPR0501MB2004.namprd05.prod.outlook.com (10.164.22.30) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 21 Dec 2015 19:58:40 +0000 To: Susan Hares , 'Benoit Claise' , "'The IESG'" References: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> <56741869.5020505@juniper.net> <00af01d139c6$898fb720$9caf2560$@ndzh.com> From: Eric C Rosen Message-ID: <567859EC.6030103@juniper.net> Date: Mon, 21 Dec 2015 14:58:36 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <00af01d139c6$898fb720$9caf2560$@ndzh.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BY1PR18CA0023.namprd18.prod.outlook.com (25.162.126.33) To BLUPR0501MB2004.namprd05.prod.outlook.com (25.164.22.30) X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2004; 2:YX8q2a/P7mZM9+1Jg4aWQFHE1yBXWxjXhumgMIhNJ5ZsHADyC3CQlmKcfnZn/JGQHzp0ZgDzUtWXY3xHbh59HrkjAFeER6iK2st8bJTcekiUbRfx5ZDtS+v+I9m1KL6lgEV9REBKk2hZkggq/A+LOg==; 3:PR4BMgysAu7SpSpM3rsHlACf4sTnskYbfe6PElVG+CkE374P6tZQPG7HQGasSvf1yuAA5ERnADqlxHBYMOyZrVwjsSmOiJEHCecmkHt73CKYZdBsIsZEAmdJ627h61mt; 25:1XFIFmjf1epzC/USXk3JCyP/LphoYvtsQ14ym/xor6iTsDGiv2lMNpNJ88udpR62saCYJwEExXGGeO4V2a0EFGUhLRjvZZDzSo7TTiTgcesf/RGSIbygrYBnjEdu9cZks4n0r3D0E9YylAmzXrSPEsrc86cGAnPPwVjLIf4xsW6pNs7uprThFE8lSfT59aCKzP/nsm0zWKvOq1Mw6725JHWrqgbwqEdb0chMlh3yz2Ih/XKFqRU92Rx16MCneVx93pMqd2AQAkfU6zN9vBxE/w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB2004; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2004; 20:eHko4aRveUN+g2/6MucudWfz9PRMR6SSyO2ju+GTJQetgkT06d6E/e6gt38dXID5Zvh9+9doIASozvm13ERHPbakcb95ofVBL8cCtjduWZRXKRhfP2HWbx/lGJ8sg/cUP7pEvUYyyl1HNfOALoioF9TKISPz2uyQHtEFT7wSygBwlSzVviwubdpOB0ddPCT16ceTViw3su8uRWnjz4pgbU6gYdvx6CokVmNZAh82DRFFXqAu7jdFPp5cB2y1CDkkBikVfkaDx/+jmpknk+SX1rEwkp+2AVCISOkTjcLxIWeuhx2dtpXrR54udFlapFyLVNsBsMIXuHTnlq7s1iQk1tyO/CGyb/OmziuRRHej7sDv39uUbV5k/nmHpHB6zsWxrL2pfsYLfW50JC19bGjWPFlXsFoeINwIJwGNSZXLCCG9c9JfTwn+p3Qjzwz9KrS28/5SvqxLK/Yx9J/mepEFeS0Ic9JVCNc0pi5lBy68+pLNGuIl/g/D03KQElKfuXP4; 4:SP5t6kg3xAPvHwTmeDrCgLsaIPR+aLH7BtW6eh9kJ3o3d8FroUc3PyQA5BzSH146z7XNuGx/ltSuCM0PnHrXVxcv8E3wnlXmDmg53PFK/n7vrR/fqGi8DYz4rUx3EkEOkSUOMhsBFF67jFJ1duz8J8o340BjKPVxzU6/f7RrCAc7EwpyZWaiQDAhIfyhcHK/gjxklNYdDvllwGZWacMA1mdFeBFu6kg3Rcd6UuV/FI/tmh8eSTOJifw9dFbPWVzRZx1avLQJuZD6mtV+6e46+dxQ9wevfBhXX8xl8dFPSat2Qchoeej834NyMILMJLn3Ql47b1KAkll8d7axDVeS2AaWvrGW9fvxBoQOcgBSyJOUcIqjfobyqbtOWAf49Gb3 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR0501MB2004; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2004; X-Forefront-PRVS: 079756C6B9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(189002)(76104003)(199003)(76176999)(189998001)(1096002)(586003)(5008740100001)(3846002)(99136001)(6116002)(86362001)(5001770100001)(59896002)(230700001)(5001960100002)(97736004)(50466002)(5004730100002)(105586002)(65816999)(80316001)(54356999)(50986999)(230783001)(2950100001)(106356001)(42186005)(77096005)(47776003)(83506001)(33656002)(87976001)(65956001)(92566002)(101416001)(40100003)(122386002)(81156007)(65806001)(36756003)(4001350100001)(66066001)(87266999)(64126003)(23676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2004; H:[172.29.33.26]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjA1MDFNQjIwMDQ7MjM6UXhJQ0thOWN6M0lOSFJhclcvcUtmK3Fo?= =?utf-8?B?TVF1Q3ErVTlUeUZWb3dzODBvNzlxaXZlNFFMS2VnazVCYWhnQVZUUEZpUDF5?= =?utf-8?B?WUZpOURNU3BUZm5YU241ZTR2NTNqRVpZUUJKUDJnaUVGTUhNM3dTNkJyQ1FG?= =?utf-8?B?Y2NOZWxvNGNwMTU3QUVWd1kvZjlydVZ2am85UXhQejdDUktHVEw1amswMFFr?= =?utf-8?B?R3ZjL21nTFpLRU5KZXQxOXZHUVRrcXFNT1VmS1BlVmp5S3Erd2JCRWx0a1M5?= =?utf-8?B?aW13clpSZy9LWFR1T2lST05DVE1oNUNqRURpRHM5N3FIV09DOU9oL1BqZURy?= =?utf-8?B?YVljUFhXbGdQT0llKzRxMk5pbVpKYTkyMWpna2cxVVVVNWZYZ0pmNUZWMFpB?= =?utf-8?B?cE1tSWk5K3ZIMWFRR0xwM29QQS9TZzZnUkZxSXJEdmExZjFENW1iR0JodzR6?= =?utf-8?B?bzUxUEdTbXR6eHI5OWFsOElBQmwrdVYybXo4M0xzVFI4cmt2ejdZQ3hVK2xh?= =?utf-8?B?eDlMQWxVUGpWUUtjNUN1T24wTkl5ek9GZHFlTUtORnhaSWVDb2I2L1ZNVUJU?= =?utf-8?B?SjZPZHNpRldsK0RqVENWczBGMHN2MjlLVHcwUjUzbjFLQXpJUGdORW1SbDhj?= =?utf-8?B?cDgrQVVQVlZIWHpaYTN6ODNWZ0tZK3U5RW9qL3QrTU1CS3Blc3NSeEhPMEkz?= =?utf-8?B?ck5BUzFvWkhWUXBsUUJsQUs0ODBHbzlKcCtLd0NNbWZlb0dwVkxZSU5yMUZs?= =?utf-8?B?NUFteUhJY1ZFTE1acUVURXcyYU5Jd1hHbytjMW5VMHl0TDVzYW9USjdPTkdH?= =?utf-8?B?M0l4T1MrOW82T3VmZzFiN3FxTlpxam52YkpPSzFubWRMY2NPNGlXZXNRaGRy?= =?utf-8?B?Yk4vOEtuaC9aR3VJRHRxVUlXRm1PeUlGektUbndac2lzV0NwQXBzcDBoTXVE?= =?utf-8?B?azRKU25EaFVhdHBLaXd5b0VuT0JPZW1FSVcvRTM5TTM3NHY2Y0I1dlExVmlu?= =?utf-8?B?cnNtYngzYXBWWXFTQXgva1JuaUR6TnczZVp5UTJ5RWxZMnFYUldPNWtsSzB4?= =?utf-8?B?MGd3UGg2YW43RHFhMk4wZlJsQ1pXci9FUmNmL1pQV3VsSHN4L01tZWlDYVd2?= =?utf-8?B?L1F5VUlmSk9PTlp3YUpTSjd6MkpoMm51RmlybCtCcEN0dGhPRHNHZ0l4ZWVz?= =?utf-8?B?YmJ4b0pVZ1lid3lKRjNXSzJHOVFWcjN5eEp3blFpVjhVZEdONVB6OHp6VkNE?= =?utf-8?B?RStNSSttSmJaS0JTUGorM1lZQWRtc3IwRzRKdlFmblIvdGQ3Mmk5aWptakpj?= =?utf-8?B?MUJXcXJVYjBtZmoxT21uYlVCMXduVGZmT1lOOWozdy9ScWlBU3RDZXgvbks5?= =?utf-8?B?Q29mYjE0ZkpNZ2l3MGZTSWJxWGwzTTdTYTgyTWhNdndhRVJlQklzRkVOZDVD?= =?utf-8?B?UlFuTHB1RWprUkZPQTRpS1dIUmVhNFl3a2RXeGt6L0FkZkVJSFlEOW03Tk91?= =?utf-8?B?Vk1XaEdCcUl3bVBDb1VsaU96QTl4SmVETjRnRGRrUUsvQlRUaVJ1eGg4K0M3?= =?utf-8?B?RVNjcDdXNnE3dlYxY2tWK0VVdHVDVjJBb2pEeFNIUFFBNnBobkRDOFlkZENB?= =?utf-8?B?UnMzTWRCTDB1MG1PZ2FOakxNQzhFV2MxT2E3UHI3eStVYTVDdzBjamcwclE9?= =?utf-8?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2004; 5:YMxQ4kOJxUFlMjpbFxms+7OiKnHAhIW7yfPJx8eelYOK/T4cuR36A8Gu6q962+EiDSC9qyI8Vi/uLXVQ3XUgUfajZitWoyg16ZddUC7Qsud/jc7CZHH0ryuCHiYHSywdjnvU0qCCicld0vJy+zWaxQ==; 24:OXCX/oVqjP1lx1bkP59477de/qaFYUqjFiUTS1+D1/RMfVH4m6YjLpsB9mwg27s3ROs96itRnLm9eF4gLmWl9J2CXL3GlLgzhnT2axFDUO8= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Dec 2015 19:58:40.4407 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2004 Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, draft-ietf-bess-mvpn-extranet@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, 21 Dec 2015 19:58:48 -0000 Sue, With regard to the issues re extended communities, you say "I cannot tell from your description what fields exist or the values in these two communities". Per RFC 4360, an EC consists of a type field, possibly a sub-type field, and a value field. The two ECs are defined to be Transitive Opaque Extended Communities. Per RFC 7153, the codepoint to place in the type field of a Transitive Opaque Extended Community can be found in the IANA registry "BGP Transitive Extended Community Types". Also per RFC 7153, the codepoints to placed in the sub-type field of a Transitive Opaque Extended Community can be found in the IANA registry "Transitive Opaque Extended Community Sub-Types", and the document requests IANA to make these two sub-type assignments. The text of the extranet draft says, in both cases, that the value field is to be set to zero. Thus the fields and values are already clearly specified. However, I did neglect to add normative references to RFC 4360 and RFC 7153. I will add normative references to both RFC 4360 and RFC 7153 to the sections defining the two new ECs. I'll modify the text a bit to make it clearer that the value field of the ECs MUST be set to zero, MUST be left unchanged during propagation, and MUST be ignored upon reception. With regard to deployment considerations ... Sue> What is necessary for the OPS/NM directorate review is a summary deployment section to guide operations on deployment tools, tips, and constraints. I am not aware of any IETF requirement to include such a section. Sue> Management of OAM overlays is a necessary part of understanding a protocol which is based 50+ pages of rules. Do you believe this protocol can operate without standard monitoring or provisioning tools? Certainly the protocol can operate without standard tools. Numerous deployments of Extranet MVPN have been operating for years without standard tools. Whether provisioning and/or monitoring tools need to be standardized is orthogonal to anything in this document. It might be nice for operators to have tools to verify whether their provisioning and their device configurations have been done correctly, but the design of such tools is certainly outside the scope of this document. Sue> you indicate that if the rules/constraints in this complex overlay of rules are violated (p. 11, 12, 19), and especially p. 19 in section 2.3.2 which indicates a priori knowledge, inability to detect. Whenever a VPN is provisioned, there is a risk that provisioning errors will result in an unintended cross-connection of VPNs, which would create a security problem for the customers. Extranet can be particularly tricky, as it intentionally cross-connects VPNs, but in a manner that is intended to be strictly limited by policy. If one is connecting two VPNs that have overlapping address spaces, one has to be sure that the inter-VPN traffic isn't to/from the part of the address space that is in the overlap. The draft discusses a lot of the corner cases, and a lot of the scenarios in which things can go wrong. But it is not intended to be an "operator's guide to provisioning and configuring extranet MVPN." With regard to section 2.3.2, the point is the following. If one is deploying hardware that cannot implement the "discard multicast flows that are received on the wrong tunnel" procedures, then one has to provision the extranet to limit the ways in which multiple flows can be aggregated into a single tunnel. Section 2.3.2 also points out that one cannot tell from inspection of the control messages whether this provisioning has been done correctly. Operators worried about whether their provisioning systems are up to the task may choose to deploy equipment that can do the "discard multicast flows from the wrong tunnel" procedures. Sue> What is necessary for the OPS/NM directorate review is a summary deployment section to guide operations on deployment tools, tips, and constraints. 3+ paragraphs in 1 section. I'm still perplexed about what you are asking for, or about what you think these "3 paragraphs" would say. The draft has extensive discussion of deployment constraints. There is no IETF requirement for a document of this sort to include a "tips and tools" section; that is clearly out of scope. Eric From nobody Mon Dec 21 12:31:19 2015 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 31F311ACD09; Mon, 21 Dec 2015 12:31:17 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151221203117.7405.28676.idtracker@ietfa.amsl.com> Date: Mon, 21 Dec 2015 12:31:17 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-mvpn-extranet-05.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 20:31:17 -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 Working Group of the IETF. Title : Extranet Multicast in BGP/IP MPLS VPNs Authors : Yakov Rekhter Eric C. Rosen Rahul Aggarwal Yiqun Cai Thomas Morin Filename : draft-ietf-bess-mvpn-extranet-05.txt Pages : 61 Date : 2015-12-21 Abstract: Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide MVPN extranet service. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-mvpn-extranet-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-extranet-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 21 14:49:14 2015 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 DDBFA1ACE30; Mon, 21 Dec 2015 14:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48O6NFjhmW0p; Mon, 21 Dec 2015 14:49:11 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150211ACE2F; Mon, 21 Dec 2015 14:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=843; q=dns/txt; s=iport; t=1450738151; x=1451947751; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=koGbU1iiqE59Iwnyz24ZBtVjF7USqYneuXA+UtKjZts=; b=i374jy9PjBA7NhHB21ASkiWI8hI7qLK5vA0mAFU21TZU9ZxRUSB0y8+k yNlhz2HmZ/wyawn1wPkEcrBICBQXwNP/3Pz3kycyOleyZtUqTObaoc4GQ ExowmVUsxhvJ15VnkqAKBL9Rz503feLsyytXfUoPRWzJTIkcsm6TTaSK7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAgB5gXhW/5BdJa1egzqBPwaMTK8Gg?= =?us-ascii?q?hkBDYFkhg0CgSo4FAEBAQEBAQGBCoQ1AQEEOj8QAgEINhAhESUCBAENBYgaAxK?= =?us-ascii?q?7Dg2EAwEBAQEBAQEBAQEBAQEBAQEBAQEahlYBhH2CU4ZtAQSHXosqg3gBi1KBe?= =?us-ascii?q?IFchEWPL4dbASABAUKCRIFAcgGDeYEIAQEB?= X-IronPort-AV: E=Sophos;i="5.20,461,1444694400"; d="scan'208";a="220331193" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Dec 2015 22:49:10 +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 tBLMnA68017860 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Dec 2015 22:49:10 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; Mon, 21 Dec 2015 16:49:09 -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; Mon, 21 Dec 2015 16:49:09 -0600 From: "Alvaro Retana (aretana)" To: Kathleen Moriarty , Eric C Rosen Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS) Thread-Index: AQHRPEHNpn9tZQ7wSE+4RBvon4gopw== Date: Mon, 21 Dec 2015 22:49:09 +0000 Message-ID: References: <20151218014710.16763.71345.idtracker@ietfa.amsl.com> <56742534.5080302@juniper.net> 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.117.15.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <583D1525BFB10A4AB389FEA58CE623BF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "bess-chairs@ietf.org" , "draft-ietf-bess-mvpn-extranet@ietf.org" , The IESG , "bess@ietf.org" , "martin.vigoureux@alcatel-lucent.com" Subject: Re: [bess] Kathleen Moriarty's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS) 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, 21 Dec 2015 22:49:13 -0000 Kathleen: Hi! Eric updated the draft a couple of hours ago. ;-) Please take a look. Thanks! Alvaro. On 12/18/15, 11:19 AM, "Kathleen Moriarty" wrote: >> >>I understand that there are issues having to do with the possibility of >>observing or altering the traffic on the wire. Certainly I could mention >>that the procedures of this document do not provide encryption, and >>hence do >>not by themselves ensure the privacy/integrity of the data against >>attacks >>on the backbone network. Would that be sufficient? > >Yes, just having that warning would go a long a way. I'm not asking >you to solve it (although that would be nice), but rather to make sure >it is included as a security consideration. > >Let me know when the text has been added and I'll clear. > From nobody Tue Dec 22 00:18:19 2015 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 5CF671A8706; Tue, 22 Dec 2015 00:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oZb3lmjaiiH; Tue, 22 Dec 2015 00:18:16 -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 E7C8D1A86F1; Tue, 22 Dec 2015 00:18:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBW75673; Tue, 22 Dec 2015 08:18:13 +0000 (GMT) Received: from LHREML708-CAH.china.huawei.com (10.201.5.202) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 22 Dec 2015 08:18:12 +0000 Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 22 Dec 2015 08:18:11 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.73]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Tue, 22 Dec 2015 16:18:07 +0800 From: Mach Chen To: "draft-ietf-bess-mvpn-mib@tools.ietf.org" Thread-Topic: Shepherd review on draft-ietf-bess-mvpn-mib-01 Thread-Index: AdE8kUjGiBPQPDa8Qqa42K0qHj3d2w== Date: Tue, 22 Dec 2015 08:18:06 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] 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.0A020205.56790745.007A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.73, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 04fde5a5981dcdac5aaaed2fe4052ad4 Archived-At: Cc: "bess-chairs@ietf.org" , "bess@ietf.org" Subject: [bess] Shepherd review on draft-ietf-bess-mvpn-mib-01 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, 22 Dec 2015 08:18:18 -0000 Hi Authors, I am requested (by the WG chairs) to shepherd this draft, here are my sheph= erd review comments on this document. 1. To make the document more readable, expect for the well-known abbreviati= ons, there are a lot of abbreviations (e.g., MVRF, I-/S-PMSI, etc.) that sh= ould be expanded when first use.=20 2. Abstract and introduction section s/ multicast in MPLS/BGP-based Layer-3 VPN (MVPN)/ Multicast in BGP/MPLS in= IP VPN (MVPN), to align with the definition in RFC6513 3. Section 2.1 - mvpnIpmsiTable/Entry This table contains all advertised or received intra-as I-PMSIs. With PIM-MVPN, it is applicable only when BGP-Based Autodiscovery of MVPN Membership is used. - mvpnInterAsIpmsiTable/Entry This table contains all advertised or received inter-as I-PMSIs. With PIM-MVPN, it is applicable only when BGP-Based Autodiscovery of MVPN Membership is used. 1) For each table, why is there a "/Entry" followed? To avoid confusion, I= 'd suggest to remove them if there is no special intention or meaning.=20 2 )In addition, from the above text, I have the feeling that a mvpnIpmsiTab= le or mvpnInterAsIpmsiTable can only contain advertised or received I-PMSIs= , but cannot contain both. Is this the intention? 4. Section 2.2, the LAST-UPDATED, ORGANIZATION, CONTACT-INFO and the Revisi= on history should be updated to reflect the latest status.=20 5. mvpnMvrfNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of MVRFs for IPv4 or IPv6 or mLDP C-Multicast that are present in this device." Should the "or" be changed to "and"? 6. There are several places in draft say the following or similar: "An entry in this table is created for every MVRF in the device." I'd suggest to replace the "every" as "each". 7. Page 10: mvpnGenCmcastRouteProtocol OBJECT-TYPE SYNTAX INTEGER { pim (1), bgp (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Protocol used to signal C-multicast states across the provider core. s/ Protocol /The protocol is 8. Page 13: mvpnBgpGenVrfRtImport OBJECT-TYPE SYNTAX MplsL3VpnRouteDistinguisher MAX-ACCESS read-write STATUS current DESCRIPTION "The VRF Route Import Extended Community that this device adds to unicast vpn routes that it advertises for this mvpn." ::=3D { mvpnBgpGeneralEntry 2} mvpnBgpGenSrcAs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The Source AS number in Source AS Extended Community that this device adds to the unicast vpn routes that it advertises for this mvpn." Why should the "Source", "Extended", and "Community" be upper case? If ther= e is no special intention, suggest to change to lower case. You may need to= look through the whole document to do a text clean up.=20 =20 9. Section 3, Security consideration. Given that the document introduces some read-write objects, I don't think t= hat the current statement of "This document does not introduce new security= risks." will pass the IESG review. I'd suggest the authors to enhance the = security consideration section. For the mib security consideration, you may= refer to some existing mid documents (e.g, https://tools.ietf.org/html/dra= ft-ietf-mpls-tp-oam-id-mib-11) that have already passed the IESG review. Al= so, you may refer to some history discussions on a mib security considerati= on (e.g., https://datatracker.ietf.org/doc/draft-ietf-trill-oam-mib/history= / ). 10.Please make sure that the MIB Modules are compiled cleanly. 11. BTW, I saw the WG chairs had issued the IPR poll, and only Jeffery repl= ied, to progress this draft, the authors and contributors have to respond t= o the IPR poll. Happy Holidays!=20 Best regards, Mach From nobody Tue Dec 22 01:04:17 2015 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 34DDC1A87BF; Tue, 22 Dec 2015 01:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwBUF-zty3Du; Tue, 22 Dec 2015 01:04:15 -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 4578E1A87BC; Tue, 22 Dec 2015 01:04:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFT74535; Tue, 22 Dec 2015 09:04:12 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 22 Dec 2015 09:04:11 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.73]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Tue, 22 Dec 2015 17:03:44 +0800 From: Mach Chen To: "draft-ietf-bess-l2l3-vpn-mcast-mib@tools.ietf.org" Thread-Topic: Shepherd review on draft-ietf-bess-l2l3-vpn-mcast-mib-01 Thread-Index: AdE8l6g2f4Ni5AFqQjuOGGjy0vqRCw== Date: Tue, 22 Dec 2015 09:03:43 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] 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.0A020203.5679120C.0139, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.73, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 75a0d10ed1d129c1268f58b3e24218a5 Archived-At: Cc: "bess-chairs@ietf.org" , "bess@ietf.org" Subject: [bess] Shepherd review on draft-ietf-bess-l2l3-vpn-mcast-mib-01 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, 22 Dec 2015 09:04:16 -0000 Hi Authors, I am requested (by the WG chairs) to shepherd this draft, here are my sheph= erd review comments on this document. 1. Idnits tool shows: ** There are 4 instances of too long lines in the document, the longest o= ne being 3 characters in excess of 72. 2. Expand the unwell-known abbreviations when first use. 2. Abstract says: "This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community." But the intended status of this document is "Standards Track", what's the r= eal intention? 3. From the title, the document is to define mibs for L2 and L3 Multicast V= PNs, it's better to define and scope what are L2 multicast VPN and L3 multi= cast VPN. And the draft uses "Multicast in VPN" to identify MVPN, it seems = not accurate. It's better to use the consistent definition and description = for MVPN through the whole document IMHO. 4. Section 4, The LAST-UPDATED, ORGANIZATION, CONTACT-INFO and the Revision history shoul= d be updated to reflect the latest status. 5. Page 5, This document defines the following flags: + Leaf Information Required (L)" s/+ Leaf Information Required (L)"/ Leaf Information Required (L)" 6. Section 5. Security Considerations "N/A" The same issue as the MVPN mib, please enhance it. 7. Please make sure that the MIB Modules are compiled cleanly. Best regards, Mach From nobody Tue Dec 22 06:53:23 2015 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 8C3A41A079D; Tue, 22 Dec 2015 06:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 cOU5Fm26Kbz1; Tue, 22 Dec 2015 06:53:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141E71A066C; Tue, 22 Dec 2015 06:53:13 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.33.26] (66.129.241.10) by BY2PR0501MB2006.namprd05.prod.outlook.com (10.163.197.17) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 22 Dec 2015 14:52:50 +0000 To: Benoit Claise , The IESG References: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> From: Eric C Rosen Message-ID: <567963BD.5040706@juniper.net> Date: Tue, 22 Dec 2015 09:52:45 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: CY1PR17CA0003.namprd17.prod.outlook.com (25.163.68.13) To BY2PR0501MB2006.namprd05.prod.outlook.com (25.163.197.17) X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2006; 2:bbvPtEbVyzbRRMDCz9XjSZ0YOmuug6ijw6nRus/swrq3/GeLJAECix6I1DjWWFjTBGNq7jdxy7rwuZ/eYV8u2cqimqM4OYf7LrfZbnGp5xfNNa3lQV+woYWO+G18980JvQyuIe5djMMSKqunVabaig==; 3:bOH/72iJkXfPXMsc1OeA3wF+U0T1n39fMhNZ2K2wUnHFEyac57DVs4o+7BpxdM8BR8RiH6QL3JFnCJMuUG9AGCGi//IfLId4Gxr5zjfZbTGIJzWX2X45H3md1VA8J/mO; 25:Nje/u0ansRjsaql4BpS7ZEOW8R14GaFioxwS51RI3+YbFEREQ83dudYwAnV0ScRlX/XyhYxKfUdLNBW32LT47FGL3Xr3eiixf0alEm40tbonZX5fVDU0dA8jj9G65rC+ICpVfd8+vpDTuOpss2aAz0RA9gMfHWaKWHwdksNInFrDWdFZERVIc8deunxX1Bdt9vA6fT3FRsf7A+50EjdHvrAP8MIyfbqAPpuPBqHKsdyRrhEYtvfmNT9xxw0lULpm X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB2006; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2006; 20:3/MVKxar9m95FClTBZBkPvb4/O6SWNj33rbChj0kky6Iw7orjzYwgoeAprPZk+VdTxLYkymJdng59/W6h+0c/goyGOlWkqkHeC4WTLhi3W4VRBKO37QwFyQ78FcrpGzwVXGX0r6zJDCtXiQflTfLjJEAZEqtbSjFCXFwpI5+aeXteJ57p9DwuwB5Lam5pipB9XusBjXjpQ6HoQamvFUnZPW3Jn7bOcsi4EnnN82ByJAZwWTfkYOAJqPiNbO+dssNXsRBmBXBFWE+hi8BAcOQSmuIqGL8fwFtEb6PBwJiwfTkpPp5CWmfmYtj/IJzdsB+iPPZm8iSfc9HYP8BeQHo7K0Xgb6NupN7c8MtWtJ0UfCdCb0IMrSoQ5MaoU01Mjg+8Nbi6l6vAK0Ww5svb1B4IxZtEiRfBWWSxL72SCQgReFEO0VItomIrF+5hGeiloBBiDPlzPG6aVcFZJ3Srlnxz+UKKadXMH9aU6gldp0Tjrk+q9KUSunrNvIUd3tMS3Lh; 4:4hzw2l/F4q9b2bUSei+vKrzz3TDOTA8/Wy63FQSSbzy8e2hguByCgbzmA3RzbwJ7PgC4yQRnmiagjymA+GaOhxv6G6n74mtBs1pKZsog0ty/KLP6cmwsPEuX7hHdvGMpvF4Y1MX8KywFq1qevJosx/t8J4o80wbxgqlk58uwVF1PowNf4hwPMNn6UyHnwGUOg7lZFXsQO+MN6qqddomb+VuqoaU77f0RprR0z/2U2otYQAH8cDJxQ0M4hwTwirlO+BTQUftKS6XZgEVr5q8woLAB0kqFc95Fa1J9x90RzyawJaZsV1Cd6JJiMvx64+uxT/SALK8QcjAqHqfNlnnajFZbu+6ILbmUJs0+1vho1rFjd9CTEC+4xi2TS90CTDH0 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:BY2PR0501MB2006; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB2006; X-Forefront-PRVS: 0798146F16 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(479174004)(199003)(189002)(52044002)(24454002)(377454003)(15975445007)(81156007)(19580395003)(40100003)(5001770100001)(65806001)(189998001)(76176999)(33656002)(86362001)(47776003)(36756003)(122386002)(101416001)(80316001)(87266999)(83506001)(4001350100001)(1096002)(65956001)(5001960100002)(87976001)(23676002)(99136001)(5004730100002)(92566002)(586003)(66066001)(97736004)(59896002)(2950100001)(230783001)(54356999)(42186005)(106356001)(105586002)(6116002)(5008740100001)(50466002)(65816999)(77096005)(50986999)(64126003)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB2006; H:[172.29.33.26]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjA1MDFNQjIwMDY7MjM6QmhCM3RvbXhpaytWTlAzUE83bUF5b1dl?= =?utf-8?B?bDI1RUlBaGtRWExKa2xnYXpvOHdKc01mTFJEQ3ZyWnF1L1p4ZDQzaHA3eWxw?= =?utf-8?B?N1IzS3ZqVytMbHFKZU1SZmJWeWc3SXAyM3F4ajdjc1ZleGpPbVhWVXRpZXZU?= =?utf-8?B?R3dOWkgrTXc5ZkZkaDVseEM2eWhXcDlEdVQ0MEx1N0M1dHRkcXF3TkZVRzh4?= =?utf-8?B?MXY0YU5VZWRBTzB5dVN0aVBmM1ZsRWtWeFBJalJUL0Vua3BhemJYSEdyWCtp?= =?utf-8?B?VUZuNmJtNDBqKzdZRUlUd0RDbW12N3RtQ0lVTkR2dmRtT0VZZ1J2UTIzWGxw?= =?utf-8?B?K2txU1E2TVRjWmNRc2t3TkxHdUVrdG8rWFF2QmdSbVN4QUtuNGszYkNKTWgy?= =?utf-8?B?RlZlZ0lleC85YTk4bjJzTzQwM21XbXNXMk1HQkViQTdUYVZCTXNEYWZJSWNz?= =?utf-8?B?R1hwTjFZM1ZqdTJDOFJqQ1g5L2IzVEpSZ3BhdU16aFdGbnFiS3NxYlRYdEpa?= =?utf-8?B?amFPMmNwa3ZyTW9lRlpucGF4clBNS0xRcHdrSFUza0d4YVZieSs2V3dEY2dI?= =?utf-8?B?ODlRemkyZzk0eXYwRTNnUk4yeHN6aEVCS0xtSHNKYkxrWlFYY3kvUnVnUkpQ?= =?utf-8?B?N3dYR1o2bFE5QWV2azZ5bVVIbElGYitFQUNWNDlRRWk4dGFUdjhIQzh5cU9s?= =?utf-8?B?MjdWTmplZjRjaWZYcUN2N0V5UHgxYmtMcDJmUytQZ2xKTU1ia05YT0FHbUFV?= =?utf-8?B?RlRiS21YTnhmaG1VaUlKaXpiYXkxQkd0SEFGR3FCR0h0N09mV3FEY09mck85?= =?utf-8?B?MXVDbldQTGlhZ0plMjJKWlpCSzBmeUF0enM2RnR4VnEwWVF0NTVwZ2JEUStm?= =?utf-8?B?VXdIbFZvY3R5RGxMZG1CRm04MGN2WlpxSTYvcmtBR2daa1JxTngvVXZtRk9o?= =?utf-8?B?dFlyczN6V01udkFNYTVaSVNXQlNkVGM5NnJNM1d1TnVDclM1S2xacGN5V1lh?= =?utf-8?B?KzR1ZnlVOExrYmVrSXgzNzhXOEkreE1paXJUNTQwNHZiQ1FhbW12WDBnNndL?= =?utf-8?B?WVNmSEJEVVhXTnd2aXp1S1Y3YU1BRnI5emxzN2tGbWZqRVRTMFJ6b1pNMUVt?= =?utf-8?B?SFNHeXdIUVdEK1JKWWJ4ZzhnNkIyV08yZVhKM2pCVG1Gb3JYWjNqTFZJQlhk?= =?utf-8?B?Rnc1S1l5MkI4dWZyWDYwVll6Zkg3UjlmMHhTTzQxVGw5N2M2cXVEekNEZnVE?= =?utf-8?B?d1RqMXFBY01JNnk1dE54WFpIeXNQSW4vb2d6OCtjNEdrbnAxNWhtQzUwaVNK?= =?utf-8?B?OWJXWU1NdEpSZWNnVzNTUXVBSU4vemtXRVNxZlRTL1ZlQ0NKSVJzaTc1RVQw?= =?utf-8?B?NVVBemdSaUNuNmpyYytpMVNKT3dhdlBwUkV0c0ZzVVMxT0ZBRW9kQ0t6QU1D?= =?utf-8?B?dmltdWcyekN6YnhzSTgrblM2VVYrQytIaWM0dFdjTlVhRFViaDBDKzJXV0Zy?= =?utf-8?B?aXZvTjJjVXIyOU1YQXpOckRJd2l3RmNJSnFJRVBTTFhYOWpXT3VBY2VCbU9W?= =?utf-8?B?RnhNTHdpd1Y0M0Zhd25lTzJZVDJnTzNYWjRXZnF2bFNsUkwzNDNxSUZTSXdV?= =?utf-8?B?Qzdpb1l2eXNQcnZuU2tZbnV5VlY3dDBNR3VJbzdicGtROE9pOVFOV21Nd3lF?= =?utf-8?B?YXZQZi95bkdVWnhNQnNERXJ0dm5JMjJ2eEltTHloNUw5RDA0Yjd5bjJZaWZE?= =?utf-8?B?bWJsZHdkYmI1UmR6cm1IMVVua1UxOFBOVE5ZdkZkZ1JNSUJ6K0k0aXhXdzMr?= =?utf-8?Q?XLofm0dYxkrO4/N?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2006; 5:J8uu7G0HOSR5s7XaIoFFF9YMMonPDyeb6GA34/h3yZQx+spPBuyE9jpSidmlKGEsPgH7X+L3Finc19b3TadNdGcnCgsWKb6CdsYRh7+QG19piSQ58WYDsveVZL7r1CJWlogsNYXN6RRZtkVV19f+Bg==; 24:hJfvvg7WxYnewiVAsTW6DTFyIYuo/I2OJ9u4iujBxzrQKm7x34lXMUT/60jPyMnPPAtVHKUjnnML6K3dfggiipDGHCNEKcQfGD4EBKr5XxE= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Dec 2015 14:52:50.5973 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB2006 Archived-At: Cc: draft-ietf-bess-mvpn-extranet@ietf.org, shares@ndzh.com, aretana@cisco.com, 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: Tue, 22 Dec 2015 14:53:18 -0000 Draft-ietf-bess-mvpn-extranet-05 has been posted. This revision contains some edits to the sections on the Extended Communities, and some other editorial changes, stemming from the ops-dir review. I did not follow the suggestion of the ops-dir review to add an "Operator Tips and Tricks" section, as that would be outside the scope of the document, and there is no IETF requirement to include such a section. On 12/17/2015 8:30 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-bess-mvpn-extranet-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > As mentioned in Sue Hares' OPS DIR, 3 major concerns. The last one is > actually for the security ADs. > > 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 > > Please provide the type of detail as show in RFC 4360 sections 3.1, 3.2, > and 3.3. > > 2) Why is there no Deployment considerations section? > > The whole draft is a set of rules for handling policy, BGP A-D routes, > tunnel set-up, and PIM Join/leaves in the case of an intra net. Unless > these rules are followed exactly, traffic may flow into a VPN it is not > suppose to. > > If the customer and the SP must coordinate on setting up filters, the > procedure is outside the document. > > An error in any of these set-ups is considered a “security violation”. > > Milo Medin stated “with enough trust” a rock can fly to the moon. > However, the NASA flights were fragile and risky. In the journey to the > moon, there was no other choice. Instrumentation has 4-5 backups. > > In this set-up, one has to ask “is there another choice” to this whole > design that seem fragile addition of extranets to an intra-AS multicast > design. If the design is not fragile, then there should be a deployment > section indicating how to manage the RTs, RDs, and policy set-up. > Perhaps experience with the Intra-As has shown deployment tips that would > make this less fragile. If so, it would be good to include an > operations consideration section. > > If a new class of tools provides monitoring or provisioning, mentioning > these would be useful. If yang modules are being developed, that would > be useful. > > Places that indicate issues with violated constraint: > > p. 11, 12, 19 (2.3.2 – a priori knowledge, inability to detect), , p. 25 > last paragraph (violation of constraints will cause things to not work. > However, only policy can control), p. 27 4.2.2 (1st paragraph, Route > Reflector must not change), p. 31 (5.1, first paragraph), > > 3) Is security section really a security section? It seems more like > “do this policy” or this will fail. It should get a stronger review from > the security directorate > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Editorial suggestions: > > > > Summary: In general the authors provide dense English text to describe > this rules. In general the English text contains valid complex > sentences. However, a few things should be suggested: > > > > 1) PTA – define it in a definition section or spell out the > abbreviation > > 2) Phrases like “the RT RT-R” become overly dense. Use “Route > Target RT-R”. > > 3) Breaking up section 6.2.1 – with subjection and subtitles would > make it more readable, > > 4) P. 36 second paragraph. The reason for the “MUST” in 1st full > paragraph is a bit vague. It seems logical, but the reasoning is just > vague in the text. > > 5) paragraph 2 in page 47 (section 7.3.1) is awkward, please reword. > > > 6) Paragraph 5 in page 47 (section 7.3.1) – does not explain why the > condition should hold. The authors have done this in eac other case, so > it seems inconsistent. > > 7) Page 53 – section 7.4.5 paragraph 3 “VRF route Import EC” – > please spell out first usage and give abbreviation (VRF Route Import > Extended Community (EC). > > From nobody Tue Dec 22 07:25:19 2015 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 53FE61A1A5F; Tue, 22 Dec 2015 07:25:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151222152516.3794.33060.idtracker@ietfa.amsl.com> Date: Tue, 22 Dec 2015 07:25:16 -0800 Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, draft-ietf-bess-mvpn-extranet@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: [bess] Kathleen Moriarty's No Objection on draft-ietf-bess-mvpn-extranet-05: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 15:25:16 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-bess-mvpn-extranet-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for adding text to clearly state there is no session encryption in the security considerations section. From nobody Tue Dec 22 09:52:26 2015 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 5AE9F1A8A08; Tue, 22 Dec 2015 09:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFZ7SWAOb8lO; Tue, 22 Dec 2015 09:52:18 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 70BC51A8904; Tue, 22 Dec 2015 09:52:17 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Eric C Rosen'" , "'Benoit Claise'" , "'The IESG'" References: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> <56741869.5020505@juniper.net> <00af01d139c6$898fb720$9caf2560$@ndzh.com> <567859EC.6030103@juniper.net> In-Reply-To: <567859EC.6030103@juniper.net> Date: Tue, 22 Dec 2015 12:51:54 -0500 Message-ID: <006101d13ce1$725cd650$571682f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01D13CB7.8989DB90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLS05QNmCOjnF9/ygy/QKz2M1D3eQInyoXdAa7znfEBVAvt05yqsZKg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-bess-mvpn-extranet@ietf.org, "'John G. Scudder'" , aretana@cisco.com, 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: Tue, 22 Dec 2015 17:52:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0062_01D13CB7.8989DB90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Eric:=20 =20 Thank you for revisions in version -05 of your document. Unfortunately = it does not resolve either of the two points I raised.=20 =20 1) On the BGP Extended Communities, I feel your specification is = unclear and warrants change on the DISCUSS Criteria due to = interoperability issues. I=E2=80=99ve given you 2 small sections to = add to your document at the beginning of section 4.4. to resolve this = DISCUSS point. You need to just fill in one part below on RR = restrictions for Extranet Separation Extended community. =20 =20 2) On the deployment section: I given text and examples =E2=80=93 but I = think you still misunderstand what I am looking for. =20 =20 Since you are an author of academic papers, consider I am looking for = an operator-based =E2=80=9Cabstract=E2=80=9D 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 =20 The =E2=80=9Csecurity consideration =E2=80=9D in section 10 in the text = use =E2=80=9Csecurity consideration=E2=80=9D as a euphemism for the = traffic being sent to the wrong place. This is deployment and security = issue =E2=80=93 not just a security consideration. The third paragraph = of your text in section 10 starting with =E2=80=9CIn general, different = VPNs are allowed to have overlapping IP address=E2=80=9D needs to = clearly state what you stated to me in this last email. (see the text = below).=20 =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 =20 Cheerily,=20 =20 Sue=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =20 BGP Communities text to resolve comment:=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 4.4.1 Extranet Source Extended Community=20 =20 To facilitate this, we define a new Transitive Opaque Extended = Community, the "Extranet Source" Extended Community.=20 (high-type field is 0x43, sub-type: TBD). The value field of this = extended community is all zeros. =20 =20 Restrictions: This value field MUST be set to zero upon origination, = MUST be ignored upon reception and MUST be passed unchanged by = intermediate routers. =20 =20 Additional Restrictions: A Route Reflector MUST NOT add/remove the = Extranet Source Extended Community from the VPN-IP routes reflected by = the Route Reflector, including the case where VPN-IP routes received = via IBGP are reflected to EBGP peers (inter-AS option (c), see [RFC6513] = Section 10). 4.4.2 Extranet Separation Extended community=20 =20 We define a new Transitive Opaque Extended Community, the "Extranet = Separation" Extended Community (high-type field is 0x43, sub-type: TBD). = This Extended Community is used only when extranet separation is = being used. =20 =20 Restrictions: Its value field MUST be set to zero upon origination, = MUST be ignored upon reception, and MUST be passed unchanged by intermediate routers. =20 Restrictions on Adding/deleting this community: ?? (Eric =E2=80=93 = please add something here).=20 =20 =20 Comments that could be put in a Security section:=20 =20 Whenever a VPN is provisioned, there is a risk that provisioning errors = will result in an unintended cross-connection of VPNs, which would = create a security problem for the customers. Extranet can be = particularly tricky, as it intentionally cross-connects VPNs, but in a = manner that is intended to be strictly limited by policy. If one is = connecting two VPNs that have overlapping address spaces, one has to be = sure that the inter-VPN traffic isn't to/from the part of the address = space that is in the overlap. The draft discusses a lot of the corner = cases, and a lot of the scenarios in which things can go wrong. =20 =20 =20 -----Original Message----- From: Eric C Rosen [mailto:erosen@juniper.net]=20 Sent: Monday, December 21, 2015 2:59 PM To: Susan Hares; 'Benoit Claise'; 'The IESG' Cc: draft-ietf-bess-mvpn-extranet@ietf.org; aretana@cisco.com; = 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) =20 Sue, =20 With regard to the issues re extended communities, you say "I cannot = tell from your description what fields exist or the values in these two = communities". =20 Per RFC 4360, an EC consists of a type field, possibly a sub-type field, = and a value field. The two ECs are defined to be Transitive Opaque = Extended Communities. Per RFC 7153, the codepoint to place in the type = field of a Transitive Opaque Extended Community can be found in the IANA = registry "BGP Transitive Extended Community Types". Also per RFC 7153, = the codepoints to placed in the sub-type field of a Transitive Opaque = Extended Community can be found in the IANA registry "Transitive Opaque = Extended Community Sub-Types", and the document requests IANA to make = these two sub-type assignments. The text of the extranet draft says, in = both cases, that the value field is to be set to zero. Thus the fields = and values are already clearly specified. However, I did neglect to add = normative references to RFC 4360 and RFC 7153. =20 I will add normative references to both RFC 4360 and RFC 7153 to the = sections defining the two new ECs. =20 I'll modify the text a bit to make it clearer that the value field of = the ECs MUST be set to zero, MUST be left unchanged during propagation, = and MUST be ignored upon reception. =20 With regard to deployment considerations ... =20 Sue> What is necessary for the OPS/NM directorate review is a summary deployment section to guide operations on deployment tools, tips, and = constraints. =20 I am not aware of any IETF requirement to include such a section. =20 Sue> Management of OAM overlays is a necessary part of understanding a protocol which is based 50+ pages of rules. Do you believe this = protocol can operate without standard monitoring or provisioning tools? =20 Certainly the protocol can operate without standard tools. Numerous = deployments of Extranet MVPN have been operating for years without = standard tools. Whether provisioning and/or monitoring tools need to be = standardized is orthogonal to anything in this document. =20 It might be nice for operators to have tools to verify whether their = provisioning and their device configurations have been done correctly, = but the design of such tools is certainly outside the scope of this = document. =20 Sue> you indicate that if the rules/constraints in this complex overlay of rules are violated (p. 11, 12, 19), and especially p. 19 in section 2.3.2 which indicates a priori knowledge, inability to detect. =20 Whenever a VPN is provisioned, there is a risk that provisioning errors = will result in an unintended cross-connection of VPNs, which would = create a security problem for the customers. Extranet can be = particularly tricky, as it intentionally cross-connects VPNs, but in a = manner that is intended to be strictly limited by policy. If one is = connecting two VPNs that have overlapping address spaces, one has to be = sure that the inter-VPN traffic isn't to/from the part of the address = space that is in the overlap. The draft discusses a lot of the corner = cases, and a lot of the scenarios in which things can go wrong. But it = is not intended to be an "operator's guide to provisioning and = configuring extranet MVPN." =20 With regard to section 2.3.2, the point is the following. If one is = deploying hardware that cannot implement the "discard multicast flows = that are received on the wrong tunnel" procedures, then one has to = provision the extranet to limit the ways in which multiple flows can be = aggregated into a single tunnel. Section 2.3.2 also points out that one = cannot tell from inspection of the control messages whether this = provisioning has been done correctly. Operators worried about whether = their provisioning systems are up to the task may choose to deploy = equipment that can do the "discard multicast flows from the wrong = tunnel" procedures. =20 Sue> What is necessary for the OPS/NM directorate review is a summary deployment section to guide operations on deployment tools, tips, and = constraints. 3+ paragraphs in 1 section. =20 I'm still perplexed about what you are asking for, or about what you = think these "3 paragraphs" would say. The draft has extensive = discussion of deployment constraints. There is no IETF requirement for = a document of this sort to include a "tips and tools" section; that is = clearly out of scope. =20 Eric =20 =20 =20 =20 ------=_NextPart_000_0062_01D13CB7.8989DB90 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Eric: =

 

Thank you for revisions in version -05 of your = document. =C2=A0Unfortunately it does not resolve either of the two = points I raised.

 

1)      = On the BGP Extended Communities, I feel = your specification is unclear and warrants change on the DISCUSS = Criteria due to interoperability issues.=C2=A0=C2=A0 I=E2=80=99ve given = you 2 small sections to add to your document at the beginning of section = 4.4. to resolve this DISCUSS point. =C2=A0You need to just fill in one = part below on RR restrictions for Extranet Separation Extended = community. =C2=A0

 

2) = On the deployment section: =C2=A0I given text and examples = =E2=80=93 but I think you still misunderstand what I am looking for. = =C2=A0=C2=A0

 

Since = you are an author of academic papers,=C2=A0 consider I am looking for an = operator-based =E2=80=9Cabstract=E2=80=9D that focuses the reader on the = key points. =C2=A0I am sure you can create one for this document, but I = not clear why you object to it the concept.=C2=A0

 

The = =E2=80=9Csecurity consideration =E2=80=9D in section 10 in =C2=A0the = text use =E2=80=9Csecurity consideration=E2=80=9D as a euphemism for the = traffic being sent to the wrong place.=C2=A0 This is deployment and = security issue =E2=80=93 not just a security consideration. = =C2=A0=C2=A0The third paragraph of your text in section 10 starting with = =E2=80=9CIn general, different VPNs are allowed to have overlapping IP = address=E2=80=9D needs to clearly state what you = stated to me in this last email. =C2=A0(see the text below). =

 

To limit the email back-forth, will you please let = me know that you have read my suggested text insertions on both these = topics. =C2=A0I will email Benoit/Joel offline regarding #2 deployment = to see if he believes it is not a DISCUSS criteria. = =C2=A0

 

Cheerily,

 

Sue =

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 

BGP = Communities text to resolve comment:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

4.4.1 Extranet Source Extended Community =

 

=C2=A0=C2=A0 To facilitate this, we define a new = Transitive Opaque Extended=C2=A0 Community, the "Extranet = Source" Extended Community.

=C2=A0=C2=A0=C2=A0(high-type field is 0x43, = sub-type: TBD).=C2=A0 The value field of this extended community is all = zeros.=C2=A0=C2=A0=C2=A0

=C2=A0

Restrictions: This value field MUST be = set=C2=A0 to zero upon origination, =C2=A0MUST be ignored upon reception = and MUST=C2=A0 be passed unchanged by intermediate routers.=C2=A0 =

 

=C2=A0 Additional Restrictions: =C2=A0A = Route Reflector MUST NOT add/remove the Extranet Source Extended=C2=A0 = Community from the VPN-IP routes reflected by=C2=A0 the Route = Reflector,=C2=A0 including the case where VPN-IP routes received via = IBGP are reflected to EBGP peers (inter-AS option (c), see = [RFC6513]=C2=A0=C2=A0 Section 10).

4.4.2 = Extranet Separation Extended community

 

We define a new Transitive Opaque Extended = Community, the "Extranet=C2=A0 Separation" Extended Community = (high-type field is 0x43, sub-type: TBD).=C2=A0=C2=A0 This Extended = Community is used only=C2=A0 when extranet separation is being = used.=C2=A0

 

=C2=A0=C2=A0 Restrictions: =C2=A0Its value = field MUST be set to zero upon origination, MUST be ignored upon = reception, and MUST be

=C2=A0=C2=A0 passed unchanged by intermediate = routers.

 

=C2=A0 Restrictions on Adding/deleting this = community:=C2=A0 ??=C2=A0 (Eric =E2=80=93 please add something here). =

=C2=A0

 

Comments that could be put in a Security = section:

 

Whenever a VPN is provisioned, there is a risk that = provisioning errors will result in an unintended cross-connection of = VPNs, which would create a security problem for the customers.=C2=A0 = Extranet can be particularly tricky, as it intentionally cross-connects = VPNs, but in a manner that is intended to be strictly limited by = policy.=C2=A0 If one is connecting two VPNs that have overlapping = address spaces, one has to be sure that the inter-VPN traffic isn't = to/from the part of the address space that is in the overlap.=C2=A0 The = draft discusses a lot of the corner cases, and a lot of the scenarios in = which things can go wrong. =C2=A0

 

 

-----Original Message-----
From: Eric C Rosen = [mailto:erosen@juniper.net]
Sent: Monday, December 21, 2015 2:59 = PM
To: Susan Hares; 'Benoit Claise'; 'The IESG'
Cc: = draft-ietf-bess-mvpn-extranet@ietf.org; aretana@cisco.com; = 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)

 

Sue,

 

With = regard to the issues re extended communities, you say "I cannot = tell from your description what fields exist or the values in these two = communities".

 

Per = RFC 4360, an EC consists of a type field, possibly a sub-type field, and = a value field.=C2=A0 The two ECs are defined to be Transitive Opaque = Extended Communities.=C2=A0 Per RFC 7153, the codepoint to place in the = type field of a Transitive Opaque Extended Community can be found in the = IANA registry "BGP Transitive Extended Community Types".=C2=A0 = Also per RFC 7153, the codepoints to placed in the sub-type field of a = Transitive Opaque Extended Community can be found in the IANA registry = "Transitive Opaque Extended Community Sub-Types", and the = document requests IANA to make these two sub-type assignments. The text = of the extranet draft says, in both cases, that the value field is to be = set to zero.=C2=A0 Thus the fields and values are already clearly = specified.=C2=A0 However, I did neglect to add normative references to = RFC 4360 and RFC 7153.

 

I will = add normative references to both RFC 4360 and RFC 7153 to the sections = defining the two new ECs.

 

I'll = modify the text a bit to make it clearer that the value field of the ECs = MUST be set to zero, MUST be left unchanged during propagation, and MUST = be ignored upon reception.

 

With = regard to deployment considerations ...

 

Sue> What is necessary for the OPS/NM = directorate review is a summary

deployment section to guide operations on = deployment tools, tips, and constraints.

 

I am = not aware of any IETF requirement to include such a = section.

 

Sue> Management of OAM overlays is a necessary = part of understanding a

protocol = which is based 50+ pages of rules.=C2=A0 Do you believe this protocol = can operate without standard monitoring or provisioning = tools?

 

Certainly the protocol can operate without standard = tools.=C2=A0 Numerous deployments of Extranet MVPN have been operating = for years without standard tools.=C2=A0 Whether provisioning and/or = monitoring tools need to be standardized is orthogonal to anything in = this document.

 

It = might be nice for operators to have tools to verify whether their = provisioning and their device configurations have been done correctly, = but the design of such tools is certainly outside the scope of this = document.

 

Sue> you indicate that if the rules/constraints = in this complex overlay

of rules = are violated (p. 11, 12, 19), and especially p. 19 in = section

2.3.2 which indicates a = priori knowledge, inability to detect.

 

Whenever a VPN is provisioned, there is a risk that = provisioning errors will result in an unintended cross-connection of = VPNs, which would create a security problem for the customers.=C2=A0 = Extranet can be particularly tricky, as it intentionally cross-connects = VPNs, but in a manner that is intended to be strictly limited by = policy.=C2=A0 If one is connecting two VPNs that have overlapping = address spaces, one has to be sure that the inter-VPN traffic isn't = to/from the part of the address space that is in the overlap.=C2=A0 The = draft discusses a lot of the corner cases, and a lot of the scenarios in = which things can go wrong.=C2=A0 But it is not intended to be an = "operator's guide to provisioning and configuring extranet = MVPN."

 

With = regard to section 2.3.2, the point is the following.=C2=A0 If one is = deploying hardware that cannot implement the "discard multicast = flows that are received on the wrong tunnel" procedures, then one = has to provision the extranet to limit the ways in which multiple flows = can be aggregated into a single tunnel.=C2=A0 Section 2.3.2 also points = out that one cannot tell from inspection of the control messages whether = this provisioning has been done correctly. Operators worried about = whether their provisioning systems are up to the task may choose to = deploy equipment that can do the "discard multicast flows from the = wrong tunnel" procedures.

 

Sue> What is necessary for the OPS/NM = directorate review is a summary

deployment section to guide operations on = deployment tools, tips, and constraints.=C2=A0 3+ paragraphs in 1 = section.

 

I'm still perplexed about what you are asking for, = or about what you think these "3 paragraphs" would say.=C2=A0 = The draft has extensive discussion of deployment constraints.=C2=A0 = There is no IETF requirement for a document of this sort to include a = "tips and tools" section; that is clearly out of = scope.

 

Eric

 

 

 

 

------=_NextPart_000_0062_01D13CB7.8989DB90-- From nobody Tue Dec 22 11:08:33 2015 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 8CD3D1A8A91; Tue, 22 Dec 2015 11:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 M4KC9GZXf_jH; Tue, 22 Dec 2015 11:08:23 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB381A8A8E; Tue, 22 Dec 2015 11:08:23 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.33.26] (66.129.241.10) by SN1PR0501MB2158.namprd05.prod.outlook.com (10.163.229.152) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 22 Dec 2015 19:08:19 +0000 To: Susan Hares , 'Benoit Claise' , "'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> From: Eric C Rosen Message-ID: <56799F9F.4010907@juniper.net> Date: Tue, 22 Dec 2015 14:08:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <006101d13ce1$725cd650$571682f0$@ndzh.com> Content-Type: multipart/alternative; boundary="------------040307000108060509040004" X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: SN1PR16CA0010.namprd16.prod.outlook.com (25.169.34.20) To SN1PR0501MB2158.namprd05.prod.outlook.com (25.163.229.152) X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 2:W4qI0UI58a5CYHIQaGqD5E2HxhXdi/PtEteH2ZTmmMo1OTI1H/pbHsRcpz48SjmsgxAigWNLAao/c9hWQPmWXMeXrNKG1HjYUr2BhMjCq9DJtVouBiH0tAWpHCtF8vaEL3qo3VYu6oS0QKdml/3Hhg==; 3:K08KYxGT5snoDrK42aHJ4J1VpOmJYuLAStNZPNi7nCj48tw35RE9xoJeX9YHAfV8UmCnXL3fJjW+Km4qlkvHFSkNxlhQiv2MOJ5KIEG2DwZnirkWDzN+MP5avpcjbFCk; 25:nbVsklJ5LV3E3XMpCTkt6iVEdwY/mVkVmQGt2Ib0eV4cJc7ALPxhGq3iXveF0cGrZ7R1wmzUUkIbDO4v/gHf0AhRkInsy8SJU+sNHizFRfAYpklofMzrHjxKpdwlddqr/Kq79wjhcjo67OouQFh1TnWjwkIxH8352W6/8FwSaJ+5zFW8Jswa60IHXagMSUhmlviMU3yUB+ovQHDm/4vjEde3uhWMwCMib9FVaab4XhnY1c7WOLdU+F96CMEgoQGWuldNXeYEMG1bCrtoQJ+9Ag== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2158; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 20:EkQbSC8ZZ1vI7KSqba5lrvmTHVr9uyKGT7PVZx2l3m4ElvS4TrgBrbMBCjKkMdeLhqnvmWD+YsXJUXE+Od67hsjtvi1LeFhGFuyUS5cGQY5otJmzX8P2mVNqYTF10nEfnVNuLl5vFNmBye7jf/1C5zW5TpszHmYMrtV5ylRSht6DZKe9TE+p2dl3turEHXYTqBhdMCsiTkK74TdB+llrQAh6oMNz7cTDCEgE+b/0Qu0TD8E+pkCxYGA6wAvBH/URVsaXMpKSenPXhBZsDFXqaL5a6/pSz26qH8x01CyH/zEBXZjlhS8DaN8H0CdE0Z6f0rKRDDQCTq9/8SkaPbjO7Gvz4ZIDf7gJgozu/CecLDt9BKbnVq2i7xhtlhGE1icQyBYAmUqogf04BJrKTl0EvTW4/Pnq7bcvQHcldSiu8vYEekkIaeeJEf0Hpa79vVhqmDfFWczZsoZO71AyiMxbSOQYlK2tMYE4+nR2oGYcEFRTc52DJtR9Bzlkxw9JnNwk; 4:44vnMexgSgiMrVhUKHA94yYtOT0QU7aIX3f0c0KkQvUZ0lOzqGIUGZH1aycvviYIepORYW+33MgNm5OmRJ2pTgm2rD/uG4QBKY4S1nCe+9D6CvAmM5cZbnL5rlVUE5t0GNtcmQl2s5SYb0N4lVYQvsgREmlvsR8EQ71Hi0mlpfCvzGOSIwfcnEZohf2nq46wj+G1XznhKAPUVEulPVGUWnrFO/SSyzrO8SRBugym6uLPXDHay5AxHEwfZW/plQVLADF9oGVpgLb+C4KtaoZF8gTS68DsSfVWPTeuWZKOS0LT0kGapm1whF7DMUaFcO/G06kM6Mqivqiz+vw/iiOwRDQREj8qlZuWSq/0uvURc9UMcjPFeQ+IU/408TSfGfb1 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR0501MB2158; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2158; X-Forefront-PRVS: 0798146F16 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(199003)(479174004)(377454003)(189002)(24454002)(64126003)(19625215002)(4001430100002)(40100003)(66066001)(54356999)(87266999)(76176999)(92566002)(33656002)(50986999)(65806001)(65956001)(4001350100001)(97736004)(122386002)(5001960100002)(554214002)(107886002)(77096005)(106356001)(81156007)(83506001)(230783001)(59896002)(65816999)(84326002)(15187005004)(512874002)(6116002)(87976001)(790700001)(105586002)(42186005)(3846002)(93886004)(586003)(1096002)(86362001)(99136001)(101416001)(5001770100001)(189998001)(2950100001)(5008740100001)(36756003)(16236675004)(5004730100002)(80316001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2158; H:[172.29.33.26]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA1MDFNQjIxNTg7MjM6MFZZMWZTRmg3VStNMk8vekRWZXdsMGtr?= =?utf-8?B?ZmlPTG9uaHFDZ2dpQXZXT09xTm1Qa1Q4TlRBNFpyZXZ1UTlSem45d3NTNHQy?= =?utf-8?B?V3BPVXJRY3c0U3J4bDZvaldueUdzVmRwdStCWEFyZDQ1UG50dmwyNFdwcGxW?= =?utf-8?B?L0g4VzRyNGFwTXptdGRWeVk0SmhNeUowNmFVV2kxOEUrTzNJb2M1TGFydDhP?= =?utf-8?B?YmZuMXZpME5vYy91VjdCcWZDQXRmS0ZjQ05RcXdlTXowVXBrR3lkMVNQbkk1?= =?utf-8?B?R0l3SEFCT0txSnNOb05EMU51OXRQVm9yMDVpcm82V3Z2c0R6eFFyZ3RFVmly?= =?utf-8?B?cmVURkFxT3ppemFXbk1NUnR6VmpkanViaFdoR2xyd3lFd0o0Uk9haXhqNVdR?= =?utf-8?B?cUtaY0M3ZmVLUmJwd0xOQ2lCdlJ5QXFEQlVCWmZ1NVBZd1NobkNWdzJNZmR4?= =?utf-8?B?RnhXSi96OGZuZFhLUGpPQjY5RVREOFNDYnQxRk9zc2FBMklweXl5T01qZG14?= =?utf-8?B?a0tZU3RGVjBXVC9aRWkwUlAxeDViTGtlOEd1UTZqc0FlcU03Sjc4MGIyR1pE?= =?utf-8?B?M2ZCNmVrU255MHlER25KRmczenRXbnlCRDMydmttZmt2M1FuUnBuRmZOWkc3?= =?utf-8?B?djFTclZrYmI4S3VidjltQ21jamkvZ2xmb3FrN1BNNVUrTkhzZUxRa2p1SGgx?= =?utf-8?B?WmFUZnJVMHBZNzJaUjZOUmZDcmE5bDkvYldjd2xYcmxyZ3VpTVdHeEFIS08w?= =?utf-8?B?Y095ZUltc2hoOENxRStpV3Z3WWdOdVZTVyswY0JFYml4QkZRckJIRXlBY1kr?= =?utf-8?B?MnpVZk9WRHphRFVVWkxOZU1xWnNTWDBOTlhQandsQ0tYajluZFdsMGMyVkE0?= =?utf-8?B?dVdLemR3SXFzcDdqYzNoL1IxMkFRNXN3UjEzVjl0QTM1WHkvWWdkSE80Tlp6?= =?utf-8?B?cEJDeU5Zekdta0VydU9VWmpyaGNDMWJLYW5vM3A5VUhZN0VrTytzc1VtM3Q3?= =?utf-8?B?VWxza0FzZkhGbXRHdXpVNi9EbXR2NGQ3MklXaXBFVUJsKzJKZFpOdzFvcUpB?= =?utf-8?B?Wk9VUVlqbnZFMDJvaklTTUdHaHZxUVJqYjljQUVIR211WkZzbDIvaEF4c0lS?= =?utf-8?B?MlR5Z3BLODhBM2NTUEExZld4WWY2NVlPTnBGaXloR1dZRlgyN1NCKy9ISVdT?= =?utf-8?B?aHpnVnpZY0MrS1V5dUY5aFRiZE84WFJsOHJrZ05QbUxyeXRCODRHTFlhU0FR?= =?utf-8?B?TXVZeGp2aHFsVW1DNFRVdS9UMWpWdFlnZlRPODNNbVk2ZjJkblZlNGhXQ0hC?= =?utf-8?B?a1UzcWhFTmwvcnBjUHZkNkdGcXlKSkxrVUppVXQ5NGlLM3c3SUV5RGNBMUdW?= =?utf-8?B?SjVWaVRhaTBaQUFmSXZKbVlqZW1XKzhrSkJVL29HSWVXdUswQ1FuTEttQzl4?= =?utf-8?B?dDdxYlZQZ3JpcUoyM0MwWVNSaUNxb1pXU2pDZjdFU2hIOTZTNkxQdFhqaUZw?= =?utf-8?B?eHVEVTZWYjNyK2RWN1hiUDROSlBJdjF5SjI3WkVlbGdHbE1iYlhGdXlNUkNU?= =?utf-8?B?T1dPKy8vWTIvejU1bHVIdC9rSk41eGdVdDhCbXFGM3dUTnpYY2hSRnNjeitB?= =?utf-8?B?dlhUSWhvMkpGWkNlMmFKM21JMXZueWlmSmNzcnJiTGJwNmVSL3lDbUF2ZW5M?= =?utf-8?B?VGh1ZzdUNU0vYkoyZTJzN1lMYXo1VUpvenVkTFNoanJyYTM0YzJZc0FrbzZW?= =?utf-8?B?T3hpYTdUTXNBWjJDVkdUaEt5WlJyUFpZMWcyWGJsTFJqMmtXU21zQ2tzWnpJ?= =?utf-8?B?NWZSclRodi8vWm1oT0JXbVE1Z25KNFcvUW9EOFdoTHVFNEpWdUppMmJMVyt1?= =?utf-8?B?WUVhbkgvSVRBQkZobVlKRHVMT2ZwajVhOUpMM2FOMHlzNkRzcXFTMHdXSVI1?= =?utf-8?B?azlPTHZZTTdqcmV1MmtlcFpLLzQyb0JmclJWTDZFVkxBcWI1dkJTRk05eU1G?= =?utf-8?B?T0FGcFk5SUFkSzZsdURaSWZuZy84aFpBeUJoTUFBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 5:m++uozqMWD4vGfPim3bfI5wHLkPeMV6NDjzJLJxgL2rqI6heVo7Ue3IMGYfh+kpFdsf8VK1k2hxVg1Z4lVQYS5pHyOa0z2qWxpLG/f4R8ZMA9CsuC4b+1hS9h9OSxz9Wl0czXBmfPwX9V828+Mekag==; 24:u7H1IliJ33taJcu6aCoaRaBC4FobYf5i7eBvvExLKdgmdBD2lrU46tIpryZBLNUq70PWI/UX022DBwuU5nt5dTW98VmrQIO/8sKA8kVZvuc= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Dec 2015 19:08:19.3856 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2158 Archived-At: Cc: draft-ietf-bess-mvpn-extranet@ietf.org, "'John G. Scudder'" , aretana@cisco.com, 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: Tue, 22 Dec 2015 19:08:27 -0000 --------------040307000108060509040004 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit On 12/22/2015 12:51 PM, Susan Hares wrote: > > Eric: > > Thank you for revisions in version -05 of your document. > Unfortunately it does not resolve either of the two points I raised. > > 1)*On the BGP Extended Communities*, I feel your specification is > *unclear and warrants change on the DISCUSS* Criteria due to > interoperability issues. > I've explained why I don't think this is correct. In particular, I don't think it is wise to mention the value of the "Transitive Opaque Extended Community Type" codepoint, as this can be found in the IANA registry for Transitive Extended Community types, and implementers should really be encouraged to consult the registries for the codepoints. > I’ve given you 2 small sections to add to your document at the > beginning of section 4.4. to resolve this DISCUSS point. > Note that the codepoint you mention for Transitive Opaque Extended Community Type is not correct. Unnecessary last minute changes do tend to introduce errors. > You need to just fill in one part below on RR restrictions for > *Extranet Separation Extended community*. > I will add some text saying that RRs must not add or remove this EC. > 2) *On the deployment section:* I given text and examples – but I > think you still misunderstand what I am looking for. > Perhaps. > Since you are an author of academic papers, > I am not. > consider I am looking for an operator-based “abstract” 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. > It seems to me that you are asking for something that could be titled "An Operator's Guide to Provisioning Extranet MVPN". While that might be useful, it is not within the scope of the current document. As I've said, I am not aware of any IETF requirement that requires such a thing to be included. > will you please let me know that you have read my suggested text > insertions on both these topics. I have. --------------040307000108060509040004 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit On 12/22/2015 12:51 PM, Susan Hares wrote:

Eric:

 

Thank you for revisions in version -05 of your document.  Unfortunately it does not resolve either of the two points I raised.

 

1)      On the BGP Extended Communities, I feel your specification is unclear and warrants change on the DISCUSS Criteria due to interoperability issues.  


I've explained why I don't think this is correct.  In particular, I don't think it is wise to mention the value of the "Transitive Opaque Extended Community Type" codepoint, as this can be found in the IANA registry for Transitive Extended Community types, and implementers should really be encouraged to consult the registries for the codepoints.

I’ve given you 2 small sections to add to your document at the beginning of section 4.4. to resolve this DISCUSS point. 


Note that the codepoint you mention for Transitive Opaque Extended Community Type is not correct.  Unnecessary last minute changes do tend to introduce errors.

You need to just fill in one part below on RR restrictions for Extranet Separation Extended community. 


I will add some text saying that RRs must not add or remove this EC.

 

2) On the deployment section:  I given text and examples – but I think you still misunderstand what I am looking for.  


Perhaps.

 

Since you are an author of academic papers, 


I am not. 

consider I am looking for an operator-based “abstract” 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. 


It seems to me that you are asking for something that could be titled "An Operator's Guide to Provisioning Extranet MVPN".  While that might be useful, it is not within the scope of the current document.  As I've said, I am not aware of any IETF requirement that requires such a thing to be included.

will you please let me know that you have read my suggested text insertions on both these topics.

I have.








--------------040307000108060509040004-- From nobody Wed Dec 23 07:14:01 2015 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 CD7201A01D8; Wed, 23 Dec 2015 07:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKysROx8KYKs; Wed, 23 Dec 2015 07:13:57 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 6586A1A01D5; Wed, 23 Dec 2015 07:13:56 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Eric C Rosen'" , "'Benoit Claise'" , "'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> In-Reply-To: <56799F9F.4010907@juniper.net> Date: Wed, 23 Dec 2015 10:13:38 -0500 Message-ID: <000d01d13d94$80868a10$81939e30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01D13D6A.97B515F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLS05QNmCOjnF9/ygy/QKz2M1D3eQInyoXdAa7znfEBVAvt0wHDkPeBAtg1BY+ch0jwgA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: 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: Wed, 23 Dec 2015 15:14:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000E_01D13D6A.97B515F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Eric:=20 =20 To clear my objection to this draft, please add these sections to make = it clear what the content of the BGP values and their handling. We = disagree on what the BGP registry document states, but that point is not = worth holding up this document. People can find the type and sub-type = fields in the registry. What is not in the registry is a clear = description of the restrictions of the value field and handling. =20 =20 Placing the BGP Extended communities within the rest of the rules is = just unclear. Please put these two sections in and give the details in = this sections.=20 =20 As to the deployment section, you did not consider the text I offer = below and the suggested insertion in the security section. Perhaps you = can consider that text in your next email. On whether this deployment = section is =E2=80=9CDISCUSS=E2=80=9D worthy, I am still communicating = with Benoit and Joel.=20 =20 I wish you the peace and joy of the Christmas season, =20 Sue Hares=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sections which must be added to clear my concerns=20 ---------------------------------------------------------------- =20 4.4.1 Extranet Source Extended Community=20 =20 To facilitate this, we define a new Transitive Opaque Extended = Community, the "Extranet Source" Extended Community.=20 The value field of this extended community is all zeros. =20 =20 Restrictions: This value field MUST be set to zero upon origination, = MUST be ignored upon reception and MUST be passed unchanged by = intermediate routers. =20 =20 Additional Restrictions: A Route Reflector MUST NOT add/remove the = Extranet Source Extended Community from the VPN-IP routes reflected by = the Route Reflector, including the case where VPN-IP routes received = via IBGP are reflected to EBGP peers (inter-AS option (c), see [RFC6513] = Section 10). =20 4.4.2 Extranet Separation Extended community=20 =20 We define a new Transitive Opaque Extended Community, the "Extranet = Separation" Extended Community. This Extended Community is used only = when extranet separation is being used. =20 =20 Restrictions: Its value field MUST be set to zero upon origination, = MUST be ignored upon reception, and MUST be passed unchanged by intermediate routers. =20 Restrictions on Adding/deleting this community: ?? (Eric =E2=80=93 = please add something here).=20 =20 Comments that could be put in a Security section:=20 =20 Whenever a VPN is provisioned, there is a risk that provisioning errors = will result in an unintended cross-connection of VPNs, which would = create a security problem for the customers. Extranet can be = particularly tricky, as it intentionally cross-connects VPNs, but in a = manner that is intended to be strictly limited by policy. If one is = connecting two VPNs that have overlapping address spaces, one has to be = sure that the inter-VPN traffic isn't to/from the part of the address = space that is in the overlap. The draft discusses a lot of the corner = cases, and a lot of the scenarios in which things can go wrong. =20 =20 =20 From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Eric C Rosen Sent: Tuesday, December 22, 2015 2:08 PM To: Susan Hares; 'Benoit Claise'; 'The IESG' Cc: draft-ietf-bess-mvpn-extranet@ietf.org; 'John G. Scudder'; = aretana@cisco.com; 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) =20 On 12/22/2015 12:51 PM, Susan Hares wrote: Eric:=20 =20 Thank you for revisions in version -05 of your document. Unfortunately = it does not resolve either of the two points I raised.=20 =20 1) On the BGP Extended Communities, I feel your specification is = unclear and warrants change on the DISCUSS Criteria due to = interoperability issues. =20 I've explained why I don't think this is correct. In particular, I = don't think it is wise to mention the value of the "Transitive Opaque = Extended Community Type" codepoint, as this can be found in the IANA = registry for Transitive Extended Community types, and implementers = should really be encouraged to consult the registries for the = codepoints. 2) I=E2=80=99ve given you 2 small sections to add to your document = at the beginning of section 4.4. to resolve this DISCUSS point. =20 Note that the codepoint you mention for Transitive Opaque Extended = Community Type is not correct. Unnecessary last minute changes do tend = to introduce errors. 3) You need to just fill in one part below on RR restrictions for = Extranet Separation Extended community. =20 I will add some text saying that RRs must not add or remove this EC. =20 2) On the deployment section: I given text and examples =E2=80=93 but I = think you still misunderstand what I am looking for. =20 Perhaps. =20 Since you are an author of academic papers, =20 I am not. =20 consider I am looking for an operator-based =E2=80=9Cabstract=E2=80=9D = 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 It seems to me that you are asking for something that could be titled = "An Operator's Guide to Provisioning Extranet MVPN". While that might = be useful, it is not within the scope of the current document. As I've = said, I am not aware of any IETF requirement that requires such a thing = to be included. will you please let me know that you have read my suggested text = insertions on both these topics. I have. ------=_NextPart_000_000E_01D13D6A.97B515F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Eric: =

 

To clear my objection to = this draft, please add these = sections to make it clear what the content of the BGP values and their = handling.=C2=A0 =C2=A0=C2=A0We disagree on what the BGP registry = document states, but that point is not worth holding up this = document.=C2=A0 People can find the type and sub-type fields in the = registry.=C2=A0 What is not in the registry is a clear description of = the restrictions of the value field and handling.=C2=A0 =

 

Placing the BGP Extended = communities within the rest of the rules is just unclear. Please put = these two sections in and give the details in this sections. =

=C2=A0

As to the deployment = section, you did not consider the text I offer below and the suggested = insertion in the security section. =C2=A0Perhaps you can consider that = text in your next email. =C2=A0On whether this deployment section is = =E2=80=9CDISCUSS=E2=80=9D worthy, I am still communicating with Benoit = and Joel.

 

I wish you the peace and = joy of the Christmas season,

 

Sue Hares =

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Sections = which must be added to clear my concerns

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

 

4.4.1 Extranet Source Extended Community =

 

   To facilitate this, we define a new = Transitive Opaque Extended  Community, the "Extranet = Source" Extended Community.

=C2=A0=C2=A0=C2=A0The value field of this extended = community is all zeros.   

 

Restrictions: This value field MUST be = set  to zero upon origination,  MUST be ignored upon reception = and MUST  be passed unchanged by intermediate routers.  =

 

 Additional = Restrictions:  A Route Reflector MUST NOT add/remove the = Extranet Source Extended  Community from the VPN-IP routes = reflected by  the Route Reflector,  including the case where = VPN-IP routes received via IBGP are reflected to EBGP peers (inter-AS = option (c), see [RFC6513]   Section 10).

 

4.4.2 Extranet Separation Extended community =

 

We define a new Transitive Opaque Extended = Community, the "Extranet  Separation" Extended = Community.=C2=A0 This Extended Community is used only  when = extranet separation is being used. 

 

   Restrictions:  Its value = field MUST be set to zero upon origination, MUST be ignored upon = reception, and MUST be

   passed unchanged by intermediate = routers.

 

  Restrictions on Adding/deleting this = community:  ??  (Eric =E2=80=93 please add something = here).

 

Comments that could be put in a Security = section:

 

Whenever a VPN is provisioned, there is a risk that = provisioning errors will result in an unintended cross-connection of = VPNs, which would create a security problem for the customers.  = Extranet can be particularly tricky, as it intentionally cross-connects = VPNs, but in a manner that is intended to be strictly limited by = policy.  If one is connecting two VPNs that have overlapping = address spaces, one has to be sure that the inter-VPN traffic isn't = to/from the part of the address space that is in the overlap.  The = draft discusses a lot of the corner cases, and a lot of the scenarios in = which things can go wrong.  

 

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Eric C = Rosen
Sent: Tuesday, December 22, 2015 2:08 PM
To: = Susan Hares; 'Benoit Claise'; 'The IESG'
Cc: = draft-ietf-bess-mvpn-extranet@ietf.org; 'John G. Scudder'; = aretana@cisco.com; 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)

 

On = 12/22/2015 12:51 PM, Susan Hares wrote:

Eric:

 

Thank = you for revisions in version -05 of your document.  Unfortunately = it does not resolve either of the two points I raised.

 

1)      = On the BGP Extended Communities, I feel = your specification is unclear and warrants change on the DISCUSS = Criteria due to interoperability issues.  


I've explained why I don't think this is = correct.  In particular, I don't think it is wise to mention the = value of the "Transitive Opaque Extended Community Type" = codepoint, as this can be found in the IANA registry for Transitive = Extended Community types, and implementers should really be encouraged = to consult the registries for the = codepoints.


2)      = I=E2=80=99ve given you 2 small sections to add = to your document at the beginning of section 4.4. to resolve this = DISCUSS point. 


Note that the codepoint you mention for Transitive = Opaque Extended Community Type is not correct.  Unnecessary last = minute changes do tend to introduce = errors.


3)      = You need to just fill in one part below on RR = restrictions for Extranet Separation Extended community.  =


I = will add some text saying that RRs must not add or remove this = EC.


 

2) = On the deployment section:  I given text and examples = =E2=80=93 but I think you still misunderstand what I am looking for. =  


Perhaps.


 

Since = you are an author of academic papers, 


I am not. 


consider I am looking for an operator-based = =E2=80=9Cabstract=E2=80=9D 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. 


It seems to me that you are asking for something = that could be titled "An Operator's Guide to Provisioning Extranet = MVPN".  While that might be useful, it is not within the scope = of the current document.  As I've said, I am not aware of any IETF = requirement that requires such a thing to be = included.


will = you please let me know that you have read my suggested text insertions = on both these topics.


I = have.







<= /html> ------=_NextPart_000_000E_01D13D6A.97B515F0-- From nobody Mon Dec 28 07:20:49 2015 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 081AF1A00DF; Mon, 28 Dec 2015 07:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, 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 i-shuKWHaD6X; Mon, 28 Dec 2015 07:20:44 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0137.outbound.protection.outlook.com [65.55.169.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85571A0141; Mon, 28 Dec 2015 07:20:43 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.34.172] (66.129.241.12) by BY2PR0501MB2151.namprd05.prod.outlook.com (10.163.198.25) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 28 Dec 2015 15:20:40 +0000 References: <20151221171512.15817.2209.idtracker@ietfa.amsl.com> To: , From: Eric C Rosen Message-ID: <56815342.7030609@juniper.net> Date: Mon, 28 Dec 2015 10:20:34 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20151221171512.15817.2209.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: CO1PR06CA030.namprd06.prod.outlook.com (10.242.160.20) To BY2PR0501MB2151.namprd05.prod.outlook.com (25.163.198.25) X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2151; 2:HfGbVEnVMdXW4h4nWlpjxW9DGwR8iUb2xaljoXhqBR/gZUh795gA98M2+FzK5vbzIhyh/B8G6NxjgXEK1u0uPKU5InfzjOIu1M3K0waDKeHDWgK0UPyRQlanxqCMLHdZf1zfTCZxOFrcBLlBrAOHlw==; 3:gCTmRvT6A2r/McuvMhG66o0KqCX7mw5rVB+5/mJIul+GXWXyF9MNzDisLeyGtFhdz5XbEFcepWKHBs4ZFRRSD4tIxLaKsapVRLiSrGSctH46OTFii1o/NGbgFIeJJZNG; 25:IvJd4aH8FUKiUj1GGPznHwO8HRLXn2kEfl2DPN/e6V85qbz1iAUXm2w2h7eelxLxgwS5nFxLPz8++a0ZpOnBAWZ7z3XbDKuWZoSqMHFX0xW6Dc9QGW08FDzzIt/j98n2TCaDBqJbem70+UxUiC4Eoh1Qd/PQ4XaIp/hIm9OhM+eouk8N+ri5nUTu1yBcPJ0QeFZce9ztK6YcuONN0/Fo32gtaa3Eal3yAL7kg5b4MF3GBUH7I2hACE+BkEn/hgjLjSOaFAA1eevo2uRrc9MlYA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB2151; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2151; 20:GpSz5IxZN1sh+I7cj2C/0rrb//LnCCX8wrxD3TLJYPsMmZgWkVOcmUrCmTiJwxvLS6yx9KahYzZ/SE8bOcSLXBJEBHY6CaK0sPAqBh3rWR68gBH4a6ekjtAv+BGLlV4XI8Ma4OIaor6MjVajQIpAGUso2LoHVYiMRtkUtXd23I4tVEXYbx+iZt4HUHkl/VmcnwcW0nPxIMBL2OxiJibnq3aPVUZBQsSCxqqNNVlixcc5LpYs2NQtP2IxZYv0iNQ+Q9+591diWwnd9h9V3P48HU02Ox25cXNHcmcAjWdJrYaK/R0I0mUn52SZght9HN4lX0Xn0ia9WS6hCrTojsVxRFcH2SdQTowFqeOYD4RSV2gWHCR4QH9g5K4TD0D2hwdelsbFPcNS1mXGeNIpK6lFajCuKPUt5nC2zNvv/hJKEDIFThC2U0+13QS4K2P3R16WbGAq7m2/IfdiKcVFBPfzbaEcPInmyGox4F2ogyKh40KBARqcqVnt3teC09SqeIr9; 4:8y1iwctKhapp7IbqxLxh5jh/5hwmxpEnkoDHI0FfPBsU0u90RQ8saZ1uT7CMxWuah1PwmN3usuG5N+JiBt1cKJSW+iKfuLr2MI85KT6ddWKtpG/EYDOAc+pwwsK5I9IIpQIcVhbSQ93jdS/Pt+R8YZpsJICjoYVm61z03Hk2bw7B/okpca91UQ4vH4Qi2SqFNFkV5MYgDQ/Evlldn9d7dILLq0jFGp5GxwGBQD2LGGlroJDcB08fK4uwoU/ulyvdokpArdGjynMe/T1mNwroRW1XOyuK9uDejx6GduBccx/ZrZPbPlFgb/co2WbzLraclDgmO9gC/yF5QDN3RlpOEEZ0ts6HMD2+iTnfwX1ZyfIfx53/QSVSQVC15UCKWP2t X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BY2PR0501MB2151; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB2151; X-Forefront-PRVS: 08041D247D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(189002)(199003)(105586002)(5008740100001)(97736004)(65806001)(65956001)(117636001)(81156007)(23746002)(36756003)(450100001)(4001350100001)(106356001)(54356999)(76176999)(50986999)(87266999)(59896002)(230783001)(66066001)(189998001)(99136001)(65816999)(5004730100002)(3846002)(50466002)(6116002)(101416001)(83506001)(77096005)(586003)(92566002)(107886002)(47776003)(230700001)(5001770100001)(64126003)(40100003)(42186005)(5001960100002)(1096002)(122386002)(2950100001)(87976001)(86362001)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB2151; H:[172.29.34.172]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY2PR0501MB2151; 23:pKYR3rCXF/+HgFmMEp/3ykeySqH/6DIqQoQ?= =?Windows-1252?Q?Rbgej+xluixEu3VSmIcP/w1/GfaDsqOhItqPO7ezkEL31FDWQJwJwyHQ?= =?Windows-1252?Q?MQztWGvWfM1EGzdIoJnzemBBAzmfjNivLWMcHQ9hZWxOdVKcSgUaz+GB?= =?Windows-1252?Q?LFLcJ2NLfBdIu+0EJr93tS1iNRCWKqul/4B4cLem1CrBUu40OfCjBJrA?= =?Windows-1252?Q?lOCUj2/DVF7T/qJlb8tsDo0MVpL/HIUbK6Vlw2ROlpjljye/65LNSQFt?= =?Windows-1252?Q?+K3pfZYl2jW+jNa36guIStNYBYuaQ3P6p+fCtMhFsj/vkBXz9wNks6S7?= =?Windows-1252?Q?jhyC18yRVgKVhCKoScfFt3ujoexzAZ7fzvBbRN/wIb072CalQW5NDMJU?= =?Windows-1252?Q?cHep7zjtC300TFuhGMDEkOTScDGujspn9oIB9ICUg3YaJZjwSFscIxWg?= =?Windows-1252?Q?KEuBcTUDmhv/oQPe2XIIx/Ln/BoHHHB8I1arxox9/YFOHRMTjqevoYfV?= =?Windows-1252?Q?25PCgSCbWo+6G9v8HgeFxojQlPxiY6GT23L59qPRbsmJsekfPDN0gWzd?= =?Windows-1252?Q?LQ0+JKfi66f5xsRt7p5j2Sembv4n5yV9zBE3vdG9d54rNKtfOX2wqHO/?= =?Windows-1252?Q?TRqypCwuNpj1l7ZX0URDo7EYXtqGV9fqYK5K4+PcXa8kNeT9lGG0dOh5?= =?Windows-1252?Q?qjOkU97XNkSZVDcA8AWPJJ3a3Zu/uXVADBTg6vG+ltkkAT9DVhE9Mum0?= =?Windows-1252?Q?qWxiFFtjWaqpRtXvjYT5H/94r93NL5Q4sthYh5nX476bJ1B9+Tzw1llF?= =?Windows-1252?Q?sg3C0u330N5KUBlyLrHBFc4boKYMAIBHZaf+UD0uwaKqycdjfq6sXY3j?= =?Windows-1252?Q?sqJDNBV6kRKr6j0g1sGYFink8LY6wx5zAO3mCabDRtXiXWgExnempEsL?= =?Windows-1252?Q?lPR3b0qhzkJb3nHKvBUTxi5icuiKe5MjR+uRA78BaFVCEB9zsV5ooHQt?= =?Windows-1252?Q?hg1kWxEmlx1bG0lwbxIMNHboemDwv1xwQWRBO5lMMx9esigZa+nJb5Dk?= =?Windows-1252?Q?0iX6jBadwvC6I4sVrVg2BnmBN5KSMbHAx38OO1h3QN7rGk5JTubbPeEd?= =?Windows-1252?Q?UFZNsSmIxHtnNb/2Be4V81rbqaGBwxMxibzVf5Jj0Qui82bCxgt3gNIG?= =?Windows-1252?Q?1Xwa3SJ4oQC02mCVTpyKph2n2leR/Ef5+YG6fdBc/B527eaMYjsA0oS8?= =?Windows-1252?Q?cp74NMH3gREp4vz6/3JmWUWFS6dSmmzozRdWAI4fmhVhrRnzdToK7EQt?= =?Windows-1252?Q?L5y7qvSpQ0g45W/w4K32/hynVYRj8ih83NMqhTyeUNLTQpSc=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2151; 5:rVvi4yKfWjJyTLBcrAvt+hDJV3W5fwCOsxAIUBFg0W+EH7iCNjYC10DzPKf/yAn+O235WV2kY8bkCIcYV16hONRUMgIvESz3Fgl3saEf+fkqRRtfoaaDVb689k5DTlGfCAdNweJpyzIC2ze2i2MNSg==; 24:M9JmhW32cyEvasLJIV6uy8KBveJBq7xlP9VopewgXye+GUg+Y1IXLrASKbpq5MDHeOr3WF7dQsLCsV+fNXgGi5idHGuTHDa22lfuJbHNA0s= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Dec 2015 15:20:40.7741 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB2151 Archived-At: Subject: Re: [bess] I-D Action: draft-ietf-idr-tunnel-encaps-01.txt 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, 28 Dec 2015 15:20:46 -0000 The -01 revision of draft-ietf-idr-tunnel-encaps has the following changes from the -00 revision: - By popular request, it has been written in such a way as to obsolete RFC5512. This means that anything useful in RFC5512 had to be incorporated into the new draft. I would welcome opinions on whether this was done correctly. - Two new sub-TLVs are specified: "MPLS Label Stack" and "Prefix-SID". I would welcome opinions on whether these are useful or not. (I'm pretty sure that the first is useful, the second is more speculative.) - If you are familiar with deployed uses of the Encapsulation Extended Community, the Color Extended Community, or the Router's MAC Extended Community, it may be worth checking section 4 to make sure that the draft does not introduce any problems. - I wish more folks would take a critical look at section 8, which is primarily about the use of VXLAN/NVGRE/VXLAN-GPE together with labeled address families. I would also be interested in hearing if anyone has an opinion on the utility of using this sort of mechanism to signal IPsec tunnels. Once RFC 5512 is obsoleted, RFC 5566 ("BGP IPsec Tunnel Encapsulation Attribute") will need to be revised. It might be possible to generalize that in such a way as to facilitate the secure interconnection of two private ASes across the public Internet. Comments on whether RFC 5566 takes a reasonable approach would be welcome.