From martin.vigoureux@alcatel-lucent.com Mon Nov 5 05:04:04 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A6321F86BA for ; Mon, 5 Nov 2012 05:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xV98LPo3Uhpt for ; Mon, 5 Nov 2012 05:04:04 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id B279821F85BA for ; Mon, 5 Nov 2012 05:04:03 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA5D3IKS009508 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 5 Nov 2012 14:04:00 +0100 Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 5 Nov 2012 14:03:08 +0100 Received: from [135.244.4.169] (135.5.27.18) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 5 Nov 2012 08:03:06 -0500 Message-ID: <5097B908.30805@alcatel-lucent.com> Date: Mon, 5 Nov 2012 14:03:04 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Subject: Fwd: Help the NomCom: Community Feedback References: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> In-Reply-To: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.18] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 13:04:04 -0000 The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 11. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org From thomas.morin@orange.com Thu Nov 8 04:57:39 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7023021F8B71 for ; Thu, 8 Nov 2012 04:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfwgAvd7Or7d for ; Thu, 8 Nov 2012 04:57:39 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B7B5321F8B6E for ; Thu, 8 Nov 2012 04:57:38 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 6161618C2FC; Thu, 8 Nov 2012 13:57:37 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 479134C073; Thu, 8 Nov 2012 13:57:37 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 8 Nov 2012 13:57:36 +0100 From: To: "l3vpn@ietf.org" , "draft-rosen-l3vpn-mvpn-mldp-nlri@tools.ietf.org" Subject: Re: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 --> adopted ! Thread-Topic: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 --> adopted ! Thread-Index: AQHNvbCfyAb+1y8TdU2OxcyutXbOZQ== Date: Thu, 8 Nov 2012 12:57:36 +0000 Message-ID: <19370_1352379457_509BAC41_19370_551_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D070A5415@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <50729A0B.6030201@alcatel-lucent.com> In-Reply-To: <50729A0B.6030201@alcatel-lucent.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="utf-8" Content-ID: <3513550795FE0C4FBECB14FE31CF2F3C@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 12:57:39 -0000 SGVsbG8sDQoNClRoaXMgY2FsbCBmb3IgYWRvcHRpb24gaXMgY2xvc2VkIGFuZCB3ZSBoYXZlIGNv bnNlbnN1cyB0byBhZG9wdCANCmRyYWZ0LXJvc2VuLWwzdnBuLW12cG4tbWxkcC1ubHJpIGFzIGEg d29ya2luZyBncm91cCBkb2N1bWVudC4NCg0KQXV0aG9ycywgY2FuIHlvdSBwbGVhc2UgcmVzdWJt aXQgYXMgZHJhZnQtaWV0Zi1sM3Zwbi1tdnBuLW1sZHAtbmxyaS0wMCA/DQoNClRoYW5rcywNCg0K LVRob21hcw0KDQoNCk1hcnRpbiBWaWdvdXJldXgsIDIwMTItMTAtMDg6DQo+IEhlbGxvIHdvcmtp bmcgZ3JvdXAsDQo+DQo+IHRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2Vla3MgcG9sbCBmb3IgYWRv cHRpb24gb2YNCj4gZHJhZnQtcm9zZW4tbDN2cG4tbXZwbi1tbGRwLW5scmktMDENCj4NCj4gUGxl YXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QgYW5kIHN0YXRlIGlmIHlvdSBzdXBwb3J0IGFk b3B0aW9uIG9yDQo+IG5vdCAoaW4gdGhlIGxhdGVyIGNhc2UsIHBsZWFzZSBhbHNvIHN0YXRlIHRo ZSByZWFzb25zKS4NCj4NCj4gVGhpcyBwb2xsIHJ1bnMgdW50aWwgT2N0b2JlciAyMm5kLg0KPg0K PiBDb2luY2lkZW50YWxseSwgd2UgYXJlIGFsc28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9mIGFu eSBJUFIgdGhhdA0KPiBhcHBsaWVzIHRvIHRoaXMgZHJhZnQsIHRvIGVuc3VyZSB0aGF0IElQUiBo YXMgYmVlbiBkaXNjbG9zZWQgaW4NCj4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChz ZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5DQo+IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0K Pg0KPiBJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRv ciBwbGVhc2UgcmVzcG9uZCB0bw0KPiB0aGlzIGVtYWlsIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUg YXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhlIGRyYWZ0DQo+IHdpbGwgbm90IGJlIGFkb3B0 ZWQgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yDQo+ IGFuZCBjb250cmlidXRvci4NCj4NCj4gSWYgeW91IGFyZSBvbiB0aGUgTDNWUE4gV0cgbWFpbGlu ZyBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3INCj4gb3IgY29udHJpYnV0b3Is IHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YN Cj4gYW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNl IHdpdGggSUVURiBydWxlcy4NCj4NCj4gVGhhbmsgeW91LA0KPg0KPiBNYXJ0aW4gJiBUaG9tYXMN Cj4gbDN2cG4gY2hhaXJzDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCkZyYW5jZSBUZWxlY29t IC0gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0 ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4KVGhhbmsgeW91LgoK From martin.vigoureux@alcatel-lucent.com Thu Nov 8 06:21:39 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF1E21F8B7F for ; Thu, 8 Nov 2012 06:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.249 X-Spam-Level: X-Spam-Status: No, score=-108.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHhkhR-vrDwc for ; Thu, 8 Nov 2012 06:21:38 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 586BC21F8AEA for ; Thu, 8 Nov 2012 06:21:38 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA8EGwdx031617 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Nov 2012 15:21:34 +0100 Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Nov 2012 15:21:07 +0100 Received: from [135.244.10.98] (135.5.27.17) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 8 Nov 2012 09:21:04 -0500 Message-ID: <509BBFCB.3090801@alcatel-lucent.com> Date: Thu, 8 Nov 2012 15:20:59 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: L3VPN Subject: Re: WG Last Call for draft-ietf-l3vpn-virtual-hub References: <506D586A.1030202@orange.com> In-Reply-To: <506D586A.1030202@orange.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.5.27.17] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: Thomas Morin X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:21:39 -0000 All, the WG LC has ended. Authors, please process the comments received, perform updates to the document as appropriate and check with people having made the comments. Thank you. martin Le 04/10/2012 11:35, Thomas Morin a écrit : > Hello working group, > > This email starts a two-week Working Group Last Call on > draft-ietf-l3vpn-virtual-hub, which is considered mature and ready for a > working group review. > > Please read the document if you haven't read the most recent version, > and send your comments to the list, no later than Thursday October 18th. > > Thank you, > > -Thomas& Martin > > [ http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-hub ] From thomas.morin@orange.com Thu Nov 8 06:42:45 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8AD21F8B4B for ; Thu, 8 Nov 2012 06:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+8qmIP0LCx6 for ; Thu, 8 Nov 2012 06:42:44 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 441B421F8A65 for ; Thu, 8 Nov 2012 06:42:44 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 85AD522CF0F; Thu, 8 Nov 2012 15:42:43 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6C97227C046; Thu, 8 Nov 2012 15:42:43 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 8 Nov 2012 15:42:43 +0100 From: To: Robert Raszuk Subject: Re: WG Last Call for draft-ietf-l3vpn-virtual-hub Thread-Topic: WG Last Call for draft-ietf-l3vpn-virtual-hub Thread-Index: Ac2iE3FMW6RiiHpgSIKjZYYN9eq7BwAOHheABtrA0AA= Date: Thu, 8 Nov 2012 14:42:42 +0000 Message-ID: <14556_1352385763_509BC4E3_14556_449_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D070A61F6@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <506D586A.1030202@orange.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="utf-8" Content-ID: <8E515B208C1E9143AA90C1C201E2DAEE@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:42:45 -0000 SGkgUm9iZXJ0LA0KDQpJZiB5b3UgYXJlIHNlZWtpbmcgeW91ciBwcm9wb3NhbCB0byBiZSBpbnRl Z3JhdGVkIGluIHlvdXIgZG9jdW1lbnQsIHRoZW4gDQpJJ2Qgc3VnZ2VzdCB5b3UgdG8gcHJvdmlk ZSB0ZXh0IGZvciBpbmNsdXNpb24gaW4gdGhlIGRvY3VtZW50IGFuZCB0YWtlIA0KdGhlIG9wcG9y dHVuaXR5IG9mIHRoZSBtZWV0aW5nIGluIEF0bGFudGEgdG8gZGlzY3VzcyB3aXRoIGF1dGhvcnMu DQoNClNpbmNlIHlvdSBhcmUgcHV0dGluZyBmb3J3YXJkIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNo LCBhIHBvc3NpYmlsaXR5IGlzIA0KYWxzbyB0byBwcm9ncmVzcyBpdCBhcyBhIHNlcGFyYXRlIGRv Y3VtZW50Lg0KDQpUaGFua3MsDQoNCi1UaG9tYXMNCg0KDQoNCjIwMTItMTAtMDQsIFJvYmVydCBS YXN6dWs6DQo+IEhlbGxvIFRob21hcywNCj4NCj4gSSB0aGluayB0aGUgZHJhZnQgaXMgdXNlZnVs IGhvd2V2ZXIgYXMgY29tbXVuaWNhdGVkIHRvIGF1dGhvcnMgb2YgdGhpcw0KPiBkcmFmdCBvbiAy bmQgQXVnIDIwMTEgSSBhbSBvZiB0aGUgb3BpbmlvbiB0aGF0IGl0IHNob3VsZCBiZSBleHRlbmRl ZA0KPiB0byBhY2NvbW9kYXRlIGV2ZW4gZnVydGhlciBzY2FsaW5nIGVuaGFuY2VtZW50cyBub3Qg anVzdCBmb3IgU1AgUEVzDQo+IGJ1dCBhbHNvIGZvciBhY3R1YWwgY3VzdG9tZXIgVlBOIHNpdGVz Lg0KPg0KPiBXaGF0IEkgaGF2ZSBzdWdnZXN0ZWQgb3ZlciBhIHllYXIgYWdvIHdhcyB0aGUgZXh0 ZW5zaW9uIG9mIHRoaXMNCj4gcHJvcG9zYWwgdG8gQ1NDIGNhc2Ugd2hlcmUgdmlydHVhbCBodWIg aXMgcGxhY2VkIGluIHRoZSBzZXJ2aWNlDQo+IHByb3ZpZGVyIG5ldHdvcmsgYXMgZ2l2ZW4gY3Vz dG9tZXIncyBWUE4gaHViIGFuZCB3aGVyZSBvcHRpbWFsDQo+IGZvcndhcmRpbmcgZGVjaXNpb24g Y2FuIGJlIGNvbXB1dGVkIGZvciByb3V0aW5nIHNpdGUgdG8gc2l0ZSBjdXN0b21lcg0KPiB0cmFm ZmljLg0KPg0KPiBUaGF0IGlkZWEgaXMgaW4gZmFjdCBzaW1wbGVyIHRoZW4gdGhlIG9uZSBwcm9w b3NlZCBpbiB0aGUgY3VycmVudA0KPiBkcmFmdCBhcyBpdCBkb2VzIG5vdCByZXF1aXJlIGltcG9y dC9leHBvcnQgUlQgY29uZmlndXJhdGlvbiBhdCB0aGUNCj4gdmlydHVhbCBodWIuIEluc3RlYWQg anVzdCBsaWtlIGluIHBsYW5lIHZhbmlsbGEgQ1NDIGNhc2UgZWFjaA0KPiBjdXN0b21lcidzIHJv dXRlcyBhcmUgaGFuZGxlZCBzZXBhcmF0ZWx5IGFuZCBwbGFjZWQgaW50byBhcHByb3ByaWF0ZQ0K PiB2aXJ0dWFsIGh1Yi4NCj4NCj4gTW9yZW92ZXIgZXZlbiBnb2luZyBmdXJ0aGVyIHNjYWxpbmcg b2Ygc3VjaCB2aXJ0dWFsIGh1YnMgcmVzaWRpbmcgaW4NCj4gc3RyYXRlZ2ljIGxvY2F0aW9ucyBv ZiBTUCBjb3JlIGluZnJhc3RydWN0dXJlIGNvdWxkIGJlIGFjY29tcGxpc2hlZA0KPiB3aXRoIHNp bXBsZSBncmlkIGNvbXB1dGluZyBvciBkaXN0cmlidXRlZCByb3V0aW5nIHBsYXRmb3JtcyBiZWlu Zw0KPiBmdWxseSB0cmFuc3BhcmVudCB0byBhbnkgbmVlZCBmb3IgYWRkaXRpb25hbCBQRSdzIGNv bmZpZ3VyYXRpb24gb3INCj4gd2hhdCBwZXJoYXBzIGlzIG1vcmUgaW1wb3J0YW50IGFueSBwZXIg VlBOIGNodXJuIGluIHJvdXRpbmcNCj4gaW5mb3JtYXRpb24uDQo+DQo+IFRvIHJlYWxpemUgdGhp cyBtb2RlbCBub24gb2YgdGhlIGN1cnJlbnRseSBkZXBsb3llZCBQRXMgd291bGQgbmVlZCB0bw0K PiBiZSB1cGdyYWRlZCBvciBldmVuIHJlY29uZmlndXJlZCBwcm92aWRlZCBnaXZlbiBTUCBhbHJl YWR5IHByb3ZpZGVzDQo+IENTQyBzZXJ2aWNlLg0KPg0KPiBMYXN0IGJ1dCBub3QgbGVhc3QgdGhl IGRhdGEgcGxhbmUgb3V0ZXIgZW5jYXBzdWxhdGlvbiBvZiBzdWNoIHZpcnR1YWwNCj4gaHViIGNv dWxkIGJlIElQIChHUkUpIHRoZXJlZm9yIG9wZW5pbmcgbmV3IG9wcG9ydHVuaXRpZXMgZm9yIG9m ZmVyaW5nDQo+IENTQyB0eXBlIG9mIFZQTnMgZm9yIG11Y2ggbGFyZ2VyIGN1c3RvbWVyIGJhc2Ug dGhlbiBjdXJyZW50bHkgbGltaXRlZA0KPiB0byBvbmx5IHRob3NlIHNpdGVzIHdoaWNoIGFyZSBk aXJlY3RseSBhdHRhY2hlZCB0byBnaXZlbidzIFNQDQo+IGluZnJhc3RydWN0dXJlLg0KPg0KPiBC ZXN0IHJlZ2FyZHMsDQo+IFIuDQo+DQo+IE9uIFRodSwgT2N0IDQsIDIwMTIgYXQgMTE6MzUgQU0s IFRob21hcyBNb3JpbiA8dGhvbWFzLm1vcmluQG9yYW5nZS5jb20+IHdyb3RlOg0KPj4gSGVsbG8g d29ya2luZyBncm91cCwNCj4+DQo+PiBUaGlzIGVtYWlsIHN0YXJ0cyBhIHR3by13ZWVrIFdvcmtp bmcgR3JvdXAgTGFzdCBDYWxsIG9uDQo+PiBkcmFmdC1pZXRmLWwzdnBuLXZpcnR1YWwtaHViLCB3 aGljaCBpcyBjb25zaWRlcmVkIG1hdHVyZSBhbmQgcmVhZHkgZm9yIGENCj4+IHdvcmtpbmcgZ3Jv dXAgcmV2aWV3Lg0KPj4NCj4+IFBsZWFzZSByZWFkIHRoZSBkb2N1bWVudCBpZiB5b3UgaGF2ZW4n dCByZWFkIHRoZSBtb3N0IHJlY2VudCB2ZXJzaW9uLCBhbmQNCj4+IHNlbmQgeW91ciBjb21tZW50 cyB0byB0aGUgbGlzdCwgbm8gbGF0ZXIgdGhhbiBUaHVyc2RheSBPY3RvYmVyIDE4dGguDQo+Pg0K Pj4gVGhhbmsgeW91LA0KPj4NCj4+IC1UaG9tYXMgJiBNYXJ0aW4NCj4+DQo+PiBbIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbDN2cG4tdmlydHVhbC1odWIgXQ0KCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLApGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFu Y2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From yakov@juniper.net Thu Nov 8 07:06:01 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F008F21F8B7F for ; Thu, 8 Nov 2012 07:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AUZvgnR3r4B for ; Thu, 8 Nov 2012 07:06:01 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8C83221F8B7D for ; Thu, 8 Nov 2012 07:05:59 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUJvKVoKjD0dVZnaEUVbTBbDJp9lY+Syp@postini.com; Thu, 08 Nov 2012 07:06:01 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Nov 2012 07:03:06 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qA8F2t384781; Thu, 8 Nov 2012 07:03:01 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201211081503.qA8F2t384781@magenta.juniper.net> To: Martin Vigoureux Subject: Re: WG Last Call for draft-ietf-l3vpn-virtual-hub In-Reply-To: <509BBFCB.3090801@alcatel-lucent.com> References: <506D586A.1030202@orange.com> <509BBFCB.3090801@alcatel-lucent.com> X-MH-In-Reply-To: Martin Vigoureux message dated "Thu, 08 Nov 2012 15:20:59 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <48385.1352386975.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Nov 2012 07:02:55 -0800 From: Yakov Rekhter Cc: Thomas Morin , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:06:02 -0000 Martin, > All, > = > the WG LC has ended. > Authors, please process the comments received, perform updates to the = > document as appropriate and check with people having made the comments. > Thank you. Ok. Yakov. > = > martin > = > Le 04/10/2012 11:35, Thomas Morin a =C3=A9crit : > > Hello working group, > > > This email starts a two-week Working Group Last Call on > > draft-ietf-l3vpn-virtual-hub, which is considered mature and ready for= a > > working group review. > > > > Please read the document if you haven't read the most recent version, > > and send your comments to the list, no later than Thursday October 18t= h. > > > > Thank you, > > > > -Thomas& Martin > > > > [ http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-hub ] From yakov@juniper.net Thu Nov 8 07:20:00 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C1821F85AA for ; Thu, 8 Nov 2012 07:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yya7B6fT9qUq for ; Thu, 8 Nov 2012 07:19:59 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id B6A5821F8595 for ; Thu, 8 Nov 2012 07:19:58 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUJvNnZBw6oPdQqpisywJ5kqr1WT3FEgc@postini.com; Thu, 08 Nov 2012 07:19:58 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Nov 2012 07:17:19 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qA8FHJ342412; Thu, 8 Nov 2012 07:17:19 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201211081517.qA8FHJ342412@magenta.juniper.net> To: Subject: Re: Last Call comments on draft-ietf-l3vpn-virtual-hub In-Reply-To: <23373.1350054126@erosen-linux> References: <23373.1350054126@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Fri, 12 Oct 2012 11:02:06 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48950.1352387839.1@juniper.net> Date: Thu, 8 Nov 2012 07:17:19 -0800 From: Yakov Rekhter Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:20:00 -0000 Eric, > I have a number of comments on the virtual-hub draft. Some are minor and/or > editorial, but a number are more substantial. I think these comments need > to be addressed before the draft is submitted for publication. > > I've placed a lot of comments in-line, but let me summarize what I think are > the major issues: I am in the process of addressing your comments. In this e-mail I'd like to focus on one particular one: > Eric> Let's consider the case where the source is at a site attached to > Eric> V-hub2. V-hub1 will receive an S-PMSI A-D route matching (S,G) from > Eric> V-hub2. V-hub1 then modifies this A-D route and forwards it to > Eric> V-spoke1. V-hub1 could use this route to identify the P-tunnel > Eric> originating at V-hub2, thereby instructing V-spoke1 to join V-hub2's > Eric> tunnel directly. Then V-hub1 would not be in the data path from S to > Eric> R, but it would participate in the control plane. Wouldn't this meet > Eric> all the requirements of the V-hub/V-spoke architecture, while producing > Eric> a more optimal path for multicast data, and eliminating the need to > Eric> have the V-hubs splice together any P-tunnels? > > Eric> Was any consideration given to such an alternative? Please note that the procedures specified in the draft assume the ability to perform sender-based RPF, as specified in 9.1.1 of rfc6513. Given that, if one would follow what you outlined above, could you point me to the specific text in 9.1.1 that would enable V-spoke1 to determine that from its own perspective the UMH for (C-S, C-G) is V-hub1 ? Furthermore, your outline above talks about S-PMSI A-D route. How would it work for I-PMSI A-D routes ? Yakov. From mohanp@sbcglobal.net Thu Nov 8 08:25:31 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1132E21F8B6E for ; Thu, 8 Nov 2012 08:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.722 X-Spam-Level: **** X-Spam-Status: No, score=4.722 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, MPART_ALT_DIFF=0.739, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LY2H27aq2JXx for ; Thu, 8 Nov 2012 08:25:30 -0800 (PST) Received: from nm15-vm0.bullet.mail.sp2.yahoo.com (nm15-vm0.bullet.mail.sp2.yahoo.com [98.139.91.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFB321F8419 for ; Thu, 8 Nov 2012 08:23:34 -0800 (PST) Received: from [72.30.22.78] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 08 Nov 2012 16:23:34 -0000 Received: from [98.139.44.78] by tm12.bullet.mail.sp2.yahoo.com with NNFMP; 08 Nov 2012 16:23:33 -0000 Received: from [127.0.0.1] by omp1015.access.mail.sp2.yahoo.com with NNFMP; 08 Nov 2012 16:23:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 961122.22036.bm@omp1015.access.mail.sp2.yahoo.com Received: (qmail 47091 invoked by uid 60001); 8 Nov 2012 16:23:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1352391813; bh=x+2EIjPjeGP8F2be0yhFHcDehNZIjn0hlgQ+k2AGNlQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:To:MIME-Version:Content-Type; b=uAvG5CV4RDTEjoSQc6NuOtvCN0qWys3jMxj50/EZK2MRwYGOJfvlf4hZh2JUU1coL7zcZTQ/Bra80ImGpet8Z764jEMvRyx8tkkScG1J1ONHZCOlORH/nc6DQ2+g4YJ2oP5K2Tui+Du/wNFF+Gb9v6hdFKNKSj54AB7f1OU7eTw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:To:MIME-Version:Content-Type; b=mONaJmOlVmXpOjpW0UZpvTyBm6vT981bqjZ65EoHNAqLZ3svPkzjN77gdvKLGcI8YOWTDEVha2Xf/RSh69NxqOckChNFel7vWCRUae8JgrTHIZ8bWxLVBq6T22o6rsaTRuYkcfrz+Dsp80SFr61ICD04SciaxSypg/DhJELxIO8=; X-YMail-OSG: .1xRxX4VM1kIVGl0nxyvy1WKpv17nHIcsDolst.v4IJZuOL Rtd3maj_5GXSB75_dO9vE3g46D7r6U6vqFXSDRwWgNUDOKaLKhRAk1YuhwvK LWB7QfVprw_qIksTsaVUSwZWFmd_1G5wVFDpf5XgTBm7sulTYFzE_3SzpkIc o0kYUy9BRyKz9Ol9E140LWVaSIXx_JiYs2Zof_0uDFC2dnCQDQfGfE8hxIH3 U22vePGMdVRP5fi3XC5B403JqbhJuM8uzwl4gbY2J5Pdqc8OJuIeWPDTJ4GB ZmlJ6SjLWObgf.OICzB0FR1psaXS10hIV6VZtTSGIWaVNDM88NcQZDrkBppL kzMif06EtSZrv0XgkN6EPN2ny0uCgwMIAr1aqo1kY28Q5JYelC2R0EUR0sjX Tq5yd6qwKrwhjTKy5.js_YPRLiBnCoT2Ae1mEL_ZQX7yk9UGvDxWWqHgesju TDoH1um59eKTk2It4UwrJDhsISteWrMKdZbfRLW8D33CRqItyi1U.G91_bb3 UosVI_jihuVy9cHG5VzkrtJI9GlQFqmaWDkAGdFu9T8TW7v8Vx4PUF0GXtJ7 L6dXBG3UXhIzBhVsGIpcLQOqVF87lhvaM92JlahNJ.90WBXw8lh2W5gcxObc Rv5suBWHOkH4WvXCoEV8Bd2WVGhs_THmXZeBgi7qIbyF3J5Gb Received: from [201.167.20.44] by web184706.mail.ne1.yahoo.com via HTTP; Thu, 08 Nov 2012 08:23:32 PST X-Rocket-MIMEInfo: 001.001, PHA.PGEgaHJlZj0iaHR0cDovL3d3dy5ydWdieXNlYWNhZGV0cy5jb20vY3Jhd2Zpc2hhaWQvMThkYXZpZGtpbmcvIj5odHRwOi8vd3d3LnJ1Z2J5c2VhY2FkZXRzLmNvbS9jcmF3ZmlzaGFpZC8xOGRhdmlka2luZy88L2E.PC9wPgoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 Message-ID: <1352391812.45947.androidMobile@web184706.mail.ne1.yahoo.com> Date: Thu, 8 Nov 2012 08:23:32 -0800 (PST) From: Mohan Parthasarathy To: "erosen@cisco.com" , "l3vpn@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "thomas.morin@orange.com" , "afarrel@juniper.net" , "karagian@cs.utwente.nl" , "Marco.Liebsch@neclab.eu" , "zhipeng.fuf@kyoob.com.cn" , "robert@raszuk.net" , "brian.e.carpenter@gmail.com" , "alexandru.petrescu@gmail.com" , "h.anthony.chan@huawei.com" , "dmm@ietf.org" , "joelja@bogus.com" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="814484595-930993674-1352391812=:45947" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:25:31 -0000 --814484595-930993674-1352391812=:45947 Content-Type: text/plain; charset=us-ascii

http://www.rugbyseacadets.com/crawfishaid/18davidking/

--814484595-930993674-1352391812=:45947 Content-Type: text/html; charset=us-ascii

http://www.rugbyseacadets.com/crawfishaid/18davidking/

--814484595-930993674-1352391812=:45947-- From jie.dong@huawei.com Fri Nov 9 08:01:42 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D36E21F8738 for ; Fri, 9 Nov 2012 08:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGzamKw8kI8i for ; Fri, 9 Nov 2012 08:01:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9A64221F8720 for ; Fri, 9 Nov 2012 08:01:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALJ59166; Fri, 09 Nov 2012 16:01:40 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 9 Nov 2012 16:01:20 +0000 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 9 Nov 2012 16:01:37 +0000 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.86]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sat, 10 Nov 2012 00:01:34 +0800 From: Jie Dong To: "l3vpn@ietf.org" Subject: Solicit comments on L3VPN Performance Monitoring Analysis and Framework drafts Thread-Topic: Solicit comments on L3VPN Performance Monitoring Analysis and Framework drafts Thread-Index: AQHNvpN9pwoAjR0u4kGSHwO3LJgV7Q== Date: Fri, 9 Nov 2012 16:01:33 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927325A5387@szxeml504-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 16:01:42 -0000 Hi all,=20 Two drafts on L3VPN performance monitoring (PM) have been presented this mo= rning in the L3VPN session. As suggested by the chair, the authors would ap= preciate comments and contributions to these two L3VPN PM drafts.=20 MPLS performance monitoring mechanism have been defined in RFC 6374, such m= echanisms are applicable to PWs and MPLS-TP LSPs, but some work is needed t= o apply MPLS PM in L3VPN. Please read the drafts and provide your opinions.= Many thanks. Best regards, Jie= From bruno.decraene@orange.com Mon Nov 12 01:44:33 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F276521F84D8 for ; Mon, 12 Nov 2012 01:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0DvPYbZiH1Z for ; Mon, 12 Nov 2012 01:44:32 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3979721F84C7 for ; Mon, 12 Nov 2012 01:44:32 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8D5BF22C25D; Mon, 12 Nov 2012 10:44:31 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 707BB23806B; Mon, 12 Nov 2012 10:44:31 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Mon, 12 Nov 2012 10:44:31 +0100 From: To: "asreekan@cisco.com" Subject: draft-ymbk-l3vpn-origination-02 Thread-Topic: draft-ymbk-l3vpn-origination-02 Thread-Index: Ac3AulAYdXvrkSkPQ5Sg9BkPstJlyQ== Date: Mon, 12 Nov 2012 09:44:25 +0000 Message-ID: <1289_1352713471_50A0C4FF_1289_1326_1_53C29892C857584299CBF5D05346208A0F9D98@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 09:44:33 -0000 Arjun, all, I confess that I don't know much about SIDR, but I guess that I'm not the o= nly one in L3 VPN. Therefore clarification may be useful for the L3 VPN WG. Let's assume that no RPKI is used. 1) Given that the goal is to protect from unintentional errors, can you ela= borate on the added value brought by l3vpn-origination compared to the use = of a (extended) community agreed upon the VPN sites (e.g. some kind of a sh= ared password)? The latter being available now, how much is it deployed/used now? (I would = assume that l3vpn-origination would be used by a subset of such current use= rs) 2) Can you elaborate on how l3vpn-origination protects from unintentional e= rrors by the legitimate originator? Seems to me that both correct and erroneous routes would be signed by the e= gress CE/PE and hence accepted by the ingress. 3) Given that a VPN may want to import routes from outside of the VPN (e.g.= provider IP services (e.g. voice gateway), extranet), how does l3vpn-origi= nation protect from unintentional errors from those partners? Thanks for the clarifications, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bruno.decraene@orange.com Mon Nov 12 02:02:43 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589B221F84BC for ; Mon, 12 Nov 2012 02:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.723 X-Spam-Level: X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-utd0AO5C7u for ; Mon, 12 Nov 2012 02:02:42 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A1C9621F84BB for ; Mon, 12 Nov 2012 02:02:42 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8B52C22C519; Mon, 12 Nov 2012 11:02:41 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 7124F4C063; Mon, 12 Nov 2012 11:02:41 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Mon, 12 Nov 2012 11:02:41 +0100 From: To: "asreekan@cisco.com" Subject: draft-ymbk-l3vpn-origination-02 (scalability) Thread-Topic: draft-ymbk-l3vpn-origination-02 (scalability) Thread-Index: AQHNwLzaUyWM6SD8/U2KrMCUE/CfEw== Date: Mon, 12 Nov 2012 10:02:36 +0000 Message-ID: <29153_1352714561_50A0C941_29153_157_1_53C29892C857584299CBF5D05346208A0F9DFC@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <1289_1352713471_50A0C4FF_1289_1326_1_53C29892C857584299CBF5D05346208A0F9D98@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <1289_1352713471_50A0C4FF_1289_1326_1_53C29892C857584299CBF5D05346208A0F9D98@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 10:02:43 -0000 Arjun, all, Given the number of routes in large L3 VPN networks (much higher than in th= e Internet), IMO the draft should elaborate on the scalability impact of th= is draft (signing, checking signatures, NLRI deaggregation). e.g. try to quantify the reduction of capacity on RR and PE, and the increa= se in convergence time. Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From asreekan@cisco.com Wed Nov 14 17:59:51 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2E621F8573 for ; Wed, 14 Nov 2012 17:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXPdXUcsR8nh for ; Wed, 14 Nov 2012 17:59:50 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A379A21F853A for ; Wed, 14 Nov 2012 17:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3804; q=dns/txt; s=iport; t=1352944790; x=1354154390; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=moKDkT82J95mP2uHoZfJGr72CapDGCrKjJSAA3S4F54=; b=bhE9kK7lma0FwO180sQcdCCfu29uhDegim0gM6R5eSocUfaucVQ9avnn RaqHNCf1mLFsJF/nOjQFHQ+En27YUCzMgjOBQZWHEtkJOlM650asAui5q TTKkyt6Z5uLliSRaX7p4klBXkDtVsvrCmwPMg3mfH/2FkRhJzi9yUjSDa k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQJAJ1LpFCtJXG//2dsb2JhbABEw0WBAQeCHgEBAQQSASc3CAwGAQgRBAEBCw4GCTkUCQkBBA4FCAwOh2gBm1SgBowtgweCRGEDpFSBa4JvgV0HFwYY X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142558502" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 15 Nov 2012 01:59:50 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAF1xoMb011117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Nov 2012 01:59:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 19:59:49 -0600 From: "Arjun Sreekantiah (asreekan)" To: "bruno.decraene@orange.com" Subject: RE: draft-ymbk-l3vpn-origination-02 Thread-Topic: draft-ymbk-l3vpn-origination-02 Thread-Index: Ac3C1OPbPsQ26gl8RBC8+IuyHnbL7A== Date: Thu, 15 Nov 2012 01:59:49 +0000 Message-ID: <6CDE9DE8E74F58419C4C489FE0852B8F21E23AD3@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.139.154] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--36.828800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Randy Bush \(randy@psg.com\)" , "Pranav Mehta \(pmehta\)" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 01:59:51 -0000 Bruno, Thanks for the comments. Replies below -----Original Message----- From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]=20 Sent: Monday, November 12, 2012 1:44 AM To: Arjun Sreekantiah (asreekan) Cc: l3vpn@ietf.org Subject: draft-ymbk-l3vpn-origination-02 Arjun, all, I confess that I don't know much about SIDR, but I guess that I'm not the o= nly one in L3 VPN. Therefore clarification may be useful for the L3 VPN WG. Let's assume that no RPKI is used. 1) Given that the goal is to protect from unintentional errors, can you ela= borate on the added value brought by l3vpn-origination compared to the use = of a (extended) community agreed upon the VPN sites (e.g. some kind of a sh= ared password)? The latter being available now, how much is it deployed/used now? (I would = assume that l3vpn-origination would be used by a subset of such current use= rs) [Arjun]=20 Please note that the scheme does provide protection against attack scenario= s as well, this is not just protecting errors from configuration. Using a c= ommunity or extended community makes it vulnerable in a attack scenarios. I= t is easy to figure out the community or extended community value for prefi= xes for that VPN simply by looking at the BGP update or some show command o= utput for the prefix in that VPN. In the scheme, we use a digest generated = from a secret (possibly shared ) key and hence this is not easy to deciphe= r.=20 Also, communities (and extended communities) are not propagated across the = ebgp boundary by default.=20 2) Can you elaborate on how l3vpn-origination protects from unintentional e= rrors by the legitimate originator? Seems to me that both correct and erroneous routes would be signed by the e= gress CE/PE and hence accepted by the ingress. [Arjun] The idea here is to protect against routes being originated from unintended= /unauthorized sources (similar to RPKI based prefix validation), so any sp= urious routes sourced in transit can be detected and dealt with in the appr= opriate manner. Detecting erroneous routes coming from the proper origin= ator itself is beyond the scope of what is defined. 3) Given that a VPN may want to import routes from outside of the VPN (e.g.= provider IP services (e.g. voice gateway), extranet), how does l3vpn-origi= nation protect from unintentional errors from those partners? [Arjun] For simplicity we would recommend sharing keys with the extranet partners, = voice gateway sources this does mean that errors originating from those sou= rces will not be protected. Again we would expect these services to be trus= ted sources. Thanks Arjun=20 Thanks for the clarifications, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bruno.decraene@orange.com Thu Nov 15 01:25:04 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9179021F85CD for ; Thu, 15 Nov 2012 01:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qezmaik3hzeE for ; Thu, 15 Nov 2012 01:25:03 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 91E2A21F85C4 for ; Thu, 15 Nov 2012 01:25:03 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id ED6EF2648C4; Thu, 15 Nov 2012 10:25:02 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C45584C06E; Thu, 15 Nov 2012 10:25:02 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 15 Nov 2012 10:25:02 +0100 From: To: "Arjun Sreekantiah (asreekan)" Subject: RE: draft-ymbk-l3vpn-origination-02 Thread-Topic: draft-ymbk-l3vpn-origination-02 Thread-Index: Ac3C1OPbdXvrkSkPQ5Sg9BkPstJlyQAO75bQ Date: Thu, 15 Nov 2012 09:25:02 +0000 Message-ID: <30536_1352971502_50A4B4EE_30536_2496_1_53C29892C857584299CBF5D05346208A107874@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <6CDE9DE8E74F58419C4C489FE0852B8F21E23AD3@xmb-aln-x02.cisco.com> In-Reply-To: <6CDE9DE8E74F58419C4C489FE0852B8F21E23AD3@xmb-aln-x02.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.15.84515 Cc: "Randy Bush \(randy@psg.com\)" , "Pranav Mehta \(pmehta\)" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 09:25:04 -0000 Arjun, Thanks for your reply.=20 Please see inline. Bruno >From: Arjun Sreekantiah (asreekan) [mailto:asreekan@cisco.com] >Sent: Thur= sday, November 15, 2012 3:00 AM > >-----Original Message----- >From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] >Sent: Monday, November 12, 2012 1:44 AM >To: Arjun Sreekantiah (asreekan) >Cc: l3vpn@ietf.org >Subject: draft-ymbk-l3vpn-origination-02 > >Arjun, all, > >I confess that I don't know much about SIDR, but I guess that I'm not the = only >one in L3 VPN. Therefore clarification may be useful for the L3 VPN WG. > >Let's assume that no RPKI is used. > >1) Given that the goal is to protect from unintentional errors, can you >elaborate on the added value brought by l3vpn-origination compared to the = use >of a (extended) community agreed upon the VPN sites (e.g. some kind of a s= hared >password)? >The latter being available now, how much is it deployed/used now? (I would >assume that l3vpn-origination would be used by a subset of such current us= ers) >[Arjun] >Please note that the scheme does provide protection against attack scenari= os as >well, this is not just protecting errors from configuration. [Bruno]. The draft claims differently. I.e. only for protection against uni= ntentional errors "Abstract A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are subject to unintentional errors, both by the legitimate originator and by non-legitimate origins." "7. Security Considerations This is not protection against attacks, only configuration errors, aka 'fat= fingers'." > Using a community >or extended community makes it vulnerable in a attack scenarios. It is eas= y to >figure out the community or extended community value for prefixes for that= VPN >simply by looking at the BGP update or some show command output for the pr= efix >in that VPN. In the scheme, we use a digest generated from a secret (possi= bly >shared ) key and hence this is not easy to decipher. > >Also, communities (and extended communities) are not propagated across the= ebgp >boundary by default. I would tend to disagree for regular communities. Regardless, we would probably all agree that enabling BGP communities is ea= sier than deploying ymbk-l3vpn-origination >2) Can you elaborate on how l3vpn-origination protects from unintentional >errors by the legitimate originator? >Seems to me that both correct and erroneous routes would be signed by the >egress CE/PE and hence accepted by the ingress. >[Arjun] >The idea here is to protect against routes being originated from >unintended/unauthorized sources (similar to RPKI based prefix validation),= so >any spurious routes sourced in transit can be detected and dealt with in t= he >appropriate manner. Detecting erroneous routes coming from the proper >originator itself is beyond the scope of what is defined. That does not seem to match the first sentence of the abstract: " A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are subject to unintentional errors, both by the legitimate originator and by non-legitimate origins." > >3) Given that a VPN may want to import routes from outside of the VPN (e.g. >provider IP services (e.g. voice gateway), extranet), how does l3vpn- >origination protect from unintentional errors from those partners? >[Arjun] >For simplicity we would recommend sharing keys with the extranet partners, >voice gateway sources this does mean that errors originating from those so= urces >will not be protected. Again we would expect these services to be trusted >sources. In this case, the draft does not solve the problem it has defined in the ab= stract. "A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are subject to unintentional errors, both by the legitimate originator and by non-legitimate origins." Bottom line: You need to make clear in the draft what the problem statement= is i.e. the problem that you want to solve. This is not very clear current= ly. Thanks, Bruno > >Thanks >Arjun > >Thanks for the clarifications, >Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From thomas.morin@orange.com Thu Nov 15 06:43:22 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDEF21F8918 for ; Thu, 15 Nov 2012 06:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDYIfoFkWBgw for ; Thu, 15 Nov 2012 06:43:21 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD3221F8911 for ; Thu, 15 Nov 2012 06:43:21 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 0857322D06C for ; Thu, 15 Nov 2012 15:43:20 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E19D74C071 for ; Thu, 15 Nov 2012 15:43:19 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 15 Nov 2012 15:43:19 +0100 From: To: "l3vpn@ietf.org" Subject: Re: draft-ymbk-l3vpn-origination-02 Thread-Topic: draft-ymbk-l3vpn-origination-02 Thread-Index: AQHNwz+NdXvrkSkPQ5Sg9BkPstJlyQ== Date: Thu, 15 Nov 2012 14:43:18 +0000 Message-ID: <21679_1352990599_50A4FF87_21679_1103_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D070E889C@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <6CDE9DE8E74F58419C4C489FE0852B8F21E23AD3@xmb-aln-x02.cisco.com> In-Reply-To: <6CDE9DE8E74F58419C4C489FE0852B8F21E23AD3@xmb-aln-x02.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 14:43:22 -0000 SGkgQXJqdW4sDQoNCkFyanVuIFNyZWVrYW50aWFoOg0KPiBQbGVhc2Ugbm90ZSB0aGF0IHRoZSBz Y2hlbWUgZG9lcyBwcm92aWRlIHByb3RlY3Rpb24gYWdhaW5zdCBhdHRhY2sgc2NlbmFyaW9zIGFz IHdlbGwsIHRoaXMgaXMgbm90IGp1c3QgcHJvdGVjdGluZyBlcnJvcnMgZnJvbSBjb25maWd1cmF0 aW9uLg0KDQpJZiBvbmx5IHRoZSBOTFJJIGlzIHNpZ25lZCwgYXMgc3BlY2lmaWVkIGluIHRoZSBk cmF0ZiwgYW5kIG5vdCB0aGUgDQphdHRyaWJ1dGVzIG5vciB0aGUgcmVzdCBvZiB0aGUgTVBfUkVB Q0hfTkxSSSBhdHRyaWJ1dGUsIGhvdyBkb2VzIGl0IA0KcHJvdmlkZSBhbiBlZmZpY2llbnQgcHJv dGVjdGlvbiBhZ2FpbnN0IGF0dGFja3MgPw0KDQotVGhvbWFzCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRy ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91 cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgph IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0 aW9uLApGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4K ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh dXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From internet-drafts@ietf.org Thu Nov 15 13:42:09 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6CE21F8A29; Thu, 15 Nov 2012 13:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwcVKS5qHlmT; Thu, 15 Nov 2012 13:42:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD03921F89AA; Thu, 15 Nov 2012 13:42:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-mvpn-mldp-nlri-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121115214208.3964.15409.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2012 13:42:08 -0800 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:42:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Working = Group of the IETF. Title : Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes Author(s) : IJsbrand Wijnands Eric C. Rosen Uwe Joorde Filename : draft-ietf-l3vpn-mvpn-mldp-nlri-00.txt Pages : 11 Date : 2012-11-15 Abstract: Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in their VPNs. It is also desirable to be able to support customers who have MPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multicast Extensions to Label Distribution Protocol (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-mldp-nlri There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-mldp-nlri-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lucy.yong@huawei.com Thu Nov 15 16:23:14 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B680E21E8040 for ; Thu, 15 Nov 2012 16:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KT+TIihp7c3C for ; Thu, 15 Nov 2012 16:23:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3491F041A for ; Thu, 15 Nov 2012 16:23:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALP56998; Fri, 16 Nov 2012 00:23:09 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 00:22:50 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 00:23:06 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 15 Nov 2012 16:23:03 -0800 From: Lucy yong To: "mnapierala@att.com" , "lufang@cisco.com" Subject: comments and questions on the draft-fang-l3vpn-end-system-requirements-01.txt Thread-Topic: comments and questions on the draft-fang-l3vpn-end-system-requirements-01.txt Thread-Index: Ac3DkIi/ZZU/UsO+R0ayKh/Oes7ApA== Date: Fri, 16 Nov 2012 00:23:02 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44830EB3@dfweml505-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.89.223] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D44830EB3dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 00:23:14 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D44830EB3dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Maria and Luyuan, I read through this document. It is well written document. I have some comm= ents and questions as follow. * In section 2.2., it requires that in end-system environment, the= PE forwarding function should decouple from PE control function (physicall= y) but does not make any requirement on the interworking between two funct= ions. Do you expect the proprietary implementation in this interworking is = acceptable or have to be a standardized interworking solution? I suggest m= entioning this decoupling also enables some "centralized/distributed" comb= ined control plane solution, which may fit the DC environment better. * Section 3.3 IP subnet support. Could you elaborate how you want t= o group virtual resources into IP subnets? Do you mean Sp may want the reso= urces that run VoIP on one IP subnet and the resources that run video on an= other IP subnets regardless where the resources locate? What does "user d= efined IP subnet" mean? Please give an example. * Text: A collection of virtual resources might provide external or internal services. Such collection may serve an external "customer" or internal "tenant" to whom a Service Provider provides service(s). In MPLS/BGP VPN terminology a collection of virtual resources dedicated to a process or application corresponds to a VPN. -end. The first sentence means cloud service. The resources include comp= ute, storage, network appliance, and networking. It is not clear to me what= the second sentence mean? * Text: -VM or application end-point should be able to directly acc= ess multiple VPNs without a need to traverse a gateway. -end. In this case, does it use the same IP address or different IP address wh= en accessing different VPNs? Please clarify. * In section 5, suggest to add one advantage, it makes IP mobility = easier because the decoupling eliminates the physical network limitation in= supporting the mobility * Text: the virtual service itself must be delivered to an end-system such that switching elements connecting the end-system to the encap/decap device are not aware of the virtual topology. -end. This is about local access between CE and PE, right? This is always t= he case. Do you expect the payload to be encapsulated in local access too? = Why state it in this section? * Regarding to section 7.1, Do you require that the end system to s= upport LDP and RSVP-TE in order to support the end-system VPN? * In Section 8, what is the midpoint router? The first hop router, = or gateway router, or any LSR? Describe from one end-system to another end = system do not make this clear because PE may be on the end-system or may no= t. * In section 9, what does "abstracting the externally visible netwo= rk address from ..." mean? * In section 10, text: The inter-connection of end-system VPNs with traditional VPNs requires an integrated control plane and unified orchestration of network and end-system resources. -end. What does that mean? Do you want to say interworking between traditional= control plane in WAN and orchestration system in DC? * There is no any requirement on a gateway usage. Do you expect no = gateway at all in end system VPN? Do we need NAT, firewall in end system VP= N? * The document does not use the requirement language to describe th= e requirement. "MUST", "SHOULD", etc. Look forward to hearing from you on these. Cheers, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D44830EB3dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Maria and Luyuan,

 

I read through this document. It is well written doc= ument. I have some comments and questions as follow.

 

·         In section 2.2., it requires that in end-sys= tem environment,  the PE forwarding function should decouple from PE c= ontrol function (physically) but does not make any requirement on the inter= working between  two functions. Do you expect the proprietary implementation in this interworking is acceptable &= nbsp;or have to be a standardized interworking solution? I suggest mentioni= ng this decoupling also enables some “centralized/distributed” =  combined control plane solution, which may fit the DC environment better.

·         Section 3.3 IP subnet support. Could you ela= borate how you want to group virtual resources into IP subnets? Do you mean= Sp may want the resources that run VoIP on one IP subnet and the resources= that run video on another IP subnets regardless where the resources locate?  What does  “user d= efined IP subnet” mean? Please give an example.

·         Text:  

   A collection of virtual res= ources might provide external or

   internal services. Such col= lection may serve an external "customer"

   or internal "tenant&qu= ot; to whom a Service Provider provides

   service(s). In MPLS/BGP VPN= terminology a collection of virtual

   resources dedicated to a pr= ocess or application corresponds to a

   VPN.

   -end. The first sentence means c= loud service. The resources include compute, storage, network appliance, an= d networking. It is not clear to me what the second sentence mean?

 

·         Text: -VM or application end-point should be able to directly acces= s

      multiple = VPNs without a need to traverse a gateway. –end.

   In this case, does it use the sa= me IP address or different IP address when accessing different VPNs? Please= clarify.

 

·         In section 5, suggest to add one advantage, it makes IP mobility ea= sier because the decoupling eliminates the physical network limitation in s= upporting the mobility

·         Text: the virtual service itself must be delivered to an

   end-system such that switch= ing elements connecting the end-system

   to the encap/decap device a= re not aware of the virtual topology.

-end. This is about local access between CE a= nd PE, right? This is always the case. Do you expect the payload to be enca= psulated in local access too? Why state it in this section?

·         Regarding to section 7.1, Do you require tha= t the end system to support LDP and RSVP-TE in order to support the end-sys= tem VPN?

·         In Section 8, what is the midpoint router? T= he first hop router, or gateway router, or any LSR? Describe from one end-s= ystem to another end system do not make this clear because PE may be on the= end-system or may not.

·         In section 9, what does “abstracting t= he externally visible network address from …” mean?<= /p>

·         In section 10, text:

   The inter-connection of end-syst= em VPNs with traditional VPNs

   requires an integrated cont= rol plane and unified orchestration of

   network and end-system reso= urces. –end.

   What does that mean? Do you want= to say interworking between traditional control plane in WAN and orchestra= tion system in DC?

 

·         There is no any requirement on a gateway usa= ge. Do you expect no gateway at all in end system VPN? Do we need NAT, fire= wall in end system VPN?

·         The document does not use the requirement la= nguage to describe the requirement. “MUST”, “SHOULD”= ;, etc.

 

Look forward to hearing from you on these.

 

Cheers,

Lucy

--_000_2691CE0099834E4A9C5044EEC662BB9D44830EB3dfweml505mbx_-- From asreekan@cisco.com Fri Nov 16 17:07:35 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D6121F8AEA for ; Fri, 16 Nov 2012 17:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VcN3O5cEj09 for ; Fri, 16 Nov 2012 17:07:34 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 63E9521F8A22 for ; Fri, 16 Nov 2012 17:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6912; q=dns/txt; s=iport; t=1353114454; x=1354324054; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NcNZsC1XvhKfzGDLh3i6s9LdE//d3D9lUzBUKdqeZEQ=; b=FGFY24XoT/xS8ZSD54C2fmWBH7MEzoSuimjyhP3aQtXOZc/uUGSwRfqr 8uBQZFgU+pTY3ybbqfMljeqXRilug+6UiO5TjXnfbv05YKQXjZljAoFmW BgAdpQruTQe35YpsbyxGw0aRh3LK1IvDZZkdHfkfJN0zxzIf8Ez2XLfQL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQIALbiplCtJV2c/2dsb2JhbABEwy2BAQeCHgEBAQMBEgEnNwgFBwQCAQgRBAEBCw4GCQcyFAkIAQEEDgUIDAcHh2UFAZ5yoCmMM4FogkRhA6RUgWuCb4FdBxcGGA X-IronPort-AV: E=McAfee;i="5400,1158,6898"; a="143406414" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 17 Nov 2012 01:07:33 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qAH17Xwa020523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 17 Nov 2012 01:07:33 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.85]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Fri, 16 Nov 2012 19:07:33 -0600 From: "Arjun Sreekantiah (asreekan)" To: "bruno.decraene@orange.com" Subject: RE: draft-ymbk-l3vpn-origination-02 Thread-Topic: draft-ymbk-l3vpn-origination-02 Thread-Index: Ac3C1OPbPsQ26gl8RBC8+IuyHnbL7AAcH2oAAEP1bGA= Date: Sat, 17 Nov 2012 01:07:33 +0000 Message-ID: <6CDE9DE8E74F58419C4C489FE0852B8F21E34EEA@xmb-rcd-x02.cisco.com> References: <6CDE9DE8E74F58419C4C489FE0852B8F21E23AD3@xmb-aln-x02.cisco.com> <30536_1352971502_50A4B4EE_30536_2496_1_53C29892C857584299CBF5D05346208A107874@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <30536_1352971502_50A4B4EE_30536_2496_1_53C29892C857584299CBF5D05346208A107874@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.139.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Randy Bush \(randy@psg.com\)" , "Pranav Mehta \(pmehta\)" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 01:07:35 -0000 Bruno, More inline. >From: Arjun Sreekantiah (asreekan) [mailto:asreekan@cisco.com] >Sent:=20 >Thursday, November 15, 2012 3:00 AM > >-----Original Message----- >From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] >Sent: Monday, November 12, 2012 1:44 AM >To: Arjun Sreekantiah (asreekan) >Cc: l3vpn@ietf.org >Subject: draft-ymbk-l3vpn-origination-02 > >Arjun, all, > >I confess that I don't know much about SIDR, but I guess that I'm not=20 >the only one in L3 VPN. Therefore clarification may be useful for the L3 V= PN WG. > >Let's assume that no RPKI is used. > >1) Given that the goal is to protect from unintentional errors, can you=20 >elaborate on the added value brought by l3vpn-origination compared to=20 >the use of a (extended) community agreed upon the VPN sites (e.g. some=20 >kind of a shared password)? >The latter being available now, how much is it deployed/used now? (I=20 >would assume that l3vpn-origination would be used by a subset of such=20 >current users) [Arjun] Please note that the scheme does provide=20 >protection against attack scenarios as well, this is not just=20 >protecting errors from configuration. >[Bruno]. The draft claims differently. I.e. only for protection against un= intentional errors >"Abstract > A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are > subject to unintentional errors, both by the legitimate originator > and by non-legitimate origins." >"7. Security Considerations >This is not protection against attacks, only configuration errors, aka 'fa= t fingers'." [Arjun] The primary motivation behind the draft is mis-configuration aka 'fat finge= rs' but the digest scheme does provide more security wise than just using = a "secret" community. Once the secret community value Is known the same could be used to compromise any prefix from the originato= r whereas with the digest scheme, you would need to snoop out the digest va= lue associated with each prefix since there is a unique digest per prefix. = Granted the scheme does not address replay attacks (this is what section 7 = is referring to), but neither do well known schemes for origin validation l= ike RPKI based prefix validation so this is similar. ( this is a tradeoff t= o keep the solution simple) =20 Also the community based scheme is not as simple to implement as it would a= ppear. You would need to make sure that the secret community values do not = collide with valid community values used in policy elsewhere, this would been more difficult to do, when you need a unique co= mmunity value per VPN. Also you need to make sure that these values are not= stripped or interpreted in a different manner by transit ASes and also nee= d to make sure that transit ASes propagate the community values transparent= ly which would now require the intermediate hops to be aware of the scheme. > Using a community >or extended community makes it vulnerable in a attack scenarios. It is=20 >easy to figure out the community or extended community value for=20 >prefixes for that VPN simply by looking at the BGP update or some show=20 >command output for the prefix in that VPN. In the scheme, we use a=20 >digest generated from a secret (possibly shared ) key and hence this is n= ot easy to decipher. > >Also, communities (and extended communities) are not propagated across=20 >the ebgp boundary by default. >I would tend to disagree for regular communities. >Regardless, we would probably all agree that enabling BGP communities is e= asier than deploying ymbk-l3vpn-origination [Arjun] Please see my comment above - this would have its own complexity. >2) Can you elaborate on how l3vpn-origination protects from=20 >unintentional errors by the legitimate originator? >Seems to me that both correct and erroneous routes would be signed by=20 >the egress CE/PE and hence accepted by the ingress. >[Arjun] >The idea here is to protect against routes being originated from=20 >unintended/unauthorized sources (similar to RPKI based prefix=20 >validation), so any spurious routes sourced in transit can be detected=20 >and dealt with in the appropriate manner. Detecting erroneous routes =20 >coming from the proper originator itself is beyond the scope of what is = defined. >That does not seem to match the first sentence of the abstract: >" A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are > subject to unintentional errors, both by the legitimate originator > and by non-legitimate origins." [Arjun] This is referring to the fact that a PE attaching a site to the wrong VPN c= an be a legitimate originator with fat fingering which is covered by the sc= heme. I was referring earlier to some fat-fingering on the CE Sourcing and signing the route itself which is beyond the scope. We can ad= d text to clarify this part - Thanks for pointing it out. > >3) Given that a VPN may want to import routes from outside of the VPN (e.g= . >provider IP services (e.g. voice gateway), extranet), how does l3vpn-=20 >origination protect from unintentional errors from those partners? >[Arjun] >For simplicity we would recommend sharing keys with the extranet=20 >partners, voice gateway sources this does mean that errors originating=20 >from those sources will not be protected. Again we would expect these=20 >services to be trusted sources. In this case, the draft does not solve the problem it has defined in the ab= stract. "A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are subject to unintentional errors, both by the legitimate originator and by non-legitimate origins." [Arjun] Please see above for this statement referred to. Thanks Arjun > >Thanks >Arjun > >Thanks for the clarifications, >Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From asreekan@cisco.com Fri Nov 16 17:08:16 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1679E21F8B01 for ; Fri, 16 Nov 2012 17:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u76i4Ar2ag2h for ; Fri, 16 Nov 2012 17:08:15 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id F231C21F8AF7 for ; Fri, 16 Nov 2012 17:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3068; q=dns/txt; s=iport; t=1353114495; x=1354324095; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XSbBFZ6nYnoHlDnJQLSYl8BZGQHl4gO0kIb65HxDQoU=; b=FOhurQofHH10Y8yveuNrnVZ3S2pOnsvzGAd3R7uz+x6V+5dcxEmGlcty kIHaazM7WdzrouTDVtSnBA/Hyi60puYSsNufes2U3ZYvpf5RoLYyEE0xL trd1B9AsF/vkEDDC8Ekrt9qNDj40LtUtXhNPGTft4INYTFYNlfPYu5okh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALbiplCtJV2Z/2dsb2JhbABEhiC8FneBCIIeAQEBBBIBEBFRBAIBCBEEAQEDAgYdAwICAjAUAQgIAQEEARIIEweHagGeco0okwGBIosRg3oyYQOkVIFrgm+BXQcXBhg X-IronPort-AV: E=McAfee;i="5400,1158,6898"; a="143406540" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 17 Nov 2012 01:08:12 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAH18C4I000969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 17 Nov 2012 01:08:12 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.85]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Fri, 16 Nov 2012 19:08:12 -0600 From: "Arjun Sreekantiah (asreekan)" To: "thomas.morin@orange.com" , "l3vpn@ietf.org" Subject: RE: draft-ymbk-l3vpn-origination-02 Thread-Topic: draft-ymbk-l3vpn-origination-02 Thread-Index: Ac3C1OPbPsQ26gl8RBC8+IuyHnbL7AAnPPEAADqtmPA= Date: Sat, 17 Nov 2012 01:08:11 +0000 Message-ID: <6CDE9DE8E74F58419C4C489FE0852B8F21E34F03@xmb-rcd-x02.cisco.com> References: <6CDE9DE8E74F58419C4C489FE0852B8F21E23AD3@xmb-aln-x02.cisco.com> <21679_1352990599_50A4FF87_21679_1103_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D070E889C@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <21679_1352990599_50A4FF87_21679_1103_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D070E889C@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.139.154] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19370.005 x-tm-as-result: No--24.821100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 01:08:16 -0000 SGkgVGhvbWFzLA0KQXR0cmlidXRlcyBpbiB0aGUgQkdQIHVwZGF0ZSBzdWNoIGFzIHRoZSBuZXh0 aG9wIGFuZCBhc3BhdGggYXJlIHJld3JpdHRlbi9tb2RpZmllZCBhdCB0aGUgZWJncCBib3VuZGFy eSBzbyBzaWduaW5nIHRoZSBhdHRyaWJ1dGVzIGF0IHRoZSBvcmlnaW5hdG9yIGlzIG9mIGxpdHRs ZSB2YWx1ZSB1bmxlc3MgdGhlIHNhbWUgaXMgZG9uZSBhdCBlYWNoIGhvcCwNCkluIHdoaWNoIGNh c2Ugd2UgYXJlIGF0dGVtcHRpbmcgcGF0aCB2YWxpZGF0aW9uIC0gdGhpcyB3b3VsZCBpbnRyb2R1 Y2UgYSBsb3QgbW9yZSBjb21wbGV4aXR5IGludG8gdGhlIHNvbHV0aW9uIGFuZCByZXF1aXJlIGlu dGVybWVkaWF0ZSBob3BzIHRvIGJlIGF3YXJlIG9mIHRoZSBzY2hlbWUgLSBUaGUgcHJpbWFyeSBz Y29wZSBvZiB0aGUgZHJhZnQgaXMgdG8gYWNjb21wbGlzaCBvcmlnaW4gdmFsaWRhdGlvbiBmb3Ig VlBOIHJvdXRlcyAodmVyaWZ5IHJvdXRlcyBhcmUgY29taW5nIGZyb20gdmFsaWQgb3JpZ2luYXRv cikgIHNpbWlsYXIgdG8gdGhlIFJQS0kgYmFzZWQgIHByZWZpeCB2YWxpZGF0aW9uIGZvciBpbnRl cm5ldC4NCg0KVGhhbmtzDQpBcmp1bg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGwzdnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsM3Zwbi1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgdGhvbWFzLm1vcmluQG9yYW5nZS5jb20NClNlbnQ6IFRodXJzZGF5LCBOb3Zl bWJlciAxNSwgMjAxMiA2OjQzIEFNDQpUbzogbDN2cG5AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBk cmFmdC15bWJrLWwzdnBuLW9yaWdpbmF0aW9uLTAyDQoNCkhpIEFyanVuLA0KDQpBcmp1biBTcmVl a2FudGlhaDoNCj4gUGxlYXNlIG5vdGUgdGhhdCB0aGUgc2NoZW1lIGRvZXMgcHJvdmlkZSBwcm90 ZWN0aW9uIGFnYWluc3QgYXR0YWNrIHNjZW5hcmlvcyBhcyB3ZWxsLCB0aGlzIGlzIG5vdCBqdXN0 IHByb3RlY3RpbmcgZXJyb3JzIGZyb20gY29uZmlndXJhdGlvbi4NCg0KSWYgb25seSB0aGUgTkxS SSBpcyBzaWduZWQsIGFzIHNwZWNpZmllZCBpbiB0aGUgZHJhdGYsIGFuZCBub3QgdGhlIGF0dHJp YnV0ZXMgbm9yIHRoZSByZXN0IG9mIHRoZSBNUF9SRUFDSF9OTFJJIGF0dHJpYnV0ZSwgaG93IGRv ZXMgaXQgcHJvdmlkZSBhbiBlZmZpY2llbnQgcHJvdGVjdGlvbiBhZ2FpbnN0IGF0dGFja3MgPw0K DQotVGhvbWFzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBGcmFuY2UgVGVsZWNvbSAtIE9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KVGhhbmsgeW91Lg0KDQo= From bruno.decraene@orange.com Mon Nov 19 01:18:26 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B8F21F850E for ; Mon, 19 Nov 2012 01:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ozDJHTO+jRj for ; Mon, 19 Nov 2012 01:18:25 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7204F21F850D for ; Mon, 19 Nov 2012 01:18:24 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id D24D622C45B; Mon, 19 Nov 2012 10:18:23 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id A19CE35C045; Mon, 19 Nov 2012 10:18:23 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Mon, 19 Nov 2012 10:18:23 +0100 From: To: "Arjun Sreekantiah (asreekan)" Subject: RE: draft-ymbk-l3vpn-origination-02 Thread-Topic: draft-ymbk-l3vpn-origination-02 Thread-Index: Ac3C1OPbdXvrkSkPQ5Sg9BkPstJlyQAcH2oAAEP1bGAAdtKXEA== Date: Mon, 19 Nov 2012 09:18:22 +0000 Message-ID: <30354_1353316703_50A9F95F_30354_1766_3_53C29892C857584299CBF5D05346208A108C38@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <6CDE9DE8E74F58419C4C489FE0852B8F21E23AD3@xmb-aln-x02.cisco.com> <30536_1352971502_50A4B4EE_30536_2496_1_53C29892C857584299CBF5D05346208A107874@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6CDE9DE8E74F58419C4C489FE0852B8F21E34EEA@xmb-rcd-x02.cisco.com> In-Reply-To: <6CDE9DE8E74F58419C4C489FE0852B8F21E34EEA@xmb-rcd-x02.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "Randy Bush \(randy@psg.com\)" , "Pranav Mehta \(pmehta\)" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 09:18:26 -0000 Arjun, Thanks for your reply. More inline. >From: Arjun Sreekantiah (asreekan) [mailto:asreekan@cisco.com] > >Bruno, >More inline. > >>From: Arjun Sreekantiah (asreekan) [mailto:asreekan@cisco.com] >Sent: >>Thursday, November 15, 2012 3:00 AM >> >>-----Original Message----- >>From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] >>Sent: Monday, November 12, 2012 1:44 AM >>To: Arjun Sreekantiah (asreekan) >>Cc: l3vpn@ietf.org >>Subject: draft-ymbk-l3vpn-origination-02 >> >>Arjun, all, >> >>I confess that I don't know much about SIDR, but I guess that I'm not >>the only one in L3 VPN. Therefore clarification may be useful for the L3 = VPN >WG. >> >>Let's assume that no RPKI is used. >> >>1) Given that the goal is to protect from unintentional errors, can you >>elaborate on the added value brought by l3vpn-origination compared to >>the use of a (extended) community agreed upon the VPN sites (e.g. some >>kind of a shared password)? >>The latter being available now, how much is it deployed/used now? (I >>would assume that l3vpn-origination would be used by a subset of such >>current users) [Arjun] Please note that the scheme does provide >>protection against attack scenarios as well, this is not just >>protecting errors from configuration. > >>[Bruno]. The draft claims differently. I.e. only for protection against >unintentional errors >>"Abstract >> A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are >> subject to unintentional errors, both by the legitimate originator >> and by non-legitimate origins." >>"7. Security Considerations >>This is not protection against attacks, only configuration errors, aka 'f= at >fingers'." > >[Arjun] >The primary motivation behind the draft is mis-configuration aka 'fat fing= ers' OK. In this case the problem is that the solution defined in the draft does= not help protecting from mis-configuration from the people who can do it: = service provider, extranet VPN. You agreed on this in your previous email: = http://www.ietf.org/mail-archive/web/l3vpn/current/msg03490.html It does protect from mis-configuration from people who cannot send routes i= n the VPN... But this is also of limited value because in this case this wo= uld probably be an attack so you would need to provide protection against a= ttacks. (And personally, as an attacker, may be I would rather play with th= e MPLS labels which seems more powerful and more difficult to detect) >but the digest scheme does provide more security wise than just using a >"secret" community. The question is: how much more. Then we can discuss how much the additional= cost outweighs the additional benefit. > Once the secret community value >Is known the same could be used to compromise any prefix from the originat= or >whereas with the digest scheme, you would need to snoop out the digest val= ue >associated with each prefix since there is a unique digest per prefix. Gra= nted >the scheme does not address replay attacks (this is what section 7 is refe= rring >to), but neither do well known schemes for origin validation like RPKI bas= ed >prefix validation so this is similar. ( this is a tradeoff to keep the sol= ution >simple) Although I'm not familiar with the SIDR work, I see a significant differenc= e: in the Internet, IP routes are public and hence you can use a database t= o check who is allowed to originate a given route. This is not the case in = a VPN context. That's why IMHO, the level of protection provided is signifi= cantly lower. >Also the community based scheme is not as simple to implement as it would >appear. You would need to make sure that the secret community values do not >collide with valid community values used in policy >elsewhere, this would been more difficult to do, when you need a unique >community value per VPN. Also you need to make sure that these values are = not >stripped or interpreted in a different manner by transit ASes and also nee= d to >make sure that transit ASes propagate the community values transparently w= hich >would now require the intermediate hops to be aware of the scheme. In short, you need to know how to use a BGP community. IMO, people knows. N= ote that this is a pre-requisite for L3 VPN (route distribution are based o= n extended community). > >> Using a community >>or extended community makes it vulnerable in a attack scenarios. It is >>easy to figure out the community or extended community value for >>prefixes for that VPN simply by looking at the BGP update or some show >>command output for the prefix in that VPN. In the scheme, we use a >>digest generated from a secret (possibly shared ) key and hence this is = not >easy to decipher. >> >>Also, communities (and extended communities) are not propagated across >>the ebgp boundary by default. > >>I would tend to disagree for regular communities. >>Regardless, we would probably all agree that enabling BGP communities is >easier than deploying ymbk-l3vpn-origination > >[Arjun] >Please see my comment above - this would have its own complexity. > >>2) Can you elaborate on how l3vpn-origination protects from >>unintentional errors by the legitimate originator? >>Seems to me that both correct and erroneous routes would be signed by >>the egress CE/PE and hence accepted by the ingress. >>[Arjun] >>The idea here is to protect against routes being originated from >>unintended/unauthorized sources (similar to RPKI based prefix >>validation), so any spurious routes sourced in transit can be detected >>and dealt with in the appropriate manner. Detecting erroneous routes >>coming from the proper originator itself is beyond the scope of what is >defined. > >>That does not seem to match the first sentence of the abstract: >>" A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are >> subject to unintentional errors, both by the legitimate originator >> and by non-legitimate origins." >[Arjun] >This is referring to the fact that a PE attaching a site to the wrong VPN = can >be a legitimate originator with fat fingering which is covered by the sche= me. This is indeed covered in the subcase " 5.1. End CE to CE Authentication" However, in the sub-case, "5.3. PE-PE Based Validation", this is very deba= table:=20 a) you assume a mis-configuration (of the RT) on the PE from the SP b) to detect this you rely on the correct configuration (of the key) on the= PE from the SP. Seems to me that "b" is debatable if you assume "a". (in short, do you trus= t the configuration, or not?) > I was referring earlier to some fat-fingering on the CE >Sourcing and signing the route itself which is beyond the scope. We can a= dd >text to clarify this part - Thanks for pointing it out. Ok. Thanks. For the same reason, could you also add that: - for the sub-case "5.3. PE-PE Based Validation", fat-fingering on the PE = is beyond the scope of the document - in case of extra-net, fat-fingering on the partner(s) VPN is beyond the s= cope of the document - in case the SP originates routes in the customers VPN (e.g. voice gateway= , cloud services....) fat-fingering in the SP is beyond the scope of the do= cument Thanks. Bruno >>3) Given that a VPN may want to import routes from outside of the VPN (e.= g. >>provider IP services (e.g. voice gateway), extranet), how does l3vpn- >>origination protect from unintentional errors from those partners? >>[Arjun] >>For simplicity we would recommend sharing keys with the extranet >>partners, voice gateway sources this does mean that errors originating >>from those sources will not be protected. Again we would expect these >>services to be trusted sources. > >In this case, the draft does not solve the problem it has defined in the >abstract. >"A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are > subject to unintentional errors, both by the legitimate originator > and by non-legitimate origins." >[Arjun] >Please see above for this statement referred to. > >Thanks >Arjun >> >>Thanks >>Arjun >> >>Thanks for the clarifications, >>Bruno > > >__________________________________________________________________________= _____ >__________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc pas etre diffuses, expl= oites >ou copies sans autorisation. Si vous avez recu ce message par erreur, veui= llez >le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les >messages electroniques etant susceptibles d'alteration, France Telecom - O= range >decline toute responsabilite si ce message a ete altere, deforme ou falsif= ie. >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 del= ete >this message and its attachments. >As emails may be altered, France Telecom - Orange is not liable for messag= es >that have been modified, changed or falsified. >Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From internet-drafts@ietf.org Mon Nov 19 07:21:54 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB96921F8689; Mon, 19 Nov 2012 07:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYIbFxA1ZVUv; Mon, 19 Nov 2012 07:21:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691E021F8667; Mon, 19 Nov 2012 07:21:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-virtual-hub-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121119152154.15000.15521.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2012 07:21:54 -0800 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 15:21:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Working = Group of the IETF. Title : Virtual Hub-and-Spoke in BGP/MPLS VPNs Author(s) : Huajin Jeng James Uttaro Luay Jalil Bruno Decraene Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-l3vpn-virtual-hub-03.txt Pages : 25 Date : 2012-11-19 Abstract: With BGP/MPLS VPNs any-to-any connectivity among sites of a given Virtual Private Network would require each Provider Edge router that has one or more of these sites connected to it to hold all the routes of that Virtual Private Network. The approach described in this document allows to reduce the number of Provider Edge routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes. Furthermore, when Provider Edge routers use ingress replication to carry multicast traffic of VPN customers, the approach described in this document may allow to reduce bandwidth inefficiency associated with ingress replication, and to redistribute the replication load among Provider Edge routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-virtual-hub There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-hub-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-virtual-hub-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yakov@juniper.net Mon Nov 19 07:31:22 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADB021F865B for ; Mon, 19 Nov 2012 07:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.898 X-Spam-Level: X-Spam-Status: No, score=-105.898 tagged_above=-999 required=5 tests=[AWL=0.702, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JA0y2W0x7n6 for ; Mon, 19 Nov 2012 07:31:22 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 28C9E21F867D for ; Mon, 19 Nov 2012 07:31:20 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUKpQxluTlGP+myv355wGdJpT8ZlvHgLa@postini.com; Mon, 19 Nov 2012 07:31:21 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 19 Nov 2012 07:28:19 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qAJFSI305952; Mon, 19 Nov 2012 07:28:18 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201211191528.qAJFSI305952@magenta.juniper.net> To: Martin Vigoureux Subject: Re: WG Last Call for draft-ietf-l3vpn-virtual-hub In-Reply-To: <509BBFCB.3090801@alcatel-lucent.com> References: <506D586A.1030202@orange.com> <509BBFCB.3090801@alcatel-lucent.com> X-MH-In-Reply-To: Martin Vigoureux message dated "Thu, 08 Nov 2012 15:20:59 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <68095.1353338898.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Nov 2012 07:28:18 -0800 From: Yakov Rekhter Cc: Thomas Morin , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 15:31:22 -0000 Martin, > All, > = > the WG LC has ended. > Authors, please process the comments received, perform updates to the = > document as appropriate and check with people having made the comments. > Thank you. The authors processed the comments received and posted the updated the draft (-03) that addresses the comment. I also posted response to the comments from Eric. Yakov. > = > martin > = > Le 04/10/2012 11:35, Thomas Morin a =C3=A9crit : > > Hello working group, > > > > This email starts a two-week Working Group Last Call on > > draft-ietf-l3vpn-virtual-hub, which is considered mature and ready for= a > > working group review. > > > > Please read the document if you haven't read the most recent version, > > and send your comments to the list, no later than Thursday October 18t= h. > > > > Thank you, > > > > -Thomas& Martin > > > > [ http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-hub ] From yakov@juniper.net Mon Nov 19 07:27:19 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B0821F8598 for ; Mon, 19 Nov 2012 07:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.793 X-Spam-Level: X-Spam-Status: No, score=-103.793 tagged_above=-999 required=5 tests=[AWL=-2.806, BAYES_50=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLYPC2hAKDT1 for ; Mon, 19 Nov 2012 07:27:14 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDEF21F8635 for ; Mon, 19 Nov 2012 07:27:13 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUKpP0BG62Xm72qJntN1jL1Ubihn5e2lF@postini.com; Mon, 19 Nov 2012 07:27:13 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 19 Nov 2012 07:25:11 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qAJFPA397494; Mon, 19 Nov 2012 07:25:10 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201211191525.qAJFPA397494@magenta.juniper.net> To: Subject: Re: Last Call comments on draft-ietf-l3vpn-virtual-hub In-Reply-To: <23373.1350054126@erosen-linux> References: <23373.1350054126@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Fri, 12 Oct 2012 11:02:06 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <68034.1353338710.1@juniper.net> Date: Mon, 19 Nov 2012 07:25:10 -0800 From: Yakov Rekhter X-Mailman-Approved-At: Mon, 19 Nov 2012 08:01:22 -0800 Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 15:27:19 -0000 Eric, > I have a number of comments on the virtual-hub draft. Some are minor and/or > editorial, but a number are more substantial. I think these comments need > to be addressed before the draft is submitted for publication. > > I've placed a lot of comments in-line, but let me summarize what I think are > the major issues: > > - It is not at all clear what has to be implemented in order to conform to > this draft. There is a lot of complexity introduced to handle a few > specific scenarios, but it's not clear whether it is mandatory to support > those scenarios. Is it mandatory to support the scenario where a customer > gets Internet access via a site that is homed to a V-spoke PE? Is it > mandatory to support the scenario where a customer has a site that is > multihomed to a pair of V-spoke PEs, and the customer is expecting a > certain load-balancing behavior? > > Much of the discussion about these scenarios is of the sort that says "you > could do this, you could do that, or you could do some other thing", but > it's not clear what is required for conformance. This really needs to be > clarified. Support the scenario where a customer gets Internet access via a site that is homed to a V-spoke PE is optional. The revised text (-03) makes this explicit. > - Various procedures seem to assume that a PE, when processing a default > route, will know whether that route is "the Internet VPN-IP default route" > or "the non-Internet VPN-IP default route". Yet there is no clear > statement of how this is known. I think it is supposed to be inferred > somehow from the RTs carried by the route, but the draft never says that a > VRF has to be provisioned to know that any specific RT is used for this > particular purpose. Done. > This is an example of a more general issue: the draft suggests that > certain routes need to be exported with a different RT (or a different set > of RTs) than certain other routes, but it doesn't say explicitly that an > importing VRF has to know that any particular import RT has any particular > semantics. This is an area that I think needs to be clarified. Done. > - If V-hub1 receives a packet from the backbone, and the packet is destined > to a site which is attached both to V-hub1 and to another V-hub, V-hub2, > V-hub1 is allowed to do load-balancing by choosing whether (a) to send the > packet directly to the site, or (b) to send the packet to V-hub2. But I > don't see anything in the draft that prevents V-hub2 from doing its own > load-balancing, and perhaps sending the packet back to V-hub1. The possibility for V-hub(V-hub1) that has received an MPLS packet from the backbone to send the packet to another PE (V-hub2) is limited to packets received for the VPN-IP default route (identified by a specific label). Such packet sent to V-hub2 has not matched a VPN-IP default route on V-hub2 (since the hub does not import such VPN-IP default route) but a more specific route. Hence V-hub2 will not have the ability to send the packet to another PE. The revised draft makes this explicit. More on this below. > - The draft says that a V-hub shouldn't originate a default route if it > receives a default route from one of its attached CEs. But it doesn't say > what to do if the V-hub originates a default route and the CE later sends > it a default route. Nor does it say what to do if the CE later withdraws > the default route. One can surmise what needs to be done in these cases, > but the spec should say explicitly what to do. Done. > - In at least one place, the draft states "a PE that acts as a V-spoke of a > given VPN needs to maintain ... two or more VPN-IP default routes whose > Next Hops are the addresses of the V-hubs". This seems to rule out the > case where the V-spoke and V-hub are separated by an "option B" ASBR. > (The option B ASBR would change the next hop.) If this restriction is > intentional, it should be stated explicitly, and a reason for it should be > given. Inter-AS is outside of the scope. The revised text makes this clear. > - Hidden in the "fine print" is a significant change to RFC 6514. This > draft proposes to allow the setting of the LIR flag in I-PMSI A-D routes, > while RFC 6514 prohibits it. Presumably this change is only meant to > apply when the V-hub/V-spoke architecture is being used, but the draft > doesn't really say how the receiver of an I-PMSI A-D route is supposed to > know whether LIR is legal or not, and it doesn't address interoperability > issues with PEs that adhere to the RFC 6514 rules. If this change is > considered desirable, it should really be separated out from this draft > and proposed in a separate internet-draft. The draft assumes that when ingress replication is used all the PEs implement procedures specified in section 7.9 of the draft. The revised text makes this clear. > I think this should be removed from the V-hub draft. > > - The V-hub/V-spoke architecture affects certain multicast scenarios, but not > others. In particular, I think it only affects multicast scenarios where > (a) the source of a multicast flow is at a site attached to a V-spoke, and a > receiver of that flow is at a site attached to a different V-spoke, or (b) > the source of a multicast flow is at a site attached to a V-hub, and a > receiver of that flow is at a site attached to a V-spoke that is not > associated with that same V-hub. But it is left as an exercise to the > reader to figure out what these scenarios are. The draft should state > them explicitly. Done. > - In general,when a multicast flow needs to go from one V-spoke to another > V-spoke, the draft requires the BGP control messages to go from V-spoke to > V-hub to V-spoke. I agree that, in order to meet the goals of the draft, > it is necessary to put the V-hub in the control path. However, the draft > also requires the data flow itself to go from V-spoke to V-hub to V-spoke. > I do not see why the V-hub needs to insert itself into the multicast data > path. For unicast, the V-hub needs to be in the data path because it > needs to do an IP lookup for each data packet. For multicast, the V-hub > does not do an IP lookup for each data packet, so I don't see why it needs > to be in the data path. The last statement in the above is incorrect - see 7.8.2 for counterexamples. The revised draft made this explicit. > As long as the V-spoke PEs have global table unicast routes to each other, > it should be possible to keep the V-hubs out of the multicast data path > between two V-spokes. (When a V-hub tells a V-spoke which P-tunnel to > join in order to receive (C-S,C-G) traffic, why can't the V-hub specify a > P-tunnel that is routed at the PE that is actually attached to the C-S?) > > The draft does not say that the V-spokes don't have global table routes to > each other, just that they don't have VPN-IP routes to the multicast > sources. So I think the draft needs to provide some justification for > putting the V-hubs in the multicast data path. see further down... > - Something should be said about whether this draft is expected to work in a > "seamless MPLS environment" where there is an ABR between a V-hub and a > V-spoke. Even a statement that seamless MPLS (and/or seamless MPLS > multicast) is out of scope (if that's the authors' intention) would be > helpful. If "seamless MPLS multicast" is not out of scope, then something > needs to be said about the handling of the P2MP Segmented Next Hop > Extended Community on A-D routes received by the V-hub from V-spokes or > from other V-hubs. > > (It might also be helpful to say that "MVPN extranet" is out of scope.) This draft is expected to work with the seamless MPLS unicast draft. The two are orthogonal: seamless MPLS unicast draft deals with the transport (MPLS LSP) layer while this draft deals with the VPN service layer. As you requested, I added a sentence to the draft stating that seamless MPLS multicast is out of scope. > There are also a few more minor issues that I think need to be addressed: > > - I'd like to see some more explicit mention of the asymmetry in the > procedures. A V-spoke only imports the default route from certain V-hubs, > but all V-hubs import all routes from all V-spokes. I'm not saying that > this is a problem, just that it is a part of the architectural model and > should be mentioned explicitly. Done. > - Some may think the following is a very minor issue, but I think it is very > confusing to use the term "Default I-PMSI A-D route" to refer to a route > that is not a "default route" and that is also not a route advertising a > "default I-PMSI". Fixed. > - The procedures of the draft do not appear to generalize easily to a > multi-level hierarchy. If this is a non-goal, that should be stated > explicitly. There are plenty of non-goals. It is an explicit non-goal of the draft to explicitly spell out all the non-goals. > > > > More comments appear in-line. responses in-line below.... > > > ... > > draft-ietf-l3vpn-virtual-hub-01.txt > > ... > > > Abstract > > With BGP/MPLS VPNs any-to-any connectivity among sites of a given > Virtual Private Network would require each Provider Edge router that > has one or more of these sites connected to it to hold all the routes > of that Virtual Private Network. The approach described in this > document allows to reduce the number of Provider Edge routers that > have to maintain all these routes by requiring only a subset of these > routers to maintain all these routes. > > Eric> As far as I can tell, the real purpose of this document is enable > Eric> "BGP/MPLS IP VPNs" to provide any-to-any connectivity by using a sort > Eric> of "hub and spoke" overlay. Only the hubs hold all the routes. > Eric> Spoke-to-spoke traffic is "default routed" from the source spoke to a > Eric> hub, where it is reforwarded to the destination spoke. I don't think > Eric> the above paragraph captures this very well. The "above paragraph" is in the Abstract section. As such, it need not go into the details. If you look at section 2, it does go into a bit more details and covers the points you mentioned above. > Furthermore, when Provider Edge routers use ingress replication to > carry multicast traffic of VPN customers, the approach described in > this document could allow to reduce bandwidth inefficiency associated > with ingress replication, and to redistribute the replication load > among Provider Edge routers. > > Eric> I find this quite misleading; whether bandwidth inefficiency is > Eric> reduced or increased depends upon the topology, and upon the location > Eric> of the receivers relative to the location of the source and of the > Eric> hubs. To address this, "could" is replaced with "may". > Eric> Also, it's not clear what is meant by "redistribute the > Eric> replication load", or why this is a good thing. The drat does not make any value judgement on whether redistributing the replication load "is a good thing". > ... > > 2. Overview > > With BGP/MPLS VPNs [rfc4364] providing any-to-any connectivity among > sites of a given Virtual Private Network (VPN) is usually > accomplished by requiring each Provider Edge router (PE) that has one > or more of these sites connected to it to hold all the routes of that > VPN. The approach described in this document allows to reduce the > number of PEs that have to maintain all these routes by requiring > only a subset of such PEs to maintain all these routes. > > Consider a VPN that has its sites connected to a set of PEs. In the > context of this VPN we designate a subset of these PEs as "Virtual > Spoke" PEs (or just Virtual Spokes), while some other (non- > overlapping) subset of these PEs will be "Virtual Hub" PEs (or just > Virtual Hubs), with the rest of the PEs in the set will be "vanilla" > PEs (PEs that implement the [rfc4364] procedures, but do not > implement procedures specified in this document). > > For the sake of brevity we will use the term "V-hub" to denote a > Virtual Hub, and "V-spoke" to denote a Virtual Spoke. > > For a given VPN, its set of V-hubs could include not only the PEs > that have sites of that VPN connected to them, but also PEs that have > no sites of that VPN connected to them. > > Eric> Two paragraphs before this, it says that a Virtual Hub or Spoke (of a > Eric> given VPN) is a subset of the set of PEs that are attached to the sites > Eric> of the VPN. So how can a V-hub be a PE that has no sites of the VPN > Eric> connected to it? Yes, a V-hub can be a PE that has no sites connected to it. The revised draft fixed this. > Eric> Perhaps what is meant is that a particular V-hub VRF, say VRF-1, for a > Eric> given VPN, may import routes from other V-hub and V-spoke VRFs of that > Eric> VPN, even if VRF-1 is not itself connected to a customer site. Correct. The revised draft fixes this. > Eric> However, this does contradict the second paragraph of this section. The revised draft fixes the second paragraph. > Note that while in the context of one VPN a given PE may act as a V- > hub, in the context of another VPN the same PE may act as a V-spoke, > and vice versa. Thus a given PE may act as a V-hub only for some, but > not all the VPNs present on that PE. Likewise, a given PE may act as > a V-spoke only for some, but not all the VPNs present on that PE. > > Eric> It might have been better to define "V-hub" and "V-spoke" to be types > Eric> of VRFs, rather than types of PEs. (Then one wouldn't run into the > Eric> awkwardness of having to say that a given PE is both a V-spoke PE and a > Eric> V-hub PE, depending on which VPN one is speaking of.) I am not sure that this would be better. > For a given VPN each V-spoke of that VPN is "associated" with two or > more V-hubs of that VPN (we use two V-hubs for redundancy to avoid a > single point of failure). Note that a given V-hub may have no V- > spokes associated with it. > > Eric> Shouldn't it be "one or more"? Presumably the procedures still work if > Eric> a given V-spoke is associated with only one V-hub. "Two or more" is > Eric> just a deployment recommendation. Correct. Fixed. > Eric> Consider the set of V-spokes that are associated with V-hub-1. Is it > Eric> allowable for some V-spokes in the set to be associated with V-hub-2 > Eric> (and NOT associated with V-hub-3), while others are associated with > Eric> V-hub-3 (and NOT associated with V-hub-2)? I think the draft should > Eric> answer this explicitly. Done. > A PE that acts as a V-hub of a given VPN maintains all the routes of > that VPN. > > Eric> By the way, this statement rules out the possibility of a multi-level > Eric> hierarchy, where a VRF serves as a hub to the lower layer and as a > Eric> spoke to the higher layer. Is this intentionally ruled out? Multi-level hierarchy is outside the scope. > A PE that acts as a V-spoke of a given VPN needs to > maintain only the routes originated by the sites of that VPN > connected to that PE, > > Eric> suggest "only the routes originated by" --> "only the routes of that > Eric> VPN that are originated by" Done. > > plus two or more VPN-IP default routes whose > > Eric> "one or more"? Done. > > Next Hops are the addresses of the V-hubs associated with that V- > spoke. > > Eric> An implication of this is that the V-hubs and associated V-spokes must > Eric> be in the same AS. Or at least that they are not separated by an ASBR > Eric> with an "option B" interconnect? Is that the intention? (I don't > Eric> think it is.) Yes. The revised text makes this explicit. > This way, only a subset of PEs that have sites of a given VPN, > namely only the PEs acting as V-hubs of that VPN, have to maintain > all the routes of that VPN. PEs acting as V-spokes of that VPN need > to maintain only a (small) subset of the routes of that VPN. > > When PEs use ingress replication to carry multicast traffic of VPN > customers, the approach described in this document could allow to > reduce bandwidth inefficiency associated with ingress replication, > and to redistribute the replication load among the PEs. This is > because a PE that acts as a V-spoke of a given VPN would need to > replicate multicast traffic only to other V-hubs (while other V-hubs > would replicate this traffic to the V-spokes associated with these V- > hubs), rather than to all the PEs of that VPN. Likewise, a PE that > acts as a V-hub of a given VPN would need to replicate multicast > traffic to other V-hubs, and the V-spokes, but only to the V-spokes > associated with that V-hub, rather than replicating the traffic to > all the PEs of that VPN. Limiting replication could be especially > beneficial if a PE that does the replication has limited replication > capabilities and/or has links with limited bandwidth. > > Eric> I think "if a PE that does the replication has limited replication > Eric> capabilities" is supposed to be "if the V-spoke PEs have limited > Eric> replication capabilities". Since the V-hubs do more replication rather > Eric> than less, this "advantage" doesn't exist if the V-hubs have limited > Eric> replication capabilities. I changes the text, as you suggested. > Eric> Also, consider the following case. There are 2 hubs and 10 spokes, > Eric> where each spoke is associated with both hubs. Multicast is done using > Eric> a I-PMSI or (C-*,C-*) S-PMSI. A source of (S,G) traffic is behind one > Eric> spoke, and each of the other spokes and each of the hubs has a receiver > Eric> for the (S,G) traffic. Some of the spokes have joined (S,G) via one > Eric> hub, some via the other. Now when the spoke attached to the source > Eric> gets an (S,G) packet from the customer site, it sends a replica to each > Eric> hub, and each hub sends a replica to each spoke. That's a total of 22 > Eric> replicas. If the spoke had done the replication itself, there would be > Eric> only 11 replicas. It's not obvious that this reduces any inefficiency. And that is precisely why the revised text said that it *may* reduce bandwidth inefficiency. > 3. Routing Information Exchange > > Routing information exchange among all the PEs of a given VPN is > subject to the following rules. > > Eric> It would be helpful to say which of the rules are normal RFC4364 rules, > Eric> and which are being introduced by this draft. Done. > A PE that has sites of a given VPN connected to it has to retain > routing information received from the VPN sites connected to it. > This is irrespective of whether this PE acts as a V-hub or a V-spoke > of that VPN. > > A PE that has sites of a given VPN connected to it has to export (as > VPN-IP routes) all the routes received from these sites. > > Eric> This isn't precisely true. It is often only the bestpaths that are > Eric> exported, not "all" the routes. And sometimes routes are filtered so > Eric> that they are not exported. The rules of which routes to export follows the 4364 rules. The latest draft makes this explicit. > This is > irrespective of whether this PE acts as a V-hub or a V-spoke of that > VPN. > > In addition, a V-hub of a given VPN has to export a VPN-IP default > > Eric> Should "has to" be "MUST"? Yes. Fixed. > Eric> Is it really required to export a VPN-IP default route? Wouldn't it be > Eric> sufficient to export a route that is a "summary route" of the VPN > Eric> customer's routes? (Assuming that such a summary route were known?) > Eric> Or a small set of summary routes? That should work, as long as the > Eric> label associated with the summary routes causes an IP lookup in the > Eric> VRF. This spec requires to export a VPN-IP default route. > route for that VPN. This route SHOULD be exported to only the V- > spokes of that VPN that are associated with that V-hub. > > Eric> If this is "SHOULD" rather than "MUST", it would be worthwhile to > Eric> discuss the downside of exporting the default route to the other > Eric> V-hubs. It should be "MUST". Fixed. > To enable a V-spoke of a given VPN to share its outbound traffic load > among the V-hubs associated with that V-spoke, each V-hub of that > VPN, when originating a VPN-IP default route MUST use a distinct RD > (per V-hub, per VPN). > > If a V-spoke imports several VPN-IP default routes, each originated > by its own V-hub, and these routes have the same preference, then > traffic from the V-spoke to other sites of that VPN would be load > shared among the V-hubs. > > A V-hub of a given VPN has to import all the non-default VPN-IP > routes originated by all other PEs that have sites of that VPN > connected to them (irrespective of whether these other PEs act as V- > hubs or V-spokes for that VPN). > > Eric> Also mention explicitly that a V-hub has to import all the non-default > Eric> routes from V-spokes that are not associated with that V-hub. Done. > A V-hub of a given VPN MUST NOT import a VPN-IP default route unless > this is the Internet VPN-IP default route (for the definition of > "Internet VPN-IP default route" see section "Internet Connectivity"). > > Eric> Section "Internet Connectivity" does not answer the obvious question > Eric> here, which is how does a V-hub know whether the VPN-IP default route > Eric> it is importing is the Internet VPN-IP default route or not. The new version answers this question in section "Internet Connectivity". > A V-spoke of a given VPN has to import a VPN-IP default route for > that VPN that has been originated by the V-hubs of that VPN that are > associated with that V-spoke. > > Eric> Suggest rewording to something like: "Within a given VPN, a V-spoke > Eric> MUST import all VPN-IP default routes that have been originated by the > Eric> V-hubs associated with that V-spoke". Done. > In addition, a V-spoke of a given VPN MAY import VPN-IP routes for > that VPN that have been originated by some other V-spokes of that > VPN. > > Eric> May a V-spoke import VPN-IP routes from V-hubs that it is not > Eric> "associated" with? May it import a VPN-IP route a V-spoke that is > Eric> associated with a different V-hub? Is the intention that a V-spoke MAY > Eric> import any routes whatsoever, or are there some restrictions preventing > Eric> a V-spoke from importing certain routes? The rules for export/import of VPN-IP routes are such that the only routes a V-spoke may import are (a) the default VPN-IP route originated by the V-hub(s) associated with the V-spoke, and (b) VPN-IP routes originated by the V-spokes that are associated with the same V-hub(s) as the V-spoke itself. I clarified this in the revised text. > The above rules that govern the routing information exchange among > all the PEs of a given VPN are realized using Route Target (RT) > extended communities [rfc4360] and VRF export/import policies based > on these RTs. One possible scheme that enables to realize such rules > is described in Section "Deployment Considerations". This document > does not preclude use of other schemes, as long as such schemes would > support the above rules. > > > 4. Forwarding Considerations > > This section describes changes/modifications to the forwarding > procedures specified in [rfc4364]. > > The MPLS label that the V-hub advertises with a VPN-IP default route > MUST be the label that points to the VRF of the V-hub. This way, > whenever the V-hub receives packets carrying this label, the V-hub > forwards the packets by performing IP lookup in the VRF identified by > the label. > > Eric> I think it is best to avoid phrases like "label that points to" or > Eric> "VRF identified by the label". Such phrases have been known to > Eric> mislead people into thinking that labels have to be implemented as > Eric> pointers or identifiers of some sort. I'd suggest saying something > Eric> like: (a) the label is mapped to an NHLFE that identifies a > Eric> particular VRF, and (b) when the label is popped, the packet's > Eric> destination address is looked up in the VRF, (c) further disposition > Eric> of the packet is the result of this lookup (as specified later in this > Eric> document). Done, as you suggested. > Eric> It should also be stated explicitly that "per-VRF labels" do NOT need > Eric> to be advertised for routes other than the default route. Done, as you asked. > When a V-hub of a given VPN originates a VPN-IP default route for > that VPN, the V-hub MUST NOT install in its VRF of that VPN a default > route, unless this route has been originated either (a) as a result > of the V-hub receiving an IP default route from one of the CEs of > that VPN connected to it, or (b) as a result of the V-hub receiving > (and importing) a VPN-IP default route from some other PE, or (c) the > VRF being provisioned with a default route pointing to the routing > table on the same PE that maintains the Internet routes. > > Eric> I'm a little confused by this. It seems to say that a V-hub that > Eric> originates an VPN-IP default route must not install a default route > Eric> (originated by someone else) unless that route is from a CE, or from > Eric> another PE, or else is a static route pointing to the global table. > Eric> What exactly is it that is NOT allowed? The only thing that seems > Eric> prohibited is a static route to another VRF. Is that the intention? Anything that is neither (a), nor (b), nor (c) is NOT allowed. > In the absence of V-hubs and V-spokes, support for IBGP/EBGP load > balancing in the presence of any-to-any connectivity uses the > following rule. > > Eric> Please include a reference to the RFC where this rule is given. > > When a PE receives a packet from another PE, the PE > that receives the packet determines (using the MPLS label carried in > the packet) the VRF that should be used for further forwarding the > packet. If (using the information present in the VRF) the PE > determines that the packet could be forwarded over one of the > attachment circuits of that VRF (for the definition of "VRF > attachment circuits" see [rfc4364]), then the PE MUST forward the > packet over one of these circuits, and MUST NOT forward the packet to > another PE. > > Eric> This is the existing rule for load balancing? To always forward the > Eric> traffic over a particular interface? That doesn't sound like load > Eric> balancing to me. Or do you really mean to say that IBGP/EBGP load > Eric> balancing is impossible according to the current L3VPN specs? If the > Eric> latter, please supply the reference. In the absence of V-hubs and V-spokes support for IBGP/EBGP load balancing is outside the scope of this draft. So, I removed the above text (as it is clearly outside the scope of the draft). > In order to support IBGP/EBGP load balancing on a V-hub the above > rule is modified as follows. When a V-hub receives a packet from > another PE scenario, the V-hub identifies (using the MPLS label > carried in the packet) the VRF that should be used for further > forwarding the packet. If the MPLS label carried in the packet is the > label that the V-hub advertised in the VPN-IP default route, then the > V-hub is not restricted to use only one of the VRF attachment > circuits for forwarding the packet - the V-hub may forward the packet > to another PE. > > Eric> If the V-hub may perform loadsharing by forwarding the packet to > Eric> another PE, how can we be sure that the other PE will not also perform > Eric> loadsharing and end up sending the packet back? Perhaps it should be > Eric> required the label bound to a non-default route be a label that does > Eric> NOT cause an IP lookup in the VRF. Or is it the intention that load > Eric> sharing only be done for data streams that area default routed? The latter. The new text spells this out. > To illustrate this consider the following example: > > <- RD:0/0 RD:0/0-> > > <- RD:10.2.1 <-10.2.1/24 > CE1----PE-S-------------PE-H----------------PE-S1-------------CE2 > / > | | > | | 10.2.1/24 > | | > CE4 CE3 > > A multi-homed site (not shown in the above figure) is connect via CE2 > and CE3. Thus both CE2 and and CE3 advertise a route to 10.2.1/24. > CE2 advertises this route to PE-S1, which in turn originates a VPN-IP > route RD:10.2.1. CE3 advertises this route to PE-H. > > Eric> I guess "this route" in the last sentence is supposed to refer to the > Eric> IP route to 10.2.1/24, but the wording makes it seem like it refers to > Eric> the VPN-IP route to RD:10.2.1. You are correct - "this route" refers to 10.2.1/24. Revised draft spells this out. > PE-H is a V-hub, while PE-S and PE-S1 are V-spokes associated with > that V-hub. Thus PE-H originates a VPN-IP default route (RD:0/0), and > both PE-S and PE-S1 import that route. > > PE-H receives from PE-S1 a VPN-IP route to RD:10.2.1 and from CE3 a > plain IP route to 10.2.1. Thus the VRF entry on PE-H has two possible > next hops for 10.2.1: CE3 and PE-S1 (the latter is an indirect next > hop). > > Eric> Not sure what "indirect next hop" means in this context. Means PE-S1 is not directly connected to PE-H. > Now consider what happens when CE1 originates a packet destined to > 10.2.1.1. When PE-S receives this packet, PE-S (following the VPN-IP > default route) forwards the packet to PE-H. In the absence of the > modification specified above, when PE-H receives this packet, PE-H > will be forced to forward the packet to CE3 (as PE-H can reach CE3 > via a VRF attachment circuit). However, that would prevent IBGP/EBGP > load balancing, as it would preclude the possibility of forwarding > this packet via PE-S1 and CE2. > > With the modified rule specified above, PE-H determines that the MPLS > label in the packet is the MPLS label that PE-H advertised to PE-S in > the VPN-IP default route. > > Eric> Perhaps replace this sentence with: "With the modified rule specified > Eric> above, the MPLS label in the packet is the label that PE-H advertised > Eric> to PE-S in the VPN-IP default route." After all, when the packet > Eric> arrives, PE-H just looks up the label and follows the instructions in > Eric> the NHLFE; it doesn't determine how the label was advertised. Done, as you suggested. > Thus PE-H may forward the packet either via > CE3 or via PE-S1 (with PE-S1 subsequently forwarding the packet to > CE2), resulting in preserving IBGP/EBGP load balancing. > > Likewise, if CE4 originates a packet destined to 10.2.1.1, PE-H may > forward the packet either via CE3 or via PE-S1 (with PE-S1 > subsequently forwarding the traffic to CE2), resulting in preserving > IBGP/EBGP load balancing. > > Note however, that if there is some other CE, CE5, connected to PE- > S1, and that CE5 sends a packet to 10.2.1.1, then (due to the IP > longest match rule) PE-S1 will always forward this packet to CE2. > Thus IBGP/EBGP load balancing will not be available for the > destinations that have been learned locally by a V-spoke. > > Moreover, if CE3 advertises 10.2.1.0/25 and 10.2.1/24, while CE2 > advertises 10.2.1.128/25 and 10.2.1/24 (which is yet another form of > load balancing for a multi-homed site), then when CE5 sends a packet > to 10.2.1.1, then (due to the IP longest match rule) PE-S1 will > always forward this packet to CE2, even though the VPN customer would > expect this traffic to flow via CE3. > > This document proposes two options to address this, as well as to > make the IBGP/EBGP load balancing available for the destinations that > have been learned locally by a V-spoke. One option is to provision > PEs that have multi-homed sites connected to them as V-hubs. > > Eric> An SP can certainly have the policy that multi-homed customer sites do > Eric> not get connected to V-spokes. However, it is not quite correct to say > Eric> that this policy "makes IBGP/EBGP load balancing available for the > Eric> destinations that have been learned locally by a V-spoke". Fixed. > Another > option is for the V-spoke, when it receives an IP route from a CE, > not to install this route in its forwarding table, but just re- > advertise this route as a VPN-IP route, together with an MPLS label. > The packet's next hop of the Next Hop Label Forwarding Entry (NHLFE) > [rfc3031] associated with that label MUST point to the CE that > advertised the IP route. > > Eric> Perhaps replace this last sentence with something like: "The NHLFE > Eric> associated with that label MUST specify that the CE that advertised the > Eric> IP route is the next hop". Done, as you suggested. > As a result, when the PE receives data that > carries that label, the PE performs no IP lookup on the data, and > just forwards the data to the CE. Note that doing this would result > in forcing the traffic between a pair of sites connected to the same > V-spoke to go through the V-hub of that V-spoke. > > Eric> This option does make "load balancing available for the destinations > Eric> that have been learned locally by a V-spoke", but the efficacy of the > Eric> load balancing seems questionable, as load due to traffic between the > Eric> two local sites is doubled. The load balancing refers to balancing the load on CE-PE links. Doubling the traffic has to do with the provider infrastructure. > 5. Internet Connectivity > > In this document we consider two possible scenarios of providing > Internet connectivity for a given VPN. > > The first scenario is when one or more sites of a given VPN are > connected to a PE, and that PE also maintains Internet routes. In > this case the Internet connectivity for that VPN is provided by > provisioning in the VPN's VRF on that PE a default route pointing to > the routing table on that PE that maintains the Internet routes. > > Eric> Shouldn't this say "MAY be provided" rather than "is provided"? Done, as you suggested. > This PE MUST act as a V-hub for that VPN, and therefore MUST > originate a VPN-IP default route. > > Eric> I think what this really should say is that if a PE is acting as a > Eric> V-spoke for a particular VPN, then one MUST NOT provision the VPN's VRF > Eric> on that PE with a default route pointing to the routing table that > Eric> maintains the Internet routes". As written, it suggests that doing > Eric> this provisioning will automatically change the PE from a V-spoke to a > Eric> V-hub. Done, as you suggested. > The second scenario is when a site of a given VPN has connection to > the Internet, and a CE of that site advertises an IP default route to > the PE connected to that CE. This scenario has two sub-cases: (a) PE > is provisioned as a V-hub, and (b) PE is provisioned as a V-spoke. > > If a PE is provisioned as a V-hub, then the PE re-advertises this IP > default route as a VPN-IP default route, > > Eric> If the PE is provisioned as a V-hub, it presumably has already > Eric> advertised a VPN-IP default route. Now it seems that it has to > Eric> advertise a new VPN-IP default route. Please state exactly how the > Eric> new route and the old route differ. The two routes differ in their RTs. The revised text spells this out. > and install in its VRF an IP > default route with the next hop pointing to the CE(s) that advertise > the IP default route to the PE. > > If a PE is provisioned as a V-spoke, then the PE MUST NOT install in > its VRF an IP default route. > > Eric> If the V-spoke PE does not install an IP default route in its VRF, how > Eric> is traffic from the spoke site going to get to the hub? Perhaps what > Eric> is meant is something like "receiving a default route from a CE does > Eric> not (or MUST NOT) cause a V-spoke to install a default route in its > Eric> VRF". You are correct. Done. > The PE MUST originate a VPN-IP default > route with a (non-null) MPLS label. The packet's next hop of the Next > Hop Label Forwarding Entry (NHLFE) [rfc3031] associated with that > label MUST point to the CE that advertises the IP default route. As a > > Eric> I'd say that the next hop of the NHLFE "must be the CE" or "must > Eric> specify the CE", rather than "must point to the CE". Done, as you suggested. > result, when the PE receives data that carries that label, the PE > performs no IP lookup on the data, and just forwards the data to the > CE. Note that in this case the VRF on the PE is going to have an IP > default route, but this route would be created as a result of > receiving a VPN-IP default route from one of the V-hubs of that PE > (and not as a result of receiving the IP default route from the CE). > Note also that if this PE has other sites of that VPN connected to > it, then traffic from these sites to the Internet would go to that > PE, then to the V-hub selected by the PE, then from that V-hub back > to the PE, and then to the CE that advertises IP default route to the > PE. > > Eric> Would this ever be considered to be a desirable traffic pattern? If a > Eric> customer gets his internet access via a gateway at a particular site, > Eric> perhaps it's not a very good idea to attach that site to a V-spoke. Whether this is "a desirable traffic pattern", or whether "it's not a very good idea" is outside the scope of the draft. > If a PE is provisioned as a V-spoke of a given VPN, and if a CE of > that VPN advertises an IP default route to the PE (as the CE belongs > to the site that provides the Internet connectivity for the VPN), > then the PE can not advertise an IP default route back to that CE. > Yet, the CE has to point to the PE as the next hop for all the > traffic to other sites of that VPN. This document proposes the > following options to accomplish this. The first option is to require > the V-spoke to implement procedures of section "Further refinements". > > Eric> Well, here's what it says in "further refinements": > > install in the V-spoke's data plane only the default route > (following the Virtual Hub and Spoke model, as described above), > > Eric> I think this means "install only the default route advertised by the > Eric> V-hub, not the default route advertised by the CE". But the draft > Eric> really needs to make this clear. (I think this also contradicts the Done. > Eric> previous statement that the V-spoke does not install an IP default > Eric> route in its VRF; but perhaps it's just not clear what "install in the > Eric> V-spoke's data plane" means.) > > but keep all the VPN-IP routes in the V-spoke's control plane > (and thus being able to advertise these routes from the V-spoke > to the CEs). > > Eric> If the V-spoke can hold all these control plane routes, why is it a > Eric> V-spoke and not a V-hub (or a "vanilla" PE)? Because the V-spoke need not hold these routes in its FIB. > The second option is for the V-spoke to advertise to the CE 10/8, > 172.16/12, and 192.168/16. Note that this option is applicable only > if the service provider knows that the VPN customer uses only the > [rfc1918] addresses. > > Eric> If it's known that the customer only uses RFC 1918 addresses, one can > Eric> have the V-hubs advertise VPN-IP routes 10/8, 172.16/12, and > Eric> 192.168/16, with per-VRF labels, instead of having them advertise > Eric> a VPN-IP default. Then you wouldn't need any special configuration on > Eric> the V-spokes, and you wouldn't have to worry about having an IP default > Eric> route in the V-spoke VRF. > > Eric> But I don't really see why it's important that the addresses be RFC1918 > Eric> addresses. If the SP knows the addresses used by the customer, and if > Eric> these addresses can be summarized by a small number of routes, it > Eric> doesn't make any difference whether the customer is using RFC1918 > Eric> addresses or not. Assuming that the SP has to know the addresses used by a customer may not be practical. This is irrespective of whether the customer is using rfc1918 addresses or not. So, the second option is deleted from the draft. > The third option is to re-provision this PE as a V-hub. > > Eric> There are supposed to be three options to allow a PE provisioned as a > Eric> V-spoke to be connected to the customer site that provides Internet > Eric> connectivity for the customer. This third option does not accomplish > Eric> its goal, since a PE provisioned as a V-hub is not a PE provisioned as > Eric> a V-spoke. That is correct. The revised text fixes this. > In all of the above we refer to the originated VPN-IP default route > as the "Internet VPN-IP default route". > > Eric> It is not clear what "all of the above" refers to. I think it would > Eric> be clearer to say that an "Internet VPN-IP default route" is a VPN-IP > Eric> default route, advertised by a V-hub or V-spoke, but originated by a > Eric> CE attached to that V-hub or V-spoke. Done. > Eric> Unless that's not correct, in > Eric> which case I think a clearer definition would be helpful. > Note that if a V-hub originates the Internet VPN-IP default route for > a given VPN, the V-hub does not originate any other VPN-IP default > routes for that VPN. > > Eric> Probably the V-hub has already originated such a route; this case > Eric> should be addressed explicitly. Done. > If a V-hub originates the Internet VPN-IP default route, then all the > V-spokes associated with that V-hub MUST import that route. In > addition (and in contrast with a non-Internet VPN-IP default route), > other V-hubs MAY import that route. > > Eric> But the draft hasn't said (at least not yet) how PEs other than the > Eric> originator can determine whether a VPN-IP default route is the > Eric> Internet VPN-IP default route or not! Something to do with RTs, I > Eric> guess. You guessed correctly. The revised text clarifies this. > > A V-hub MAY also import the Internet VPN-IP default routes originated > by V-spoke(s). > > A V-spoke MUST NOT import the Internet VPN-IP default route > originated by any other V-spoke. Such a route MAY be imported only by > V-hubs. > > The above rules that govern exchange of the Internet VPN-IP default > route among all the PEs of a given VPN are realized using Route > Target (RT) extended communities [rfc4360] and VRF export/import > policies based on these RTs. One possible scheme that enables to > realize such rules is described in Section "Deployment > Considerations". This document does not preclude use of other > schemes, as long as such schemes would support the above rules. > > Eric> It seems to me that one of the necessary rules is that each VRF is > Eric> provisioned to know which RTs are carried by the Internet Default > Eric> VPN-IP route but not by the non-Internet Default VPN-IP route. > Eric> However, this rule is not mentioned anywhere in the draft. The revised text fixes this. > If the Internet VPN-IP default route originated by a V-hub has the > same preference as the (non Internet) VPN-IP default route originated > by some other V-hub, then a V-spoke that imports VPN-IP default > routes originated by both of these V-hubs would load share the > outgoing Internet traffic between these two V-hubs (and thus some of > the outgoing Internet traffic from that V-spoke will first be routed > to the V-hub that does not originate the Internet VPN-IP default > route, and then from that V-hub to the V-hub that does originate the > Internet VPN-IP default route). > > If taking an extra-hub hop for the Internet traffic is viewed as > undesirable, > > Eric> It's hard to imagine that this would ever be desirable, especially > Eric> since the "extra-hub hop" could cause the path to the Internet to be > Eric> arbitrarily lengthened. Whether "it's hard to imagine that this would ever be desirable" is outside the scope of the draft. > then it is RECOMMENDED that the Internet VPN-IP default > route be of higher preference than a (non-Internet) VPN-IP default > route originated by some other V-hub. > > Eric> If the only way to tell whether a VPN-IP default route is Internet or > Eric> non-Internet is by looking at its route targets, following this > Eric> recommendation is going to require a very complicated set of policies > Eric> to be implemented, in order to handle all the various special cases > Eric> (e.g., the non-Internet default route is in the local AS, but the > Eric> Internet default route, which is to be preferable, is several ASes > Eric> away). I have to wonder whether this is a realistic recommendation. Whether this is "a realistic recommendation" is outside the scope of the draft. > However, in this case the > traffic from the V-spokes to other sites of that VPN will not be load > balanced. > > 6. Deployment Considerations > > For a given VPN a V-hub and a set of V-spokes associated with that V- > hub should be chosen in a way that minimizes the additional network > distance/latency penalty, given that VPN geographic footprint. > > For a given VPN some/all of its V-spokes could be grouped into > geographically-based clusters with any-any connectivity within each > cluster. Note that the V-spokes within a given cluster need not be > associated with the same V-hub(s). Likewise, not all V-spokes > associated with a given V-hub need to be in the same cluster. A use > case for this would be VPN for large retail chain in which data > traffic is hub/spoke between each store and centralized data-centers > but there is need for direct VoIP traffic between stores within same > geographical area. > > Eric> I don't understand what it means to group a set of V-spokes into a > Eric> geographically-based cluster. That is, what do you have to do exactly > Eric> in order to do this "grouping"? It means that the V-spokes are within the same geographical region. The revised text makes this explicit. > The following describes one possible scheme that enables to realize > the rules for exchanging routing information among PEs, as specified > in Section "Routing Information Exchange". > > Consider a "vanilla" any-to-any VPN. All the PEs of such VPN are > provisioned with the same export and import RT - we will refer to > this RT as RT-VPN. > > To evolve this VPN into V-hubs and V-spokes we keep the same export > RT-VPN on all the PEs of that VPN (both V-hubs and V-spokes). This > RT-VPN is attached to all the VPN-IP routes that PEs originate as a > result of receiving corresponding IP routes from their CEs. We also > keep the same import RT-VPN on all the V-hubs. > > In addition, each V-hub is provisioned with its own import RT, called There is a bug here - it should be "its own export RT", not "its own import RT". > RT-VH. This RT-VH MUST be different from the export RT provisioned > on that V-hub. For a given PE this RT-VH has to be distinct for every > V-hub present on that PE. To avoid the situation where within a given > VPN all the V-spokes would be associated with every V-hub (in other > words, to partition V-spokes among V-hubs), different V-hubs within > that VPN MAY use different RT-VHs. At one extreme every V-hub may use > a distinct RT-VH. However, it is also possible for several V-hubs to > use the same RT-VH, in which case all these V-hubs are used by the > same set of V-spokes. Use of IP-address specific RTs may be an > attractive option for RT-VHs. > > Eric> If several V-hubs are to use the same RT-VH, then I don't see what is > Eric> attractive about the use of IP-address specific RTs. The revised text clarifies that the use of IP-address specific RTs may be an attractive option when every V-hub uses a distinct RT-VH. > When a V-hub originates a (non-Internet) VPN-IP default route, then > the V-hub attaches RT-VH to that route. Thus this route is imported > by all the V-spokes associated with the V-hub. > > > If a V-hub originates the Internet VPN-IP default route, then the V- > hub attaches both RT-VH and RT-VPN to that route. Thus this route is > imported by all the V-spokes associated with the V-hub, as well as by > other V-hubs. > > If a V-spoke originates the Internet VPN-IP default route, then the > V-spoke attaches only RT-VPN to that route. Thus this route is not > imported by any of the V-spokes, but is imported by V-hubs. > > A given V-spoke is provisioned to import only VPN-IP routes that > carry RT-VHs of the V-hubs associated with that V-spoke (thus > associating a new V-spoke with a given V-hub requires provisioning > only on that V-spoke - no provisioning changes are required on the V- > hub). > > A V-spoke may be provisioned to export VPN-IP routes not just to the > V-hubs, but also to the V-spokes that import the same VPN-IP default > route(s) as the V-spoke itself. The V-spoke accomplishes this by > adding its import RT-VH(s) to the VPN-IP routes exported by the V- > spoke. > > Use of RT Constrains [rfc4684] may further facilitate/optimize > routing exchange in support of V-hubs and V-spokes. > > Eric> The section on Internet Connectivity mentions several situations in > Eric> which a V-hub must know whether a default VPN-IP route it is receiving > Eric> is an Internet default VPN-IP route or not. > Eric> If the VPNs are set up > Eric> according to the deployment considerations of this section, how does a > Eric> V-hub make this determination? Does each V-hub VRF have to be > Eric> explicitly configured to know that any VPN-IP default route carrying a > Eric> particular set of RTs (or all of a particular set, or some of a > Eric> particular set) is the Internet default route? Yes. > Eric> If so, this is not > Eric> simply a "deployment consideration", it is an essential part of the > Eric> V-hub/V-spoke architecture, and should be called out explicitly. Done, as you requested. > > > > > 7. Multicast Considerations > > This section describes procedures for supporting MVPN in the presence > of Virtual Hub-and-Spoke. The procedures rely on MVPN specifications > as defined in [MVPN], [BGP-MVPN]. > > The procedures assume that for the purpose of ensuring non- > duplication both V-hubs and V-spokes can discard packets from a > "wrong" PE, as specified in [MVPN]. This applies for all types of P- > tunnels, including Ingress Replication. > > > 7.1. Terminology > > When Ingress Replication is used to realize P-tunnels, a P-tunnel > being "bound" to a particular I-PMSI/S-PMSI A-D route means the set > of (unicast) tunnels used to carry traffic from the PE originating > the route to the PEs that import the route. > > When Ingress Replication is used to realize P-tunnels, traffic > received by a PE on a P-tunnel "bound" to particular I-PMSI/S-PMSI A- > D received by the PE means the traffic received on the (unicast) > tunnel that the PE originating the route uses to send traffic to the > PE that receives the route. > > Eric> These sentences are difficult to parse. Suggest something like: > We will speak of a P-tunnel being "bound" to a particular > I-PMSI/S-PMSI A-D route if the P-tunnel is specified in that route's > PMSI Tunnel Attribute. > > When Ingress Replication is used, the P-tunnel bound to a particular > I-PMSI/S-PMSI A-D route is actually a set of unicast tunnels. The PE > originating the route uses these unicast tunnels to carry traffic to > the PEs that import the route. When we say that traffic has been > received by a PE on a P-tunnel "bound" to particular I-PMSI/S-PMSI A- > D route received by that PE, we refer to the unicast tunnel that the > PE originating the route uses to send traffic to the PE that receives > the route. Done, as you suggested. > 7.2. Eligible Upstream Multicast Hop (UMH) routes > > On a V-spoke the set of Eligible UMH routes consists of all the > unicast VPN-IP routes received by the V-spoke, including the default > VPN-IP routes received from its V-hub(s). Note that such routes may > include VPN-IP routes received from other V-spokes. > > Eric> This rules out the use of SAFI-129 routes for UMH determination. > Eric> Probably that is not the intention. You are correct - this is not the intention. The revised text spells this out. > 7.3. Originating VPN-IP default route by a V-hub > > A V-hub, when originating a VPN-IP default route, follows the > procedures of [BGP-MVPN]. > > Eric> You might refer more specifically to Sections 6 and 7 of [BGP-MVPN]. A > Eric> reference to Section 5.1 of [MVPN] might also be helpful. Done. > > Specifically the V-hub must add the VRF > Route Import extended community that embeds the V-hub's IP address. > The route also must include the Source AS extended community. > > > 7.4. Handling C-multicast routes > > Origination of C-multicast routes follow the procedures of [BGP-MVPN] > (this is irrespective of whether these routes are originated by a V- > hub or by a V-spoke). Note that for a given V-spoke its set of > eligible UMH routes may contains not only the VPN-IP default routes > advertised by its V-hubs, but also VPN-IP routes advertised by some > other V-spokes. > > Eric> Also, I think both Internet VPN-IP default routes and non-Internet > Eric> VPN-IP default routes are UMH-eligible; this would be worth pointing > Eric> out. I fixed this in 7.2 of the latest draft. > Eric> It's worth pointing out explicitly that in a V-spoke, no matter what > Eric> the multicast source is, the matching UMH-eligible route is probably > Eric> going to be the VPN-IP default route from one of the V-spoke's > Eric> associated V-hubs. This means that the V-spoke is likely to see the > Eric> V-hub as the "upstream PE" for the multicast source. That is not always the case, as a V-spoke may receive UMH-eligible routes from other V-spokes, in which case the V-hub will *not* be the upstream PE for the multicast sources connected to these V-spokes. > When a V-hub receives a C-multicast route, the V-hub determines > whether the C-RP/C-S of the route is reachable via one of its VRF > interfaces, and if yes, then the V-hub follows the [BGP-MVPN] > procedures. Otherwise, the C-RP/C-S of the route is reachable via > some other PE, in which case the V-hub uses the type (Source Tree > Join vs Shared Tree Join), the Multicast Source, and Multicast Group > from the received route to construct a new route. > > Eric> suggest "construct a new route" --> "construct a new route of the same > Eric> type, with the same Multicast Source and Multicast Group" Done, as you suggested. > Eric> I'd point out explicitly that this is the case where a V-spoke sees the > Eric> V-hub as the "upstream PE" for a given source, but the V-hub sees some > Eric> other PE (either V-hub or V-spoke) as the "upstream PE". Done. > > The hub constructs > the rest of the new route following procedures specified in "11.1.3. > Constructing the rest of the C-multicast route" of [BGP-MVPN]. The > hub also creates the appropriate (C-*, C-G)/(C-S, C-G) state in its > MVPN-TIB. > > > 7.5. Originating I-PMSI/S-PMSI/SA A-D routes by V-spoke > > When a V-spoke originates an I-PMSI/S-PMSI/SA A-D route, the V-spoke > follows the procedures of [BGP-MVPN], including the procedures for > constructing RT(s) carried by the route. Note that as a result, such > a route will be imported by the V-hubs. The P-tunnel bound to this > route is used to carry to these V-hubs traffic originated by the > sites connected to the V-spoke. > > Eric> The above paragraph suggests, incorrectly, that an SA A-D route > Eric> identifies a P-tunnel The revised text clarifies this. > > This route may also be imported by some other V-spokes - the V-spokes > that import the (unicast) VPN-IP routes originated by the V-spoke > that originates the I-PMSI/S-PMSI/SA A-D route. In this case the > route would carry not one, but two RTs: the first one results in > importing the route by V-hubs, the second results in importing the > route by the V-spokes (the second RT is the RT that V-spoke use for > importing the VPN-IP default route). In this case the P-tunnel bound > to this route is also used to carry traffic originated by the sites > connected to the V-spoke that originates the route to these other V- > spokes. > > Eric> With regard to "not one, but two RTs", is there anything in this draft > Eric> that limits the number of RTs to two? No. Fixed. > 7.6. Originating I-PMSI/S-PMSI/SA A-D routes by V-hub > > When a V-hub originates an I-PMSI/S-PMSI/SA A-D route, the V-hub > follows the procedures of [BGP-MVPN], except that in addition to the > RT(s) constructed following these procedures, the route also carries > the RT of the VPN-IP default route advertised by the V-hub. Note > that as a result, such a route will be imported by other V-hubs, and > also by the V-spokes, but only by the V-spokes that import the VPN-IP > default route originated by the V-hub. > > Eric> It might be clearer to say "only by the V-spokes that are associated > Eric> with that V-hub". Done. > > The P-tunnel bound to this > route is used to carry to these other V-hubs and V-spokes the traffic > originated by the sites connected to the V-hub that originates the > route. > > In addition, a V-hub originates another I-PMSI A-D route - we'll > refer to this route as a "Default I-PMSI A-D route". > > Eric> I find this use of the word "Default" to be very confusing, as the > Eric> "Default I-PMSI A-D route" is not a "default route", nor is it a route > Eric> advertising a "default I-PMSI". This I-PMSI A-D route only goes to > Eric> the V-hubs associated V-spokes, it might be less confusing to call it > Eric> the "Associated-V-spoke-only I-PMSI A-D route" or something like that. > Eric> (If the set of V-spokes associated with a given V-hub had a name, > Eric> e.g., "V-spoke cluster", this could be called an "Intra-cluster I-PMSI > Eric> A-D route", or a "cluster-specific I-PMSI A-D route", which would be > Eric> clearer.) The revised draft uses the term "Associated V-spoke-only I-PMSI A-D route". > The RT carried > by this route is the RT that is carried in the VPN-IP default route > advertised by the V-hub (RT-VH). Therefore, this route will be > imported only by the V-spokes that import the VPN-IP default route > advertised by this V-hub. The P-tunnel bound to this route is used to > carry to these V-spokes traffic originated by either (a) other V- > hubs, or (b) V-spokes, including the V-spokes that import the VPN-IP > default route from the V-hub. More details on the use of this P- > tunnel is described later. > > As a result, a V-hub originates not one, but two I-PMSI A-D routes. > Each of these routes MUST have a distinct RD. > > When a V-hub receives traffic from one of the sites connected to the > V-hub, and the V-hub determines (using some local policies) that this > traffic should be transmitted using an I-PMSI, the V-hub forwards > this traffic on the P-tunnel bound to the first (non Default) I-PMSI > A-D route, but not on the P-tunnel bound to the second, the Default > I-PMSI A-D route. > > Eric> The use of the terms "first" and "second" above is confusing, as it is > Eric> not clear what ordering is being referred to. Done. > > 7.7. Receiving I-PMSI/S-PMSI/SA A-D routes by V-spoke > > When a V-spoke receives an I-PMSI/S-PMSI/SA A-D route, the V-spoke > follows the procedures of [BGP-MVPN]. As a result, a V-spoke that > imports the VPN-IP default route originated by a given V-hub will > also import I-PMSI/S-PMSI/SA A-D routes originated by that V-hub. > Specifically, the V-spoke will import both the non Default I-PMSI A-D > route and the Default I-PMSI A-D route originated by the V-hub. > > In addition, if a V-spoke imports the (unicast) VPN-IP routes > originated by some other V-spokes, then the V-spoke will also import > I-PMSI/S-PMSI/SA A-D routes originated by these other V-spokes. > > > 7.8. Receiving I-PMSI/S-PMSI/SA A-D routes by V-hub > > The following describe procedures that a V-hub must follow when it > receives an I-PMSI/S-PMSI/SA A-D route. > > > 7.8.1. Case 1 > > This is the case where the received I-PMSI/S-PMSI/SA A-D route was > originated by a V-spoke that imports the VPN-IP default route originated > by the V-hub, and the received route is imported not just by the V-hub > (as well as by all other V-hubs), but also by other V-spokes, but only > by the V-spokes that import the VPN-IP default route originated by the > V-hub. > > Eric> It's kind of hard to parse this sentence. Does this mean that the > Eric> route was originated by one of the V-hub's associated V-spokes. Correct. > Eric> How does the V-hub know that? By examining the RT(s) carried in the route. > Eric> Does this also mean that the route is > Eric> imported by all the V-spokes associated with the V-hub? How does the > Eric> V-hub know that? Yes. The V-hub knows that by examining the RT(s) carried in the route. > This is also the case where the received route was originated by > a V-hub that uses the same RT as the received V-hub for advertising the > > Eric> "received" --> "receiving" Done. > > VPN-IP default route. > > > Eric> So the traffic transmitted in the P-tunnel bound to this route must be > Eric> traffic from a V-spoke site, right? It could be either from a V-spoke site, or from a V-hub site. > Eric> Other V-spokes associated with the > Eric> same hub may thus receive traffic directly from the originating > Eric> V-spoke, and all V-hubs (associated with the originating V-spoke or > Eric> not) receive traffic directly from the originating V-spoke. Presumably > Eric> a V-hub, say V-hub2, that is not associated with the originating > Eric> V-spoke, will need to reforward traffic from the originating V-spoke to > Eric> the V-spokes with which it (V-hub2) is associated. The case where V-hub2 has to reforward traffic is covered in Case 2. > In this case the received I-PMSI/S-PMSI/SA A-D route carries more > than one RT. One of these RTs results in importing this route by the > V-hubs. Another of these RTs is the RT that the V-hub uses when > advertising its VPN-IP default route (RT-VH). > > Eric> RT-VH is only mentioned in the "deployment considerations" section, > Eric> and setting up the RTs as described in that section is not mandatory. > Eric> The rules in this section have to be specified in a way that doesn't > Eric> presuppose on those deployment considerations. The revised text fixes this. > This RT results in > importing the received I-PMSI/S-PMSI/SA A-D route o all the V-spokes > that import the VPN-IP default route originated by the V-hub. > > Eric> Since the V-hub has particular procedures to execute in this case, it > Eric> would be nice to say exactly how the V-hub knows that a particular > Eric> received A-D route is a "case 1" route. Previous text suggests that > Eric> the only difference between the RT-VH and other RTs is the way the > Eric> RT-VH is configured to be an import or export RT of a particular set of > Eric> VRFs. But this text suggests that the V-hub has to know which of its > Eric> import RTs is the RT-VH. Fixed. > In handling such I-PMSI/S-PMSI/SA A-D route the V-hub follows the > [BGP-MVPN] procedures. Specifically, in contrast to Case 2 below, the > V-hub MUST NOT re-advertise this route. > > Eric> Is the paragraph below meant to be a summary of what it means to > Eric> "follow the [BGP-MVPN] procedures? Or is it intended to specify some > Eric> new procedure? I think the former, but that should be clarified. The > Eric> [BGP-MVPN] procedure is that traffic traffic received from a P-tunnel > Eric> does not get re-forwarded onto another P-tunnel, right? The "procedures" in the above talk about handling I-PMSI/S-PMSI/SA A-D *routes*. The text is fairly explicit on that. The above text does not talk about handling traffic received in P-tunnels. The following paragraph covers this. > The V-hub may forward traffic received on a P-tunnel bound to this I- > PMSI/S-PMSI A-D route to only the sites connected to that V-hub. The > V-hub MUST NOT forward the traffic received on this P-tunnel to any > other V-hubs or V-spokes, including the V-spokes that import the VPN- > IP default route originated by the V-hub. Specifically, the V-hub > MUST NOT forward the traffic received on the P-tunnel advertised in > the received I-PMSI A-D route over the P-tunnel that the V-hub binds > to its Default I-PMSI A-D route. > > > 7.8.2. Case 2 > > This is the case where the received I-PMSI/S-PMSI/SA A-D route was > originated by either some other V-hub, or by a V-spoke. The I-PMSI/S- > PMSI/SA A-D route is imported by the V-hub (as well as by other V- > hubs), but not by any of the V-spokes that import the VPN-IP default > route originated by the V-hub. > > Eric> How does the V-hub know that the A-D route is not imported by any of > Eric> "the V-spokes that import the VPN-IP default route originated by the > Eric> V-hub"? This rule should be specified in terms of the RTs carried by > Eric> the route, not in terms of what other PEs may or may not be doing. See second paragraph in 7.8.2. I moved this paragraph up. > Eric> BTW, I'd suggest using a term like "the V-spokes associated with the > Eric> V-hub" instead of "the V-spokes that import the VPN-IP default > Eric> route originated by the V-hub" I added this clarification. > In this case the received I-PMSI/S-PMSI/SA A-D route does not carry > the RT that the receiving V-hub uses when advertising its VPN-IP > default route (RT-VH), although the route may carry more than one RT. > > Eric> Again, I think there should be a clear statement of how a V-hub knows, > Eric> by inspection of the RTs, when a received A-D route is a "case 2" > Eric> route. Done, as you requested. > In this case the V-hubs follows the procedures of [BGP-MVPN] with the > following additions. > > Once a V-hub accepts an I-PMSI A-D route, when the V-hub receives > data on the P-tunnel bound to that I-PMSI A-D route, the V-hub > follows procedures in [MVPN], [MVPN-BGP] to determine whether to > accept the data. If the data is accepted, then the V-hub further > forwards the data over the P-tunnel bound to the Default I-PMSI A-D > route originated by the V-hub. > > Eric> This seems to rule out the possibility of a V-hub using an "S-PMSI > Eric> only" model between a V-hub and its associated V-spokes, unless an > Eric> "S-PMSI only" model is used uniformly throughout the MVPN. Is this the > Eric> intention? If so, it should be stated explicitly. Please note that (by definition) the "S-PMSI only" model assumes that no PEs use I-PMSI - quoting from rfc6625: ..."S-PMSI only" model, where no I-PMSIs are used at all for the given MVPN. >From that definition it follows that for a given MVPN one can not have "S-PMSI only" model if at least some of the PEs of that VPN use I-PMSIs. Thus if a V-hub accepts an I-PMSI A-D route (which is the scenario described in the paragraph), then we can not have the "S-PMSI only" model. The fact that an "S-PMSI only" model has to be used uniformly throughout the MVPN is due to the definition of this model made in rfc6625. However, your comment reminded me to cover the case of wildcard S-PMSIs. The revised text does this. > Note that in deciding whether to > forward the data over the P-tunnel bound to the Default I-PMSI A-D > route originated by the V-hub, the V-hub SHOULD take into account the > (multicast) state present in its MVPN-TIB that has been created as a > result receiving C-multicast routes from the V-spokes associated with > the V-hub. > > Eric> Certainly the V-hub should take its multicast forwarding state into > Eric> account when it does multicast forwarding ;-) Is something more > Eric> specific intended here? The revised text add a bit more. > Whenever a V-hub accepts an S-PMSI/SA A-D route, the V-hub, in > contrast to Case 1 above, MUST re-advertise this route to its V- > spokes. To accomplish this, the V-hub changes the RT carried by the > route to the RT that the V-hub uses when originating its VPN-IP > default route (RT-VH), > > Eric> What if the route is carrying multiple RTs? Which one gets changed? > Eric> What happens to the others? The one that results in importing the route by the V-hub. Others are unchanged. The revised text clarifies this. > and sets Next Hop to self. In addition, for S- > PMSI/SA A-D routes the V-hub changes the RD of the route to the RD > that the hub uses when originating its VPN-IP default route, and for > S-PMSI A-D routes the V-hub changes the Originating Router's IP > address in the MCAST-VPN NLRI of the route to its own IP address. > > Moreover, before re-advertising S-PMSI A-D routes to V-spokes, the V- > hub modifies the PMSI Tunnel attribute of these routes as appropriate > (e.g., by replacing the P-tunnel rooted at the originator of these > routes with a P-tunnel rooted at the V-hub). > > Whenever the V-hub receives data on the P-tunnel bound to the > received S-PMSI A-D route, the V-hub follows procedures of [MVPN], > [MVPN-BGP] to determine whether to accept the data. If the data is > accepted, then the V-hub further forwards it over the P-tunnel bound > to the S-PMSI A-D route that has been re-advertised by the V-hub. > > Eric> At this point, there have been a lot of details, but still no > Eric> statement of the what the data path for multicast traffic is supposed > Eric> to be. By reverse engineering the procedures, I conclude that the > Eric> intention is to do the following (please correct me if I am wrong). > Eric> Suppose V-spoke1 is associated with V-hub1, but not with V-hub2. > Eric> Suppose V-spoke2 is associated with V-hub2, but not with V-hub1. > Eric> Suppose there is a receiver, R, for (S,G) traffic, at a site attached > Eric> to V-spoke1. And suppose that S is at a site attached either to > Eric> V-spoke2 or to V-hub2. Now V-spoke1 will think the upstream PE for S > Eric> is V-hub1. So V-spoke1 joins (S,G) via V-hub1, and V-hub1 then joins > Eric> (S,G) via V-spoke2 or V-hub2. The data path of the (S,G) traffic that > Eric> goes to R will be S-->V-hub2/V-spoke2-->V-hub1-->V-spoke1-->R. > > Eric> I.e., it's like real multicast, with V-hub1 as an intermediate hop. > > Eric> I understand why V-spoke1 does not communicate in the control plane > Eric> with V-spoke2 or V-hub2. But I don't really understand the point of > Eric> using V-hub1 as a intermediate hop in the data plane. For unicast > Eric> traffic from a V-spoke, the associated V-hub needs to be an > Eric> intermediate hop, because it needs to do an IP lookup in its VRF. For > Eric> multicast traffic, no IP lookup is done, and thus there is really no > Eric> need to pass the data traffic through the associated V-hub. > > Eric> Let's consider the case where the source is at a site attached to > Eric> V-hub2. V-hub1 will receive an S-PMSI A-D route matching (S,G) from > Eric> V-hub2. V-hub1 then modifies this A-D route and forwards it to > Eric> V-spoke1. V-hub1 could use this route to identify the P-tunnel > Eric> originating at V-hub2, thereby instructing V-spoke1 to join V-hub2's > Eric> tunnel directly. Then V-hub1 would not be in the data path from S to > Eric> R, but it would participate in the control plane. Wouldn't this meet > Eric> all the requirements of the V-hub/V-spoke architecture, while producing > Eric> a more optimal path for multicast data, and eliminating the need to > Eric> have the V-hubs splice together any P-tunnels? > > Eric> Was any consideration given to such an alternative? Please note that the procedures specified in the draft assume the ability to perform sender-based RPF, as specified in 9.1.1 of rfc6513. Given that, if one would follow what you outlined above, could you point me to the specific text in 9.1.1 of rfc6513 that would enable V-spoke1 to determine that from its own perspective the UMH for (C-S, C-G) is V-hub1 ? Furthermore, your outline above talks about S-PMSI A-D route. How would it work for I-PMSI A-D routes ? > Eric> On another topic, this section should explicitly address any issues > Eric> that might arise if there are AS boundaries (or, if "seamless mpls' is > Eric> being used, area boundaries) between the hubs and spokes, or between > Eric> different hubs. It shouldn't be left as an exercise to the reader to > Eric> figure out whether the procedures work unchanged in those casees. As I mentioned before, the latest draft limits its scope to the case where a given V-hub and all of the V-spokes associated with the V-hub are in the same AS. > If multiple S-PMSIs received by the V-hub have been aggregated into > the same P-tunnel, then the V-hub, prior to forwarding to the V- > spokes the data received on this P-tunnel may de-aggregate and then > re-aggregate (in a different way) this data using the state present > in its MVPN-TIB that has been created as a result of receiving C- > multicast routes from the V-spokes. Even if S-PMSIs received by the > V-hub each has its own P-tunnel, the V-hub, prior to forwarding to > the V-spokes the data received on these P-tunnels may aggregate these > S-PMSIs using the state present in its MVPN-TIB that has been created > as a result of receiving C-multicast routes from the V-spokes. > > > > 7.9. Use of Ingress Replication with I-PMSI A-D routes > > The existing procedures for S-PMSI A-D routes are sufficient to > discard packets coming from a "wrong" PE for any type of P-tunnels, > including Ingress Replication. > > The following modifications to originating/receiving I-PMSI A-D > routes enable to discard packets coming from a "wrong" PE when > Ingress Replication is used for I-PMSI P-tunnels (for other types of > P-tunnels the procedures specified in [MVPN], [BGP-MVPN] are > sufficient). > > If Ingress Replication is used with I-PMSI A-D routes, then when a PE > advertises such routes, the Tunnel Type in the PMSI Tunnel attribute > is set to Ingress Replication; the Leaf Information Required flag is > set to 1; the the attribute carries no MPLS labels. > > Eric> I believe this is incompatible with RFC 6514, which prohibits the > Eric> setting of the Leaf Information Required flag in I-PMSI A-D routes. > Eric> This violates RFC 6514, which prohibits the setting fo the LIR flag in > Eric> I-PMSI A-D routes. > > Eric> I do not see that it makes any sense to allow the LIR flag to be used > Eric> in I-PMSI A-D routes for the V-hub/V-spoke architecture, while > Eric> disallowing it otherwise. I'm not even sure that's well-defined; how > Eric> exactly will a PE know whether an I-PMSI A-D route with LIR set is > Eric> legal in a particular scenario? > > Eric> If it is considered desirable to allow the LIR flag to be used in > Eric> I-PMSI A-D routes, a separate draft should be written, updating RFC > Eric> 6514, that proposes to remove RFC 6514's restriction. Presumably that > Eric> draft would address interoperability issues with implementations that > Eric> are compliant to RFC 6514 and disallow the LIR flag in I-PMSI A-D > Eric> routes. However, I have to say that I don't think this change is > Eric> necessary, because the same effect can be obtained by using a wildcard > Eric> S-PMSI. > > Eric> In any case, I don't think a change like this should be hidden in "the > Eric> fine print" of a draft that is on a different topic. There is no "fine print" - the text is quite explicit. However, the revised text explicitly spells out the differences with 6514. Note also, that there is nothing in the draft that precludes the use of a wildcard S-PMSI. > A PE that receives such I-PMSI A-D route MUST respond with a Leaf A-D > route. The PMSI Tunnel attribute of that Leaf A-D route is > constructed as follows. The Tunnel Type is set to Ingress > Replication. The Tunnel Identifier MUST carry a routable address of > the PE that originates the Leaf A-D route. The PMSI Tunnel attribute > MUST carry a downstream assigned MPLS label that is used to > demultiplex the traffic received over a unicast tunnel by the PE. > > ... > > 9. Further refinements > > In some cases a VPN customer may not want to rely solely on an (IP) > default route being advertised from a V-spoke to a CE, but may want > CEs to receive all the VPN routes (e.g., for the purpose of faster > detection of VPN connectivity failures, and activating some backup > connectivity). > > In this case one possible approach would be to install in the V- > spoke's data plane only the default route (following the Virtual Hub > and Spoke model, as described above), but keep all the VPN-IP routes > in the V-spoke's control plane (and thus being able to advertise > these routes from the V-spoke to the CEs). Granted, this would not > change control plane resource consumption, but would (significantly) > reduce resource consumption on the data plane. > > Eric> If the whole point of the V-hub/V-spoke architecture is to allow > Eric> Spoke-PEs to maintain only a small set of routes, I don't quite see the > Eric> point of having the spoke-PE maintain all the Internet routes. In the revised draft I made it clear that we are talking here about reduced forwarding state. Yakov. From lucy.yong@huawei.com Mon Nov 19 15:08:01 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8746521E803C for ; Mon, 19 Nov 2012 15:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.076 X-Spam-Level: X-Spam-Status: No, score=-6.076 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR8HuAmuXwaI for ; Mon, 19 Nov 2012 15:08:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 97BA821F8559 for ; Mon, 19 Nov 2012 15:08:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALS25994; Mon, 19 Nov 2012 23:07:59 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 23:07:31 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 23:07:58 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 15:07:52 -0800 From: Lucy yong To: "l3vpn@ietf.org" Subject: FW: New Version Notification for draft-yong-l3vpn-nvgre-vxlan-encap-00.txt Thread-Topic: New Version Notification for draft-yong-l3vpn-nvgre-vxlan-encap-00.txt Thread-Index: AQHNxqqB/7q+tfYmvkG2pAjtk8siXZfxx85g Date: Mon, 19 Nov 2012 23:07:51 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D448322A7@dfweml505-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.92.62] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 23:08:01 -0000 RllJLiBXZWxjb21lIGFueSBjb21tZW50IG9uIHRoaXMuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDE5LCAyMDEyIDU6 MDYgUE0NCj4gVG86IEx1Y3kgeW9uZw0KPiBDYzogWHV4aWFvaHUNCj4gU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15b25nLWwzdnBuLW52Z3JlLXZ4bGFuLQ0KPiBl bmNhcC0wMC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteW9uZy1s M3Zwbi1udmdyZS12eGxhbi1lbmNhcC0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBMdWN5IFlvbmcgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5 Lg0KPiANCj4gRmlsZW5hbWU6CSBkcmFmdC15b25nLWwzdnBuLW52Z3JlLXZ4bGFuLWVuY2FwDQo+ IFJldmlzaW9uOgkgMDANCj4gVGl0bGU6CQkgTlZHUkUgYW5kIFZYTEFOIEVuY2Fwc3VsYXRpb24g Zm9yIEwzVlBOIEV4dGVuc2lvbg0KPiBDcmVhdGlvbiBkYXRlOgkgMjAxMi0xMS0xOQ0KPiBXRyBJ RDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gTnVtYmVyIG9mIHBhZ2VzOiA3DQo+IFVSTDog ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteW9u Zy1sM3Zwbi0NCj4gbnZncmUtdnhsYW4tZW5jYXAtMDAudHh0DQo+IFN0YXR1czogICAgICAgICAg aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15b25nLWwzdnBuLQ0KPiBudmdy ZS12eGxhbi1lbmNhcA0KPiBIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXlvbmctbDN2cG4tbnZncmUtDQo+IHZ4bGFuLWVuY2FwLTAwDQo+IA0KPiANCj4g QWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIE5WR1JFIGFuZCBWWExBTiBl bmNhcHN1bGF0aW9uIGZvciBMM1ZQTg0KPiAgICBFeHRlbnNpb24uIEJvdGggTlZHUkUgYW5kIFZY TEFOIGFyZSBvcmlnaW5hbGx5IGRlc2lnbmVkIGZvciBMMg0KPiAgICBvdmVybGF5LiBUaGUgZHJh ZnQgcHJvcG9zZXMgdGhlIGVuaGFuY2VtZW50IG9uIGJvdGggdG8gYWxsb3cgTDMNCj4gICAgb3Zl cmxheSBjb21wbGV0ZWx5IGRlY291cGxlZCBmcm9tIHRoZSBMMiBvdmVybGF5IGluIHRlcm1zIG9m DQo+ICAgIGVuY29kaW5nIHNjaGVtYSBhbmQgZGF0YSBwcm9jZXNzaW5nLg0KPiANCj4gDQo+IA0K PiANCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From randy@psg.com Mon Nov 19 19:04:25 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2A521F87D2 for ; Mon, 19 Nov 2012 19:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNNNvUX2XbKp for ; Mon, 19 Nov 2012 19:04:25 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 0617D21F87CC for ; Mon, 19 Nov 2012 19:04:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tae8L-000NfQ-NN; Tue, 20 Nov 2012 03:04:22 +0000 Date: Tue, 20 Nov 2012 10:04:16 +0700 Message-ID: From: Randy Bush To: Subject: Re: draft-ymbk-l3vpn-origination-02 In-Reply-To: <30354_1353316703_50A9F95F_30354_1766_3_53C29892C857584299CBF5D05346208A108C38@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <6CDE9DE8E74F58419C4C489FE0852B8F21E23AD3@xmb-aln-x02.cisco.com> <30536_1352971502_50A4B4EE_30536_2496_1_53C29892C857584299CBF5D05346208A107874@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6CDE9DE8E74F58419C4C489FE0852B8F21E34EEA@xmb-rcd-x02.cisco.com> <30354_1353316703_50A9F95F_30354_1766_3_53C29892C857584299CBF5D05346208A108C38@PEXCVZYM11.corporate.adroot.infra.ftgroup> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "Pranav Mehta \(pmehta\)" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 03:04:25 -0000 being lazy, i really wanted to spec communities. but communities are too small to hold a reasonable hash. and they are not necessarily transitive. randy From erosen@cisco.com Wed Nov 21 10:42:59 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAE821F86C3 for ; Wed, 21 Nov 2012 10:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9i5mfEOc6qq for ; Wed, 21 Nov 2012 10:42:59 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9CF21F8616 for ; Wed, 21 Nov 2012 10:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2112; q=dns/txt; s=iport; t=1353523379; x=1354732979; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=zqyeeLm+65eVlWJ5vcItApd147cRyMum4Xm12oBWNBs=; b=EhZFTrzcmT2fuZozzNzYLw4LjM6Idh93i2QXzGwL238DqpCZ6X7lcUzu KoYcU3j/L/wrvEFKnpomNLxKAeexmghhNnK73N43+JGdlqkzMrvG/30u2 6/XTNYXV0JfQXLIY1KxUrxTOHKhO7MWJaYQBH76mx18H626N0uUp0hDlg w=; X-IronPort-AV: E=McAfee;i="5400,1158,6903"; a="64529238" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 21 Nov 2012 18:42:57 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qALIgu5r017880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2012 18:42:57 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id qALIgtU4020244; Wed, 21 Nov 2012 13:42:55 -0500 To: Yakov Rekhter Subject: Re: Last Call comments on draft-ietf-l3vpn-virtual-hub In-reply-to: Your message of Thu, 08 Nov 2012 07:17:19 -0800. <201211081517.qA8FHJ342412@magenta.juniper.net> Date: Wed, 21 Nov 2012 13:42:55 -0500 Message-ID: <20243.1353523375@erosen-linux> From: Eric Rosen Cc: erosen@cisco.com, L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 18:43:00 -0000 Yakov> I am in the process of addressing your comments. In this e-mail I'd Yakov> like to focus on one particular one: Eric> Let's consider the case where the source is at a site attached to Eric> V-hub2. V-hub1 will receive an S-PMSI A-D route matching (S,G) from Eric> V-hub2. V-hub1 then modifies this A-D route and forwards it to Eric> V-spoke1. V-hub1 could use this route to identify the P-tunnel Eric> originating at V-hub2, thereby instructing V-spoke1 to join V-hub2's Eric> tunnel directly. Then V-hub1 would not be in the data path from S to Eric> R, but it would participate in the control plane. Wouldn't this meet Eric> all the requirements of the V-hub/V-spoke architecture, while producing Eric> a more optimal path for multicast data, and eliminating the need to Eric> have the V-hubs splice together any P-tunnels? Eric> Was any consideration given to such an alternative? Yakov> Please note that the procedures specified in the draft assume Yakov> the ability to perform sender-based RPF, as specified in 9.1.1 Yakov> of rfc6513. The text of RFC6513 does not anticipate the use of a "virtual hub". But what's wrong with the following procedure: - V-spoke1 selects V-hub1 as the upstream PE for (C-S,C-G). - V-hub1 instructs V-spoke1 to receive (C-S,C-G) traffic from a unidirectional P-tunnel rooted at V-hub2. (V-spoke1 follows this instruction because V-hub1 is its upstream PE for (C-S,C-G).) - V-spoke1 drops any (C-S,C-G) traffic that did not arrive from V-hub2 over the specified P-tunnel. Yakov> Furthermore, your outline above talks about S-PMSI A-D route. How Yakov> would it work for I-PMSI A-D routes ? Since V-spoke1 cannot determine the real upstream PE, V-spoke1 would probably have to get a (C-S,C-G) S-PMSI A-D route from V-hub1 for each (C-S,C-G) in which V-spoke1 has interest. The PMSI Tunnel attribute would identify the real upstream PE. I think V-hub1 has the necessary state to generate these, since it gets the C-multicast Joins its associated spokes. Of course, there are trade-offs to be considered. From yakov@juniper.net Wed Nov 21 11:51:01 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342D121F8441 for ; Wed, 21 Nov 2012 11:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.038 X-Spam-Level: X-Spam-Status: No, score=-106.038 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMrQcGQp2lTz for ; Wed, 21 Nov 2012 11:51:00 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 04AAA21F85DB for ; Wed, 21 Nov 2012 11:50:51 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUK0wm/cBECbcDL30khubd7g3KhvlVgaP@postini.com; Wed, 21 Nov 2012 11:50:52 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 21 Nov 2012 11:46:28 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qALJkS390008; Wed, 21 Nov 2012 11:46:28 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201211211946.qALJkS390008@magenta.juniper.net> To: Subject: Re: Last Call comments on draft-ietf-l3vpn-virtual-hub In-Reply-To: <20243.1353523375@erosen-linux> References: <20243.1353523375@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Wed, 21 Nov 2012 13:42:55 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27521.1353527188.1@juniper.net> Date: Wed, 21 Nov 2012 11:46:28 -0800 From: Yakov Rekhter Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 19:51:01 -0000 Eric, > Yakov> I am in the process of addressing your comments. In this e-mail I'd > Yakov> like to focus on one particular one: > > Eric> Let's consider the case where the source is at a site attached to > Eric> V-hub2. V-hub1 will receive an S-PMSI A-D route matching (S,G) from > Eric> V-hub2. V-hub1 then modifies this A-D route and forwards it to > Eric> V-spoke1. V-hub1 could use this route to identify the P-tunnel > Eric> originating at V-hub2, thereby instructing V-spoke1 to join V-hub2's > Eric> tunnel directly. Then V-hub1 would not be in the data path from S to > Eric> R, but it would participate in the control plane. Wouldn't this meet > Eric> all the requirements of the V-hub/V-spoke architecture, while producing > Eric> a more optimal path for multicast data, and eliminating the need to > Eric> have the V-hubs splice together any P-tunnels? > > Eric> Was any consideration given to such an alternative? > > Yakov> Please note that the procedures specified in the draft assume > Yakov> the ability to perform sender-based RPF, as specified in 9.1.1 > Yakov> of rfc6513. > > The text of RFC6513 does not anticipate the use of a "virtual hub". But > what's wrong with the following procedure: > > - V-spoke1 selects V-hub1 as the upstream PE for (C-S,C-G). > > - V-hub1 instructs V-spoke1 to receive (C-S,C-G) traffic from a > unidirectional P-tunnel rooted at V-hub2. (V-spoke1 follows this > instruction because V-hub1 is its upstream PE for (C-S,C-G).) > > - V-spoke1 drops any (C-S,C-G) traffic that did not arrive from V-hub2 over > the specified P-tunnel. You just confirmed my point that the existing procedures in 6513 are insufficient to support your alternative, and the draft is very explicit in terms of its reliance on the 6513 procedures. > Yakov> Furthermore, your outline above talks about S-PMSI A-D route. How > Yakov> would it work for I-PMSI A-D routes ? > > Since V-spoke1 cannot determine the real upstream PE, V-spoke1 would > probably have to get a (C-S,C-G) S-PMSI A-D route from V-hub1 for each > (C-S,C-G) in which V-spoke1 has interest. The PMSI Tunnel attribute would > identify the real upstream PE. I think V-hub1 has the necessary state to > generate these, since it gets the C-multicast Joins its associated spokes. For one thing, this would rule out the use of I-PMSI between V-hub and associated with it V-spokes, and would result in proliferation of (C-S, C-G) S-PMSI routes. Moreover, how would your alternative support DM (unsoliciated flooded data) ? How it would support (C-*, C-*) wildcard S-PMSI ? Yakov. From yakov@juniper.net Wed Nov 21 12:43:33 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3797F21F887F for ; Wed, 21 Nov 2012 12:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.131 X-Spam-Level: X-Spam-Status: No, score=-106.131 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO9HpDomUQGG for ; Wed, 21 Nov 2012 12:43:32 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8238B21F887E for ; Wed, 21 Nov 2012 12:43:32 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUK088f3AY4suoG2LujTdIvvwf+LdJ7Gi@postini.com; Wed, 21 Nov 2012 12:43:32 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 21 Nov 2012 12:37:15 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qALKbE361244; Wed, 21 Nov 2012 12:37:14 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201211212037.qALKbE361244@magenta.juniper.net> To: Subject: Re: Last Call comments on draft-ietf-l3vpn-virtual-hub In-Reply-To: <20243.1353523375@erosen-linux> References: <20243.1353523375@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Wed, 21 Nov 2012 13:42:55 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28350.1353530234.1@juniper.net> Date: Wed, 21 Nov 2012 12:37:14 -0800 From: Yakov Rekhter Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 20:43:33 -0000 Eric, > Yakov> I am in the process of addressing your comments. In this e-mail I'd > Yakov> like to focus on one particular one: > > Eric> Let's consider the case where the source is at a site attached to > Eric> V-hub2. V-hub1 will receive an S-PMSI A-D route matching (S,G) from > Eric> V-hub2. V-hub1 then modifies this A-D route and forwards it to > Eric> V-spoke1. V-hub1 could use this route to identify the P-tunnel > Eric> originating at V-hub2, thereby instructing V-spoke1 to join V-hub2's > Eric> tunnel directly. Then V-hub1 would not be in the data path from S to > Eric> R, but it would participate in the control plane. Wouldn't this meet > Eric> all the requirements of the V-hub/V-spoke architecture, while producing > Eric> a more optimal path for multicast data, and eliminating the need to > Eric> have the V-hubs splice together any P-tunnels? > > Eric> Was any consideration given to such an alternative? > > Yakov> Please note that the procedures specified in the draft assume > Yakov> the ability to perform sender-based RPF, as specified in 9.1.1 > Yakov> of rfc6513. > > The text of RFC6513 does not anticipate the use of a "virtual hub". But > what's wrong with the following procedure: > > - V-spoke1 selects V-hub1 as the upstream PE for (C-S,C-G). > > - V-hub1 instructs V-spoke1 to receive (C-S,C-G) traffic from a > unidirectional P-tunnel rooted at V-hub2. (V-spoke1 follows this > instruction because V-hub1 is its upstream PE for (C-S,C-G).) > > - V-spoke1 drops any (C-S,C-G) traffic that did not arrive from V-hub2 over > the specified P-tunnel. On more question, in addition to the questions I raised in the e-mail I sent you earlier today: How would your alternative support scenarios where the root of a P-tunnel needs to know leaves of that tunnel (e.g., p2mp RSVP-TE is used for P-tunnel, or the root performs aggregation using upstream-assigned label)? E.g., using your example above, assume that V-hub2 originated an (C-S, C-G) S-PMSI A-D route with Leaf Information Required. Please point me to the procedures in rfc6513, rfc6514 that would result in a Leaf A-D route originated by V-spoke1 to be received (and correctly processed) by V-hub2. Yakov. From erosen@cisco.com Wed Nov 21 13:08:58 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4084021F87F2 for ; Wed, 21 Nov 2012 13:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkJ6QK5gylY8 for ; Wed, 21 Nov 2012 13:08:57 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB9921F87B6 for ; Wed, 21 Nov 2012 13:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1410; q=dns/txt; s=iport; t=1353532137; x=1354741737; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=RQ95eKxbqMXtG/L2SRCLDTZpnnXkC72Vv1xWu+hCfqU=; b=Z3HbUKw0prDD/1Om+K/zBbjMkj5XqRoxJiOh5mgtEfM2lQzv0zvo0/QP mgzBmtIu4ovCRXmKp+4HqWNdvM+ZwMHDRW2xCpZ1OfsP7BjxouzIx2eZ7 O1eZiLH/LHlj9N84cM1rUkaAAS4endXHNaa4TIOr7d8KLJl6VwEGaaOEZ M=; X-IronPort-AV: E=McAfee;i="5400,1158,6903"; a="144983339" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 21 Nov 2012 21:08:57 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qALL8uLu000637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2012 21:08:56 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id qALL8tmh021854; Wed, 21 Nov 2012 16:08:55 -0500 To: Yakov Rekhter Subject: Re: Last Call comments on draft-ietf-l3vpn-virtual-hub In-reply-to: Your message of Wed, 21 Nov 2012 11:46:28 -0800. <201211211946.qALJkS390008@magenta.juniper.net> Date: Wed, 21 Nov 2012 16:08:55 -0500 Message-ID: <21853.1353532135@erosen-linux> From: Eric Rosen Cc: erosen@cisco.com, L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 21:08:58 -0000 So in the following case: - source attached to V-hub2 - receiver attached to V-spoke1 - V-spoke1 associated with V-hub1 I was questioning whether it is really necessary to have a data path of source-->V-hub2-->V-hub1-->V-spoke1-->receiver, or whether we could have the more optimal data path of source-->V-hub2-->V-spoke1-->receiver If I understand correctly, the answer is that in order to obtain the more optimal path: 1. We would need a new procedure for determining which packets need to be discarded because they come from the "wrong place"; this would have to be tunnel-based rather than sender-based. (A similar issue arises in extranet.) 2. This procedure would require more BGP routes to be sent from a v-hub to its associated spokes, since in hub has to tell its associated spokes the tunnel to use for each (S,G). (This makes it difficult to use I-PMSI or (*,*) S-PMSI A-D routes in the hub-to-associated-spoke control plane.) While I agree that these points are valid, I don't see 1 as a real issue, and 2 is a common tradeoff (increasing the optimality of the data plane requires more control messages). The issue of unsolicited flooded data is really a sub-issue of 2. However, in the context of WG LC, I think you have adequately answered the question of why it makes the choice it does. From erosen@cisco.com Wed Nov 21 13:15:06 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C117221F8855 for ; Wed, 21 Nov 2012 13:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foUJE4Tzn4O9 for ; Wed, 21 Nov 2012 13:15:06 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C843A21F8856 for ; Wed, 21 Nov 2012 13:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=917; q=dns/txt; s=iport; t=1353532506; x=1354742106; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=wxEijirwCwTgkta+Voez+C0mbzYVlN9T1oGnA/CL5NE=; b=atcE01sP2jRnHPAtv3MMHIncEiDKf4uZw3wvQdqgXfW02XQRXqMZAuHw 0elX3uK7ikacrPUpU6E4Ot3oMKe6kDsRkLM3Mhgzbuc4Dj2i77xhM/rM1 GCVf07wEf+8twNAhH11aFmidfFF7DnCTxc9vUy6awXHtswNiwuSYFqkfv 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6903"; a="64615224" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 21 Nov 2012 21:15:02 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qALLF1jP019914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2012 21:15:02 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id qALLF18t021950; Wed, 21 Nov 2012 16:15:01 -0500 To: Yakov Rekhter Subject: Re: Last Call comments on draft-ietf-l3vpn-virtual-hub In-reply-to: Your message of Wed, 21 Nov 2012 12:37:14 -0800. <201211212037.qALKbE361244@magenta.juniper.net> Date: Wed, 21 Nov 2012 16:15:01 -0500 Message-ID: <21949.1353532501@erosen-linux> From: Eric Rosen Cc: erosen@cisco.com, L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 21:15:06 -0000 > How would your alternative support scenarios where the root of a > P-tunnel needs to know leaves of that tunnel (e.g., p2mp RSVP-TE > is used for P-tunnel, or the root performs aggregation using > upstream-assigned label)? And don't forget ingress replication ;-) > E.g., using your example above, > assume that V-hub2 originated an (C-S, C-G) S-PMSI A-D route with > Leaf Information Required. Please point me to the procedures in > rfc6513, rfc6514 that would result in a Leaf A-D route originated > by V-spoke1 to be received (and correctly processed) by V-hub2. Well, you've answered your own question. On receiving an S-PMSI A-D route, V-spoke1 would have to send a Leaf A-D route to the root of the tunnel (as specified in the PMSI Tunnel attribute), rather than to the source of the S-PMSI A-D route. You are correct that this would require new procedures that have to be specified. From bruno.decraene@orange.com Fri Nov 23 06:16:21 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAEC21F853C for ; Fri, 23 Nov 2012 06:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdT7S13xeOkv for ; Fri, 23 Nov 2012 06:16:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE8121F853B for ; Fri, 23 Nov 2012 06:16:20 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id B66F93B42C8; Fri, 23 Nov 2012 15:16:18 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 96EEB27C0AB; Fri, 23 Nov 2012 15:16:18 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Fri, 23 Nov 2012 15:16:18 +0100 From: To: Randy Bush Subject: RE: draft-ymbk-l3vpn-origination-02 Thread-Topic: draft-ymbk-l3vpn-origination-02 Thread-Index: AQHNxsu5dXvrkSkPQ5Sg9BkPstJlyZf3dyUw Date: Fri, 23 Nov 2012 14:16:17 +0000 Message-ID: <12703_1353680178_50AF8532_12703_137_1_53C29892C857584299CBF5D05346208A10E7C2@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <6CDE9DE8E74F58419C4C489FE0852B8F21E23AD3@xmb-aln-x02.cisco.com> <30536_1352971502_50A4B4EE_30536_2496_1_53C29892C857584299CBF5D05346208A107874@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6CDE9DE8E74F58419C4C489FE0852B8F21E34EEA@xmb-rcd-x02.cisco.com> <30354_1353316703_50A9F95F_30354_1766_3_53C29892C857584299CBF5D05346208A108C38@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "Pranav Mehta \(pmehta\)" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 14:16:21 -0000 Hi Randy, >From: Randy Bush [mailto:randy@psg.com] >Sent: Tuesday, November 20, 2012 = 4:04 AM > >being lazy, i really wanted to spec communities. but communities are >too small to hold a reasonable hash.=20 Regular community may be too small to protect from attacks but probably not= to protect against unintentional errors, which is the goal of the draft as= per the abstract. That's why IMO, the draft should clearly states what are the VPN customers'= requirements in term of protection and how much the draft address thoses r= equirements. In addition, a few uses cases would be useful to better understand the issu= es the draft is proposing to solve. Extended community are bigger (6 or 7 octets). Not working on crypto, I don= 't know if that's big enough to sign an IP prefix.=20 > and they are not necessarily transitive. If you pick the transitive flavor, I assume that the SP(s) will not specifi= cally filter out the customers' communities as the SP is supposed to provid= e a transparent IP VPN service. (and we could argue that the "L3VPN Origination BGP Path" Attribute is also= not guaranteed to be transitive (e.g. to protect from BGP session failure = caused by incorrect handling of BGP attributes, SP could filter out the att= ributes) Bruno > >randy ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From randy@psg.com Fri Nov 23 07:02:03 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2534C21F858F for ; Fri, 23 Nov 2012 07:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbDwiYnmSzyg for ; Fri, 23 Nov 2012 07:02:02 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 976A121F8422 for ; Fri, 23 Nov 2012 07:02:02 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TbulR-000EYd-Gt; Fri, 23 Nov 2012 15:01:59 +0000 Date: Fri, 23 Nov 2012 22:01:45 +0700 Message-ID: From: Randy Bush To: Subject: Re: draft-ymbk-l3vpn-origination-02 In-Reply-To: <12703_1353680178_50AF8532_12703_137_1_53C29892C857584299CBF5D05346208A10E7C2@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <6CDE9DE8E74F58419C4C489FE0852B8F21E23AD3@xmb-aln-x02.cisco.com> <30536_1352971502_50A4B4EE_30536_2496_1_53C29892C857584299CBF5D05346208A107874@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6CDE9DE8E74F58419C4C489FE0852B8F21E34EEA@xmb-rcd-x02.cisco.com> <30354_1353316703_50A9F95F_30354_1766_3_53C29892C857584299CBF5D05346208A108C38@PEXCVZYM11.corporate.adroot.infra.ftgroup> <12703_1353680178_50AF8532_12703_137_1_53C29892C857584299CBF5D05346208A10E7C2@PEXCVZYM11.corporate.adroot.infra.ftgroup> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "Pranav Mehta \(pmehta\)" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 15:02:03 -0000 > Extended community are bigger (6 or 7 octets). crypto folk all say too small randy From thomas.morin@orange.com Thu Nov 29 01:14:52 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B554E21F8894 for ; Thu, 29 Nov 2012 01:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+1Yo0YFIzkK for ; Thu, 29 Nov 2012 01:14:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 988FF21F8590 for ; Thu, 29 Nov 2012 01:14:48 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9345722C51B for ; Thu, 29 Nov 2012 10:14:47 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 763E44C017 for ; Thu, 29 Nov 2012 10:14:47 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 29 Nov 2012 10:14:47 +0100 From: To: "l3vpn@ietf.org" Subject: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 Thread-Topic: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 Thread-Index: AQHNzhH5EQMWRADRq0a2aXmDkECtCg== Date: Thu, 29 Nov 2012 09:14:46 +0000 Message-ID: <2286_1354180487_50B72787_2286_43_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D071169C5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 09:14:53 -0000 SGVsbG8gd29ya2luZyBncm91cCwNCg0KVGhpcyBlbWFpbCBzdGFydHMgYSB0d28td2VlayBwb2xs IG9uIGFkb3B0aW5nDQpkcmFmdC13aWpuYW5kcy1sM3Zwbi1tbGRwLXZyZi1pbi1iYW5kLXNpZ25h bGluZy0wMSBbMV0uDQoNClBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0IGFuZCBzdGF0 ZSBpZiB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBvcg0Kbm90IChpbiB0aGUgbGF0ZXIgY2FzZSwgcGxl YXNlIGFsc28gc3RhdGUgdGhlIHJlYXNvbnMpLg0KDQpUaGlzIHBvbGwgcnVucyB1bnRpbCBEZWNl bWJlciAxM3RoLg0KDQoNCkNvaW5jaWRlbnRhbGx5LCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBr bm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0DQphcHBsaWVzIHRvIHRoaXMgZHJhZnQsIHRvIGVuc3Vy ZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4NCmNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQ UiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OQ0KYW5kIDUzNzggZm9yIG1vcmUgZGV0 YWlscykuDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRy aWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvDQp0aGlzIGVtYWlsIHdoZXRoZXIgb3Igbm90IHlvdSBh cmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhlIGRyYWZ0DQp3aWxsIG5vdCBiZSBhZG9w dGVkIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvcg0K YW5kIGNvbnRyaWJ1dG9yLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBMM1ZQTiBXRyBtYWlsaW5nIGxp c3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciANCm9yIGNvbnRyaWJ1dG9yLCB0aGVu IHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIA0KYW55 IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGgg SUVURiBydWxlcy4NCg0KVGhhbmsgeW91LA0KDQpNYXJ0aW4gJiBUaG9tYXMNCmwzdnBuIGNoYWly cw0KDQpbMV0gDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aWpuYW5kcy1sM3Zw bi1tbGRwLXZyZi1pbi1iYW5kLXNpZ25hbGluZy0wMQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwK RnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3Ig cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From jeff.tantsura@ericsson.com Thu Nov 29 01:19:57 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1960121F84C4 for ; Thu, 29 Nov 2012 01:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtZ8tyC0N8Ua for ; Thu, 29 Nov 2012 01:19:56 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 634DF21F8590 for ; Thu, 29 Nov 2012 01:19:56 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qAT9SK7s029973; Thu, 29 Nov 2012 03:28:22 -0600 Received: from EUSAAHC004.ericsson.se (147.117.188.84) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 29 Nov 2012 04:19:54 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 04:19:54 -0500 From: Jeff Tantsura To: "thomas.morin@orange.com" , "l3vpn@ietf.org" Subject: RE: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 Thread-Topic: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 Thread-Index: AQHNzhH5EQMWRADRq0a2aXmDkECtCpgAiOEQ Date: Thu, 29 Nov 2012 09:19:52 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C748390C023A@eusaamb109.ericsson.se> References: <2286_1354180487_50B72787_2286_43_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D071169C5@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <2286_1354180487_50B72787_2286_43_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D071169C5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 09:19:57 -0000 WWVzL3N1cHBvcnQgLSB3ZWxsIHdyaXR0ZW4gYW5kIGFkZHJlc3NlcyBhIHJlYWwgcHJvYmxlbQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbDN2cG4tYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiB0aG9tYXMubW9y aW5Ab3JhbmdlLmNvbQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDI5LCAyMDEyIDE6MTUgQU0N ClRvOiBsM3ZwbkBpZXRmLm9yZw0KU3ViamVjdDogUG9sbCBmb3IgYWRvcHRpb246IGRyYWZ0LXdp am5hbmRzLWwzdnBuLW1sZHAtdnJmLWluLWJhbmQtc2lnbmFsaW5nLTAxDQoNCkhlbGxvIHdvcmtp bmcgZ3JvdXAsDQoNClRoaXMgZW1haWwgc3RhcnRzIGEgdHdvLXdlZWsgcG9sbCBvbiBhZG9wdGlu Zw0KZHJhZnQtd2lqbmFuZHMtbDN2cG4tbWxkcC12cmYtaW4tYmFuZC1zaWduYWxpbmctMDEgWzFd Lg0KDQpQbGVhc2Ugc2VuZCBjb21tZW50cyB0byB0aGUgbGlzdCBhbmQgc3RhdGUgaWYgeW91IHN1 cHBvcnQgYWRvcHRpb24gb3Igbm90IChpbiB0aGUgbGF0ZXIgY2FzZSwgcGxlYXNlIGFsc28gc3Rh dGUgdGhlIHJlYXNvbnMpLg0KDQpUaGlzIHBvbGwgcnVucyB1bnRpbCBEZWNlbWJlciAxM3RoLg0K DQoNCkNvaW5jaWRlbnRhbGx5LCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2Yg YW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhh cyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBS RkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQoNCklmIHlv dSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBy ZXNwb25kIHRvIHRoaXMgZW1haWwgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkg cmVsZXZhbnQgSVBSLiBUaGUgZHJhZnQgd2lsbCBub3QgYmUgYWRvcHRlZCB1bnRpbCBhIHJlc3Bv bnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0K DQpJZiB5b3UgYXJlIG9uIHRoZSBMM1ZQTiBXRyBtYWlsaW5nIGxpc3QgYnV0IGFyZSBub3QgbGlz dGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSBy ZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQg YmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KDQpUaGFuayB5 b3UsDQoNCk1hcnRpbiAmIFRob21hcw0KbDN2cG4gY2hhaXJzDQoNClsxXQ0KaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtd2lqbmFuZHMtbDN2cG4tbWxkcC12cmYtaW4tYmFuZC1zaWdu YWxpbmctMDENCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIEZyYW5jZSBUZWxlY29tIC0gT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu DQpUaGFuayB5b3UuDQoNCg== From naikumar@cisco.com Thu Nov 29 01:37:47 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97A921F8935 for ; Thu, 29 Nov 2012 01:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPEMxxfWCnN1 for ; Thu, 29 Nov 2012 01:37:47 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1B13721F8941 for ; Thu, 29 Nov 2012 01:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3342; q=dns/txt; s=iport; t=1354181867; x=1355391467; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=KPZQxxrKQR+Nvx1+rfKl25s8Xaey3ammUVGRl/q7hMg=; b=mrczd44eH1bkUAm+S7clziTsHcTjHNVtD96uBP4V9bYHOPaJafGBiB66 TW21nAUtYB6pBXWTV6Y5gtOAUpD7Ecx/AepH4mRC0/AkH4/uVV6bmMrUb S69ieI5gtBiQFxeIZ/7hh2/9uninlE4mSO7caihCg8MRZOs1iXUaV8jHy g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOMrt1CtJV2d/2dsb2JhbABEhiu5BXMWc4IeAQEBBCMROhcEAgEIEQQBAQMCBh0DAgICMBQBCAgCBAESCIgIDKxakmWBIosdC4MjMmEDlx2PKIJygWw1 X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147466475" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 29 Nov 2012 09:37:46 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAT9bkKL030267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 09:37:46 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.191]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 03:37:46 -0600 From: "Nagendra Kumar (naikumar)" To: "thomas.morin@orange.com" , "l3vpn@ietf.org" Subject: RE: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 Thread-Topic: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 Thread-Index: AQHNzhH5EQMWRADRq0a2aXmDkECtCpgAjiyA Date: Thu, 29 Nov 2012 09:37:45 +0000 Message-ID: <47E76F08F1BCF5458111C1939C7B9C460FED5BA7@xmb-rcd-x03.cisco.com> References: <2286_1354180487_50B72787_2286_43_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D071169C5@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <2286_1354180487_50B72787_2286_43_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D071169C5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.103.236.204] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 09:37:48 -0000 U3VwcG9ydC4NCg0KUmVnYXJkcywNCk5hZ2VuZHJhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBsM3Zwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDN2cG4tYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIHRob21hcy5tb3JpbkBvcmFuZ2UuY29tDQpTZW50OiBUaHVy c2RheSwgTm92ZW1iZXIgMjksIDIwMTIgMjo0NSBQTQ0KVG86IGwzdnBuQGlldGYub3JnDQpTdWJq ZWN0OiBQb2xsIGZvciBhZG9wdGlvbjogZHJhZnQtd2lqbmFuZHMtbDN2cG4tbWxkcC12cmYtaW4t YmFuZC1zaWduYWxpbmctMDENCg0KSGVsbG8gd29ya2luZyBncm91cCwNCg0KVGhpcyBlbWFpbCBz dGFydHMgYSB0d28td2VlayBwb2xsIG9uIGFkb3B0aW5nDQpkcmFmdC13aWpuYW5kcy1sM3Zwbi1t bGRwLXZyZi1pbi1iYW5kLXNpZ25hbGluZy0wMSBbMV0uDQoNClBsZWFzZSBzZW5kIGNvbW1lbnRz IHRvIHRoZSBsaXN0IGFuZCBzdGF0ZSBpZiB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBvciBub3QgKGlu IHRoZSBsYXRlciBjYXNlLCBwbGVhc2UgYWxzbyBzdGF0ZSB0aGUgcmVhc29ucykuDQoNClRoaXMg cG9sbCBydW5zIHVudGlsIERlY2VtYmVyIDEzdGguDQoNCg0KQ29pbmNpZGVudGFsbHksIHdlIGFy ZSBhbHNvIHBvbGxpbmcgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0 aGlzIGRyYWZ0LCB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBs aWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQg NTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVu dCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCB3aGV0 aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoZSBkcmFmdCB3 aWxsIG5vdCBiZSBhZG9wdGVkIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJv bSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQoNCklmIHlvdSBhcmUgb24gdGhlIEwzVlBO IFdHIG1haWxpbmcgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRy aWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3 YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3Jt YW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNClRoYW5rIHlvdSwNCg0KTWFydGluICYgVGhvbWFzDQps M3ZwbiBjaGFpcnMNCg0KWzFdDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aWpu YW5kcy1sM3Zwbi1tbGRwLXZyZi1pbi1iYW5kLXNpZ25hbGluZy0wMQ0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMg cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMg am9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQn YWx0ZXJhdGlvbiwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g TWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBU ZWxlY29tIC0gT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0K From ice@cisco.com Thu Nov 29 03:40:02 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE4C21F89BF for ; Thu, 29 Nov 2012 03:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6b4NXV5RX6B for ; Thu, 29 Nov 2012 03:40:01 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5573521F87DA for ; Thu, 29 Nov 2012 03:40:01 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qATBLBqs003405; Thu, 29 Nov 2012 12:21:11 +0100 (CET) Received: from ams-iwijnand-8712.cisco.com (ams-iwijnand-8712.cisco.com [10.55.191.147]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qATBLAod001790; Thu, 29 Nov 2012 12:21:10 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 From: IJsbrand Wijnands In-Reply-To: <2286_1354180487_50B72787_2286_43_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D071169C5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Thu, 29 Nov 2012 12:21:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <83D2550A-EA93-4D63-885C-3D30BB60DA86@cisco.com> References: <2286_1354180487_50B72787_2286_43_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D071169C5@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1499) Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 11:40:02 -0000 Hi Folks, I support as co-author. Regarding IPR, Cisco filed disclosure ID # 1305 against = draft-wijnands-mpls-mldp-in-band-signaling. The IPR also covers the idea = documented in draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01. I'll = ask Cisco legal to file a separate disclosure to IETF regarding this = draft. Thx, Ice. On 29 Nov 2012, at 10:14, wrote: > Hello working group, >=20 > This email starts a two-week poll on adopting > draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 [1]. >=20 > Please send comments to the list and state if you support adoption or > not (in the later case, please also state the reasons). >=20 > This poll runs until December 13th. >=20 >=20 > 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). >=20 > If you are listed as a document author or contributor please respond = to > this email 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. >=20 > If you are on the L3VPN WG mailing list but are not listed as an = author=20 > or contributor, then please explicitly respond only if you are aware = of=20 > any IPR that has not yet been disclosed in conformance with IETF = rules. >=20 > Thank you, >=20 > Martin & Thomas > l3vpn chairs >=20 > [1]=20 > = http://tools.ietf.org/html/draft-wijnands-l3vpn-mldp-vrf-in-band-signaling= -01 > = __________________________________________________________________________= _______________________________________________ >=20 > 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, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 >=20 From william.zayas@fibercrossing.net Thu Nov 29 04:30:31 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B93121F8A05 for ; Thu, 29 Nov 2012 04:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.413 X-Spam-Level: X-Spam-Status: No, score=0.413 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MSGID_FROM_MTA_HEADER=0.803, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1wnwV1iNHKC for ; Thu, 29 Nov 2012 04:30:30 -0800 (PST) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D67121F8A03 for ; Thu, 29 Nov 2012 04:30:30 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qATCUSI6032223 for ; Thu, 29 Nov 2012 07:30:28 -0500 Message-Id: <201211291230.qATCUSI6032223@atl4mhob06.myregisteredsite.com> Received: (qmail 341 invoked by uid 0); 29 Nov 2012 12:30:28 -0000 Received: from unknown (HELO ?192.168.1.5?) (william.zayas@fibercrossing.net@71.163.250.140) by 0 with ESMTPA; 29 Nov 2012 12:30:28 -0000 To: thomas.morin@orange.com, "=?utf-8?B?bDN2cG5AaWV0Zi5vcmc=?=" From: "=?utf-8?B?V2lsbGlhbSBaYXlhcw==?=" Subject: =?utf-8?B?UmU6IFBvbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC13aWpuYW5kcy1sM3Zwbi1tbGRw?= =?utf-8?B?LXZyZi1pbi1iYW5kLXNpZ25hbGluZy0wMQ==?= Date: Thu, 29 Nov 2012 07:30:31 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1354192231847" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 12:30:31 -0000 ------=_Part_0_1354192231847 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U3VwcG9ydC4KCkJpbGwsCgoKCi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0KRnJvbTogdGhvbWFz Lm1vcmluQG9yYW5nZS5jb20KVG86ICJsM3ZwbkBpZXRmLm9yZyIgPGwzdnBuQGlldGYub3JnPgpT dWJqZWN0OiBQb2xsIGZvciBhZG9wdGlvbjogZHJhZnQtd2lqbmFuZHMtbDN2cG4tbWxkcC12cmYt aW4tYmFuZC1zaWduYWxpbmctMDEKRGF0ZTogVGh1LCBOb3YgMjksIDIwMTIgNDoxNCBhbQoKCkhl bGxvIHdvcmtpbmcgZ3JvdXAsCgpUaGlzIGVtYWlsIHN0YXJ0cyBhIHR3by13ZWVrIHBvbGwgb24g YWRvcHRpbmcKZHJhZnQtd2lqbmFuZHMtbDN2cG4tbWxkcC12cmYtaW4tYmFuZC1zaWduYWxpbmct MDEgWzFdLgoKUGxlYXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QgYW5kIHN0YXRlIGlmIHlv dSBzdXBwb3J0IGFkb3B0aW9uIG9yCm5vdCAoaW4gdGhlIGxhdGVyIGNhc2UsIHBsZWFzZSBhbHNv IHN0YXRlIHRoZSByZWFzb25zKS4KClRoaXMgcG9sbCBydW5zIHVudGlsIERlY2VtYmVyIDEzdGgu CgoKQ29pbmNpZGVudGFsbHksIHdlIGFyZSBhbHNvIHBvbGxpbmcgZm9yIGtub3dsZWRnZSBvZiBh bnkgSVBSIHRoYXQKYXBwbGllcyB0byB0aGlzIGRyYWZ0LCB0byBlbnN1cmUgdGhhdCBJUFIgaGFz IGJlZW4gZGlzY2xvc2VkIGluCmNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJG Q3MgMzk3OSwgNDg3OSwgMzY2OQphbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4KCklmIHlvdSBh cmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNw b25kIHRvCnRoaXMgZW1haWwgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVs ZXZhbnQgSVBSLiBUaGUgZHJhZnQKd2lsbCBub3QgYmUgYWRvcHRlZCB1bnRpbCBhIHJlc3BvbnNl IGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IKYW5kIGNvbnRyaWJ1dG9yLgoKSWYg eW91IGFyZSBvbiB0aGUgTDNWUE4gV0cgbWFpbGluZyBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBh cyBhbiBhdXRob3IgCm9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3Bv bmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIAphbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVl biBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLgoKVGhhbmsgeW91LAoK TWFydGluICYgVGhvbWFzCmwzdnBuIGNoYWlycwoKWzFdIApodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC13aWpuYW5kcy1sM3Zwbi1tbGRwLXZyZi1pbi1iYW5kLXNpZ25hbGluZy0wMQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0 b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBv dSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg RnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= ------=_Part_0_1354192231847 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U3VwcG9ydC48YnI+PGJyPkJpbGwsPGJyPjxicj48YnI+PGJyPi0tLS0tIFJlcGx5IG1lc3NhZ2Ug LS0tLS08YnI+RnJvbTogdGhvbWFzLm1vcmluQG9yYW5nZS5jb208YnI+VG86ICZxdW90O2wzdnBu QGlldGYub3JnJnF1b3Q7ICZsdDtsM3ZwbkBpZXRmLm9yZyZndDs8YnI+U3ViamVjdDogUG9sbCBm b3IgYWRvcHRpb246IGRyYWZ0LXdpam5hbmRzLWwzdnBuLW1sZHAtdnJmLWluLWJhbmQtc2lnbmFs aW5nLTAxPGJyPkRhdGU6IFRodSwgTm92IDI5LCAyMDEyIDQ6MTQgYW08YnI+PGJyPjxicj5IZWxs byB3b3JraW5nIGdyb3VwLDxicj48YnI+VGhpcyBlbWFpbCBzdGFydHMgYSB0d28td2VlayBwb2xs IG9uIGFkb3B0aW5nPGJyPmRyYWZ0LXdpam5hbmRzLWwzdnBuLW1sZHAtdnJmLWluLWJhbmQtc2ln bmFsaW5nLTAxIFsxXS48YnI+PGJyPlBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0IGFu ZCBzdGF0ZSBpZiB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBvcjxicj5ub3QgKGluIHRoZSBsYXRlciBj YXNlLCBwbGVhc2UgYWxzbyBzdGF0ZSB0aGUgcmVhc29ucykuPGJyPjxicj5UaGlzIHBvbGwgcnVu cyB1bnRpbCBEZWNlbWJlciAxM3RoLjxicj48YnI+PGJyPkNvaW5jaWRlbnRhbGx5LCB3ZSBhcmUg YWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0PGJyPmFwcGxpZXMgdG8g dGhpcyBkcmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbjxicj5j b21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2Njk8 YnI+YW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuPGJyPjxicj5JZiB5b3UgYXJlIGxpc3RlZCBh cyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0bzxicj50 aGlzIGVtYWlsIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQ Ui4gVGhlIGRyYWZ0PGJyPndpbGwgbm90IGJlIGFkb3B0ZWQgdW50aWwgYSByZXNwb25zZSBoYXMg YmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yPGJyPmFuZCBjb250cmlidXRvci48YnI+PGJy PklmIHlvdSBhcmUgb24gdGhlIEwzVlBOIFdHIG1haWxpbmcgbGlzdCBidXQgYXJlIG5vdCBsaXN0 ZWQgYXMgYW4gYXV0aG9yIDxicj5vciBjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRs eSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiA8YnI+YW55IElQUiB0aGF0IGhhcyBu b3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy48YnI+ PGJyPlRoYW5rIHlvdSw8YnI+PGJyPk1hcnRpbiAmYW1wOyBUaG9tYXM8YnI+bDN2cG4gY2hhaXJz PGJyPjxicj5bMV0gPGJyPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpam5hbmRz LWwzdnBuLW1sZHAtdnJmLWluLWJhbmQtc2lnbmFsaW5nLTAxPGJyPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+PGJyPkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u Yzxicj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlcjxicj5hIGwmIzM5O2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQmIzM5O2FsdGVyYXRpb24sPGJyPkZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxicj48YnI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8YnI+dGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPGJyPklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxicj5BcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC48YnI+VGhhbmsgeW91Ljxicj48YnI+ ------=_Part_0_1354192231847-- From rajiva@cisco.com Thu Nov 29 05:11:24 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8E021F8A30 for ; Thu, 29 Nov 2012 05:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSzLRAIayZXR for ; Thu, 29 Nov 2012 05:11:20 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 393D621F893B for ; Thu, 29 Nov 2012 05:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2798; q=dns/txt; s=iport; t=1354194680; x=1355404280; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=k3jfOt94D6K7WuNj7poRVoi95nv5sAvY4+249a1ob54=; b=V6WNGqqq9Sz+pbg70lPiFeTLWIN0KjvOP6wvBaevV88qsCTAzy2jD0++ EaKHMjv7hwzRE3d+x6cRUdnnleuYgzIUjhV88zGBhLWCDFF2ndWAVWN+g SGygqez59hjkAoUbKYtaYwME0VlroBXAj4cbcsQSXrdQz2EUtK8km1ka0 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAZet1CtJV2Y/2dsb2JhbABEwCIWc4IeAQEBBDo0FwYBCBEDAQILFEIUCQgCBAESCIgIDL8bjD8Lg1VhA5cdjyiCcoFsNQ X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147522955" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 29 Nov 2012 13:11:19 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qATDBJ94004938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 13:11:19 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.84]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 07:11:19 -0600 From: "Rajiv Asati (rajiva)" To: William Zayas , "thomas.morin@orange.com" , "l3vpn@ietf.org" Subject: Re: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 Thread-Topic: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 Thread-Index: AQHNzi1SEQMWRADRq0a2aXmDkECtCpgA2mmA Date: Thu, 29 Nov 2012 13:11:19 +0000 Message-ID: In-Reply-To: <201211291230.qATCUSI6032223@atl4mhob06.myregisteredsite.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.82.251.52] Content-Type: text/plain; charset="us-ascii" Content-ID: <2903FE44D1871946A517E67724B6F8E1@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 13:11:25 -0000 Support. -----Original Message----- From: William Zayas Date: Thursday, November 29, 2012 7:30 AM To: "thomas.morin@orange.com" , "l3vpn@ietf.org" Subject: Re: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 > > > >Support. > >Bill, > > > >----- Reply message ----- >From: thomas.morin@orange.com >To: "l3vpn@ietf.org" >Subject: Poll for adoption: >draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 >Date: Thu, Nov 29, 2012 4:14 am > > >Hello working group, > >This email starts a two-week poll on adopting >draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 [1]. > >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 December 13th. > > >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 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 on the L3VPN WG mailing list but 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 >l3vpn chairs > >[1]=20 >http://tools.ietf.org/html/draft-wijnands-l3vpn-mldp-vrf-in-band-signaling >-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, >France Telecom - 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, France Telecom - Orange is not liable for >messages that have been modified, changed or falsified. >Thank you. > From mn1921@att.com Thu Nov 29 06:29:45 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A583421F89FC for ; Thu, 29 Nov 2012 06:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfV0EEpyNW60 for ; Thu, 29 Nov 2012 06:29:45 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id CD44721F89E4 for ; Thu, 29 Nov 2012 06:29:44 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 85177b05.0.569068.00-452.1578458.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 29 Nov 2012 14:29:44 +0000 (UTC) X-MXL-Hash: 50b77158008d7f7b-058ab574ab336679853b2d0c174c4dd4794b1d97 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qATETiw5025644; Thu, 29 Nov 2012 09:29:44 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qATETa1f025593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2012 09:29:36 -0500 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by sflint01.pst.cso.att.com (RSA Interceptor); Thu, 29 Nov 2012 09:29:29 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 09:29:29 -0500 From: "NAPIERALA, MARIA H" To: "thomas.morin@orange.com" , "l3vpn@ietf.org" Subject: RE: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 Thread-Topic: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 Thread-Index: AQHNzhH5EQMWRADRq0a2aXmDkECtCpgA33cw Date: Thu, 29 Nov 2012 14:29:29 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E010DB04D@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <2286_1354180487_50B72787_2286_43_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D071169C5@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <2286_1354180487_50B72787_2286_43_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D071169C5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.190.111] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=MpLlHRme c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=acbs-DA_q4AA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=Ikc] X-AnalysisOut: [TkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=duPHYNdn8] X-AnalysisOut: [UwA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=E4JVjU1o1rDCWHA] X-AnalysisOut: [-uwoA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA] X-AnalysisOut: [:10 a=Ys1C854NbEC-x4pp:21 a=Yc0wEyxgNp0Fs1Up:21] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 14:29:45 -0000 U3VwcG9ydC4NCg0KTWFyaWEgDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogbDN2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZg0KPiBPZiB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbQ0KPiBTZW50OiBUaHVyc2Rh eSwgTm92ZW1iZXIgMjksIDIwMTIgNDoxNSBBTQ0KPiBUbzogbDN2cG5AaWV0Zi5vcmcNCj4gU3Vi amVjdDogUG9sbCBmb3IgYWRvcHRpb246IGRyYWZ0LXdpam5hbmRzLWwzdnBuLW1sZHAtdnJmLWlu LWJhbmQtDQo+IHNpZ25hbGluZy0wMQ0KPiANCj4gSGVsbG8gd29ya2luZyBncm91cCwNCj4gDQo+ IFRoaXMgZW1haWwgc3RhcnRzIGEgdHdvLXdlZWsgcG9sbCBvbiBhZG9wdGluZw0KPiBkcmFmdC13 aWpuYW5kcy1sM3Zwbi1tbGRwLXZyZi1pbi1iYW5kLXNpZ25hbGluZy0wMSBbMV0uDQo+IA0KPiBQ bGVhc2Ugc2VuZCBjb21tZW50cyB0byB0aGUgbGlzdCBhbmQgc3RhdGUgaWYgeW91IHN1cHBvcnQg YWRvcHRpb24gb3INCj4gbm90IChpbiB0aGUgbGF0ZXIgY2FzZSwgcGxlYXNlIGFsc28gc3RhdGUg dGhlIHJlYXNvbnMpLg0KPiANCj4gVGhpcyBwb2xsIHJ1bnMgdW50aWwgRGVjZW1iZXIgMTN0aC4N Cj4gDQo+IA0KPiBDb2luY2lkZW50YWxseSwgd2UgYXJlIGFsc28gcG9sbGluZyBmb3Iga25vd2xl ZGdlIG9mIGFueSBJUFIgdGhhdA0KPiBhcHBsaWVzIHRvIHRoaXMgZHJhZnQsIHRvIGVuc3VyZSB0 aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4NCj4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBS IHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5DQo+IGFuZCA1Mzc4IGZvciBtb3JlIGRl dGFpbHMpLg0KPiANCj4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3Ig Y29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8NCj4gdGhpcyBlbWFpbCB3aGV0aGVyIG9yIG5v dCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoZSBkcmFmdA0KPiB3aWxsIG5v dCBiZSBhZG9wdGVkIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNo IGF1dGhvcg0KPiBhbmQgY29udHJpYnV0b3IuDQo+IA0KPiBJZiB5b3UgYXJlIG9uIHRoZSBMM1ZQ TiBXRyBtYWlsaW5nIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvcg0KPiBvciBj b250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFy ZSBhd2FyZSBvZg0KPiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4g Y29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KPiANCj4gVGhhbmsgeW91LA0KPiANCj4gTWFy dGluICYgVGhvbWFzDQo+IGwzdnBuIGNoYWlycw0KPiANCj4gWzFdDQo+IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXdpam5hbmRzLWwzdnBuLW1sZHAtdnJmLWluLWJhbmQtDQo+IHNp Z25hbGluZy0wMQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+IGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+IHBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXoN Cj4gcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQo+IGEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcw0KPiBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sDQo+IEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhDQo+IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLg0KPiANCj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQNCj4gaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsNCj4gdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+IElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQNCj4gZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiBBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yDQo+IG1l c3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4g VGhhbmsgeW91Lg0KDQo= From arkadiy.gulko@thomsonreuters.com Thu Nov 29 09:21:14 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6342021F8AC6 for ; Thu, 29 Nov 2012 09:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bmkkoit006bt for ; Thu, 29 Nov 2012 09:21:13 -0800 (PST) Received: from mailout1-trp.thomsonreuters.com (mailout1-trp.thomsonreuters.com [163.231.6.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3628321F8AC3 for ; Thu, 29 Nov 2012 09:21:12 -0800 (PST) Received: from trpusmneagrly01.int.westgroup.com (relay1 [163.231.22.97]) by mailout1-trp.thomsonreuters.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qATHLBJF028415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Nov 2012 17:21:11 GMT Received: from EAGE-ERFPHUB02.ERF.thomson.com (xch7 [163.231.23.34]) by trpusmneagrly01.int.westgroup.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qATHL8KP001664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 17:21:10 GMT Received: from C111KJZHMBX55.ERF.thomson.com ([fe80::f529:cc22:c054:b74f]) by EAGE-ERFPHUB02.ERF.thomson.com ([fe80::402b:12:41dc:62a1%12]) with mapi id 14.02.0283.003; Thu, 29 Nov 2012 11:21:00 -0600 From: To: , Subject: RE: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 Thread-Topic: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 Thread-Index: AQHNzhH5EQMWRADRq0a2aXmDkECtCpgBD0Mw Date: Thu, 29 Nov 2012 17:20:59 +0000 Message-ID: <4A496052E7B7E84A9324854763C616FA193580@C111KJZHMBX55.ERF.thomson.com> References: <2286_1354180487_50B72787_2286_43_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D071169C5@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <2286_1354180487_50B72787_2286_43_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D071169C5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.206.30.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 17:21:14 -0000 SSBzdXBwb3J0IChhcyBjby1hdXRob3IpIGFuZCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIuDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsM3Zwbi1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bDN2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHRob21hcy5tb3Jp bkBvcmFuZ2UuY29tDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjksIDIwMTIgNDoxNSBBTQ0K VG86IGwzdnBuQGlldGYub3JnDQpTdWJqZWN0OiBQb2xsIGZvciBhZG9wdGlvbjogZHJhZnQtd2lq bmFuZHMtbDN2cG4tbWxkcC12cmYtaW4tYmFuZC1zaWduYWxpbmctMDENCg0KSGVsbG8gd29ya2lu ZyBncm91cCwNCg0KVGhpcyBlbWFpbCBzdGFydHMgYSB0d28td2VlayBwb2xsIG9uIGFkb3B0aW5n DQpkcmFmdC13aWpuYW5kcy1sM3Zwbi1tbGRwLXZyZi1pbi1iYW5kLXNpZ25hbGluZy0wMSBbMV0u DQoNClBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0IGFuZCBzdGF0ZSBpZiB5b3Ugc3Vw cG9ydCBhZG9wdGlvbiBvcg0Kbm90IChpbiB0aGUgbGF0ZXIgY2FzZSwgcGxlYXNlIGFsc28gc3Rh dGUgdGhlIHJlYXNvbnMpLg0KDQpUaGlzIHBvbGwgcnVucyB1bnRpbCBEZWNlbWJlciAxM3RoLg0K DQoNCkNvaW5jaWRlbnRhbGx5LCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2Yg YW55IElQUiB0aGF0DQphcHBsaWVzIHRvIHRoaXMgZHJhZnQsIHRvIGVuc3VyZSB0aGF0IElQUiBo YXMgYmVlbiBkaXNjbG9zZWQgaW4NCmNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2Vl IFJGQ3MgMzk3OSwgNDg3OSwgMzY2OQ0KYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQoNCklm IHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFz ZSByZXNwb25kIHRvDQp0aGlzIGVtYWlsIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2Yg YW55IHJlbGV2YW50IElQUi4gVGhlIGRyYWZ0DQp3aWxsIG5vdCBiZSBhZG9wdGVkIHVudGlsIGEg cmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvcg0KYW5kIGNvbnRyaWJ1 dG9yLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBMM1ZQTiBXRyBtYWlsaW5nIGxpc3QgYnV0IGFyZSBu b3QgbGlzdGVkIGFzIGFuIGF1dGhvciANCm9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBs aWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIA0KYW55IElQUiB0aGF0IGhh cyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4N Cg0KVGhhbmsgeW91LA0KDQpNYXJ0aW4gJiBUaG9tYXMNCmwzdnBuIGNoYWlycw0KDQpbMV0gDQpo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aWpuYW5kcy1sM3Zwbi1tbGRwLXZyZi1p bi1iYW5kLXNpZ25hbGluZy0wMQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KRnJhbmNl IFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQp0aGV5IHNo b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh dGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCg== From stig@venaas.com Thu Nov 29 10:15:41 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E297721F8A88 for ; Thu, 29 Nov 2012 10:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ2H0eZ3yUBV for ; Thu, 29 Nov 2012 10:15:41 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 4283121F8A85 for ; Thu, 29 Nov 2012 10:15:41 -0800 (PST) Received: from [IPv6:2001:420:301:1004:a120:3dbb:cd9:675c] (unknown [IPv6:2001:420:301:1004:a120:3dbb:cd9:675c]) by ufisa.uninett.no (Postfix) with ESMTPSA id 3145D7FEE for ; Thu, 29 Nov 2012 19:15:37 +0100 (CET) Message-ID: <50B7A648.1090007@venaas.com> Date: Thu, 29 Nov 2012 10:15:36 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: l3vpn@ietf.org Subject: Re: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 References: <2286_1354180487_50B72787_2286_43_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D071169C5@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <2286_1354180487_50B72787_2286_43_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D071169C5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 18:15:42 -0000 On 11/29/2012 1:14 AM, thomas.morin@orange.com wrote: > Hello working group, > > This email starts a two-week poll on adopting > draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 [1]. > > Please send comments to the list and state if you support adoption or > not (in the later case, please also state the reasons). Support, Stig > This poll runs until December 13th. > > > 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 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 on the L3VPN WG mailing list but 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 > l3vpn chairs > > [1] > http://tools.ietf.org/html/draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-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, > France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From rajiva@cisco.com Thu Nov 29 10:42:40 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABE721F8A84 for ; Thu, 29 Nov 2012 10:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJzjgTg7vlEm for ; Thu, 29 Nov 2012 10:42:36 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0409321F8A73 for ; Thu, 29 Nov 2012 10:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2900; q=dns/txt; s=iport; t=1354214556; x=1355424156; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=PyOT1qAKNHYPvrs+asu5AjgSsoZzxoZM9ZEm3KHpiN8=; b=Peu7yy8kFMN4dyVpFarvGgLs0i+DIzrHlIRkeQGqW8e60V8H1FaZ2WvW PWEivVUJoMO+5PMtI3471NFPPi2bu2iXskS3p9hPQ2jIthbcZIk9psbZB jRcOg3FuTRWTthP0AUenCvhVzOsPGua1LT4a2HO1CCzNpyA9zNS+u0cN3 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADqst1CtJV2Y/2dsb2JhbABEwA0Wc4IeAQEBBDo0FwYBCBEDAQEBCxQJORQJCAIEARIIiAgMvyiMQAuDVWEDlx2PKIJygWw1 X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="144657178" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 29 Nov 2012 18:42:21 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qATIgLRo014412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 18:42:21 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.84]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 12:42:20 -0600 From: "Rajiv Asati (rajiva)" To: "arkadiy.gulko@thomsonreuters.com" , "thomas.morin@orange.com" , "l3vpn@ietf.org" Subject: Re: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 Thread-Topic: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 Thread-Index: AQHNzmFDE+1GCny/ykih2RRiB4mHKQ== Date: Thu, 29 Nov 2012 18:42:20 +0000 Message-ID: In-Reply-To: <4A496052E7B7E84A9324854763C616FA193580@C111KJZHMBX55.ERF.thomson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.82.251.52] Content-Type: text/plain; charset="us-ascii" Content-ID: <31282CAE4B20884CB60D0CFB55186C58@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 18:42:40 -0000 Support. -----Original Message----- From: "arkadiy.gulko@thomsonreuters.com" Date: Thursday, November 29, 2012 12:20 PM To: "thomas.morin@orange.com" , "l3vpn@ietf.org" Subject: RE: Poll for adoption: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 >I support (as co-author) and I'm not aware of any IPR. > >-----Original Message----- >From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of >thomas.morin@orange.com >Sent: Thursday, November 29, 2012 4:15 AM >To: l3vpn@ietf.org >Subject: Poll for adoption: >draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 > >Hello working group, > >This email starts a two-week poll on adopting >draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 [1]. > >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 December 13th. > > >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 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 on the L3VPN WG mailing list but 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 >l3vpn chairs > >[1]=20 >http://tools.ietf.org/html/draft-wijnands-l3vpn-mldp-vrf-in-band-signaling >-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, >France Telecom - 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, France Telecom - Orange is not liable for >messages that have been modified, changed or falsified. >Thank you. >