From thomas.morin@orange.com Thu Oct 4 01:48: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 B4FC621F8680 for ; Thu, 4 Oct 2012 01:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 9MJA09YabRpF for ; Thu, 4 Oct 2012 01:48:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 92B8C21F861F for ; Thu, 4 Oct 2012 01:48:15 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id C09302DC351 for ; Thu, 4 Oct 2012 10:48:14 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id A7D434C024 for ; Thu, 4 Oct 2012 10:48:14 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 4 Oct 2012 10:48:14 +0200 From: To: "l3vpn@ietf.org" Subject: Re: Poll on adoption of draft-marques-l3vpn-end-system-07 --> adopted ! Thread-Topic: Poll on adoption of draft-marques-l3vpn-end-system-07 --> adopted ! Thread-Index: AQHNogz9SKfSJpN3G02LWyVSl2Zb1A== Date: Thu, 4 Oct 2012 08:48:13 +0000 Message-ID: <31848_1349340494_506D4D4E_31848_921_2_506D4DA6.6080800@orange.com> References: <5059BB51.5050501@orange.com> In-Reply-To: <5059BB51.5050501@orange.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:15.0) Gecko/20120907 Thunderbird/15.0.1 x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="utf-8" Content-ID: <2E15C615C3C0174F81329CB5EC681097@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.6.19.115414 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, 04 Oct 2012 08:48:16 -0000 SGVsbG8sDQoNClRoaXMgY2FsbCBmb3IgYWRvcHRpb24gaXMgY2xvc2VkIGFuZCB3ZSBoYXZlIGNv bnNlbnN1cyB0byBhZG9wdCANCmRyYWZ0LW1hcnF1ZXMtbDN2cG4tZW5kLXN5c3RlbSBhcyBhIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNCkNhbiB0aGUgYXV0aG9ycyBwbGVhc2UgcmVzdWJtaXQg YXMgZHJhZnQtaWV0Zi1sM3Zwbi1lbmQtc3lzdGVtLTAwID8NCg0KVGhhbmtzLA0KDQotVGhvbWFz DQoNCg0KVGhvbWFzIE1vcmluIDoNCj4gSGVsbG8gd29ya2luZyBncm91cCwNCj4NCj4gR2l2ZW4g dGhlIHN0cm9uZyBpbnRlcmVzdCBmb3IgdGhlIHByb3Bvc2FsIGluIA0KPiBkcmFmdC1tYXJxdWVz LWwzdnBuLWVuZC1zeXN0ZW0tMDcsIGFzIGV4cHJlc3NlZCBkdXJpbmcgb3VyIGxhc3QgDQo+IG1l ZXRpbmcgaW4gVmFuY291dmVyLCB3ZSB3b3VsZCBsaWtlIHRvIHBvbGwgdGhlIFdHIGFib3V0IGFk b3B0aW5nIHRoaXMgDQo+IGRyYWZ0IGluIEwzVlBOLg0KPg0KPiBZb3UgY2FuIHJlYWQgdGhlIGRy YWZ0IGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXJxdWVzLWwzdnBu LWVuZC1zeXN0ZW0tMDcgDQo+IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXJx dWVzLWwzdnBuLWVuZC1zeXN0ZW0tMDc+DQo+DQo+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRo ZSBsaXN0IGFuZCBzdGF0ZSBpZiB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBvciANCj4gbm90IChpbiB0 aGUgbGF0ZXIgY2FzZSwgcGxlYXNlIGFsc28gc3RhdGUgdGhlIHJlYXNvbnMpLg0KPg0KPiBUaGlz IHBvbGwgcnVucyB1bnRpbCBPY3RvYmVyIDJuZC4NCj4NCj4gQ29pbmNpZGVudGFsbHksIHdlIGFy ZSBhbHNvIHBvbGxpbmcgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgDQo+IGFwcGxpZXMg dG8gdGhpcyBkcmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiAN Cj4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAz NjY5IGFuZCA1Mzc4IGZvciANCj4gbW9yZSBkZXRhaWxzKS4NCj4NCj4gSWYgeW91IGFyZSBsaXN0 ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgDQo+ IHRvIHRoaXMgZW1haWwgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZh bnQgSVBSLiBUaGUgDQo+IGRyYWZ0IHdpbGwgbm90IGJlIGFkb3B0ZWQgdW50aWwgYSByZXNwb25z ZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggDQo+IGF1dGhvciBhbmQgY29udHJpYnV0b3Iu DQo+DQo+IElmIHlvdSBhcmUgb24gdGhlIEwzVlBOIFdHIG1haWxpbmcgbGlzdCBidXQgYXJlIG5v dCBsaXN0ZWQgYXMgYW4gDQo+IGF1dGhvciBvciBjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhw bGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSANCj4gYXdhcmUgb2YgYW55IElQUiB0aGF0 IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggDQo+IElFVEYg cnVsZXMuDQo+DQo+IFRoYW5rIHlvdSwNCj4NCj4gVGhvbWFzIGFuZCBNYXJ0aW4sDQo+IGwzdnBu IGNoYWlycw0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApGcmFuY2UgVGVsZWNvbSAtIE9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5r IHlvdS4KCg== From thomas.morin@orange.com Thu Oct 4 02:34:15 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 0984121F8679 for ; Thu, 4 Oct 2012 02:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 I8u7OEMkYO1p for ; Thu, 4 Oct 2012 02:34:14 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) by ietfa.amsl.com (Postfix) with ESMTP id 35FEE21F865E for ; Thu, 4 Oct 2012 02:34:14 -0700 (PDT) Received: from home.treizh.net ([92.139.17.13]) by mwinf5d68 with ME id 6xaC1k00c0Gv3mc03xaCXz; Thu, 04 Oct 2012 11:34:13 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by home.treizh.net (Postfix) with ESMTP id 6352A7626F7 for ; Thu, 4 Oct 2012 11:34:11 +0200 (CEST) Message-ID: <506D586A.1030202@orange.com> Date: Thu, 04 Oct 2012 11:35:38 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: L3VPN Subject: WG Last Call for draft-ietf-l3vpn-virtual-hub 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, 04 Oct 2012 09:34:15 -0000 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 marco@juniper.net Thu Oct 4 07:49:34 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 8611021F86C3 for ; Thu, 4 Oct 2012 07:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 ZimCGS+S-OJY for ; Thu, 4 Oct 2012 07:49:33 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id BC7E821F86B9 for ; Thu, 4 Oct 2012 07:49:33 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUG2h/cxHC0YZQrrWJoBAAcpmjJalJrtH@postini.com; Thu, 04 Oct 2012 07:49:33 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 4 Oct 2012 07:48:49 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 4 Oct 2012 07:48:49 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 4 Oct 2012 07:50:42 -0700 Received: from mail38-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Thu, 4 Oct 2012 14:48:48 +0000 Received: from mail38-co1 (localhost [127.0.0.1]) by mail38-co1-R.bigfish.com (Postfix) with ESMTP id A732DA000FB for ; Thu, 4 Oct 2012 14:48:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.237.149; KIP:(null); UIP:(null); (null); H:BY2PRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dI9371I1432Izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944he5bhf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail38-co1 (localhost.localdomain [127.0.0.1]) by mail38-co1 (MessageSwitch) id 1349362127257012_7509; Thu, 4 Oct 2012 14:48:47 +0000 (UTC) Received: from CO1EHSMHS003.bigfish.com (unknown [10.243.78.235]) by mail38-co1.bigfish.com (Postfix) with ESMTP id 3A9F748004C; Thu, 4 Oct 2012 14:48:47 +0000 (UTC) Received: from BY2PRD0511HT005.namprd05.prod.outlook.com (157.56.237.149) by CO1EHSMHS003.bigfish.com (10.243.66.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 4 Oct 2012 14:48:46 +0000 Received: from BY2PRD0511MB440.namprd05.prod.outlook.com ([169.254.11.251]) by BY2PRD0511HT005.namprd05.prod.outlook.com ([10.255.129.40]) with mapi id 14.16.0207.009; Thu, 4 Oct 2012 14:48:43 +0000 From: Marco Rodrigues To: L3VPN Subject: Re: WG Last Call for draft-ietf-l3vpn-virtual-hub Thread-Topic: WG Last Call for draft-ietf-l3vpn-virtual-hub Thread-Index: AQHNohNyg6tqoevXv0Kse1KaEbHTGpeo93SA Date: Thu, 4 Oct 2012 14:48:42 +0000 Message-ID: In-Reply-To: <506D586A.1030202@orange.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.255.129.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <04EDBB31B0F8AE4DAB6CA4B08CCEBFBF@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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, 04 Oct 2012 14:49:34 -0000 Support.=20 Marco. On 10/4/12 5:35 AM, "Thomas Morin" wrote: >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 ss2539@att.com Thu Oct 4 08:00:53 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 06F3221F86DB for ; Thu, 4 Oct 2012 08:00:53 -0700 (PDT) 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 cbxRYWv817kd for ; Thu, 4 Oct 2012 08:00:52 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 6279821F86C1 for ; Thu, 4 Oct 2012 08:00:52 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 3a4ad605.0.1534916.00-338.4263726.nbfkord-smmo04.seg.att.com (envelope-from ); Thu, 04 Oct 2012 15:00:52 +0000 (UTC) X-MXL-Hash: 506da4a42a3f7f50-eca41c81bb826e2e97a829d8bdc7c2301d271192 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 q94F0pXt005655; Thu, 4 Oct 2012 11:00:51 -0400 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 q94F0iaX005347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 11:00:47 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by sflint01.pst.cso.att.com (RSA Interceptor); Thu, 4 Oct 2012 11:00:30 -0400 Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 11:00:30 -0400 From: "SAAD, SAMIR S" To: L3VPN Subject: RE: WG Last Call for draft-ietf-l3vpn-virtual-hub Thread-Topic: WG Last Call for draft-ietf-l3vpn-virtual-hub Thread-Index: AQHNohNweFT3owc0d0yVcBoRN8XrS5epO6gA Date: Thu, 4 Oct 2012 15:00:30 +0000 Message-ID: <438B11A5EC21D347A63ACB77E58C78BA1B3538@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <506D586A.1030202@orange.com> In-Reply-To: <506D586A.1030202@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.32.55] 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=BcJvJMR2 c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=ll1CIi-hfRQA:10 a=sSzgKg6O58wA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=uhbfMXg163oA:10 a=48vgC7mUAAAA:8 a=ua8lMKEHeTeIGL] X-AnalysisOut: [YRykYA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10] 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, 04 Oct 2012 15:00:53 -0000 U3VwcG9ydA0KDQpTYW1pciBTYWFkDQpBVCZUIExhYnMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGwzdnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsM3Zwbi1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGhvbWFzIE1vcmluDQpTZW50OiBUaHVyc2RheSwgT2N0 b2JlciAwNCwgMjAxMiA1OjM2IEFNDQpUbzogTDNWUE4NClN1YmplY3Q6IFdHIExhc3QgQ2FsbCBm b3IgZHJhZnQtaWV0Zi1sM3Zwbi12aXJ0dWFsLWh1Yg0KDQpIZWxsbyB3b3JraW5nIGdyb3VwLA0K DQpUaGlzIGVtYWlsIHN0YXJ0cyBhIHR3by13ZWVrIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9u DQpkcmFmdC1pZXRmLWwzdnBuLXZpcnR1YWwtaHViLCB3aGljaCBpcyBjb25zaWRlcmVkIG1hdHVy ZSBhbmQgcmVhZHkgZm9yIGENCndvcmtpbmcgZ3JvdXAgcmV2aWV3Lg0KDQpQbGVhc2UgcmVhZCB0 aGUgZG9jdW1lbnQgaWYgeW91IGhhdmVuJ3QgcmVhZCB0aGUgbW9zdCByZWNlbnQgdmVyc2lvbiwN CmFuZCBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QsIG5vIGxhdGVyIHRoYW4gVGh1cnNk YXkgT2N0b2JlciAxOHRoLg0KDQpUaGFuayB5b3UsDQoNCi1UaG9tYXMgJiBNYXJ0aW4NCg0KWyBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWwzdnBuLXZpcnR1YWwtaHViIF0N Cg0K From thomas.morin@orange.com Thu Oct 4 08:12: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 1E6FA11E80DC for ; Thu, 4 Oct 2012 08:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 cuSc1M3DFQzD for ; Thu, 4 Oct 2012 08:12:21 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) by ietfa.amsl.com (Postfix) with ESMTP id 581FE11E80D9 for ; Thu, 4 Oct 2012 08:12:21 -0700 (PDT) Received: from home.treizh.net ([92.139.17.13]) by mwinf5d07 with ME id 73CK1k00W0Gv3mc033CKMP; Thu, 04 Oct 2012 17:12:19 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by home.treizh.net (Postfix) with ESMTP id 6C163762B2A for ; Thu, 4 Oct 2012 17:12:18 +0200 (CEST) Message-ID: <506DA7AA.5000200@orange.com> Date: Thu, 04 Oct 2012 17:13:46 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: l3vpn@ietf.org 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: 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, 04 Oct 2012 15:12:22 -0000 Hello working group, One precision... A working group last call is essentially the opportunity to raise comments that would not have been made before to be made now, before the document moves to IESG, and the opportunity for those who haven't read it yet to realize that it is the right time to do so before processes get heavier. Advertising "support" is harmless but less useful than more detailed reviews or, for instance, explanations why than the work is considered important or statements that the work is mature. -Thomas Thomas Morin : > 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 hj2387@att.com Thu Oct 4 07:56: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 861B921F86EB for ; Thu, 4 Oct 2012 07:56:41 -0700 (PDT) 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 xpRHfz44WZAj for ; Thu, 4 Oct 2012 07:56:41 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id B9CC621F86DD for ; Thu, 4 Oct 2012 07:56:40 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 8a3ad605.0.2875.00-460.8230.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 04 Oct 2012 14:56:40 +0000 (UTC) X-MXL-Hash: 506da3a879b04919-09f4ca0df2486cf69e5ff7b8a4eba70987fa25bc Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q94EudKq008763; Thu, 4 Oct 2012 07:56:39 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q94EuU7p008636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 07:56:32 -0700 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by fflint03.pst.cso.att.com (RSA Interceptor); Thu, 4 Oct 2012 07:56:09 -0700 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 10:56:05 -0400 From: "JENG, HUAJIN" To: L3VPN Subject: RE: WG Last Call for draft-ietf-l3vpn-virtual-hub Thread-Topic: WG Last Call for draft-ietf-l3vpn-virtual-hub Thread-Index: AQHNoj26hLDOYeclwkKKn4rK6VlZ+pepO/Qw Date: Thu, 4 Oct 2012 14:56:04 +0000 Message-ID: <6A9BBBEC91E7544BA6D6A577899EDACC182EEA@MISOUT7MSGUSR9O.ITServices.sbc.com> References: <201210041435.q94EZWh29768@magenta.juniper.net> In-Reply-To: <201210041435.q94EZWh29768@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.136.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=U4gl+5Xu c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=xpurFZ7dxmYA:10 a=sSzgKg6O58wA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=uhbfMXg163oA:10 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=kGgGCePH_HyIS1qp_fkA:9 a=CjuIK1q_8ugA:10 a=oAXR_kdF8uMA] X-AnalysisOut: [:10 a=lZB815dzVvQA:10] X-Mailman-Approved-At: Thu, 04 Oct 2012 08:17:20 -0700 Cc: Yakov Rekhter , "thomas.morin@orange.com" 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, 04 Oct 2012 14:56:41 -0000 Support=20 ------------------- Date: Thu, 04 Oct 2012 11:35:38 +0200 From: Thomas Morin To: L3VPN Subject: WG Last Call for draft-ietf-l3vpn-virtual-hub Hello working group, This email starts a two-week Working Group Last Call on=20 draft-ietf-l3vpn-virtual-hub, which is considered mature and ready for a=20 working group review. Please read the document if you haven't read the most recent version,=20 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 kurapati@juniper.net Thu Oct 4 08:28:20 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 5334921F86FD for ; Thu, 4 Oct 2012 08:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 mYMVuxEhoHOv for ; Thu, 4 Oct 2012 08:28:19 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id B78F621F86FC for ; Thu, 4 Oct 2012 08:28:19 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUG2rE/UwBjm1925BtcZshLyS/bxyv4lE@postini.com; Thu, 04 Oct 2012 08:28:19 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 4 Oct 2012 08:27:23 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 4 Oct 2012 08:27:21 -0700 Received: from AM1EHSOBE003.bigfish.com (213.199.154.204) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 4 Oct 2012 08:32:50 -0700 Received: from mail46-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 4 Oct 2012 15:27:19 +0000 Received: from mail46-am1 (localhost [127.0.0.1]) by mail46-am1-R.bigfish.com (Postfix) with ESMTP id D59EB1E007C for ; Thu, 4 Oct 2012 15:27:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.241.149; KIP:(null); UIP:(null); (null); H:BL2PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zz9371Id6eah542Mzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail46-am1 (localhost.localdomain [127.0.0.1]) by mail46-am1 (MessageSwitch) id 1349364438387476_7797; Thu, 4 Oct 2012 15:27:18 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.230]) by mail46-am1.bigfish.com (Postfix) with ESMTP id 59D264600F1; Thu, 4 Oct 2012 15:27:18 +0000 (UTC) Received: from BL2PRD0511HT002.namprd05.prod.outlook.com (157.56.241.149) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 4 Oct 2012 15:27:15 +0000 Received: from BL2PRD0511MB433.namprd05.prod.outlook.com ([169.254.9.105]) by BL2PRD0511HT002.namprd05.prod.outlook.com ([10.255.131.37]) with mapi id 14.16.0207.009; Thu, 4 Oct 2012 15:27:13 +0000 From: Pavan Kurapati To: L3VPN Subject: RE: WG Last Call for draft-ietf-l3vpn-virtual-hub Thread-Topic: WG Last Call for draft-ietf-l3vpn-virtual-hub Thread-Index: AQHNoj26eP0ybTSV0E63h8EZADFuapepO/QwgAAI7TA= Date: Thu, 4 Oct 2012 15:27:12 +0000 Message-ID: References: <201210041435.q94EZWh29768@magenta.juniper.net> <6A9BBBEC91E7544BA6D6A577899EDACC182EEA@MISOUT7MSGUSR9O.ITServices.sbc.com> In-Reply-To: <6A9BBBEC91E7544BA6D6A577899EDACC182EEA@MISOUT7MSGUSR9O.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Yakov Rekhter , "thomas.morin@orange.com" 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, 04 Oct 2012 15:28:20 -0000 Support -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of J= ENG, HUAJIN Sent: Thursday, October 04, 2012 10:56 AM To: L3VPN Cc: Yakov Rekhter; thomas.morin@orange.com Subject: RE: WG Last Call for draft-ietf-l3vpn-virtual-hub Support ------------------- Date: Thu, 04 Oct 2012 11:35:38 +0200 From: Thomas Morin To: L3VPN Subject: WG Last Call for draft-ietf-l3vpn-virtual-hub Hello working group, This email starts a two-week Working Group Last Call on draft-ietf-l3vpn-vi= rtual-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 s= end 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 internet-drafts@ietf.org Thu Oct 4 10:03:29 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 D942B11E80D9; Thu, 4 Oct 2012 10:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 F+yqSX2B7417; Thu, 4 Oct 2012 10:03:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADD921F8694; Thu, 4 Oct 2012 10:03:29 -0700 (PDT) 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-end-system-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121004170329.10546.57108.idtracker@ietfa.amsl.com> Date: Thu, 04 Oct 2012 10:03:29 -0700 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, 04 Oct 2012 17:03:30 -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 : BGP-signaled end-system IP/VPNs. Author(s) : Pedro Marques Luyuan Fang Ping Pan Amit Shukla Maria Napierala Nabil Bitar Filename : draft-ietf-l3vpn-end-system-00.txt Pages : 21 Date : 2012-10-04 Abstract: This document describes a solution in which the control plane protocol specified in BGP/MPLS IP VPNs [RFC4364] is used to provide a Virtual Network service to end-systems. These end-systems may be used to provide network services or may directly host end-to-end applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rraszuk@gmail.com Thu Oct 4 11:18: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 BB45321F862A for ; Thu, 4 Oct 2012 11:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.966 X-Spam-Level: X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 uPsAEglB2wfh for ; Thu, 4 Oct 2012 11:18:39 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA6AB21F8624 for ; Thu, 4 Oct 2012 11:18:39 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so392147iad.31 for ; Thu, 04 Oct 2012 11:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/kJw1YzCSOFfAdtNRahhKE4tkBrQ8Qn8j2vd/q7sdDE=; b=svR37EyeMg3rvm14pJ0HpS89RegqllhbOFytah3GXDxOhI503HhTEkoazbgM42g/7B 9HfammV5/nWOd/VieYDLLKvMdsgpGAI4ZboWNn7tX4gMg3Ei0Q5bVWWN8UyEHs2fFhfr 6jksk09H57c5FTyoF5N7DgDZQh6TXsGYrv967ffgZIXE/DrPXrlhBqdMtXaEPxS6mWVz VAiQyUIHhRM0pkdgzOzTzLdclDojqWdPF/uTuRwEhHSIby2ce6k5lqm6Fk7aKuKwG4uQ 0tyfTtcV6pkjMM5jufDbtkJ86eyAHKlLNSy+MwG2DgyDaQjgd8e7ta2W9TB0b59KsuzK b/ww== MIME-Version: 1.0 Received: by 10.50.91.169 with SMTP id cf9mr16271936igb.44.1349374719361; Thu, 04 Oct 2012 11:18:39 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Thu, 4 Oct 2012 11:18:39 -0700 (PDT) In-Reply-To: <506D586A.1030202@orange.com> References: <506D586A.1030202@orange.com> Date: Thu, 4 Oct 2012 20:18:39 +0200 X-Google-Sender-Auth: RSFg17Eswh_tV-qpR_JY0Dw_0GI Message-ID: Subject: Re: WG Last Call for draft-ietf-l3vpn-virtual-hub From: Robert Raszuk To: Thomas Morin Content-Type: text/plain; charset=ISO-8859-1 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, 04 Oct 2012 18:18:41 -0000 Hello Thomas, I think the draft is useful however as communicated to authors of this draft on 2nd Aug 2011 I am of the opinion that it should be extended to accomodate even further scaling enhancements not just for SP PEs but also for actual customer VPN sites. What I have suggested over a year ago was the extension of this proposal to CSC case where virtual hub is placed in the service provider network as given customer's VPN hub and where optimal forwarding decision can be computed for routing site to site customer traffic. That idea is in fact simpler then the one proposed in the current draft as it does not require import/export RT configuration at the virtual hub. Instead just like in plane vanilla CSC case each customer's routes are handled separately and placed into appropriate virtual hub. Moreover even going further scaling of such virtual hubs residing in strategic locations of SP core infrastructure could be accomplished with simple grid computing or distributed routing platforms being fully transparent to any need for additional PE's configuration or what perhaps is more important any per VPN churn in routing information. To realize this model non of the currently deployed PEs would need to be upgraded or even reconfigured provided given SP already provides CSC service. Last but not least the data plane outer encapsulation of such virtual hub could be IP (GRE) therefor opening new opportunities for offering CSC type of VPNs for much larger customer base then currently limited to only those sites which are directly attached to given's SP infrastructure. Best regards, R. On Thu, Oct 4, 2012 at 11:35 AM, Thomas Morin wrote: > 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 martin.vigoureux@alcatel-lucent.com Fri Oct 5 04:27:08 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 D109A21F86CA for ; Fri, 5 Oct 2012 04:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.649 X-Spam-Level: X-Spam-Status: No, score=-109.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 vDRO1deIYZnG for ; Fri, 5 Oct 2012 04:27:08 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 29A8F21F86C6 for ; Fri, 5 Oct 2012 04:27:07 -0700 (PDT) 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 q95BQx4u021262 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 5 Oct 2012 13:27:05 +0200 Received: from [172.27.205.186] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 5 Oct 2012 13:27:01 +0200 Message-ID: <506EC404.6010303@alcatel-lucent.com> Date: Fri, 5 Oct 2012 13:27:00 +0200 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: Slots requests for IETF 85 - Atlanta Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 05 Oct 2012 11:27:08 -0000 Dear all, the L3VPN WG will meet in Atlanta. The session (still subject to change) is scheduled Friday, Morning Session I, 09:00-11:00. This is thus a call for presentation slots. Could you please send us your requests, before October 24th, indicating: draft name, speaker and desired duration (presentation + Q&As). Thank you. Martin for the L3VPN co-chairs From bruno.decraene@orange.com Fri Oct 5 08:57:13 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 085C021F8770 for ; Fri, 5 Oct 2012 08:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 ATix5P3dn0qN for ; Fri, 5 Oct 2012 08:57:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC1021F8762 for ; Fri, 5 Oct 2012 08:57:12 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id A649B2DC14B for ; Fri, 5 Oct 2012 17:57:11 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8EC1935C045 for ; Fri, 5 Oct 2012 17:57:11 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Fri, 5 Oct 2012 17:57:09 +0200 From: To: MORIN Thomas OLNC/OLN Subject: RE: WG Last Call for draft-ietf-l3vpn-virtual-hub Thread-Topic: WG Last Call for draft-ietf-l3vpn-virtual-hub Thread-Index: AQHNohNu+XxMc5jIGkC99hfLCsZ96JeqUVgw Date: Fri, 5 Oct 2012 15:57:08 +0000 Message-ID: <6050_1349452631_506F0357_6050_2598_1_6ba1a50d-323e-414a-b512-477cd00be8d4@PEXCVZYH01.corporate.adroot.infra.ftgroup> References: <506D586A.1030202@orange.com> In-Reply-To: <506D586A.1030202@orange.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="utf-8" 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.5.124533 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: Fri, 05 Oct 2012 15:57:13 -0000 SGVsbG8gVGhvbWFzLCBNYXJ0aW4sIA0KDQpJIGhhdmUgcmVhZCB0aGUgZHJhZnQgYW5kIGJlbGll dmUgaXQncyByZWFkeSBmb3Igc3VibWlzc2lvbiB0byB0aGUgSUVTRy4NCg0KSXQncyBhIHVzZWZ1 bCBwcm9wb3NpdGlvbiB0byBpbXByb3ZlIHRoZSBzY2FsYWJpbGl0eSBvZiBzb21lIFBFLiBJbiBw YXJ0aWN1bGFyIGluIHRoZSBjb250ZXh0IHdoZXJlIElQL01QTFMgbmV0d29ya3MgYXJlIGV4cGFu ZGluZyBmcm9tIHRoZSBjb3JlIHRvIHRoZSBhZ2dyZWdhdGlvbiBwYXJ0IG9mIHRoZSBuZXR3b3Jr LCB3aGVyZSBnaXZlbiBib3RoIHRoZSBzbWFsbGVyIG51bWJlciBvZiBjdXN0b21lcnMgdXNpbmcg aXQgYW5kIHRoZSBsYXJnZSBudW1iZXIgb2YgZXF1aXBtZW50cyBhbmQgbG9jYXRpb25zLCBzdWNo IFBFIGFyZSBtb3JlIGxpa2VseSB0byBiZSBjaG9zZW4gc21hbGxlciBhbmQvb3IgcmVwbGFjZWQg bGVzcyBvZnRlbi4NCkFsc28sIHRoZSBzb2x1dGlvbiBjYW4gYmUgZGVwbG95ZWQgaW5jcmVtZW50 YWxseSB3aXRoIGluY3JlbWVudGFsIGJlbmVmaXQuDQoNClRoYW5rIHlvdSwNClJlZ2FyZHMsDQpC cnVubw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBsM3Zwbi1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bDN2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ VGhvbWFzIE1vcmluDQo+U2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDQsIDIwMTIgMTE6MzYgQU0N Cj5UbzogTDNWUE4NCj5TdWJqZWN0OiBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtbDN2cG4t dmlydHVhbC1odWINCj4NCj5IZWxsbyB3b3JraW5nIGdyb3VwLA0KPg0KPlRoaXMgZW1haWwgc3Rh cnRzIGEgdHdvLXdlZWsgV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24NCj5kcmFmdC1pZXRmLWwz dnBuLXZpcnR1YWwtaHViLCB3aGljaCBpcyBjb25zaWRlcmVkIG1hdHVyZSBhbmQgcmVhZHkgZm9y IGENCj53b3JraW5nIGdyb3VwIHJldmlldy4NCj4NCj5QbGVhc2UgcmVhZCB0aGUgZG9jdW1lbnQg aWYgeW91IGhhdmVuJ3QgcmVhZCB0aGUgbW9zdCByZWNlbnQgdmVyc2lvbiwNCj5hbmQgc2VuZCB5 b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBubyBsYXRlciB0aGFuIFRodXJzZGF5IE9jdG9iZXIg MTh0aC4NCj4NCj5UaGFuayB5b3UsDQo+DQo+LVRob21hcyAmIE1hcnRpbg0KPg0KPlsgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sM3Zwbi12aXJ0dWFsLWh1YiBdDQoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl cHRpYmxlcyBkJ2FsdGVyYXRpb24sCkZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZy YW5jZSBUZWxlY29tIC0gT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2 ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From luayjalil@gmail.com Sun Oct 7 22:56:11 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 B914521F8720 for ; Sun, 7 Oct 2012 22:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 d7PapLG2VGRM for ; Sun, 7 Oct 2012 22:56:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB09C21F8615 for ; Sun, 7 Oct 2012 22:56:10 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so4158330obq.31 for ; Sun, 07 Oct 2012 22:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=OYgVivmSA2HCf1LKpvTNbXz7gvZwApHGCanjWz9VLSQ=; b=TErgYN73Pwv2WhiCx+K9KiIz3lyUcQAuo9JqTUJJlr38DuDdGqmCMM4BmECYcSM2ZF HEkRTXxG0L4/hy0Fsj4PIxua/B0IWSz8s8rjAyPl2x87WJ9hVacaENuiZ6NN5/W/CwZj QKg+l06vVt98SfoCs8Wqw9qmuBNONX9Z01IPi3+h4KZAIb7mnCMEXrMFt85Ond9J7rRg 63EdndV33Ja6QIqdciXPD7w+ZbDQCTjod2DFqtbZGIsXBF9r0X5+FVQB5l2C0uUQ+3Y4 xggzw3GUWH3Mey6SuFIH67++nuV7STMvegbbqcILiIx4j88Ru0OJAd+TBVSP2o1YZ8FB asWQ== Received: by 10.60.14.233 with SMTP id s9mr12195099oec.53.1349675770421; Sun, 07 Oct 2012 22:56:10 -0700 (PDT) Received: from Xlr8r (76-204-212-98.lightspeed.allntx.sbcglobal.net. [76.204.212.98]) by mx.google.com with ESMTPS id b5sm16835499obd.18.2012.10.07.22.56.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 07 Oct 2012 22:56:09 -0700 (PDT) From: "Luay Jalil" To: "'L3VPN'" References: <506D586A.1030202@orange.com> In-Reply-To: <506D586A.1030202@orange.com> Subject: RE: WG Last Call for draft-ietf-l3vpn-virtual-hub Date: Mon, 8 Oct 2012 00:56:12 -0500 Message-ID: <024201cda519$a0f3f380$e2dbda80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2iE27DxOng5FmaSM+z0SMHNqiX0ABZWoXA Content-Language: en-us Cc: 'Thomas Morin' X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: luayjalil@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 05:56:11 -0000 Support (co-author) This draft is useful in reducing the number of routes on some of the PEs = in an MPLS VPN environment Regards, Luay Jalil -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of Thomas Morin Sent: Thursday, October 04, 2012 4:36 AM To: L3VPN Subject: WG Last Call for draft-ietf-l3vpn-virtual-hub 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 martin.vigoureux@alcatel-lucent.com Mon Oct 8 02:17:15 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 6E71221F875C for ; Mon, 8 Oct 2012 02:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.799 X-Spam-Level: X-Spam-Status: No, score=-109.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 P0kPSPeTHrVd for ; Mon, 8 Oct 2012 02:17:14 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id A5A1A21F86CA for ; Mon, 8 Oct 2012 02:17:14 -0700 (PDT) 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 q989GTg1009162 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 8 Oct 2012 11:17:12 +0200 Received: from [172.27.205.186] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Oct 2012 11:16:59 +0200 Message-ID: <50729A0B.6030201@alcatel-lucent.com> Date: Mon, 8 Oct 2012 11:16:59 +0200 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: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 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, 08 Oct 2012 09:17:15 -0000 Hello working group, this is to start a two weeks poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 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 October 22nd. 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 From wim.henderickx@alcatel-lucent.com Mon Oct 8 02:43:11 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 609C821F876E for ; Mon, 8 Oct 2012 02:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.549 X-Spam-Level: X-Spam-Status: No, score=-9.549 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 aRtSNikwcd7f for ; Mon, 8 Oct 2012 02:43:11 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4155821F8732 for ; Mon, 8 Oct 2012 02:43:10 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q989h3mi027740 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 8 Oct 2012 11:43:06 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 8 Oct 2012 11:42:48 +0200 From: "Henderickx, Wim (Wim)" To: "VIGOUREUX, MARTIN (MARTIN)" , "l3vpn@ietf.org" Date: Mon, 8 Oct 2012 11:42:47 +0200 Subject: RE: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Thread-Topic: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Thread-Index: Ac2lNb02w4Ol9t2ISEq10M2wwC7H7wAA4Qig Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702E1CE71BB@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <50729A0B.6030201@alcatel-lucent.com> In-Reply-To: <50729A0B.6030201@alcatel-lucent.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 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, 08 Oct 2012 09:43:11 -0000 Support, not aware of IPR -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of M= artin Vigoureux Sent: maandag 8 oktober 2012 11:17 To: l3vpn@ietf.org Subject: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Hello working group, this is to start a two weeks poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 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 October 22nd. 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 From william.zayas@fibercrossing.net Mon Oct 8 05:03: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 5502E21F85EA for ; Mon, 8 Oct 2012 05:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.062 X-Spam-Level: X-Spam-Status: No, score=0.062 tagged_above=-999 required=5 tests=[AWL=-0.351, 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 UBxqk7SGRHpc for ; Mon, 8 Oct 2012 05:03:51 -0700 (PDT) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id A213521F8559 for ; Mon, 8 Oct 2012 05:03:51 -0700 (PDT) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id q98C3lml029862 for ; Mon, 8 Oct 2012 08:03:47 -0400 Message-Id: <201210081203.q98C3lml029862@atl4mhob10.myregisteredsite.com> Received: (qmail 2580 invoked by uid 0); 8 Oct 2012 12:03:47 -0000 Received: from unknown (HELO ?192.168.1.116?) (william.zayas@fibercrossing.net@76.110.101.202) by 0 with ESMTPA; 8 Oct 2012 12:03:47 -0000 To: "=?utf-8?B?SGVuZGVyaWNreCwgV2ltIChXaW0p?=" , "=?utf-8?B?VklHT1VSRVVYLCBNQVJUSU4gKE1BUlRJTik=?=" , "=?utf-8?B?bDN2cG5AaWV0Zi5vcmc=?=" From: "=?utf-8?B?V2lsbGlhbSBaYXlhcw==?=" Subject: =?utf-8?B?UmU6IFBvbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LXJvc2VuLWwzdnBuLW12cG4t?= =?utf-8?B?bWxkcC1ubHJpLTAx?= Date: Mon, 08 Oct 2012 08:03:47 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1349697827005" 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, 08 Oct 2012 12:03:52 -0000 ------=_Part_0_1349697827005 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U3VwcG9ydCwKCgpPYnJpZ2Fkby4KCgoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAi SGVuZGVyaWNreCwgV2ltIChXaW0pIiA8d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29t PgpUbzogIlZJR09VUkVVWCwgTUFSVElOIChNQVJUSU4pIiA8bWFydGluLnZpZ291cmV1eEBhbGNh dGVsLWx1Y2VudC5jb20+LCAibDN2cG5AaWV0Zi5vcmciIDxsM3ZwbkBpZXRmLm9yZz4KU3ViamVj dDogUG9sbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtcm9zZW4tbDN2cG4tbXZwbi1tbGRwLW5scmkt MDEKRGF0ZTogTW9uLCBPY3QgOCwgMjAxMiA1OjQyIGFtCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tCkZyb206IGwzdnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsM3Zwbi1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluIFZpZ291cmV1eApTZW50OiBtYWFuZGFnIDggb2t0 b2JlciAyMDEyIDExOjE3ClRvOiBsM3ZwbkBpZXRmLm9yZwpTdWJqZWN0OiBQb2xsIGZvciBhZG9w dGlvbiBvZiBkcmFmdC1yb3Nlbi1sM3Zwbi1tdnBuLW1sZHAtbmxyaS0wMQoKSGVsbG8gd29ya2lu ZyBncm91cCwKCnRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2Vla3MgcG9sbCBmb3IgYWRvcHRpb24g b2YKZHJhZnQtcm9zZW4tbDN2cG4tbXZwbi1tbGRwLW5scmktMDEKClBsZWFzZSBzZW5kIGNvbW1l bnRzIHRvIHRoZSBsaXN0IGFuZCBzdGF0ZSBpZiB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBvcgpub3Qg KGluIHRoZSBsYXRlciBjYXNlLCBwbGVhc2UgYWxzbyBzdGF0ZSB0aGUgcmVhc29ucykuCgpUaGlz IHBvbGwgcnVucyB1bnRpbCBPY3RvYmVyIDIybmQuCgpDb2luY2lkZW50YWxseSwgd2UgYXJlIGFs c28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdAphcHBsaWVzIHRvIHRoaXMg ZHJhZnQsIHRvIGVuc3VyZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4KY29tcGxpYW5j ZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5CmFuZCA1Mzc4 IGZvciBtb3JlIGRldGFpbHMpLgoKSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRo b3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8KdGhpcyBlbWFpbCB3aGV0aGVyIG9y IG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoZSBkcmFmdAp3aWxsIG5v dCBiZSBhZG9wdGVkIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNo IGF1dGhvcgphbmQgY29udHJpYnV0b3IuCgpJZiB5b3UgYXJlIG9uIHRoZSBMM1ZQTiBXRyBtYWls aW5nIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvcgpvciBjb250cmlidXRvciwg dGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZgph bnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0 aCBJRVRGIHJ1bGVzLgoKVGhhbmsgeW91LAoKTWFydGluICYgVGhvbWFzCmwzdnBuIGNoYWlycw== ------=_Part_0_1349697827005 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEvL0VOIiAiaHR0cDov L3d3dy53My5vcmcvVFIvaHRtbDQvc3RyaWN0LmR0ZCI+CjxodG1sPjxoZWFkPjwvaGVhZD48Ym9k eT5TdXBwb3J0LDxicj48YnI+PGJyPk9icmlnYWRvLjxicj48YnI+PGJyPjxicj48ZGl2IGlkPSJo dGNfaGVhZGVyIiBzdHlsZT0iIj4tLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tPGJyPkZyb206ICZx dW90O0hlbmRlcmlja3gsIFdpbSAoV2ltKSZxdW90OyAmbHQ7d2ltLmhlbmRlcmlja3hAYWxjYXRl bC1sdWNlbnQuY29tJmd0Ozxicj5UbzogJnF1b3Q7VklHT1VSRVVYLCBNQVJUSU4gKE1BUlRJTikm cXVvdDsgJmx0O21hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQuY29tJmd0OywgJnF1b3Q7 bDN2cG5AaWV0Zi5vcmcmcXVvdDsgJmx0O2wzdnBuQGlldGYub3JnJmd0Ozxicj5TdWJqZWN0OiBQ b2xsIGZvciBhZG9wdGlvbiBvZiBkcmFmdC1yb3Nlbi1sM3Zwbi1tdnBuLW1sZHAtbmxyaS0wMTxi cj5EYXRlOiBNb24sIE9jdCA4LCAyMDEyIDU6NDIgYW08YnI+PGJyPjwvZGl2Pjxicj48cHJlIHN0 eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPgoKLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogbDN2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gVmlnb3VyZXV4 ClNlbnQ6IG1hYW5kYWcgOCBva3RvYmVyIDIwMTIgMTE6MTcKVG86IGwzdnBuQGlldGYub3JnClN1 YmplY3Q6IFBvbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LXJvc2VuLWwzdnBuLW12cG4tbWxkcC1u bHJpLTAxCgpIZWxsbyB3b3JraW5nIGdyb3VwLAoKdGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVr cyBwb2xsIGZvciBhZG9wdGlvbiBvZgpkcmFmdC1yb3Nlbi1sM3Zwbi1tdnBuLW1sZHAtbmxyaS0w MQoKUGxlYXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QgYW5kIHN0YXRlIGlmIHlvdSBzdXBw b3J0IGFkb3B0aW9uIG9yCm5vdCAoaW4gdGhlIGxhdGVyIGNhc2UsIHBsZWFzZSBhbHNvIHN0YXRl IHRoZSByZWFzb25zKS4KClRoaXMgcG9sbCBydW5zIHVudGlsIE9jdG9iZXIgMjJuZC4KCkNvaW5j aWRlbnRhbGx5LCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0 aGF0CmFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVuIGRp c2Nsb3NlZCBpbgpjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5Nzks IDQ4NzksIDM2NjkKYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuCgpJZiB5b3UgYXJlIGxpc3Rl ZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0bwp0 aGlzIGVtYWlsIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQ Ui4gVGhlIGRyYWZ0CndpbGwgbm90IGJlIGFkb3B0ZWQgdW50aWwgYSByZXNwb25zZSBoYXMgYmVl biByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yCmFuZCBjb250cmlidXRvci4KCklmIHlvdSBhcmUg b24gdGhlIEwzVlBOIFdHIG1haWxpbmcgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0 aG9yCm9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBp ZiB5b3UgYXJlIGF3YXJlIG9mCmFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3Nl ZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuCgpUaGFuayB5b3UsCgpNYXJ0aW4gJmFt cDsgVGhvbWFzCmwzdnBuIGNoYWlycwoKPC9wcmU+PC9ib2R5PjwvaHRtbD4= ------=_Part_0_1349697827005-- From ice@cisco.com Mon Oct 8 05:08: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 6F0A621F867B for ; Mon, 8 Oct 2012 05:08:52 -0700 (PDT) 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=3.700, 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 TONW80ru86Q0 for ; Mon, 8 Oct 2012 05:08:52 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2DE21F8622 for ; Mon, 8 Oct 2012 05:08:46 -0700 (PDT) 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 q98C8eEE027628; Mon, 8 Oct 2012 14:08:40 +0200 (CEST) Received: from ams-iwijnand-8716.cisco.com (ams-iwijnand-8716.cisco.com [10.55.191.151]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q98C8dAb017167; Mon, 8 Oct 2012 14:08:40 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Subject: Re: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 From: IJsbrand Wijnands In-Reply-To: <50729A0B.6030201@alcatel-lucent.com> Date: Mon, 8 Oct 2012 14:08:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <672A4A78-0795-49CE-BC35-44F44D9AF228@cisco.com> References: <50729A0B.6030201@alcatel-lucent.com> To: Martin Vigoureux X-Mailer: Apple Mail (2.1486) 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, 08 Oct 2012 12:08:52 -0000 Dear WG, I support (as co-author) and I'm not aware of any IPR. Thx, Ice. On 08 Oct 2012, at 11:16, Martin Vigoureux = wrote: > Hello working group, >=20 > this is to start a two weeks poll for adoption of > draft-rosen-l3vpn-mvpn-mldp-nlri-01 >=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 October 22nd. >=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 > 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. >=20 > Thank you, >=20 > Martin & Thomas > l3vpn chairs >=20 From thomas.morin@orange.com Mon Oct 8 05:21: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 0823A21F8780 for ; Mon, 8 Oct 2012 05:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6] 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 igGq4XQuibxc for ; Mon, 8 Oct 2012 05:21:58 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2305121F877B for ; Mon, 8 Oct 2012 05:21:52 -0700 (PDT) Received: from home.treizh.net ([92.139.17.13]) by mwinf5d06 with ME id 8cMq1k00A0Gv3mc03cMqLg; Mon, 08 Oct 2012 14:21:51 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by home.treizh.net (Postfix) with ESMTP id BB6D4767535 for ; Mon, 8 Oct 2012 14:21:49 +0200 (CEST) Message-ID: <5072C5B4.5090605@orange.com> Date: Mon, 08 Oct 2012 14:23:16 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: l3vpn@ietf.org Subject: Re: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 References: <50729A0B.6030201@alcatel-lucent.com> In-Reply-To: <50729A0B.6030201@alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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, 08 Oct 2012 12:21:59 -0000 Support. -Thomas (no chair hat) Martin Vigoureux a écrit : > Hello working group, > > this is to start a two weeks poll for adoption of > draft-rosen-l3vpn-mvpn-mldp-nlri-01 > > 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 October 22nd. > > 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 From naikumar@cisco.com Mon Oct 8 08:14: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 9039621F87A2 for ; Mon, 8 Oct 2012 08:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 TerWkyoxTGeo for ; Mon, 8 Oct 2012 08:14:42 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0573821F8700 for ; Mon, 8 Oct 2012 08:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1308; q=dns/txt; s=iport; t=1349709282; x=1350918882; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3jz6hp3lGQ0sw3HdMthh72ghSdAjjhznxivk0bZJSfw=; b=jdbUGMUdCkQzFWWHd4yk2QlzPUFXBr4qjuN8rzU1GKTL76iHC7n9fCO7 bQ9yRjBkwWfKpwdAhlBNUdbWcV3CUwhKmBO0P8lxynbGJkCjT7zcrJ5dK 11Qa/jUnYZFpfzuYe21n9BytVBwt8v9HDSLcTlfmG7j8w4sgmaeXY0/Ab M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAP3sclCtJV2c/2dsb2JhbABFvyqBCIIgAQEBBBIBJzQXBAIBCBEEAQELFAkHMhQJCAIEARIIGodjmgafT4tPhTBgA6QwgWmCbYFjNA X-IronPort-AV: E=Sophos;i="4.80,554,1344211200"; d="scan'208";a="126367857" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 08 Oct 2012 15:14:41 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q98FEfgU017217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 15:14:41 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.215]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 10:14:41 -0500 From: "Nagendra Kumar (naikumar)" To: Martin Vigoureux , "l3vpn@ietf.org" Subject: RE: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Thread-Topic: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Thread-Index: AQHNpTW6nn+kBpcU5Uq4fmaocwTSJJevhMuQ Date: Mon, 8 Oct 2012 15:14:41 +0000 Message-ID: <47E76F08F1BCF5458111C1939C7B9C460F5D4253@xmb-rcd-x03.cisco.com> References: <50729A0B.6030201@alcatel-lucent.com> In-Reply-To: <50729A0B.6030201@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.76.63] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--37.057600-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 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, 08 Oct 2012 15:14:42 -0000 Support. Thanks, Nagendra -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of M= artin Vigoureux Sent: Monday, October 08, 2012 2:47 PM To: l3vpn@ietf.org Subject: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Hello working group, this is to start a two weeks poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 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 October 22nd. Coincidentally, we are also polling for knowledge of any IPR that applies t= o 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 thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and contri= butor. 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 IP= R that has not yet been disclosed in conformance with IETF rules. Thank you, Martin & Thomas l3vpn chairs From jeff.tantsura@ericsson.com Mon Oct 8 09:01: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 EF83421F86B5 for ; Mon, 8 Oct 2012 09:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 xwC98fXGiexm for ; Mon, 8 Oct 2012 09:01:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 22C2E21F85B4 for ; Mon, 8 Oct 2012 09:01:05 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q98G07NN031935; Mon, 8 Oct 2012 11:00:08 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.44]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 8 Oct 2012 11:59:25 -0400 From: Jeff Tantsura To: Martin Vigoureux , "l3vpn@ietf.org" Date: Mon, 8 Oct 2012 11:59:24 -0400 Subject: RE: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Thread-Topic: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Thread-Index: Ac2lNbg+2MvxOzyIQ6udreZwbM9eVQAOCG1g Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF627E116EBFF@EUSAACMS0701.eamcs.ericsson.se> References: <50729A0B.6030201@alcatel-lucent.com> In-Reply-To: <50729A0B.6030201@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" 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: Mon, 08 Oct 2012 16:01:06 -0000 Yes/support -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of M= artin Vigoureux Sent: Monday, October 08, 2012 2:17 AM To: l3vpn@ietf.org Subject: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Hello working group, this is to start a two weeks poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 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 October 22nd. Coincidentally, we are also polling for knowledge of any IPR that applies t= o 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 thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and contri= butor. 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 IP= R that has not yet been disclosed in conformance with IETF rules. Thank you, Martin & Thomas l3vpn chairs From agmalis@gmail.com Mon Oct 8 10:38: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 443B221F87E3 for ; Mon, 8 Oct 2012 10:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 oO-SEbPuF4ti for ; Mon, 8 Oct 2012 10:38:23 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 45C3A21F87E4 for ; Mon, 8 Oct 2012 10:38:23 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so3449286lbo.31 for ; Mon, 08 Oct 2012 10:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iLhKkRvf8WMGUkh2zUH1MTNdY+bi2b3Nvr2YeT3QNgM=; b=lBfP92uPWwX+Xt00pU5Lv24koBJSx1mML5xzw83Ue6KFi/sW+QnQmbT/K/+zZu07UK Y0iKVYxeBZUBU8Xv/vz1N0HmuBzA8rRFl/ndwSNsTDxhT/Zym3lKPgzEImVyHfHo08yl lNuUL59X/cMSDAXDzQf4Zk6sjdau+/BBoJVmdA4pDLiZqZ8NkqyVxliq0Ekqfzthspfi iTcr28zxUPgS9m+VaQXGBApsK8xeROWRo0bZ4ptYnT8UErCJcXB673qrxJKimHsBSia8 Wsrs8I/vReUx0Zwf+K3UqEnrQn+JqRoch5bxQaz5sMp+Tr7sJk6Q02SkBRDnn39uaVFb LvKw== Received: by 10.112.24.200 with SMTP id w8mr7107462lbf.116.1349717902116; Mon, 08 Oct 2012 10:38:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.61.5 with HTTP; Mon, 8 Oct 2012 10:38:01 -0700 (PDT) In-Reply-To: <024201cda519$a0f3f380$e2dbda80$@com> References: <506D586A.1030202@orange.com> <024201cda519$a0f3f380$e2dbda80$@com> From: "Andrew G. Malis" Date: Mon, 8 Oct 2012 10:38:01 -0700 Message-ID: Subject: Re: WG Last Call for draft-ietf-l3vpn-virtual-hub To: L3VPN Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 08 Oct 2012 17:38:24 -0000 I agree, the draft improves the efficiency of PE router support for L3 VPNs and is a mature output of the WG. Cheers, Andy On Sun, Oct 7, 2012 at 10:56 PM, Luay Jalil wrote: > Support (co-author) > > This draft is useful in reducing the number of routes on some of the PEs in an MPLS VPN environment > > Regards, > Luay Jalil > > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Thomas Morin > Sent: Thursday, October 04, 2012 4:36 AM > To: L3VPN > Subject: WG Last Call for draft-ietf-l3vpn-virtual-hub > > 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 ss2539@att.com Tue Oct 9 16:07: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 4E23711E80E1 for ; Tue, 9 Oct 2012 16:07:54 -0700 (PDT) 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 tJYMoI-cYerm for ; Tue, 9 Oct 2012 16:07:53 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD9211E80A6 for ; Tue, 9 Oct 2012 16:07:53 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id 94ea4705.2aab06c5d940.887403.00-575.2470407.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 09 Oct 2012 23:07:53 +0000 (UTC) X-MXL-Hash: 5074ae494b7ebaa3-f979b8f45d66566555d8a6d82b7bff0273dc7e42 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 64ea4705.0.887397.00-399.2470382.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 09 Oct 2012 23:07:51 +0000 (UTC) X-MXL-Hash: 5074ae4719d7f575-c84dd226ebd22cb04a90bd343fbbe0846a59c2a2 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 q99N7ofU015509; Tue, 9 Oct 2012 19:07:50 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q99N7dS0015461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2012 19:07:45 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by sflint02.pst.cso.att.com (RSA Interceptor); Tue, 9 Oct 2012 19:07:24 -0400 Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 19:07:23 -0400 From: "SAAD, SAMIR S" To: "l3vpn@ietf.org" Subject: RE: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Thread-Topic: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Thread-Index: AQHNpTW5Wus3ISx0kkO4izoOa76/FZexmwMA Date: Tue, 9 Oct 2012 23:07:22 +0000 Message-ID: <438B11A5EC21D347A63ACB77E58C78BA1B5A29@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <50729A0B.6030201@alcatel-lucent.com> In-Reply-To: <50729A0B.6030201@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.32.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-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=DfugXIRW c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=ll1CIi-hfRQA:10 a=SdLwIh44me8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=g4dwxYRb58kA:10 a=48vgC7mUAAAA:8 a=baAhWA8lT5iT6Q] X-AnalysisOut: [5ADZsA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] 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, 09 Oct 2012 23:07:54 -0000 Support Samir Saad AT&T Labs -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of M= artin Vigoureux Sent: Monday, October 08, 2012 5:17 AM To: l3vpn@ietf.org Subject: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Hello working group, this is to start a two weeks poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 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 October 22nd. 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 From erosen@cisco.com Wed Oct 10 06:34: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 526E521F8722 for ; Wed, 10 Oct 2012 06:34:52 -0700 (PDT) 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 zdtRGEdcdo9d for ; Wed, 10 Oct 2012 06:34:51 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C85FA21F8720 for ; Wed, 10 Oct 2012 06:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47; q=dns/txt; s=iport; t=1349876092; x=1351085692; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=bar8JikJNgZAdt9fKGRaAufDTnwTUoMyuvJt2iUYE3Y=; b=Lr0k3qH7F8MyHgHHzPsGLzfangVf+lrjZw1YDrqx9j937/RUNQZmmwM5 CGLhy+6a6JkNBYDDk6W3oSwGpvkUCR3AjnPj2HLXwGJZTB+zJwkZNwiau RLgCQJuv2sr99Xypn6GRDp63f7Ootzk4LkBJmQezY84xQqJNFuSf4reEj s=; X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="58380782" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 10 Oct 2012 13:34:51 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9ADYoNv015544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2012 13:34:51 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 q9ADYo5c025872; Wed, 10 Oct 2012 09:34:50 -0400 To: Martin Vigoureux Subject: Re: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 In-reply-to: Your message of Mon, 08 Oct 2012 11:16:59 +0200. <50729A0B.6030201@alcatel-lucent.com> Date: Wed, 10 Oct 2012 09:34:49 -0400 Message-ID: <25871.1349876089@erosen-linux> From: Eric Rosen Cc: l3vpn@ietf.org 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, 10 Oct 2012 13:34:52 -0000 Support (as co-author); not aware of any IPR. From jrmitche@puck.nether.net Thu Oct 11 07:39: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 4499321F8628 for ; Thu, 11 Oct 2012 07:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 RVUtRSSV3IZY for ; Thu, 11 Oct 2012 07:39:05 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5853421F85A1 for ; Thu, 11 Oct 2012 07:39:05 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q9BEd4Rs029096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Oct 2012 10:39:04 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q9BEd4fs029095; Thu, 11 Oct 2012 10:39:04 -0400 Date: Thu, 11 Oct 2012 10:39:04 -0400 From: Jon Mitchell To: Thomas Morin Subject: Re: WG Last Call for draft-ietf-l3vpn-virtual-hub Message-ID: <20121011143904.GA22207@puck.nether.net> References: <506D586A.1030202@orange.com> <506DA7AA.5000200@orange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <506DA7AA.5000200@orange.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 11 Oct 2012 10:39:04 -0400 (EDT) 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, 11 Oct 2012 14:39:06 -0000 Support the solution in this draft and it appears to be a well thought out solution to allow a SP who does not want to fundamentally change the service offering (having customer encapsulate/tunnel traffic on the CE, which eliminates IP based services from being offered by the SP) to scale a traditional any-to-any MPLS VPN service. I do have a clarification question though which I probably should have asked before WGLC: 1. It appears that changes are not necessarily required on v-spoke forwarding in all cases. Maybe the document could be more clear about what this higher up in the text (referring to last paragraph of section 4 and middle part of section 5, where an option is presented that would require changes to v-spoke to support the model). Do the authors intend that this capability could be deployed for a VPN if some of the v-spokes are not supporting any behaviors in this draft (defined as "vanilla" in the Overview, which later is never utilized as a term except to talk about existing deployments rather than specific PE's)? Is the only constraint that they should not be receiving a default route from CE and that multi-homed sites are provisioned as v-hubs? If an operator accepts these restrictions appraoch can a "vanilla" PE be a v-spoke or did I miss some other requirement? Thanks, Jon On Thu, Oct 04, 2012 at 05:13:46PM +0200, Thomas Morin wrote: > Hello working group, > > One precision... > > A working group last call is essentially the opportunity to raise > comments that would not have been made before to be made now, before > the document moves to IESG, and the opportunity for those who > haven't read it yet to realize that it is the right time to do so > before processes get heavier. > > Advertising "support" is harmless but less useful than more detailed > reviews or, for instance, explanations why than the work is > considered important or statements that the work is mature. > > -Thomas > > > Thomas Morin : > >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 erosen@cisco.com Fri Oct 12 08:02:13 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 047D921F8685 for ; Fri, 12 Oct 2012 08:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.793 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-8, SARE_SPEC_REPLICA_OBFU=1.812] 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 z0DfQkbkSxds for ; Fri, 12 Oct 2012 08:02:08 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id CBC5B21F867B for ; Fri, 12 Oct 2012 08:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=69865; q=dns/txt; s=iport; t=1350054127; x=1351263727; h=to:subject:in-reply-to:reply-to:date:message-id:from; bh=7YAf/NF4VVovfY78x4m3UsCKMU0DuyBsjit1DkuIciM=; b=OGK1ByHrL3dEpjkDuA1UYBGR/ul6ciZ56RFFNjoDbTjvHvQBcdPaVxrE QZb2CO9Phx8xA6l4BHzgBvoYn3y+0OgD3znWR1GXFqvJF+t3OHBxNYqyW dPqd0s6BAY033yex5IYtA3Lb3hOYALErocMZ7rPM/uwhEBtr+yrSS2Vlz 8=; X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="130984762" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 12 Oct 2012 15:02:07 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9CF26YE002743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Oct 2012 15:02:07 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 q9CF266D023374; Fri, 12 Oct 2012 11:02:06 -0400 To: L3VPN Subject: Last Call comments on draft-ietf-l3vpn-virtual-hub In-reply-to: Your message of Thu, 04 Oct 2012 11:35:38 +0200. <506D586A.1030202@orange.com> Date: Fri, 12 Oct 2012 11:02:06 -0400 Message-ID: <23373.1350054126@erosen-linux> From: Eric Rosen X-Mailman-Approved-At: Fri, 12 Oct 2012 08:04:23 -0700 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: Fri, 12 Oct 2012 15:02:13 -0000 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. - 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. 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. - 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 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. - 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. - 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. 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. - 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. 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. - 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.) 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. - 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". - 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. More comments appear in-line. ... 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. 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. Also, it's not clear what is meant by "redistribute the Eric> replication load", or why this 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? 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. Eric> However, this does contradict the second paragraph of this section. 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.) 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. 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. 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? 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" plus two or more VPN-IP default routes whose Eric> "one or more"? 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.) 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. 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. 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. 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. 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"? 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. 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. 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. 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. 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". 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 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). 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. 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? 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 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? 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. 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. 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. 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". 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". 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. 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"? 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. 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. 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". 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". 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. 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 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)? 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. 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. 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. 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. 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. 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. 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. 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. 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"? 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 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. 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. 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? 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. 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. 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. 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. 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. 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. 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" 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". 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 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? 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". 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 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. 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. How Eric> does the V-hub know that? 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? 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" 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? 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. 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. 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. 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 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. 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" 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. 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. 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? 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? 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? 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. 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. 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. From internet-drafts@ietf.org Mon Oct 15 11:16: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 AC9B821F8867; Mon, 15 Oct 2012 11:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 Ft4gSCdsSatW; Mon, 15 Oct 2012 11:16:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3603B21F87DC; Mon, 15 Oct 2012 11:16:35 -0700 (PDT) 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-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121015181635.13067.69120.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 11:16:35 -0700 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, 15 Oct 2012 18:16:35 -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-02.txt Pages : 22 Date : 2012-10-15 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 could 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-virtual-hub-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yakov@juniper.net Mon Oct 15 11:21: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 E573421F888D for ; Mon, 15 Oct 2012 11:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.922 X-Spam-Level: X-Spam-Status: No, score=-105.922 tagged_above=-999 required=5 tests=[AWL=0.678, 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 tvu9nyiuhKlD for ; Mon, 15 Oct 2012 11:21:58 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 776E021F889A for ; Mon, 15 Oct 2012 11:21:57 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUHxURLCm0tABq5tDprAeP5xittp4p+A9@postini.com; Mon, 15 Oct 2012 11:21:57 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 15 Oct 2012 11:17:37 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q9FIHbh37447 for ; Mon, 15 Oct 2012 11:17:37 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201210151817.q9FIHbh37447@magenta.juniper.net> To: Subject: I-D Action: draft-ietf-l3vpn-virtual-hub-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8648.1350325057.1@juniper.net> Date: Mon, 15 Oct 2012 11:17:37 -0700 From: Yakov Rekhter 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, 15 Oct 2012 18:21:59 -0000 Folks, This is just to prevent the draft from expiring... Yakov. ------- Forwarded Message Date: Mon, 15 Oct 2012 11:16:35 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org cc: l3vpn@ietf.org Subject: I-D Action: draft-ietf-l3vpn-virtual-hub-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Grou p 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-02.txt Pages : 22 Date : 2012-10-15 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 could 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l3vpn-virtual-hub-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------- End of Forwarded Message From rraszuk@gmail.com Mon Oct 15 20:29:10 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 D4B891F0C9D; Mon, 15 Oct 2012 20:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 UNXi4caJUZKu; Mon, 15 Oct 2012 20:29:10 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 354651F0C9C; Mon, 15 Oct 2012 20:29:10 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so10442959iec.31 for ; Mon, 15 Oct 2012 20:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=I7qEi++gnPDTqvsOg7qs26KUtLTGJKBc/fgAo4Z/rv0=; b=gctaeKugVpmNiu2iKpFXxQTGB9CIbtPY02tpENKVij9fzo2RXsj7dTOBmOdRJSHRDa xp3RupJywKlR9eY13swA9dqaSuOd8zd/uGHjt58ysHliJEgSoOj/wA4KoIO1RL4SpJEp hEk56GJT6/RKgIv+rRHMxOVQ76UmyVR0ZXjOhsur31qdl0IuBEsOzjhygU0FHetMFkRo ghlDvF4b/15HlVM430KFIZtEkOkNtG2zguvn2dtHpAPKeOwM4aCLUIqoNmD+IQBkPgeF JPAxqdkt8tdzQXCtsV6L5yc3bZeOkzYZZbxV50WqlWcmnJcMeCkuOSpFnGy7t+bvASsl vCvw== MIME-Version: 1.0 Received: by 10.50.47.201 with SMTP id f9mr10605018ign.44.1350358149757; Mon, 15 Oct 2012 20:29:09 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Mon, 15 Oct 2012 20:29:09 -0700 (PDT) In-Reply-To: References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> Date: Tue, 16 Oct 2012 05:29:09 +0200 X-Google-Sender-Auth: kZuKcMrqQC4KRNsKGNbk242b7aA Message-ID: Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt From: Robert Raszuk To: Randy Bush , keyupate@cisco.com, pmehta@cisco.com, asreekan@cisco.com, luay.jalil@verizon.com Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg , 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: Tue, 16 Oct 2012 03:29:11 -0000 Dear authors, I have one doubt regarding this proposal ... Abstract says: "This document describes how the sender of the VPN/Prefix binding may sign it so that recipient of the binding may authenticate it." I highly agree that this would be useful to address. However just going to introduction section we find: This document describes how the originating PE, West, may sign the announcement so that the destination PE, East, may authenticate the NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364] Let me point out that West PE is not the originator of the route advertisement .. neither East PE is the destination. Originator and destination are corresponding CEs on both sides. With this in mind let me also point out that RFC4364 VPN sites very often use private addresses which are never part of any public RPKI for one simple reason that public RPKI has no notion of RDs to make such prefixes unique. Last let me point out also that RFC4364 defines CSC interconnect model which this draft also does not comment on. With this in mind I find the document quite incomplete at it's current form to progress it further. Also I think l3vpn WG should be cc-ed on this thread. Best regards, R. On Mon, Oct 15, 2012 at 8:08 PM, Randy Bush wrote: > Filename: draft-ymbk-l3vpn-origination > Revision: 00 > Title: Authenticating L3VPN Origination Signaling > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-ymbk-l3vpn-origination-00.txt > Status: http://datatracker.ietf.org/doc/draft-ymbk-l3vpn-origination > Htmlized: http://tools.ietf.org/html/draft-ymbk-l3vpn-origination-00 > > > 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. This is of special concern if the VPN > traverses untrusted networks. This document describes how the sender > of the VPN/Prefix binding may sign it so that recipient of the > binding may authenticate it. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rraszuk@gmail.com Mon Oct 15 21:03:32 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 4B7AD11E8142; Mon, 15 Oct 2012 21:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 XW4VOSvfrMPA; Mon, 15 Oct 2012 21:03:31 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id ACA7D11E8138; Mon, 15 Oct 2012 21:03:31 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so4905917iad.31 for ; Mon, 15 Oct 2012 21:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JK86SH99fmgI10eSinEIz2VirxNrUDZrspG5pBE+Rvc=; b=aBGoykO8zVcQKcS2BBXJryOvR1aVfQjja8Zx1Al685TctxZZecb2B+Bx4SW0+Dl6mR Yir9FkQm+yjUdWOYPAK0vbYBkBq9CiQTu+6tge1n8VHhlYTrYQBm6A5j3bc2hHk2CDE2 K3ZRlrnb9JLk1oD/D0biLmSj2tlxdVJY77woElJZJe3+FD38JXAB83Rw1YR4Ng5Lxm5P 9sfyQb6uOY6Pb+OOXygN7Tgy43otjbwAKvUGKXJDLVA30SP5dSpCZJoJbdHjUM7rvamV wgBrQdeK1Ka3x48NVSWA1sqqm8MmrZGJ5lgZxat3VXrQlxcDldIRfd8DSgXvZoORp+EF yBCQ== MIME-Version: 1.0 Received: by 10.50.15.193 with SMTP id z1mr10833579igc.47.1350360211169; Mon, 15 Oct 2012 21:03:31 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Mon, 15 Oct 2012 21:03:31 -0700 (PDT) In-Reply-To: References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> Date: Tue, 16 Oct 2012 06:03:31 +0200 X-Google-Sender-Auth: sTKzOpe00_lIqwSf0a20kr0wAg0 Message-ID: Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt From: Robert Raszuk To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg , L3VPN , pmehta@cisco.com, luay.jalil@verizon.com 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, 16 Oct 2012 04:03:32 -0000 Hello Randy, On Tue, Oct 16, 2012 at 5:41 AM, Randy Bush wrote: > thanks for review! You are very welcome ! >> This document describes how the originating PE, West, may sign the >> announcement so that the destination PE, East, may authenticate the >> NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364] >> >> Let me point out that West PE is not the originator of the route >> advertisement .. neither East PE is the destination. Originator and >> destination are corresponding CEs on both sides. > > good catch! I was not that much fishing here ... just trying to understand if you are validating CE-CE or PE-PE. If the latter I unfortunately think there is much less of the value. When we originally started to roll out 2547 there was very clear consensus that real protection must happen on the CE-CE boundary. Trusting SP where anyone who logs into PE can do anything for any VPN there was never taken serious. Note that the draft could also allow both, but this needs to be clearly stated in the text. >> With this in mind let me also point out that RFC4364 VPN sites very >> often use private addresses which are never part of any public RPKI >> for one simple reason that public RPKI has no notion of RDs to make >> such prefixes unique. > > if they want to use the rpki, then, just as other rpki publishers using > 1918 space, they would have local trust anchors and certify the private > space. see draft-ietf-sidr-ltamgmt. And what happens in the event of PE-PE validation where only one SP of L3VPN subscribes to RPKI business ? >> Last let me point out also that RFC4364 defines CSC interconnect model >> which this draft also does not comment on. > > more specific cite, please? thanks. http://tools.ietf.org/html/rfc4364#section-9 Summary ... PEs are not involved in distribution of customer routes between customer sites. R. > randy From randy@psg.com Mon Oct 15 20:41: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 22B2021F86E4; Mon, 15 Oct 2012 20:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 y95Kd5iREG3Q; Mon, 15 Oct 2012 20:41:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3E121F851A; Mon, 15 Oct 2012 20:41:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TNy2T-000H49-N1; Tue, 16 Oct 2012 03:41:54 +0000 Date: Mon, 15 Oct 2012 17:41:52 -1000 Message-ID: From: Randy Bush To: Robert Raszuk Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt In-Reply-To: References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> 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 X-Mailman-Approved-At: Tue, 16 Oct 2012 00:22:57 -0700 Cc: idr wg , L3VPN , pmehta@cisco.com, luay.jalil@verizon.com 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, 16 Oct 2012 03:41:58 -0000 thanks for review! > This document describes how the originating PE, West, may sign the > announcement so that the destination PE, East, may authenticate the > NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364] > > Let me point out that West PE is not the originator of the route > advertisement .. neither East PE is the destination. Originator and > destination are corresponding CEs on both sides. good catch! > With this in mind let me also point out that RFC4364 VPN sites very > often use private addresses which are never part of any public RPKI > for one simple reason that public RPKI has no notion of RDs to make > such prefixes unique. if they want to use the rpki, then, just as other rpki publishers using 1918 space, they would have local trust anchors and certify the private space. see draft-ietf-sidr-ltamgmt. > Last let me point out also that RFC4364 defines CSC interconnect model > which this draft also does not comment on. more specific cite, please? thanks. randy From randy@psg.com Mon Oct 15 21:09: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 1377521F86C3; Mon, 15 Oct 2012 21:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 4SVtCiig9tF2; Mon, 15 Oct 2012 21:09:39 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id AC31821F86BB; Mon, 15 Oct 2012 21:09:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TNyTJ-000H9B-5X; Tue, 16 Oct 2012 04:09:37 +0000 Date: Mon, 15 Oct 2012 18:09:35 -1000 Message-ID: From: Randy Bush To: Robert Raszuk Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt In-Reply-To: References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> 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 X-Mailman-Approved-At: Tue, 16 Oct 2012 00:22:57 -0700 Cc: idr wg , L3VPN , pmehta@cisco.com, luay.jalil@verizon.com 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, 16 Oct 2012 04:09:40 -0000 > I was not that much fishing here ... just trying to understand if you > are validating CE-CE or PE-PE. If the latter I unfortunately think > there is much less of the value. > > When we originally started to roll out 2547 there was very clear > consensus that real protection must happen on the CE-CE boundary. > Trusting SP where anyone who logs into PE can do anything for any VPN > there was never taken serious. > > Note that the draft could also allow both, but this needs to be > clearly stated in the text. it tries to make that pretty clear This document describes how the originating PE, West, may sign the announcement so that the destination PE, East, may authenticate the NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364] Section 4.3.1. Alternatively, the originating CE router may sign the announcement so that the destination CE router may authenticate the NLRI. >> if they want to use the rpki, then, just as other rpki publishers >> using 1918 space, they would have local trust anchors and certify the >> private space. see draft-ietf-sidr-ltamgmt. > > And what happens in the event of PE-PE validation where only one SP of > L3VPN subscribes to RPKI business ? then they should not use rpki keying but rather their own key infrastructure using the Key Identifier to index their KI randy From xuxiaohu@huawei.com Tue Oct 16 19:19:34 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 B8BBF21F871E for ; Tue, 16 Oct 2012 19:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.746 X-Spam-Level: X-Spam-Status: No, score=-3.746 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MLB_Stock6=1.56] 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 n3Z66nSdwYyx for ; Tue, 16 Oct 2012 19:19:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 81C3121F85F3 for ; Tue, 16 Oct 2012 19:19:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALR83192; Wed, 17 Oct 2012 02:19:25 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 17 Oct 2012 03:18:48 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 17 Oct 2012 03:19:21 +0100 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.168]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Wed, 17 Oct 2012 10:19:12 +0800 From: Xuxiaohu To: L3VPN Subject: re: New Version Notification for draft-xu-virtual-subnet-09.txt Thread-Topic: New Version Notification for draft-xu-virtual-subnet-09.txt Thread-Index: AQHNqr0N/8TyO132JEOCsQDtiJyFfpe8vRIw Date: Wed, 17 Oct 2012 02:19:12 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755FD25@szxeml525-mbx.china.huawei.com> References: <20121015100833.1015.25120.idtracker@ietfa.amsl.com> In-Reply-To: <20121015100833.1015.25120.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Susan Hares , "fanyb@gsta.com" , "christian.jacquenet@orange.com" 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, 17 Oct 2012 02:19:34 -0000 SGkgTDNWUE4gZm9sa3MsDQoNClZpcnR1YWwgU3VibmV0IGlzIGEgTDNWUE4tYmFzZWQgc3VibmV0 IGV4dGVuc2lvbiBzb2x1dGlvbiB3aGljaCBjYW4gYmUgdXNlZCBmb3IgZGF0YSBjZW50ZXIgaW50 ZXJjb25uZWN0aW9uIGFuZCBldmVuIGRhdGEgY2VudGVyIG5ldHdvcmsuIFNpbmNlIGl0J3MgYSBz cGVjaWFsIGFwcGxpY2F0aW9uIG9mIHRoZSBCR1AvTVBMUyBWUE4gdGVjaG5vbG9neSwgd2UgY28t YXV0aG9ycyBiZWxpZXZlIHRoZSBMM1ZQTiBXRyBzaG91bGQgYmUgYSByaWdodCBwbGFjZSB0byB0 YWxrIGFib3V0IGl0Lg0KDQpBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkJlc3QgcmVnYXJk cywNClhpYW9odSAob24gYmVoYWxmIG9mIGFsbCBjby1hdXRob3JzKQ0KDQo+IC0tLS0t6YKu5Lu2 5Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IOWPkemAgeaXtumXtDogMjAxMuW5tDEw5pyI MTXml6UgMTg6MDkNCj4g5pS25Lu25Lq6OiBYdXhpYW9odQ0KPiDmioTpgIE6IFN1c2FuIEhhcmVz OyBjaHJpc3RpYW4uamFjcXVlbmV0QG9yYW5nZS5jb207IGZhbnliQGdzdGEuY29tDQo+IOS4u+mi mDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14dS12aXJ0dWFsLXN1Ym5ldC0w OS50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteHUtdmlydHVhbC1z dWJuZXQtMDkudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhb2h1 IFh1IGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1l OgkgZHJhZnQteHUtdmlydHVhbC1zdWJuZXQNCj4gUmV2aXNpb246CSAwOQ0KPiBUaXRsZToJCSBW aXJ0dWFsIFN1Ym5ldDogQSBMM1ZQTi1iYXNlZCBTdWJuZXQgRXh0ZW5zaW9uIFNvbHV0aW9uDQo+ IENyZWF0aW9uIGRhdGU6CSAyMDEyLTEwLTE1DQo+IFdHIElEOgkJIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDE3DQo+IFVSTDoNCj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMDkudHh0DQo+IFN0YXR1 czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14dS12aXJ0 dWFsLXN1Ym5ldA0KPiBIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXh1LXZpcnR1YWwtc3VibmV0LTA5DQo+IERpZmY6ICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMDkNCj4gDQo+ IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIExheWVyMyBWaXJ0dWFs IFByaXZhdGUgTmV0d29yayAoTDNWUE4pLQ0KPiAgICBiYXNlZCBzdWJuZXQgZXh0ZW5zaW9uIHNv bHV0aW9uIHJlZmVycmVkIHRvIGFzIFZpcnR1YWwgU3VibmV0LCB3aGljaA0KPiAgICBtYWlubHkg cmV1c2VzIGV4aXN0aW5nIEJvcmRlciBHYXRld2F5IFByb3RvY29sIChCR1ApL011bHRpLVByb3Rv Y29sDQo+ICAgIExhYmVsIFN3aXRjaCAoTVBMUykgSVAgVmlydHVhbCBQcml2YXRlIE5ldHdvcmsg KFZQTilbUkZDNDM2NF0gYW5kDQo+ICAgIEFkZHJlc3MgUmVzb2x1dGlvbiBQcm90b2NvbChBUlAp L05laWdoYm9yIERpc2NvdmVyeSAoTkQpIHByb3h5DQo+ICAgIFtSRkM5MjVdW1JGQzEwMjddW1JG QzQzODlddGVjaG5vbG9naWVzLiBWaXJ0dWFsIFN1Ym5ldCBwcm92aWRlcyBhDQo+ICAgIHNjYWxh YmxlIGFwcHJvYWNoIGZvciBpbnRlcmNvbm5lY3RpbmcgY2xvdWQgZGF0YSBjZW50ZXJzLg0KPiAN Cj4gDQo+IA0KPiANCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From rraszuk@gmail.com Tue Oct 16 21:47:30 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 515F221F8600; Tue, 16 Oct 2012 21:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 lUnLGpBqWmij; Tue, 16 Oct 2012 21:47:29 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBB321F8562; Tue, 16 Oct 2012 21:47:29 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so12747957iec.31 for ; Tue, 16 Oct 2012 21:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c8rIstKeMLmEBHmayDsLF800TFZQjStRTaEcm5Lth0k=; b=MOw4GwEPJ74N8ioGp0/HszCqkgCL1TumR0R+762ygTMbzJpWzYLwfvnb027xfw7jkH MdbzkyaK4zUKHPdHLduCbJvZJqTZpn2juRfse1mV068pLkaeiZUThm+LTFTLC+WJhex/ miQch2iq5S2gkkrXU/dT0SUDh/PImSS9IcwE94D+OWiPqQj2GHVaIRNzj7+4mJXvsDD0 yF1inc3SKfbB82OZS7P7NIRX6vHoqTLbq/CWWzN4/fulMeifG8s4Ey5cgHC1Li8CBnLe q+21zrtA4pk/TQE7Z0+dpixiZ6jh/xGDfwnwGU9SZmTJdWoajaUrm7c5nlII+zFHJETl SJjw== MIME-Version: 1.0 Received: by 10.42.109.194 with SMTP id m2mr13300322icp.48.1350449248933; Tue, 16 Oct 2012 21:47:28 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Tue, 16 Oct 2012 21:47:28 -0700 (PDT) In-Reply-To: <80F8B5888DDE96498217BE8A5C47436F17F611@xmb-rcd-x13.cisco.com> References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> <80F8B5888DDE96498217BE8A5C47436F17F611@xmb-rcd-x13.cisco.com> Date: Wed, 17 Oct 2012 06:47:28 +0200 X-Google-Sender-Auth: XxbdGgdqOlSLZQUWh3J1Z_nF4-M Message-ID: Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt From: Robert Raszuk To: "Pranav Mehta (pmehta)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: L3VPN , idr wg , "luay.jalil@verizon.com" , Randy Bush 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, 17 Oct 2012 04:47:30 -0000 Hey Pranav, Do you really believe that each 7-11 or Walmart store will be subscribing to global RPKI or building their own key infrastructure? I do not. It seems few orders of magnitude easier to sign advertisements at the src/spoke and validate signature at the hub site by the same very network admin residing in the enterprise hub location. That is something we should define in BGP for VPNs and not trying to reuse origin validation concept which works well (for what it is designed to do) in the Internet case. Btw ,,, I do not buy any "trusted" ASBR business ;) Best, R. On Tue, Oct 16, 2012 at 11:02 PM, Pranav Mehta (pmehta) wrote: > Robert, > > As Randy already mentioned, Draft already covers an alternate approach wh= ere originating CE would sign the announcement and it will come all the way= to destination CE to authenticate. > > Alternately this mechanism can also help in Inter-AS scenario. In Inter-= AS scenario, originating CE can sign the announcement and a "trusted" ASBR = on the Inter-AS boundary can authenticate the announcement if customer trus= ts one of the two ISPs. In such scenario, ISP may use the Key identifier= to find the Key associated with the VPN and send unsigned NLRI in its own = network once it is authenticated at ASBR boundary. > > - Pranav > > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, October 15, 2012 9:10 PM > To: Robert Raszuk > Cc: Keyur Patel (keyupate); Pranav Mehta (pmehta); Arjun Sreekantiah (asr= eekan); luay.jalil@verizon.com; idr wg; L3VPN > Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt > >> I was not that much fishing here ... just trying to understand if you >> are validating CE-CE or PE-PE. If the latter I unfortunately think >> there is much less of the value. >> >> When we originally started to roll out 2547 there was very clear >> consensus that real protection must happen on the CE-CE boundary. >> Trusting SP where anyone who logs into PE can do anything for any VPN >> there was never taken serious. >> >> Note that the draft could also allow both, but this needs to be >> clearly stated in the text. > > it tries to make that pretty clear > > This document describes how the originating PE, West, may sign the > announcement so that the destination PE, East, may authenticate the > NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364] > Section 4.3.1. Alternatively, the originating CE router may sign the > announcement so that the destination CE router may authenticate the > NLRI. > >>> if they want to use the rpki, then, just as other rpki publishers >>> using 1918 space, they would have local trust anchors and certify the >>> private space. see draft-ietf-sidr-ltamgmt. >> >> And what happens in the event of PE-PE validation where only one SP of >> L3VPN subscribes to RPKI business ? > > then they should not use rpki keying but rather their own key infrastruct= ure using the Key Identifier to index their KI > > randy From geraldine.calvignac@orange.com Wed Oct 17 02:50:49 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 DA5BC21F881E for ; Wed, 17 Oct 2012 02:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 0ynwWwmf1LLU for ; Wed, 17 Oct 2012 02:50:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8161521F8549 for ; Wed, 17 Oct 2012 02:50:45 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 35E8D18C2ED for ; Wed, 17 Oct 2012 11:50:44 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1F93A35C045 for ; Wed, 17 Oct 2012 11:50:44 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 17 Oct 2012 11:50:43 +0200 From: To: "l3vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l3vpn-virtual-hub Thread-Topic: RE: WG Last Call for draft-ietf-l3vpn-virtual-hub Thread-Index: Ac2sTN8mBm0UowLvSOWZ8zffhxFhkg== Date: Wed, 17 Oct 2012 09:50:43 +0000 Message-ID: <7315_1350467444_507E7F74_7315_1248_1_3CDAE1F19ECB70499C6242576D6D0BA30209D9@PEXCVZYM12.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.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.9.1.82415 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, 17 Oct 2012 09:50:49 -0000 Dear all, This virtual H&S VPN approach is particularly adequate when considering MPL= S access nodes which have limited capacity: limited number of routes they c= an handle within their VRFs, limited number of LSPs compared to the number = of PEs in the VPNs they are part of. Regards, Geraldine ___________________________________________________________________________= ______________________________________________ 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 robert@raszuk.net Wed Oct 17 19:50:15 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 C761121F851B for ; Wed, 17 Oct 2012 19:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 mD2qMVdfzbBv for ; Wed, 17 Oct 2012 19:50:15 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFA021F8518 for ; Wed, 17 Oct 2012 19:50:13 -0700 (PDT) Received: (qmail 17169 invoked by uid 399); 18 Oct 2012 02:51:18 -0000 Received: from unknown (HELO ?192.168.50.166?) (pbs:robert@raszuk.net@70.164.119.40) by mail1310.opentransfer.com with ESMTPM; 18 Oct 2012 02:51:18 -0000 X-Originating-IP: 70.164.119.40 To: "=?utf-8?B?UHJhbmF2IE1laHRhLCAocG1laHRhKQ==?=" From: "=?utf-8?B?cm9iZXJ0QHJhc3p1ay5uZXQ=?=" Subject: =?utf-8?B?UmU6IFtJZHJdIGRyYWZ0LXltYmstbDN2cG4tb3JpZ2luYXRpb24tMDAudHh0?= Date: Wed, 17 Oct 2012 19:50:12 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1350528612140" Message-Id: <20121018025013.9BFA021F8518@ietfa.amsl.com> Cc: L3VPN , =?utf-8?B?aWRyIHdn?= , =?utf-8?B?bHVheS5qYWxpbEB2ZXJpem9uLmNvbQ==?= , =?utf-8?B?UmFuZHkgQnVzaA==?= 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, 18 Oct 2012 02:50:15 -0000 ------=_Part_0_1350528612140 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGkgUHJhbmF2LCAgCgpIZWxwIG1lIHVuZGVyc3RhbmQgaGVyZSB0aGF0IGlmIHdlIGFyZSB0YWxr aW5nIGFib3V0IHN0YXRpY2FsbHkgY29uZmlndXJlZCBrZXkgb24gdGhlIENFcyB3b3VsZCBpdCBi ZSBub3QgYmV0dGVyIHRvIGNvbnNpZGVyIGUtc2lnbmF0dXJlIGZyb20gdmVyaXNpZ24gaW5zdGVh ZCA/CgpUaHgsClIuCgotLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tCkZyb206ICJQcmFuYXYgTWVo dGEgKHBtZWh0YSkiIDxwbWVodGFAY2lzY28uY29tPgpUbzogIlJvYmVydCBSYXN6dWsiIDxyb2Jl cnRAcmFzenVrLm5ldD4KQ2M6ICJSYW5keSBCdXNoIiA8cmFuZHlAcHNnLmNvbT4sICJLZXl1ciBQ YXRlbCAoa2V5dXBhdGUpIiA8a2V5dXBhdGVAY2lzY28uY29tPiwgIkFyanVuIFNyZWVrYW50aWFo IChhc3JlZWthbikiIDxhc3JlZWthbkBjaXNjby5jb20+LCAibHVheS5qYWxpbEB2ZXJpem9uLmNv bSIgPGx1YXkuamFsaWxAdmVyaXpvbi5jb20+LCAiaWRyIHdnIiA8aWRyQGlldGYub3JnPiwgIkwz VlBOIiA8bDN2cG5AaWV0Zi5vcmc+ClN1YmplY3Q6IFtJZHJdIGRyYWZ0LXltYmstbDN2cG4tb3Jp Z2luYXRpb24tMDAudHh0CkRhdGU6IFdlZCwgT2N0IDE3LCAyMDEyIDEwOjI1CgoKSGkgUm9iZXJ0 LAoKVGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLiAgTXkgY29tbWVudHMgaW5saW5lLi4gI1AjCgot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRv OnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1awpTZW50OiBUdWVz ZGF5LCBPY3RvYmVyIDE2LCAyMDEyIDk6NDcgUE0KVG86IFByYW5hdiBNZWh0YSAocG1laHRhKQpD YzogUmFuZHkgQnVzaDsgS2V5dXIgUGF0ZWwgKGtleXVwYXRlKTsgQXJqdW4gU3JlZWthbnRpYWgg KGFzcmVla2FuKTsgbHVheS5qYWxpbEB2ZXJpem9uLmNvbTsgaWRyIHdnOyBMM1ZQTgpTdWJqZWN0 OiBSZTogW0lkcl0gZHJhZnQteW1iay1sM3Zwbi1vcmlnaW5hdGlvbi0wMC50eHQKCkhleSBQcmFu YXYsCgpEbyB5b3UgcmVhbGx5IGJlbGlldmUgdGhhdCBlYWNoIDctMTEgb3IgV2FsbWFydCBzdG9y ZSB3aWxsIGJlIHN1YnNjcmliaW5nIHRvIGdsb2JhbCBSUEtJIG9yIGJ1aWxkaW5nIHRoZWlyIG93 biBrZXkgaW5mcmFzdHJ1Y3R1cmU/IEkgZG8gbm90LiBJdCBzZWVtcyBmZXcgb3JkZXJzIG9mIG1h Z25pdHVkZSBlYXNpZXIgdG8gc2lnbiBhZHZlcnRpc2VtZW50cyBhdCB0aGUgc3JjL3Nwb2tlIGFu ZCB2YWxpZGF0ZSBzaWduYXR1cmUgYXQgdGhlIGh1YiBzaXRlIGJ5IHRoZSBzYW1lIHZlcnkgbmV0 d29yayBhZG1pbiByZXNpZGluZyBpbiB0aGUgZW50ZXJwcmlzZSBodWIgbG9jYXRpb24uIFRoYXQg aXMgc29tZXRoaW5nIHdlIHNob3VsZCBkZWZpbmUgaW4gQkdQIGZvciBWUE5zIGFuZCBub3QgdHJ5 aW5nIHRvIHJldXNlIG9yaWdpbiB2YWxpZGF0aW9uIGNvbmNlcHQgd2hpY2ggd29ya3Mgd2VsbCAo Zm9yIHdoYXQgaXQgaXMgZGVzaWduZWQgdG8KZG8pIGluIHRoZSBJbnRlcm5ldCBjYXNlLgoKI1Aj IEkgZG9uJ3QgdGhpbmsgNy0xMS9XYWxtYXJ0IHdpbGwgYmUgc3Vic2NyaWJpbmcgdG8gZ2xvYmFs IFJQS0kgb3IgZXZlbiBidWlsZCB0aGVpciBvd24gaW5mcmFzdHJ1Y3R1cmUuICBSUEtJIG1ha2Vz IGl0IGVhc2llciB0byBkaXN0cmlidXRlIHRoZSBrZXkgYnV0IHRoZSBlbmQgQ0UgY2FuIGJlIGNv bmZpZ3VyZWQgdG8gdXNlIGEgc3RhdGljIEtleSBhbmQgdGhpcyBkcmFmdCBkb2Vzbid0IHByZWNs dWRlIHByb3Zpc2lvbmluZyB1c2luZyBzdGF0aWMgY29uZmlndXJhdGlvbi4gIEFzIGZhciBhcyBh bGwgdGhlIHNpdGVzIGJlbG9uZyB0byBzYW1lIG5ldHdvcmsgYWRtaW4sIHNhbWUga2V5IGNhbiBi ZSBwcm92aXNpb25lZCBvbiBhbGwgdGhlIHNpdGVzIGFuZCBpbiBzdWNoIGNhc2Ugd2UgZG9uJ3Qg bmVlZCB0byBnZXQgUlBLSSBpbmZyYXN0cnVjdHVyZSBpbnZvbHZlZC4gIElmIGl0J3Mgbm90IGNs ZWFyIGZyb20gdGhlIGRyYWZ0LCB3ZSBjYW4gZGVmaW5pdGVseSBjaGFuZ2UgdGhlIHdvcmRpbmcg dG8gY2xhcmlmeSB0aGlzLgoKQnR3ICwsLCBJIGRvIG5vdCBidXkgYW55ICJ0cnVzdGVkIiBBU0JS IGJ1c2luZXNzIDspCgojUCMKSW4gbW9zdCBvZiB0aGUgY2FzZXMgSSBhZ3JlZSB0aGF0IHRoaXMg YXN5bW1ldHJpYyBzb2x1dGlvbiBtaWdodCBub3QgYmUgcHJlZmVycmVkIGJ1dCB0aGluayBhYm91 dCBhIHNjZW5hcmlvIHdoZXJlIGEgVlBOIGhhcyBmZXcgc2l0ZXMgY29ubmVjdGVkIHZpYSBub24t dHJ1c3RlZCBwcm92aWRlZCBhbmQgbW9zdCBvZiB0aGUgb3RoZXIgKG1heSBiZSBpbiB0aG91c2Fu ZHMpIHNpdGVzIGFyZSBjb25uZWN0ZWQgdG8gYSB0cnVzdGVkIHByb3ZpZGVyLiAgSW5zdGVhZCBv ZiB1cGdyYWRpbmcgYWxsIHRoZXNlIHNpdGVzIHRvIGdlbmVyYXRlZCBzaWduZWQgTkxSSXMgdGhl IFZQTiBjYW4gY2hvb3NlIHRvIGp1c3QgYWRkIHRoZSBhdXRoZW50aWNhdGlvbiBhdCB0aGUgQVNC UiBib3VuZGFyeSB0byBwcm90ZWN0IHByZWZpeCBvcmlnaW5hdGlvbiBmcm9tIHVuLXRydXN0ZWQg bmV0d29yay4gIFRoZSBnb2FsIG9mIHRoaXMgZHJhZnQgaXMgdG8gYWxsb3cgdGhlIGZsZXhpYmls aXR5IGJ5IGFkZGluZyBLZXkgSWRlbnRpZmllciBzbyB0aGF0IFZQTiBpcyBub3QgZm9yY2VkIHRv IHVwZ3JhZGUgYWxsIHRoZSBzaXRlcyB1bmRlciB0aGlzIHNjZW5hcmlvLiAgCgoKVGhhbmtzLAot LSBQcmFuYXYK ------=_Part_0_1350528612140 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGkgUHJhbmF2LCAmbmJzcDs8YnI+PGJyPkhlbHAgbWUgdW5kZXJzdGFuZCBoZXJlIHRoYXQgaWYg d2UgYXJlIHRhbGtpbmcgYWJvdXQgc3RhdGljYWxseSBjb25maWd1cmVkIGtleSBvbiB0aGUgQ0Vz IHdvdWxkIGl0IGJlIG5vdCBiZXR0ZXIgdG8gY29uc2lkZXIgZS1zaWduYXR1cmUgZnJvbSB2ZXJp c2lnbiBpbnN0ZWFkID88YnI+PGJyPlRoeCw8YnI+Ui48YnI+PGJyPi0tLS0tIFJlcGx5IG1lc3Nh Z2UgLS0tLS08YnI+RnJvbTogJnF1b3Q7UHJhbmF2IE1laHRhIChwbWVodGEpJnF1b3Q7ICZsdDtw bWVodGFAY2lzY28uY29tJmd0Ozxicj5UbzogJnF1b3Q7Um9iZXJ0IFJhc3p1ayZxdW90OyAmbHQ7 cm9iZXJ0QHJhc3p1ay5uZXQmZ3Q7PGJyPkNjOiAmcXVvdDtSYW5keSBCdXNoJnF1b3Q7ICZsdDty YW5keUBwc2cuY29tJmd0OywgJnF1b3Q7S2V5dXIgUGF0ZWwgKGtleXVwYXRlKSZxdW90OyAmbHQ7 a2V5dXBhdGVAY2lzY28uY29tJmd0OywgJnF1b3Q7QXJqdW4gU3JlZWthbnRpYWggKGFzcmVla2Fu KSZxdW90OyAmbHQ7YXNyZWVrYW5AY2lzY28uY29tJmd0OywgJnF1b3Q7bHVheS5qYWxpbEB2ZXJp em9uLmNvbSZxdW90OyAmbHQ7bHVheS5qYWxpbEB2ZXJpem9uLmNvbSZndDssICZxdW90O2lkciB3 ZyZxdW90OyAmbHQ7aWRyQGlldGYub3JnJmd0OywgJnF1b3Q7TDNWUE4mcXVvdDsgJmx0O2wzdnBu QGlldGYub3JnJmd0Ozxicj5TdWJqZWN0OiBbSWRyXSBkcmFmdC15bWJrLWwzdnBuLW9yaWdpbmF0 aW9uLTAwLnR4dDxicj5EYXRlOiBXZWQsIE9jdCAxNywgMjAxMiAxMDoyNTxicj48YnI+PGJyPkhp IFJvYmVydCw8YnI+PGJyPlRoYW5rcyBmb3IgeW91ciBmZWVkYmFjay4gJm5ic3A7TXkgY29tbWVu dHMgaW5saW5lLi4gI1AjPGJyPjxicj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj5Gcm9t OiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYg T2YgUm9iZXJ0IFJhc3p1azxicj5TZW50OiBUdWVzZGF5LCBPY3RvYmVyIDE2LCAyMDEyIDk6NDcg UE08YnI+VG86IFByYW5hdiBNZWh0YSAocG1laHRhKTxicj5DYzogUmFuZHkgQnVzaDsgS2V5dXIg UGF0ZWwgKGtleXVwYXRlKTsgQXJqdW4gU3JlZWthbnRpYWggKGFzcmVla2FuKTsgbHVheS5qYWxp bEB2ZXJpem9uLmNvbTsgaWRyIHdnOyBMM1ZQTjxicj5TdWJqZWN0OiBSZTogW0lkcl0gZHJhZnQt eW1iay1sM3Zwbi1vcmlnaW5hdGlvbi0wMC50eHQ8YnI+PGJyPkhleSBQcmFuYXYsPGJyPjxicj5E byB5b3UgcmVhbGx5IGJlbGlldmUgdGhhdCBlYWNoIDctMTEgb3IgV2FsbWFydCBzdG9yZSB3aWxs IGJlIHN1YnNjcmliaW5nIHRvIGdsb2JhbCBSUEtJIG9yIGJ1aWxkaW5nIHRoZWlyIG93biBrZXkg aW5mcmFzdHJ1Y3R1cmU/IEkgZG8gbm90LiBJdCBzZWVtcyBmZXcgb3JkZXJzIG9mIG1hZ25pdHVk ZSBlYXNpZXIgdG8gc2lnbiBhZHZlcnRpc2VtZW50cyBhdCB0aGUgc3JjL3Nwb2tlIGFuZCB2YWxp ZGF0ZSBzaWduYXR1cmUgYXQgdGhlIGh1YiBzaXRlIGJ5IHRoZSBzYW1lIHZlcnkgbmV0d29yayBh ZG1pbiByZXNpZGluZyBpbiB0aGUgZW50ZXJwcmlzZSBodWIgbG9jYXRpb24uIFRoYXQgaXMgc29t ZXRoaW5nIHdlIHNob3VsZCBkZWZpbmUgaW4gQkdQIGZvciBWUE5zIGFuZCBub3QgdHJ5aW5nIHRv IHJldXNlIG9yaWdpbiB2YWxpZGF0aW9uIGNvbmNlcHQgd2hpY2ggd29ya3Mgd2VsbCAoZm9yIHdo YXQgaXQgaXMgZGVzaWduZWQgdG88YnI+ZG8pIGluIHRoZSBJbnRlcm5ldCBjYXNlLjxicj48YnI+ I1AjIEkgZG9uJiMzOTt0IHRoaW5rIDctMTEvV2FsbWFydCB3aWxsIGJlIHN1YnNjcmliaW5nIHRv IGdsb2JhbCBSUEtJIG9yIGV2ZW4gYnVpbGQgdGhlaXIgb3duIGluZnJhc3RydWN0dXJlLiAmbmJz cDtSUEtJIG1ha2VzIGl0IGVhc2llciB0byBkaXN0cmlidXRlIHRoZSBrZXkgYnV0IHRoZSBlbmQg Q0UgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gdXNlIGEgc3RhdGljIEtleSBhbmQgdGhpcyBkcmFmdCBk b2VzbiYjMzk7dCBwcmVjbHVkZSBwcm92aXNpb25pbmcgdXNpbmcgc3RhdGljIGNvbmZpZ3VyYXRp b24uICZuYnNwO0FzIGZhciBhcyBhbGwgdGhlIHNpdGVzIGJlbG9uZyB0byBzYW1lIG5ldHdvcmsg YWRtaW4sIHNhbWUga2V5IGNhbiBiZSBwcm92aXNpb25lZCBvbiBhbGwgdGhlIHNpdGVzIGFuZCBp biBzdWNoIGNhc2Ugd2UgZG9uJiMzOTt0IG5lZWQgdG8gZ2V0IFJQS0kgaW5mcmFzdHJ1Y3R1cmUg aW52b2x2ZWQuICZuYnNwO0lmIGl0JiMzOTtzIG5vdCBjbGVhciBmcm9tIHRoZSBkcmFmdCwgd2Ug Y2FuIGRlZmluaXRlbHkgY2hhbmdlIHRoZSB3b3JkaW5nIHRvIGNsYXJpZnkgdGhpcy48YnI+PGJy PkJ0dyAsLCwgSSBkbyBub3QgYnV5IGFueSAmcXVvdDt0cnVzdGVkJnF1b3Q7IEFTQlIgYnVzaW5l c3MgOyk8YnI+PGJyPiNQIzxicj5JbiBtb3N0IG9mIHRoZSBjYXNlcyBJIGFncmVlIHRoYXQgdGhp cyBhc3ltbWV0cmljIHNvbHV0aW9uIG1pZ2h0IG5vdCBiZSBwcmVmZXJyZWQgYnV0IHRoaW5rIGFi b3V0IGEgc2NlbmFyaW8gd2hlcmUgYSBWUE4gaGFzIGZldyBzaXRlcyBjb25uZWN0ZWQgdmlhIG5v bi10cnVzdGVkIHByb3ZpZGVkIGFuZCBtb3N0IG9mIHRoZSBvdGhlciAobWF5IGJlIGluIHRob3Vz YW5kcykgc2l0ZXMgYXJlIGNvbm5lY3RlZCB0byBhIHRydXN0ZWQgcHJvdmlkZXIuICZuYnNwO0lu c3RlYWQgb2YgdXBncmFkaW5nIGFsbCB0aGVzZSBzaXRlcyB0byBnZW5lcmF0ZWQgc2lnbmVkIE5M UklzIHRoZSBWUE4gY2FuIGNob29zZSB0byBqdXN0IGFkZCB0aGUgYXV0aGVudGljYXRpb24gYXQg dGhlIEFTQlIgYm91bmRhcnkgdG8gcHJvdGVjdCBwcmVmaXggb3JpZ2luYXRpb24gZnJvbSB1bi10 cnVzdGVkIG5ldHdvcmsuICZuYnNwO1RoZSBnb2FsIG9mIHRoaXMgZHJhZnQgaXMgdG8gYWxsb3cg dGhlIGZsZXhpYmlsaXR5IGJ5IGFkZGluZyBLZXkgSWRlbnRpZmllciBzbyB0aGF0IFZQTiBpcyBu b3QgZm9yY2VkIHRvIHVwZ3JhZGUgYWxsIHRoZSBzaXRlcyB1bmRlciB0aGlzIHNjZW5hcmlvLiAm bmJzcDs8YnI+PGJyPjxicj5UaGFua3MsPGJyPi0tIFByYW5hdjxicj4= ------=_Part_0_1350528612140-- From randy@psg.com Wed Oct 17 19:52:07 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 7A35021F8523; Wed, 17 Oct 2012 19:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 8bQwmOkfeNJr; Wed, 17 Oct 2012 19:52:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1A721F851B; Wed, 17 Oct 2012 19:52:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TOgDK-000Opn-DI; Thu, 18 Oct 2012 02:52:02 +0000 Date: Wed, 17 Oct 2012 16:52:01 -1000 Message-ID: From: Randy Bush To: "robert@raszuk.net" Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt 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: idr wg , L3VPN , "Pranav Mehta, \(pmehta\)" , "luay.jalil@verizon.com" 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, 18 Oct 2012 02:52:07 -0000 > Help me understand here that if we are talking about statically > configured key on the CEs would it be not better to consider > e-signature from verisign instead ? the keys are arbitrary. you can get ecerts from macdonalds for all the spec cares. randy From robert@raszuk.net Wed Oct 17 20:15: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 C24FA11E80A3 for ; Wed, 17 Oct 2012 20:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 8TkRuhVNbADU for ; Wed, 17 Oct 2012 20:15:43 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 148ED11E8097 for ; Wed, 17 Oct 2012 20:15:43 -0700 (PDT) Received: (qmail 17978 invoked by uid 399); 18 Oct 2012 03:16:47 -0000 Received: from unknown (HELO ?192.168.51.101?) (pbs:robert@raszuk.net@70.164.119.40) by mail1310.opentransfer.com with ESMTPM; 18 Oct 2012 03:16:47 -0000 X-Originating-IP: 70.164.119.40 Message-ID: <507F745C.6000508@raszuk.net> Date: Thu, 18 Oct 2012 05:15:40 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Randy Bush Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr wg , "Pranav Mehta, \(pmehta\)" , L3VPN , "luay.jalil@verizon.com" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 03:15:43 -0000 > the keys are arbitrary. you can get ecerts from macdonalds for all > the spec cares. If this is so what is so novel about your draft if compared with already existing for over 10 years L3VPN WG below document ? http://tools.ietf.org/html/draft-ietf-l3vpn-auth-00 ? Thx, R. >> Help me understand here that if we are talking about statically >> configured key on the CEs would it be not better to consider >> e-signature from verisign instead ? > > the keys are arbitrary. you can get ecerts from macdonalds for all the > spec cares. > > randy > > From pmehta@cisco.com Tue Oct 16 14:02:49 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 5EC8D11E80E4; Tue, 16 Oct 2012 14:02:49 -0700 (PDT) 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 QKlBy67HfR7w; Tue, 16 Oct 2012 14:02:48 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 523EE11E80D5; Tue, 16 Oct 2012 14:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2387; q=dns/txt; s=iport; t=1350421368; x=1351630968; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ryye2F9C8QFkHRangV/lS+04uSveCmDrXGWnkmpionY=; b=It3LNcX+0jBOy0frQcgyIkDKz9Y6QpQ4mpEnc2u8ssRsBbRQB5p0+tG+ 4RQWEbXUYutQHa3UvrD4k0gYPVDZoLE7QrCmvmlaK6wtEb3RiXl6mh45I hgbN1KeGgpGKTOKHrCsZH81nT0353tzko3pQcy59qgb/7L66Lkgf+Hic0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALjKfVCtJV2Z/2dsb2JhbABFwA2BCIIgAQEBAwESASc/BQcEAgEIEQQBAQsUCQcyFAkIAgQBDQUIGodQAwkFAZsAj1yQRYpoZ4VdYAOkMoFrgm2BXCMY X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208";a="132326985" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 16 Oct 2012 21:02:48 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9GL2lQ1001898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Oct 2012 21:02:47 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.63]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 16:02:47 -0500 From: "Pranav Mehta (pmehta)" To: Randy Bush , Robert Raszuk Subject: RE: [Idr] draft-ymbk-l3vpn-origination-00.txt Thread-Topic: [Idr] draft-ymbk-l3vpn-origination-00.txt Thread-Index: AQHNqwAew0fd+6zQc0WX8IHgfJLNm5e7mp+AgAADjgCAAAYMgIAAAbKAgAC9qHA= Date: Tue, 16 Oct 2012 21:02:46 +0000 Message-ID: <80F8B5888DDE96498217BE8A5C47436F17F611@xmb-rcd-x13.cisco.com> References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.138.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19276.004 x-tm-as-result: No--34.879000-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 X-Mailman-Approved-At: Thu, 18 Oct 2012 00:21:08 -0700 Cc: L3VPN , "luay.jalil@verizon.com" , idr wg 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, 16 Oct 2012 21:02:49 -0000 Robert, As Randy already mentioned, Draft already covers an alternate approach wher= e originating CE would sign the announcement and it will come all the way t= o destination CE to authenticate. =20 Alternately this mechanism can also help in Inter-AS scenario. In Inter-AS= scenario, originating CE can sign the announcement and a "trusted" ASBR on= the Inter-AS boundary can authenticate the announcement if customer trusts= one of the two ISPs. In such scenario, ISP may use the Key identifier t= o find the Key associated with the VPN and send unsigned NLRI in its own ne= twork once it is authenticated at ASBR boundary. - Pranav -----Original Message----- From: Randy Bush [mailto:randy@psg.com]=20 Sent: Monday, October 15, 2012 9:10 PM To: Robert Raszuk Cc: Keyur Patel (keyupate); Pranav Mehta (pmehta); Arjun Sreekantiah (asree= kan); luay.jalil@verizon.com; idr wg; L3VPN Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt > I was not that much fishing here ... just trying to understand if you=20 > are validating CE-CE or PE-PE. If the latter I unfortunately think=20 > there is much less of the value. >=20 > When we originally started to roll out 2547 there was very clear=20 > consensus that real protection must happen on the CE-CE boundary. > Trusting SP where anyone who logs into PE can do anything for any VPN=20 > there was never taken serious. >=20 > Note that the draft could also allow both, but this needs to be=20 > clearly stated in the text. it tries to make that pretty clear This document describes how the originating PE, West, may sign the announcement so that the destination PE, East, may authenticate the NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364] Section 4.3.1. Alternatively, the originating CE router may sign the announcement so that the destination CE router may authenticate the NLRI. >> if they want to use the rpki, then, just as other rpki publishers=20 >> using 1918 space, they would have local trust anchors and certify the=20 >> private space. see draft-ietf-sidr-ltamgmt. >=20 > And what happens in the event of PE-PE validation where only one SP of=20 > L3VPN subscribes to RPKI business ? then they should not use rpki keying but rather their own key infrastructur= e using the Key Identifier to index their KI randy From pmehta@cisco.com Wed Oct 17 10:25: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 68EC421F8645; Wed, 17 Oct 2012 10:25:24 -0700 (PDT) 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 Oki0vouPQlj8; Wed, 17 Oct 2012 10:25:19 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5851221F8630; Wed, 17 Oct 2012 10:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2221; q=dns/txt; s=iport; t=1350494719; x=1351704319; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fflUiMzSCMRzVB45qbPibM3RNu4QFH79EC5N/d8EU34=; b=fNo8UECYd7weRHo6PYTzwcOdluGkyF10dmJYOoFhE/Hx8gL1N3+DOsUG j85iW7ug0rzMVboB44UU5g20nWMMFq5Aqe9QM2c7C73igXMi5t+D0htnx rnxQqd2WTun5C/b4MZ8A6LiUrfwo1bH3AOKedqZ0hkhDnkEYLi3Kuk1lK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPboflCtJV2c/2dsb2JhbABFwCCBCIIgAQEBBBIBJz8MBAIBCBEEAQELFAkHIREUCQgCBA4FCBMHh1ADDgGbPJZMDYlUinBoJ4U7YAOUFox5gyWBa4JvgVwjGA X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="132670652" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 17 Oct 2012 17:25:18 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9HHPIUH026178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 17:25:19 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.63]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 12:25:18 -0500 From: "Pranav Mehta (pmehta)" To: Robert Raszuk Subject: RE: [Idr] draft-ymbk-l3vpn-origination-00.txt Thread-Topic: [Idr] draft-ymbk-l3vpn-origination-00.txt Thread-Index: AQHNqwAew0fd+6zQc0WX8IHgfJLNm5e7mp+AgAADjgCAAAYMgIAAAbKAgAC9qHCAAN9DAIAAf3Xw Date: Wed, 17 Oct 2012 17:25:18 +0000 Message-ID: <80F8B5888DDE96498217BE8A5C47436F180EF8@xmb-rcd-x13.cisco.com> References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> <80F8B5888DDE96498217BE8A5C47436F17F611@xmb-rcd-x13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.138.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--37.547400-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 X-Mailman-Approved-At: Thu, 18 Oct 2012 00:21:08 -0700 Cc: L3VPN , idr wg , "luay.jalil@verizon.com" , Randy Bush 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, 17 Oct 2012 17:25:24 -0000 Hi Robert, Thanks for your feedback. My comments inline.. #P# -----Original Message----- From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Tuesday, October 16, 2012 9:47 PM To: Pranav Mehta (pmehta) Cc: Randy Bush; Keyur Patel (keyupate); Arjun Sreekantiah (asreekan); luay.= jalil@verizon.com; idr wg; L3VPN Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt Hey Pranav, Do you really believe that each 7-11 or Walmart store will be subscribing t= o global RPKI or building their own key infrastructure? I do not. It seems = few orders of magnitude easier to sign advertisements at the src/spoke and = validate signature at the hub site by the same very network admin residing = in the enterprise hub location. That is something we should define in BGP f= or VPNs and not trying to reuse origin validation concept which works well = (for what it is designed to do) in the Internet case. #P# I don't think 7-11/Walmart will be subscribing to global RPKI or even b= uild their own infrastructure. RPKI makes it easier to distribute the key = but the end CE can be configured to use a static Key and this draft doesn't= preclude provisioning using static configuration. As far as all the sites= belong to same network admin, same key can be provisioned on all the sites= and in such case we don't need to get RPKI infrastructure involved. If it= 's not clear from the draft, we can definitely change the wording to clarif= y this. Btw ,,, I do not buy any "trusted" ASBR business ;) #P# In most of the cases I agree that this asymmetric solution might not be pre= ferred but think about a scenario where a VPN has few sites connected via n= on-trusted provided and most of the other (may be in thousands) sites are c= onnected to a trusted provider. Instead of upgrading all these sites to ge= nerated signed NLRIs the VPN can choose to just add the authentication at t= he ASBR boundary to protect prefix origination from un-trusted network. Th= e goal of this draft is to allow the flexibility by adding Key Identifier s= o that VPN is not forced to upgrade all the sites under this scenario. =20 Thanks, -- Pranav From rraszuk@gmail.com Sun Oct 21 07:33: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 488D121F8596; Sun, 21 Oct 2012 07:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 yH2-X+Nl6s1H; Sun, 21 Oct 2012 07:33:30 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7BB21F844B; Sun, 21 Oct 2012 07:33:27 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so1728732iad.31 for ; Sun, 21 Oct 2012 07:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hI9ixZCLsIX/gMnx9tuiq/uqm5guzw0vnwPNmsuuINY=; b=wP4YNBXW5zA1IjJxmKaBVpqsTRJ9URg+ZFMJCRKbRCoDEmkkIR+PP2KhIaJespxKpy 38fX4nrxxT86WvzxTQG0uAbdzfrjGOi1HYGi3d1hO4MZyk9gyRjHab95OWrUOOHTWLLb pZgc/J3bPF6HV4WeavRJwlLIpE9Wfy277e2cOoqjKj77ngQ9hXXXc7JGUskLCQFry2BQ DuyqDv8YtiY6Y5omarlHImWqOE2i0qldr17fDb5JPk8xMux92t8yIAdk3Trwd72STjf4 XlyKAZ0IhyLVJRLjMVu7gjd+IWomJbK97zNal/uF5iGVgfL9Q1A9/sq2x8tN2D2LI8OE NPmA== MIME-Version: 1.0 Received: by 10.50.188.225 with SMTP id gd1mr13920584igc.15.1350830007121; Sun, 21 Oct 2012 07:33:27 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Sun, 21 Oct 2012 07:33:27 -0700 (PDT) In-Reply-To: <507F745C.6000508@raszuk.net> References: <507F745C.6000508@raszuk.net> Date: Sun, 21 Oct 2012 16:33:27 +0200 X-Google-Sender-Auth: 5ap0VHgCVU8ir1CxHmewTsGC1-M Message-ID: Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt From: Robert Raszuk To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg , "Pranav Mehta, \(pmehta\)" , L3VPN , "luay.jalil@verizon.com" 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: Sun, 21 Oct 2012 14:33:31 -0000 Hello, Just noticed draft-ymbk-l3vpn-origination-01.txt ... Few follow-up questions to new version: 1. Section "5.2. Provider/ASBR Based Validation/Authentication" indicates possible validation at the ASBR. First clearly it is not possible to do that in option C which I think the draft should mention. In option C you could try to describe such validation on EBGP peering VPNvX RRs. Assuming option-B (or option-C on RRs) how do I set validation policy (based on what value and parameter) that only some VPN customer's routes will be subject for validation ? Same for PEs where subset of VPN customers request validation. Or is the draft discussing only option-A ASBRs ? 2. How much the NLRI validation on the ASBR option B or PE helps if RTs could have been mangled on the way and validated or not routes will end up going to wrong VPN sites ? Draft says: "ASBR2 is the trusted provider with whom CE1 has collaborated." How can one validate on ASBRs (or remote PEs) in the CE based key allocation scheme ? What happens if two VPN customers with overlaping IP addresses will choose the same keys on their CEs ? Note that CEs NLRI do not have notion of RDs and that ingress PEs convert IPv4 NLRIs from CE to VPNv4 NLRIs on PEs adding RD. How can the signature be possibly meaningful anywhere else that on the end PE's VRF or in the end site CE ? 3. In case of validating on the PEs or CEs how does one handle extranets ? Is the plan to share my keys with all extranet partners or use different key per each extranet VPN - case of per CE validation ? How would it work for PE based validation ? How would I carry multiples keys if VPN chooses not to share his secret with some of his extranets ? How do you associate a L3OPA to RTs ? Is the assumption in the draft that such validation is to happen in the VPNvX space on during/past the import the VRFs ? 4. How would service provider be able to inject his own prefixes into VPN sites for offering value add services (example VoIP gateway addresses) if customer chooses CE based validation ? 5. How do I propagate the result of ASBR or PE based validation to the VPN site if such (say multihomed) site is connected to SP not via BGP but via an IGP ? Many thx .. R. On Thu, Oct 18, 2012 at 5:15 AM, Robert Raszuk wrote: >> the keys are arbitrary. you can get ecerts from macdonalds for all >> the spec cares. > > If this is so what is so novel about your draft if compared with already > existing for over 10 years L3VPN WG below document ? > > http://tools.ietf.org/html/draft-ietf-l3vpn-auth-00 > > ? > > Thx, > R. From asreekan@cisco.com Tue Oct 23 11:20: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 A8FAE11E80FE; Tue, 23 Oct 2012 11:20:33 -0700 (PDT) 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 p-vTm7O1vvOr; Tue, 23 Oct 2012 11:20:32 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1F47411E80FA; Tue, 23 Oct 2012 11:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5788; q=dns/txt; s=iport; t=1351016430; x=1352226030; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ufxO6kHE3O7lsIKglgX+94w2Zbp//NKsUlHnEjJhz4g=; b=UULhgIuC9dxDD+tQ5er84dmxjO0elCBvoJ4osjgtyHD6NVxccbWSWYOC Q7HJpAdyM2SI1hEXa6YBa9I3hzYHj4MKu7AyVhkeM0Ljc6WVwDxuE6ITN eORfgxx2KSBOJeU9dV6pC7r5TOvJ4Mz8ryQQgvsIxYb4ZLqSSdjZnP/3B U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJHfhlCtJXHB/2dsb2JhbABEwXCBCIIeAQEBBAEBAQ8BJzQDCBACAQgYChQQJwslAgQBDQUIGodhAQubf49ckC+LXyeFV2ADlwiNN4Frgm+BXB4GGA X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208";a="134614459" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 23 Oct 2012 18:20:10 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9NIKAuc030547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 18:20:10 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 13:20:09 -0500 From: "Arjun Sreekantiah (asreekan)" To: Robert Raszuk , Randy Bush Subject: RE: [Idr] draft-ymbk-l3vpn-origination-00.txt Thread-Topic: [Idr] draft-ymbk-l3vpn-origination-00.txt Thread-Index: AQHNrNuLSOYjTNOD4UuRqk/qCgg5OJe+t84AgAV0XYCAAwd2QA== Date: Tue, 23 Oct 2012 18:20:09 +0000 Message-ID: <6CDE9DE8E74F58419C4C489FE0852B8F21DE01CE@xmb-rcd-x02.cisco.com> References: <507F745C.6000508@raszuk.net> In-Reply-To: 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-19298.000 x-tm-as-result: No--49.969600-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: idr wg , L3VPN , "luay.jalil@verizon.com" 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, 23 Oct 2012 18:20:33 -0000 Robert, Answers inline... 1. Section "5.2. Provider/ASBR Based Validation/Authentication" indicates possible validation at the ASBR. First clearly it is not possible= to do that in option C which I think the draft should mention. In option C= you could try to describe such validation on EBGP peering VPNvX RRs. Assuming option-B (or option-C on RRs) how do I set validation policy (base= d on what value and parameter) that only some VPN customer's routes will be= subject for validation ? Same for PEs where subset of VPN customers reques= t validation. Or is the draft discussing only option-A ASBRs ? [Arjun] The example provided is for option B ASBR. In option C, as you say the same= could be performed on ebgp vpn RRs. This is meant to serve as an example i= llustrating usage of the scheme and not all inclusive list. The validation policy is agreed upon between the trusted provider and the V= PN customer on a per VPN basis. - This would necessarily mean all routes fr= om that VPN will be subject to validation. Since all CEs for that VPN would= be Part of the agreement, there is no need for perform validation on a sub= set of the routes. We would however allow for incremental deployment in wh= ich case some of the CEs are not upgraded to support the scheme in which ca= se the ASBR can define appropriate policy to accommodate these prefixes, th= is is a matter of implementation. 2. How much the NLRI validation on the ASBR option B or PE helps if RTs could = have been mangled on the way and validated or not routes will end up going = to wrong VPN sites ? [Arjun] If the scheme is implemented for the affected VPNs on the option B ASBR or= PE , then a mangled RT will result in the route being associated with the = wrong VPN and the signature digest validation would fail since the key id= entifier are unique per VPN, this way the mis-configuration of RTs is handl= ed as well.=20 Also typically, some of the providers already perform inbound validation o= f the RTs today by stripping RTs received and mapping them locally to the o= nes used for that VPN. Draft says: "ASBR2 is the trusted provider with whom CE1 has collaborated." How can one validate on ASBRs (or remote PEs) in the CE based key allocatio= n scheme ? What happens if two VPN customers with overlaping IP addresses w= ill choose the same keys on their CEs ? Note that CEs NLRI do not have noti= on of RDs and that ingress PEs convert IPv4 NLRIs from CE to VPNv4 NLRIs on= PEs adding RD. How can the signature be possibly meaningful anywhere else = that on the end PE's VRF or in the end site CE ? [Arjun] Please note that we have Key Identifier defined which will be unique per VP= N (can map to the vpn-id) and is also part of the signature digest. Hence i= n this case the digest will be different for the VPNs with overlapping add= ress/keys/ The validation on the ASBR/remote PE will be performed by retrie= ving the key associated with the key identifier and computing the appropri= ate signature digest so there is not context of RD in use here. 3. In case of validating on the PEs or CEs how does one handle extranets ? Is = the plan to share my keys with all extranet partners or use different key p= er each extranet VPN - case of per CE validation ? How would it work for PE based validation ? How would I carry multiples key= s if VPN chooses not to share his secret with some of his extranets ? [Arjun] Each VPN would have a unique key identifier and associated key. You could c= hoose to share the key and key identifier among extranet partners. Also you= could choose to define separate key identifier and associated key for priv= ate and shared prefixes The private keys would not be shared with extranet = partners. How do you associate a L3OPA to RTs ? Is the assumption in the draft that s= uch validation is to happen in the VPNvX space on during/past the import th= e VRFs ? [Arjun] For PE based validation, the validation will happen during the import of R= Ts using context of key identifiers defined for that VPN. 4. How would service provider be able to inject his own prefixes into VPN site= s for offering value add services (example VoIP gateway addresses) if custo= mer chooses CE based validation ? [Arjun] In the example provided the provider is serving as transit and not sourcing= any routes. If the service provider (SP) is injecting the routes then it m= akes sense to have the SP PE also being part of the scheme by computing the= signature checksum on behalf of the CE. Here it makes sense to define a ke= y identifier per VPN on the PEs/CEs and generate the signature digest on th= e VPN routes on the PE with the end CEs performing the validation as before= . 5. How do I propagate the result of ASBR or PE based validation to the VPN sit= e if such (say multihomed) site is connected to SP not via BGP but via an I= GP ? [Arjun] This is a BGP based scheme. One option you have in the scenario mentioned = above is to have the PE generate the signature digest on behalf of the VPN = site by configuring the key identifier per VPN on the PE and the validation= would be done on the PE. Thanks Arjun On Thu, Oct 18, 2012 at 5:15 AM, Robert Raszuk wrote: >> the keys are arbitrary. you can get ecerts from macdonalds for all=20 >> the spec cares. > > If this is so what is so novel about your draft if compared with=20 > already existing for over 10 years L3VPN WG below document ? > > http://tools.ietf.org/html/draft-ietf-l3vpn-auth-00 > > ? > > Thx, > R. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From rraszuk@gmail.com Tue Oct 23 15:00:37 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 CC5E51F0C96; Tue, 23 Oct 2012 15:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 VOG0-4UncQ3S; Tue, 23 Oct 2012 15:00:37 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8181F0C92; Tue, 23 Oct 2012 15:00:36 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7076357iec.31 for ; Tue, 23 Oct 2012 15:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2Sb9TCeb9dyHyuLB9kMpQuxkxs7Bqdb5RAuouj8kYyQ=; b=oVMhU++JXnT47UeX7tSNOatNWr36cgULyispV1hihesAt88zGwphyiH219U/2gsXT+ wtfhvEREn2SI1qU6BY59ZLnIJcQZMGcOg0PQ4EU8pFNfVMIixv5Gppi5101vUJjQVuEb Gs2QLj6bNBWdtYkI+x409bXKdAnoS6Qg00oUXq1iAJG3TdGbfy1Eab+fuj5KhlYjxRy9 2Z+R8fPBHiGzc93BV7gR+YvIKtdVTlRQNSbRHqDAqYEG9ntN397Kd/4VADIXnNWZnLYa zhzSFX7zB0/xiVXqOMSTtwwoPkaIA5QDHuLw7Ahdh52r9yItRKPikLCiGJrutyfzitu2 qnKg== MIME-Version: 1.0 Received: by 10.42.109.194 with SMTP id m2mr12050689icp.48.1351029636645; Tue, 23 Oct 2012 15:00:36 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Tue, 23 Oct 2012 15:00:36 -0700 (PDT) In-Reply-To: <6CDE9DE8E74F58419C4C489FE0852B8F21DE01CE@xmb-rcd-x02.cisco.com> References: <507F745C.6000508@raszuk.net> <6CDE9DE8E74F58419C4C489FE0852B8F21DE01CE@xmb-rcd-x02.cisco.com> Date: Wed, 24 Oct 2012 00:00:36 +0200 X-Google-Sender-Auth: vrVvD-ur2_Y5CVa_q0iTLUGwu-8 Message-ID: Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt From: Robert Raszuk To: "Arjun Sreekantiah (asreekan)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randy Bush , idr wg , L3VPN , "luay.jalil@verizon.com" 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, 23 Oct 2012 22:00:37 -0000 Hi Arjun, > The validation policy is agreed upon between the trusted provider and the= VPN > customer on a per VPN basis. Let's observe that option B ASBR you are referring to has no per VPN basis notion. What you are describing is not possible to accomplish as said ASBR would have to perform the validation based on the subset of VPNv4 or VPNv6 routes based on the local RT import. Unless ASBR option B is also acting as local PE or is configured with A+B or option D there is no per VRF import based on the RTs. Please provide a sample configuration how are you going to enable L3VPN origin validation on ASBR " on a per VPN basis" ? > 2. > How much the NLRI validation on the ASBR option B or PE helps if RTs coul= d have been mangled on the way and validated or not routes will end up goin= g to wrong VPN sites ? > [Arjun] > If the scheme is implemented for the affected VPNs on the option B ASBR = or PE , > then a mangled RT will result in the route being associated with the wron= g VPN RTs do not associate routes to VPNs on the ASBRs. > and the signature digest validation would fail since the key identifier= are unique per > VPN, this way the mis-configuration of RTs is handled as well. The draft clearly provides the option to assign such signature on the CE. CEs are owned by customers and they may choose the same key id. > Also typically, some of the providers already perform inbound validation= of the RTs > today by stripping RTs received and mapping them locally to the ones used= for that > VPN. RT mapping if at all used in production other then via option D does not solve anything. > Draft says: "ASBR2 is the trusted provider with whom CE1 has collaborated= ." > How can one validate on ASBRs (or remote PEs) in the CE based key allocat= ion scheme ? What happens if two VPN customers with overlaping IP addresses= will choose the same keys on their CEs ? Note that CEs NLRI do not have no= tion of RDs and that ingress PEs convert IPv4 NLRIs from CE to VPNv4 NLRIs = on PEs adding RD. How can the signature be possibly meaningful anywhere els= e that on the end PE's VRF or in the end site CE ? > [Arjun] > Please note that we have Key Identifier defined which will be unique per = VPN (can map to the vpn-id) and is also part of the signature digest. The draft clearly provides the option to assign such signature on the CE. CEs are owned by customers and they may choose the same key id and the same prefix. > Hence in this case the digest will be different for the VPNs with overla= pping > address/keys/ The validation on the ASBR/remote PE will be performed by r= etrieving > the key associated with the key identifier and computing the appropriate= signature > digest so there is not context of RD in use here. On ASBR and global VPNv4 table RD is part of the NLRI. > 3. > In case of validating on the PEs or CEs how does one handle extranets ? I= s the plan to share my keys with all extranet partners or use different key= per each extranet VPN - case of per CE validation ? > How would it work for PE based validation ? How would I carry multiples k= eys if VPN chooses not to share his secret with some of his extranets ? > [Arjun] > Each VPN would have a unique key identifier and associated key. You could > choose to share the key and key identifier among extranet partners. Also = you could > choose to define separate key identifier and associated key for private a= nd shared > prefixes The private keys would not be shared with extranet partners. Please provide encoding to carry more then one key with the prefix so my keys are not shared with my extranet partners. > 4. > How would service provider be able to inject his own prefixes into VPN si= tes for offering value add services (example VoIP gateway addresses) if cus= tomer chooses CE based validation ? > [Arjun] > In the example provided the provider is serving as transit and not sourci= ng any > routes. Then such example is not that practical. > If the service provider (SP) is injecting the routes then it makes sense = to have the > SP PE also being part of the scheme by computing the signature checksum o= n > behalf of the CE. The question was clearly for CE based validation. > 5. > How do I propagate the result of ASBR or PE based validation to the VPN s= ite if such (say multihomed) site is connected to SP not via BGP but via an= IGP ? > [Arjun] > This is a BGP based scheme. That's the problem with this scheme. L3VPN are not only BGP based on the CE-CE basis. Origin validation could be made to work for Internet (assuming there is interest) however as documented it has number of architectural and practical problems to solve for L3VPN architecture. Best regards, R. From asreekan@cisco.com Tue Oct 23 18:27:56 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 39DF711E814E; Tue, 23 Oct 2012 18:27:56 -0700 (PDT) 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 lSW5nBG6ZW-n; Tue, 23 Oct 2012 18:27:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1657911E8149; Tue, 23 Oct 2012 18:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6860; q=dns/txt; s=iport; t=1351042075; x=1352251675; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QNwPMIN+js6krDBAkI72/Xsd8cLcZb9QexG9Wq7fUCE=; b=Ziu/rAXC5tU6mpVBS9x7AgrezFyU1Xz5OtDsz14smyzk7RUMz4WZi0r6 E9cpdJOTHXsEysHjTAGPvlrqJVmYawwdZG5ogjvLpNysXlu1r1m6C+10h sVXxHuy+DdHQrYkY7+z10qJuLTpqkZFu7lpytNnWUHh9RBpvW3eUmxZsR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALVDh1CtJV2d/2dsb2JhbABEwgOBCIIeAQEBAwESASc3CAUHBAIBCBEBAwEBCxQJByERFAMGCAIEDgUIEweHUAMJBQGbGJFshDENiVSKeWeFfmADlB2MfoMlgWuCYg2BXB4GGA X-IronPort-AV: E=Sophos;i="4.80,638,1344211200"; d="scan'208";a="134707796" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 24 Oct 2012 01:27:54 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9O1RsPv002694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 01:27:54 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 20:27:54 -0500 From: "Arjun Sreekantiah (asreekan)" To: Robert Raszuk Subject: RE: [Idr] draft-ymbk-l3vpn-origination-00.txt Thread-Topic: [Idr] draft-ymbk-l3vpn-origination-00.txt Thread-Index: AQHNrNuLSOYjTNOD4UuRqk/qCgg5OJe+t84AgAV0XYCAAwd2QIAAmiIA///U78A= Date: Wed, 24 Oct 2012 01:27:54 +0000 Message-ID: <6CDE9DE8E74F58419C4C489FE0852B8F21DE0656@xmb-rcd-x02.cisco.com> References: <507F745C.6000508@raszuk.net> <6CDE9DE8E74F58419C4C489FE0852B8F21DE01CE@xmb-rcd-x02.cisco.com> In-Reply-To: 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-19298.000 x-tm-as-result: No--52.105600-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 , idr wg , L3VPN , "luay.jalil@verizon.com" 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, 24 Oct 2012 01:27:56 -0000 Robert, More replies below. -----Original Message----- From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Tuesday, October 23, 2012 3:01 PM To: Arjun Sreekantiah (asreekan) Cc: Randy Bush; idr wg; L3VPN; luay.jalil@verizon.com Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt >Hi Arjun, >> The validation policy is agreed upon between the trusted provider and=20 >> the VPN customer on a per VPN basis. > >Let's observe that option B ASBR you are referring to has no per VPN basis= notion. What you are describing is not possible to accomplish as said ASBR= would have to perform the validation based on the subset of >VPNv4 or VPNv6 routes based on the local RT import. >Unless ASBR option B is also acting as local PE or is configured with >A+B or option D there is no per VRF import based on the RTs. [Arjun] The ASBR can still perform the validation based on configured key-id and as= sociated key without having to perform any import operation. As explained = before you can have the key-id map to a vpn-id and only the key-id and asso= ciated keys need to be defined on the ASBR. >Please provide a sample configuration how are you going to enable L3VPN or= igin validation on ASBR " on a per VPN basis" ? [Arjun] We will pass it you as soon as we have a implementation ready. > 2. >> How much the NLRI validation on the ASBR option B or PE helps if RTs cou= ld have been mangled on the way and validated or not routes will end up goi= ng to wrong VPN sites ? >> [Arjun] >> If the scheme is implemented for the affected VPNs on the option B=20 >> ASBR or PE , then a mangled RT will result in the route being=20 >> associated with the wrong VPN >RTs do not associate routes to VPNs on the ASBRs. [Arjun] We are not suggesting using RTs to do that in this scheme, just use the con= text of the key identifier to retrieve the associated key and verify the si= gnature digest. >> and the signature digest validation would fail since the key=20 >> identifier are unique per VPN, this way the mis-configuration of RTs is = handled as well. >The draft clearly provides the option to assign such signature on the CE. = CEs are owned by customers and they may choose the same key id. [Arjun] For the provider validation case, the CE will still need to agree upon keys= and key-id with the provider and the provider can ensure uniqueness of the= key-id across vpns. For the CE-CE Case, the secret key associated with key-id is private to the CEs in that V= PN and the signature digest will be unique across CEs . >> Also typically, some of the providers already perform inbound=20 >> validation of the RTs today by stripping RTs received and mapping them=20 >> locally to the ones used for that VPN. >RT mapping if at all used in production other then via option D does not s= olve anything. [Arjun] It ensures improper RTs are discarded. >> Draft says: "ASBR2 is the trusted provider with whom CE1 has collaborate= d." >> How can one validate on ASBRs (or remote PEs) in the CE based key alloca= tion scheme ? What happens if two VPN customers with overlaping IP addresse= s will choose the same keys on their CEs ? Note that >>CEs NLRI do not have= notion of RDs and that ingress PEs convert IPv4 NLRIs from CE to VPNv4 NLR= Is on PEs adding RD. How can the signature be possibly meaningful anywhere = else that on the end PE's VRF or >>in the end site CE ? > >[Arjun] > >Please note that we have Key Identifier defined which will be unique per= VPN (can map to the vpn-id) and is also part of the signature digest. >The draft clearly provides the option to assign such signature on the CE. = CEs are owned by customers and they may choose the same key id and the same= prefix. [Arjun] See above. The secret key to generate the digest is still private to the CE= s in that VPN. >> Hence in this case the digest will be different for the VPNs with=20 >> overlapping address/keys/ The validation on the ASBR/remote PE will be=20 >> performed by retrieving the key associated with the key identifier=20 >> and computing the appropriate signature digest so there is not context o= f RD in use here. >On ASBR and global VPNv4 table RD is part of the NLRI. [Arjun] Yes but I do not see what your point is here. >> 3. >> In case of validating on the PEs or CEs how does one handle extranets ? = Is the plan to share my keys with all extranet partners or use different ke= y per each extranet VPN - case of per CE validation ? >> How would it work for PE based validation ? How would I carry multiples = keys if VPN chooses not to share his secret with some of his extranets ? >> [Arjun] >> Each VPN would have a unique key identifier and associated key. You=20 >> could choose to share the key and key identifier among extranet=20 >> partners. Also you could choose to define separate key identifier and=20 >> associated key for private and shared prefixes The private keys would no= t be shared with extranet partners. >Please provide encoding to carry more then one key with the prefix so my k= eys are not shared with my extranet partners. [Arjun] There is no need to for encoding more than one key with a single prefix her= e. The prefix is either private when it is associated with a private key or= shared for which it has a shared key defined. > 4. >> How would service provider be able to inject his own prefixes into VPN s= ites for offering value add services (example VoIP gateway addresses) if cu= stomer chooses CE based validation ? >> [Arjun] >> In the example provided the provider is serving as transit and not=20 >> sourcing any routes. >> If the service provider (SP) is injecting the routes then it makes=20 > >sense to have the SP PE also being part of the scheme by computing the=20 > >signature checksum on behalf of the CE. >The question was clearly for CE based validation. [Arjun] In this case, The PE can sign the prefixes in this case using locally and d= efined key ID and key and share it with the CEs. >> 5. >> How do I propagate the result of ASBR or PE based validation to the VPN = site if such (say multihomed) site is connected to SP not via BGP but via a= n IGP ? >> [Arjun] >> This is a BGP based scheme. >That's the problem with this scheme. L3VPN are not only BGP based on the C= E-CE basis. >Origin validation could be made to work for Internet (assuming there is in= terest) however as documented it has number of architectural and practical = problems to solve for L3VPN architecture. [Arjun] I would disagree - we can work out a solution in the l3vpn case as well - s= uggest we sync up at the upcoming meeting in Atlanta if you have further c= oncerns. Thanks Arjun Best regards, R. From rraszuk@gmail.com Wed Oct 24 00:27: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 534AA21F84AF; Wed, 24 Oct 2012 00:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 ZOjzxZ0hP3jt; Wed, 24 Oct 2012 00:27:32 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A19321F84B5; Wed, 24 Oct 2012 00:27:32 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so290315iec.31 for ; Wed, 24 Oct 2012 00:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iU7U4ZpnZJ0Dychhz9TUxV28dN2AwSO20RW3hdWEkOk=; b=Ju+hAJDDCJdWgFiqkXfnk/dXLkA6OmSOXqz4O3XPGASC4Ck+lvM2s7RZNCY7zwkjfR 9PSfJbK3C95Bd12BKKdheou4cERzY2XP6otn3kdiVoyJKj3780WhNziaemfhzowT8nDD dbQJI2Q1VZxRq3jbFvmDJt9zRp3V5G9gdOQalOJfHSPfaW4YlXB8HSImHSTeNOIrj1oJ 2hK+BISGjz9CZd29W5TkfV8T8hiX7sz0hVnswuDzkxLyYlesTEXXBHFhgwB89rzyknLc 5U30q1S+3KZeODmsHm9OijKD7pg7LZCfT9b133PaMKkCT3RkKQWp1y0WQyHQSXTCLLcE wbjQ== MIME-Version: 1.0 Received: by 10.50.87.227 with SMTP id bb3mr1643245igb.15.1351063651849; Wed, 24 Oct 2012 00:27:31 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Wed, 24 Oct 2012 00:27:31 -0700 (PDT) In-Reply-To: <6CDE9DE8E74F58419C4C489FE0852B8F21DE0656@xmb-rcd-x02.cisco.com> References: <507F745C.6000508@raszuk.net> <6CDE9DE8E74F58419C4C489FE0852B8F21DE01CE@xmb-rcd-x02.cisco.com> <6CDE9DE8E74F58419C4C489FE0852B8F21DE0656@xmb-rcd-x02.cisco.com> Date: Wed, 24 Oct 2012 09:27:31 +0200 X-Google-Sender-Auth: 8o8JP5oTubNA6X4OfoLP849wfAA Message-ID: Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt From: Robert Raszuk To: "Arjun Sreekantiah (asreekan)" Content-Type: text/plain; charset=ISO-8859-1 Cc: Randy Bush , idr wg , L3VPN , "luay.jalil@verizon.com" 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, 24 Oct 2012 07:27:33 -0000 > [Arjun] > The ASBR can still perform the validation based on configured key-id and associated key > without having to perform any import operation. As explained before you can have the key- > id map to a vpn-id and only the key-id and associated keys need to be defined on the > ASBR. There is no such a thing in VPNv4/v6 advertisement like "vpn-id". >>RTs do not associate routes to VPNs on the ASBRs. > > [Arjun] > We are not suggesting using RTs to do that in this scheme, just use the context of the > key identifier to retrieve the associated key and verify the signature digest. That is precisely the main issue with your proposal. You would be much better off with adding RT validation (*based on the very same scheme as you proposed for NLRI validation in this draft*) Thx, R. From martin.vigoureux@alcatel-lucent.com Thu Oct 25 09:18: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 73FFB21F8928 for ; Thu, 25 Oct 2012 09:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.649 X-Spam-Level: X-Spam-Status: No, score=-109.649 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 fV-wXHfYK7aR for ; Thu, 25 Oct 2012 09:18:50 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id D05E621F879C for ; Thu, 25 Oct 2012 09:18:46 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q9PGICqL028725 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 25 Oct 2012 18:18:43 +0200 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 25 Oct 2012 18:18:16 +0200 Received: from [135.244.11.80] (135.5.27.18) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 25 Oct 2012 12:18:15 -0400 Message-ID: <50896643.5070604@alcatel-lucent.com> Date: Thu, 25 Oct 2012 18:18:11 +0200 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: IETF85 - L3VPN Session - Agenda available / Time to send slides Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.18] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 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, 25 Oct 2012 16:18:51 -0000 All, the agenda is available here: http://www.ietf.org/proceedings/85/agenda/agenda-85-l3vpn Please have a look at it. It is now time for the speakers to send us their slides. Please send them no later than Sunday 4th, 8pm, Atlanta time. Thanks. Martin & Thomas From Uwe.Joorde@telekom.de Mon Oct 29 00:43:05 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 9812121F868F for ; Mon, 29 Oct 2012 00:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 1KKuAbHCBKtk for ; Mon, 29 Oct 2012 00:43:05 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8C021F8449 for ; Mon, 29 Oct 2012 00:43:02 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 29 Oct 2012 08:43:00 +0100 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 29 Oct 2012 08:43:00 +0100 From: To: , Date: Mon, 29 Oct 2012 08:42:59 +0100 Subject: RE: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Thread-Topic: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Thread-Index: Ac2x49YpFDCfCl6ISnalo3JtaGTqDgDwxYCQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D15AD156D6D@HE111648.emea1.cds.t-internal.com> References: <50729A0B.6030201@alcatel-lucent.com> In-Reply-To: <50729A0B.6030201@alcatel-lucent.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 30 Oct 2012 03:13:15 -0700 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, 29 Oct 2012 07:43:05 -0000 Support, Cheers Uwe -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of M= artin Vigoureux Sent: Monday, October 08, 2012 11:17 AM To: l3vpn@ietf.org Subject: Poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 Hello working group, this is to start a two weeks poll for adoption of draft-rosen-l3vpn-mvpn-mldp-nlri-01 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 October 22nd. 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 From lucy.yong@huawei.com Wed Oct 31 09:41:36 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 3542821F8713 for ; Wed, 31 Oct 2012 09:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 PkoAuw7jMRhF for ; Wed, 31 Oct 2012 09:41:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2E66A21F870F for ; Wed, 31 Oct 2012 09:41:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMF76707; Wed, 31 Oct 2012 16:41:30 +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; Wed, 31 Oct 2012 16:40:23 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 31 Oct 2012 16:40:53 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 31 Oct 2012 09:40:50 -0700 From: Lucy yong To: "Luyuan Fang (lufang)" , "wardd@cisco.com" , "rex@cisco.com" , "mnapierala@att.com" , "nabil.bitar@verizon.com" , "dhrao@cisco.com" Subject: comment on draft-fang-l3vpn-virtual-pe-framework-01 Thread-Topic: comment on draft-fang-l3vpn-virtual-pe-framework-01 Thread-Index: Ac23hctPiQHvGKzWS4ms8LiAALc6og== Date: Wed, 31 Oct 2012 16:40:49 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482B490@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.83.91] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4482B490dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 31 Oct 2012 09:43:43 -0700 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: Wed, 31 Oct 2012 16:41:36 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4482B490dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Co-authors on this draft, I read the document and have some comments and suggestions. 1) The intention of the draft is to extend L3VPN PE to a vPE on end device= s in DC. We need to distinct about two cases clearly in the framework, one= is that a L3VPN applies to intra DC; another is a L3VPN in DC connecting L= 3VPN in WAN which connects to Enterprise site. We can fully describe vPE fu= nction in the first case. the second case is about L3VPN interworking acros= s different underlying networks, which is orthogonal to vPE functions. The = draft seems mix two together. In the nvo3 use case draft, we have clearly d= escribed two use cases. (draft-mity-nov3-use-case-04) 2) Text for the key requirement in section 1.2 : 3) Support end-to-end L3VPN connectivity, e.g. L3VPN can start from a service network end device, connect to a corresponding L3VPN in the WAN, and terminate in another service network end device. Not sure why this is the key requirement. If this is to allow end-to-end= L3VPN span across multiple DC sites, DC providers may prefer to use WAN to= interconnect DC underlying networks first. Then they can create end-to-end= L3VPN (overlay) without WAN operator interferes. This is, in turn, to beco= me the first case in two case mentioned in the first comment. IMO: the key = requirements is to support case 1 and case 2 in my first comments. 3) What does the true network abstraction mean? 4) The third paragraph in section 2.1. comment: if vPE allows L3VPN contro= l plane and forwarding function residing on different physical devices, a p= rotocol is necessary between control plane and forwarding entity. This is a= significant change for L3VPN PE function. The draft should point out. 5) The fourth paragraph in section 2.1. Comment: When vPE and VM on one en= d device, it simplifies the control plane and data plane functions between = PE and CE in RFC4364. The draft should clarity that. 6) Since we need to decouple the underlying network and the overlay networ= k, i.e. end-to-end L3VPN in this document, modeling a virtualized service n= etwork in figure 1 to include Gateway PE, Transport Device and vPE in end d= evice is misleading. The virtualized service network should not include Tra= nsport device at all. 7) Again, this model should be generic to show that a virtualized service = network may include vPEs, PE, or Gateway PE to cover both case 1 and case 2= in my first comment. 8) Again, this model architecture should separate DC physical network and = DC virtualized service network like the nvo3 architecture model in the nvo3= framework draft. This will let you describe a WAN L3VPN that may connect t= o DC underlying network and DC virtualized service network. Please see the = draft-hy-nvo3-vpn-gap-analysis draft. 9) If vPE can reside on different physical devices as described in the dra= ft, using a VRF block to describe the VPN entity on a vPE is not proper bec= ause you can't split them further. So Figure 2 need to separate the VRF int= o two entities and describe that two entities may be on one end device or m= ay on separated devices. IMO: this is significant different from the L3VPN = in RFC4364. 10) Figure 3 can only express option A in RFC4364. Option B does no= t use gateway PE, it only uses ASBR. ASBR is very different from a PE. Alth= ough in option B, L3VPN control plane can advertise the VPN routes from a P= E in an AS to the PE in another AS. It does not mean that the P nodes in an= AS know how to route to the PE in another AS. This will be an issue when u= se IP GRE tunnels. To use MPLS LSP tunnel, option B requires pre-build MPLS= LSP tunnel between two PEs that belong to different ASes, which requires t= wo SPs pre-provisioning process that may not apply to here. The framework n= eed to clarify that. In addition, WAN may use MPLS LSP tunnel and DC may us= e IP based tunnel. 11) In section 3, regarding to Centralized routing controller, it i= s good to enable SDN approach in L3VPN. However, RFC4364 does not enable SD= N approach. This is regardless use of vPE or PE. This is significant change= to the L3VPN in my opinion. 12) As the result, the framework contains significant extension or = changes to existing L3VPN. We should require the WG recharter to include th= is pieces first. Cheers, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D4482B490dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Co-authors on this draft,

=  

= I read the document and have some comments and suggestions.

=  

1)  The intention of the draft is to extend L3VPN PE to a vPE on end de= vices in DC.  We need to distinct about two cases clearly in the frame= work, one is that a L3VPN applies to intra DC; another is a L3VPN in DC connecting L3VPN in WAN which connects to Enterprise site= . We can fully describe vPE function in the first case. the second case is = about L3VPN interworking across different underlying networks, which is ort= hogonal to vPE functions. The draft seems mix two together. In the nvo3 use case draft, we have clearly descri= bed two use cases. (draft-mity-nov3-use-case-04)

 

2)  Text for the key requirement in section 1.2 :

   3= ) Support end-to-end L3VPN connectivity, e.g. L3VPN can start from a

   service network end de= vice, connect to a corresponding L3VPN in the

   WAN, and terminate in another service network end de= vice.

 

   Not sure why this is the key requirement. If this = is to allow end-to-end L3VPN span across multiple DC sites, DC providers ma= y prefer to use WAN to interconnect DC underlying networks first. Then they can create end-to-end L3VPN (overlay) without WAN operato= r interferes. This is, in turn, to become the first case in two case mentio= ned in the first comment. IMO: the key requirements is to support case 1 an= d case 2 in my first comments.

 

3)  What does the true network abstraction mean?

 

4)  The third paragraph in section 2.1. comment: if vPE all= ows L3VPN control plane and forwarding function residing on different physi= cal devices, a protocol is necessary between control plane and forwarding entity. This is a significant change for L3VP= N PE function. The draft should point out.

 

5)  The fourth paragraph in section 2.1. Comment: When vPE = and VM on one end device, it simplifies the control plane and data plane fu= nctions between PE and CE in RFC4364. The draft should clarity that.

 

6)  Since we need to decouple the underlying network and th= e overlay network, i.e. end-to-end L3VPN in this document, modeling a virtu= alized service network in figure 1 to include Gateway PE, Transport Device and vPE in end device is misleading. The virt= ualized service network should not include Transport device at all.

 

7)  Again, this model should be generic to show that a virt= ualized service network may include vPEs, PE, or Gateway PE to cover both c= ase 1 and case 2 in my first comment.

 

8)  Again, this model architecture should separate DC physi= cal network and DC virtualized service network like the nvo3 architecture m= odel in the nvo3 framework draft. This will let you describe a WAN L3VPN that may connect to DC underlying network and= DC virtualized service network. Please see the draft-hy-nvo3-vpn-gap-analy= sis draft.

 

9)  If vPE can reside on different physical devices as desc= ribed in the draft, using a VRF block to describe the VPN entity on a vPE i= s not proper because you can’t split them further. So Figure 2 need to separate the VRF into two entities and describe that t= wo entities may be on one end device or may on separated devices. IMO: this= is significant different from the L3VPN in RFC4364.

 

10)       =   Figure 3 can only express option A in RFC4364. Option B= does not use gateway PE, it only uses ASBR. ASBR is very different from a = PE. Although in option B, L3VPN control plane can advertise the VPN routes from a PE in an AS to the PE in another AS. I= t does not mean that the P nodes in an AS know how to route to the PE in an= other AS. This will be an issue when use IP GRE tunnels. To use MPLS LSP tu= nnel, option B requires pre-build MPLS LSP tunnel between two PEs that belong to different ASes, which requi= res two SPs pre-provisioning process that may not apply to here. The framew= ork need to clarify that. In addition, WAN may use MPLS LSP tunnel and DC m= ay use IP based tunnel.

 

11)       =   In section 3, regarding to Centralized routing controll= er, it is good to enable SDN approach in L3VPN. However, RFC4364 does not e= nable SDN approach. This is regardless use of vPE or PE. This is significant change to the L3VPN in my opinion.  

 

12)       =   As the result, the framework contains significant exten= sion or changes to existing L3VPN. We should require the WG recharter to in= clude this pieces first.

 

Cheers,

Lucy

 

 =

--_000_2691CE0099834E4A9C5044EEC662BB9D4482B490dfweml505mbx_-- From rraszuk@gmail.com Wed Oct 31 09:54:50 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 B67B121F873D for ; Wed, 31 Oct 2012 09:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 SxVISGPEaz2E for ; Wed, 31 Oct 2012 09:54:49 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D123521F873A for ; Wed, 31 Oct 2012 09:54:49 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so2726857iec.31 for ; Wed, 31 Oct 2012 09:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TtqzwQhL7e4KnP1jC+tKlaRsviKC9qdaatAD68vO7xg=; b=CZ+Cr0dT6WC3XZbUw/WS7A9dd9F+Ve8LJMCJo1J4jfNFHFKgJUc2CzEe8qp7Cn4oDA KPNKwB5xiPZVbG+gIbGA507AzPIXTXeV9SSUNsICQ3klR52ZGHxPI0fGP1wrmCUVhTID kwzPvvpTKUSqopqiyI/gRCKqi7qiPQULWVoaWycUuuPmbfa3c/p7ePWXABdFxT3LkHgS /k2SSNrhDdxaLg/HG/vpdzZOzIaWP0pPVVNo0GVOCNGfzx+XTW+q1Rz359boYlG/nQ5t k3mX+K+VD0N72mSeM5Bi+yqLOR+8bBNvQ5LKPppJXwjL1RzC8+PdR30IvwIduwitRFPI B3kQ== MIME-Version: 1.0 Received: by 10.50.151.172 with SMTP id ur12mr2221050igb.44.1351702489226; Wed, 31 Oct 2012 09:54:49 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Wed, 31 Oct 2012 09:54:49 -0700 (PDT) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482B490@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D4482B490@dfweml505-mbx> Date: Wed, 31 Oct 2012 17:54:49 +0100 X-Google-Sender-Auth: sHSgEIgibjKh7SAt7XoMpkKX2LI Message-ID: Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 From: Robert Raszuk To: Lucy yong Content-Type: text/plain; charset=ISO-8859-1 Cc: "nabil.bitar@verizon.com" , "l3vpn@ietf.org" , "rex@cisco.com" , "wardd@cisco.com" 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, 31 Oct 2012 16:54:50 -0000 Lucy. > To use MPLS LSP tunnel, option B requires pre-build MPLS > LSP tunnel between two PEs that belong to different ASes, which requires two > SPs pre-provisioning process that may not apply to here. Incorrect. Option B does not require "pre-build MPLS LSP tunnel between two PEs that belong to different ASes" - that would be option C. In fact option B does not require any pre established LSP or IP tunnel between PE-PE. Option B ASBR set's next hop self on VPNv4/v6 routes hence it terminates any corresponding transport encapsulation used in it's own domain. Cheers, R. From lucy.yong@huawei.com Wed Oct 31 11:50: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 ADBC721F8860 for ; Wed, 31 Oct 2012 11:50:57 -0700 (PDT) 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, 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 WP5ecgCm7NCc for ; Wed, 31 Oct 2012 11:50:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 28BB421F8847 for ; Wed, 31 Oct 2012 11:50:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALC46927; Wed, 31 Oct 2012 18:50:53 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 31 Oct 2012 18:50:24 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 31 Oct 2012 18:50:52 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 31 Oct 2012 11:50:47 -0700 From: Lucy yong To: Robert Raszuk Subject: RE: comment on draft-fang-l3vpn-virtual-pe-framework-01 Thread-Topic: comment on draft-fang-l3vpn-virtual-pe-framework-01 Thread-Index: Ac23hctPiQHvGKzWS4ms8LiAALc6ogAPVFKAAAses3A= Date: Wed, 31 Oct 2012 18:50:46 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482B57E@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D4482B490@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: DlZz HN7o Jif/ Kx4F U3tx YO/R eerv hNnW ikmj 08gV 0+rX 2vc5 6ubV AABo0w== ABGMYg== ABmPXg==; 8; ZABoAHIAYQBvAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBsADMAdgBwAG4AQABpAGUAdABmAC4AbwByAGcAOwBsAHUAZgBhAG4AZwBAAGMAaQBzAGMAbwAuAGMAbwBtADsAbQBuAGEAcABpAGUAcgBhAGwAYQBAAGEAdAB0AC4AYwBvAG0AOwBuAGEAYgBpAGwALgBiAGkAdABhAHIAQAB2AGUAcgBpAHoAbwBuAC4AYwBvAG0AOwByAGUAeABAAGMAaQBzAGMAbwAuAGMAbwBtADsAcgBvAGIAZQByAHQAQAByAGEAcwB6AHUAawAuAG4AZQB0ADsAdwBhAHIAZABkAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Sosha1_v1; 7; {BEC5DD63-5240-4EE1-8307-D0B5D0B6CFD5}; bAB1AGMAeQAuAHkAbwBuAGcAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Wed, 31 Oct 2012 18:50:45 GMT; UgBFADoAIABjAG8AbQBtAGUAbgB0ACAAbwBuACAAZAByAGEAZgB0AC0AZgBhAG4AZwAtAGwAMwB2AHAAbgAtAHYAaQByAHQAdQBhAGwALQBwAGUALQBmAHIAYQBtAGUAdwBvAHIAawAtADAAMQA= x-cr-puzzleid: {BEC5DD63-5240-4EE1-8307-D0B5D0B6CFD5} x-originating-ip: [10.47.139.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nabil.bitar@verizon.com" , "l3vpn@ietf.org" , "rex@cisco.com" , "wardd@cisco.com" 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, 31 Oct 2012 18:50:57 -0000 Hi Robert, Here is the text from RFC4364 regarding to option B.=20 In this procedure, the PE routers use IBGP to redistribute labeled VPN-IPv4 routes either to an Autonomous System Border Router (ASBR), or to a route reflector of which an ASBR is a client. The ASBR then uses EBGP to redistribute those labeled VPN-IPv4 routes to an ASBR in another AS, which in turn distributes them to the PE routers in that AS, or perhaps to another ASBR which in turn distributes them, and so on. This procedure requires that there be a label switched path leading from a packet's ingress PE to its egress PE. Hence the appropriate trust relationships must exist between and among the set of ASes along the path. Also, there must be agreement among the set of SPs as to which border routers need to receive routes with which Route Targets. -end Option C request set up two LSP tunnel, one from ingress PE to egress PE, s= econd from ingress PE to ASBR to solve the issue in IGP. Lucy > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > Raszuk > Sent: Wednesday, October 31, 2012 11:55 AM > To: Lucy yong > Cc: Luyuan Fang (lufang); wardd@cisco.com; rex@cisco.com; > mnapierala@att.com; nabil.bitar@verizon.com; dhrao@cisco.com; > l3vpn@ietf.org > Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 >=20 > Lucy. >=20 > > To use MPLS LSP tunnel, option B requires pre-build MPLS > > LSP tunnel between two PEs that belong to different ASes, which > requires two > > SPs pre-provisioning process that may not apply to here. >=20 > Incorrect. >=20 > Option B does not require "pre-build MPLS LSP tunnel between two PEs > that belong to different ASes" - that would be option C. >=20 > In fact option B does not require any pre established LSP or IP tunnel > between PE-PE. Option B ASBR set's next hop self on VPNv4/v6 routes > hence it terminates any corresponding transport encapsulation used in > it's own domain. >=20 > Cheers, > R. From sajassi@cisco.com Wed Oct 31 12:05: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 C7EB721F882E for ; Wed, 31 Oct 2012 12:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 MS9WqJ51RECN for ; Wed, 31 Oct 2012 12:05:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1035021F8829 for ; Wed, 31 Oct 2012 12:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2550; q=dns/txt; s=iport; t=1351710306; x=1352919906; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=z/A5W6Yw3yPgwMlGVwoHzkKh+ZbA+nxF40xpurF4Dlo=; b=I5RXhTWl1Eg3ZeDT6UcKiT4Q6TznX8mtJh5Mn0LN6yOrnu1dN1PypfHu MIalPbi4Pihsdp1pQQwuIXbZ80Sndn03uxZRmfvbjNhIcmrF1hSJ54PBy iyd1/Jpv/zHm7S5pi9On0k/LkRBpma0THaESrO/HnUUA9WJZLjJQT8QuY Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAh1kVCtJXG+/2dsb2JhbABEgmzAboEIgh4BAQEEEgEnOAcMBgEIEQQBAQsUCSgRFAkIAQEEAQ0FCBqHUgMPAZtFlkQNiVSLEWeFWmEDlCGNBoMmgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="137493655" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 31 Oct 2012 19:05:05 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9VJ55WO016588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 19:05:05 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 14:05:04 -0500 From: "Ali Sajassi (sajassi)" To: Lucy yong , Robert Raszuk Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 Thread-Topic: comment on draft-fang-l3vpn-virtual-pe-framework-01 Thread-Index: Ac23hctPiQHvGKzWS4ms8LiAALc6ogALI3CAAAQMrQD//46jAA== Date: Wed, 31 Oct 2012 19:05:03 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D78F743@xmb-aln-x13.cisco.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482B57E@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.128.2.115] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--43.299000-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-ID: <15B877A08553E04F823ADEEECCAEBC24@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rex Fernando \(rex\)" , "nabil.bitar@verizon.com" , "l3vpn@ietf.org" , "David Ward \(wardd\)" 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, 31 Oct 2012 19:05:06 -0000 Lucy, Robert is right. In option B, IGP LSP is terminated on ASBRs and the label switching is performed using VPN labels. The paragraph that you quoted from 4364, just says appropriate trust relationship need to exist between ASes for EBGP route redistribution. Cheers, Ali On 10/31/12 11:50 AM, "Lucy yong" wrote: >Hi Robert, > >Here is the text from RFC4364 regarding to option B. > >In this procedure, the PE routers use IBGP to redistribute > labeled VPN-IPv4 routes either to an Autonomous System Border > Router (ASBR), or to a route reflector of which an ASBR is a > client. The ASBR then uses EBGP to redistribute those labeled > VPN-IPv4 routes to an ASBR in another AS, which in turn > distributes them to the PE routers in that AS, or perhaps to > another ASBR which in turn distributes them, and so on. > >This procedure requires that there be a label switched path > leading from a packet's ingress PE to its egress PE. Hence the > appropriate trust relationships must exist between and among > the set of ASes along the path. Also, there must be agreement > among the set of SPs as to which border routers need to receive > routes with which Route Targets. >-end > >Option C request set up two LSP tunnel, one from ingress PE to egress PE, >second from ingress PE to ASBR to solve the issue in IGP. > >Lucy >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >> Raszuk >> Sent: Wednesday, October 31, 2012 11:55 AM >> To: Lucy yong >> Cc: Luyuan Fang (lufang); wardd@cisco.com; rex@cisco.com; >> mnapierala@att.com; nabil.bitar@verizon.com; dhrao@cisco.com; >> l3vpn@ietf.org >> Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 >>=20 >> Lucy. >>=20 >> > To use MPLS LSP tunnel, option B requires pre-build MPLS >> > LSP tunnel between two PEs that belong to different ASes, which >> requires two >> > SPs pre-provisioning process that may not apply to here. >>=20 >> Incorrect. >>=20 >> Option B does not require "pre-build MPLS LSP tunnel between two PEs >> that belong to different ASes" - that would be option C. >>=20 >> In fact option B does not require any pre established LSP or IP tunnel >> between PE-PE. Option B ASBR set's next hop self on VPNv4/v6 routes >> hence it terminates any corresponding transport encapsulation used in >> it's own domain. >>=20 >> Cheers, >> R. From rraszuk@gmail.com Wed Oct 31 13:16: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 1E4F521F8436 for ; Wed, 31 Oct 2012 13:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 QzJnACDK1Ss6 for ; Wed, 31 Oct 2012 13:16:05 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73FEF21F841E for ; Wed, 31 Oct 2012 13:16:05 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so3057412iec.31 for ; Wed, 31 Oct 2012 13:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6POAZaVk7AdTh2cBvW/JVBW+rg0nYJnl4Ico7Hh9E2E=; b=V6aRZYT/ryOsvhKlZfFUltHVRI6e+ytekpLPc3vgRf6n2BqvVU1DG3w0Vp5t8FFyUC D0LLpjVx0SelPSG6KtGQXrlR1dFAnJBn2M9Yw6t62UFdwqbrJ0tzYRZqzRSklZKDRdJn lhlzdNTX54N7VTSMVCe+hfLhftJaBxBxMWZoMTNxavyPhj7shA5wtJzVSH/17nX1TPax FQopA+NCNkOeRW4qlMPxK7A0+RNGxs07rcLv77GYVGi8jhXxKeP6Y/S2RhjwBPmRryDK NVDOwsSIae5vaHJWU+sVaBioSb5ShAsn7EJnCxOuUgQR/HKLkxmIJX83+g8RNoO1ojQz dSUg== MIME-Version: 1.0 Received: by 10.50.87.227 with SMTP id bb3mr2918580igb.15.1351714565040; Wed, 31 Oct 2012 13:16:05 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Wed, 31 Oct 2012 13:16:05 -0700 (PDT) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482B57E@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D4482B490@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D4482B57E@dfweml505-mbx> Date: Wed, 31 Oct 2012 21:16:05 +0100 X-Google-Sender-Auth: 8cHQiajMFVKgo05BMRIuJt6c4Fk Message-ID: Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 From: Robert Raszuk To: Lucy yong Content-Type: text/plain; charset=ISO-8859-1 Cc: "nabil.bitar@verizon.com" , "l3vpn@ietf.org" , "rex@cisco.com" , "wardd@cisco.com" 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, 31 Oct 2012 20:16:06 -0000 Lucy, Your interpretation of the RFC is wrong. Moreover your understanding of option C is also incorrect. > Option C request set up two LSP tunnel, one from ingress PE to egress PE, > second from ingress PE to ASBR to solve the issue in IGP. That may refer only to local within given AS LSP hierarchy for example using RFC3107 for external PE loopbacks distribution rather then injecting them to the local IGP. Note that that non of those concerns apply when you use IP encapsulation between PEs what is the preferred encapsulation anyway in the data center environments when tenants need to extend their VPNs across WAN. Cheers, R. On Wed, Oct 31, 2012 at 7:50 PM, Lucy yong wrote: > Hi Robert, > > Here is the text from RFC4364 regarding to option B. > > In this procedure, the PE routers use IBGP to redistribute > labeled VPN-IPv4 routes either to an Autonomous System Border > Router (ASBR), or to a route reflector of which an ASBR is a > client. The ASBR then uses EBGP to redistribute those labeled > VPN-IPv4 routes to an ASBR in another AS, which in turn > distributes them to the PE routers in that AS, or perhaps to > another ASBR which in turn distributes them, and so on. > > This procedure requires that there be a label switched path > leading from a packet's ingress PE to its egress PE. Hence the > appropriate trust relationships must exist between and among > the set of ASes along the path. Also, there must be agreement > among the set of SPs as to which border routers need to receive > routes with which Route Targets. > -end > > Option C request set up two LSP tunnel, one from ingress PE to egress PE, second from ingress PE to ASBR to solve the issue in IGP. > > Lucy >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >> Raszuk >> Sent: Wednesday, October 31, 2012 11:55 AM >> To: Lucy yong >> Cc: Luyuan Fang (lufang); wardd@cisco.com; rex@cisco.com; >> mnapierala@att.com; nabil.bitar@verizon.com; dhrao@cisco.com; >> l3vpn@ietf.org >> Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 >> >> Lucy. >> >> > To use MPLS LSP tunnel, option B requires pre-build MPLS >> > LSP tunnel between two PEs that belong to different ASes, which >> requires two >> > SPs pre-provisioning process that may not apply to here. >> >> Incorrect. >> >> Option B does not require "pre-build MPLS LSP tunnel between two PEs >> that belong to different ASes" - that would be option C. >> >> In fact option B does not require any pre established LSP or IP tunnel >> between PE-PE. Option B ASBR set's next hop self on VPNv4/v6 routes >> hence it terminates any corresponding transport encapsulation used in >> it's own domain. >> >> Cheers, >> R. From erosen@cisco.com Wed Oct 31 13:44:53 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 F2D3221F87DD for ; Wed, 31 Oct 2012 13:44:52 -0700 (PDT) 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 7VK7kg56prUi for ; Wed, 31 Oct 2012 13:44:52 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 00BF121F871D for ; Wed, 31 Oct 2012 13:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3200; q=dns/txt; s=iport; t=1351716292; x=1352925892; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=d5ZAEQUwrHdWM4dH8ue+Kro9W15qingIraZ5PcIA9ao=; b=IWbbdCMdUApX1h3w0qTm2D5YTZQfnaYf7ocEp2yKfCPeZ0D1WYDMaQxS bDLntCvOM2cEy74VAGLN20igvfPE/dcHy8zWaH4cOaNlOblOIjpZzodby /F+Xe/jH5N+sSvxXCYxlN0Mw4Lrf42MZ0V+ssQJhhwXGm6xFk1qzSXJTg I=; X-IronPort-AV: E=Sophos;i="4.80,688,1344211200"; d="scan'208";a="62815544" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 31 Oct 2012 20:44:43 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9VKigf4009353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Oct 2012 20:44:43 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 q9VKifYM021625; Wed, 31 Oct 2012 16:44:41 -0400 To: Lucy yong Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 In-reply-to: Your message of Wed, 31 Oct 2012 18:50:46 -0000. <2691CE0099834E4A9C5044EEC662BB9D4482B57E@dfweml505-mbx> Date: Wed, 31 Oct 2012 16:44:41 -0400 Message-ID: <21624.1351716281@erosen-linux> From: Eric Rosen Cc: "rex@cisco.com" , "nabil.bitar@verizon.com" , "l3vpn@ietf.org" , Robert Raszuk , "wardd@cisco.com" 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, 31 Oct 2012 20:44:53 -0000 I think there's a misunderstanding of the sentence from RFC4364: "This procedure requires that there be a label switched path leading from a packet's ingress PE to its egress PE." If a VPN packet is traveling the following path: PE1--->P1--->ASBR1--->ASBR2--->P2--->PE2 where the ASBRs are supporting option B, then there is necessarily an LSP consisting of the following sequence of routers: . What makes this sequence of routers an LSP is that they all operate on the "VPN label". (See section 3.15 of RFC 3031 for the precise definition of "Label Switched Path". Note that "LSP" is defined relative to the position of a particular label in the stack of a particular packet.) PE1 pushes on the label, ASBR1 swaps it with a label assigned by ASBR2, ASBR2 swaps it with a label assigned by PE2, PE2 pops it. We could call this the "VPN LSP", because it follows the path of distribution of a VPN-IP route. The cited text is intended to distinguish option B from option A; in option A, the sequence is not an LSP, because ASBR2 does not distribute labels to ASBR1. > which requires two SPs pre-provisioning process that may not apply to > here. The LSP exists by virtue of the distribution of the labeled VPN-IP routes. Note that, although is an LSP according to the definition in RFC 3031, each router in the sequence only has to know which router is next in the sequence; the ingress router does not need to know how to reach to the egress router. Also, there is no requirement that an LSP is used to carry packets from PE1 to ASBR1, or from ASBR2 to PE2. Either or both of those "hops" could be via a GRE tunnel, or any other method of transport. It's true that in a typical deployment, there is a "top-level" LSP and another "top-level" LSP . Neither of these is the VPN LSP; rather, each is used to carry packets from one member of the VPN LSP to the next member in sequence. But option B is independent of how packets get between adjacent members of the VPN LSP. > WAN may use MPLS LSP tunnel and DC may use IP based tunnel. That is compatible with RFC4364 option B, because the LSP still exists. > This will be an issue when use IP GRE tunnels. It's only an issue if you want to have a single GRE tunnel that goes from PE1 to PE2. If that is what you want, then you should probably be using option C. Option B does not tell the ingress PE who the egress PE is. (Well, not unless RFC 6513/6514 is also in use ...) > Option C request set up two LSP tunnel, one from ingress PE to egress PE, > second from ingress PE to ASBR to solve the issue in IGP. In option C, the "VPN LSP" would be . If one wants to use MPLS to move the packets from PE1 to PE2, one needs a "top-level" LSP like ; but this is not the "VPN LSP". I think you interpreted the text from RFC 4364 as requiring this top-level LSP for option B, but it is only intended to require the VPN LSP . I'm not sure whether this makes things any clearer or not ... From lucy.yong@huawei.com Wed Oct 31 15:01:07 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 C471121F8787 for ; Wed, 31 Oct 2012 15:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 gfyORLiWAD7j for ; Wed, 31 Oct 2012 15:01:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CF04321F8776 for ; Wed, 31 Oct 2012 15:01:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMF90487; Wed, 31 Oct 2012 22:01:04 +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; Wed, 31 Oct 2012 21:59:07 +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; Wed, 31 Oct 2012 21:59:38 +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; Wed, 31 Oct 2012 14:59:35 -0700 From: Lucy yong To: "erosen@cisco.com" Subject: RE: comment on draft-fang-l3vpn-virtual-pe-framework-01 Thread-Topic: comment on draft-fang-l3vpn-virtual-pe-framework-01 Thread-Index: Ac23hctPiQHvGKzWS4ms8LiAALc6opfT5u2A Date: Wed, 31 Oct 2012 21:59:34 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482B705@dfweml505-mbx> References: Your message of Wed, 31 Oct 2012 18:50:46 -0000. <2691CE0099834E4A9C5044EEC662BB9D4482B57E@dfweml505-mbx> <21624.1351716281@erosen-linux> In-Reply-To: <21624.1351716281@erosen-linux> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rex@cisco.com" , "nabil.bitar@verizon.com" , "l3vpn@ietf.org" , Robert Raszuk , "wardd@cisco.com" 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, 31 Oct 2012 22:01:07 -0000 Hi, Eric, Robert, and Ali, Thank you very much for the explanations. They are very helpful. You are right. The label switch path in the text means the VPN label. Indiv= idual labels are used over each segment and swapped at ASBR in option B. Th= is is not related to underlying tunnel mechanism at all. ASBR1 is the next = hop for the PE1, a tunnel is terminated at ASBR. Option A, B, C are about V= PN interworking (or say virtual overlay network). For another scenario is that, if a WAN VPN is used to interconnect DC provi= der underlying networks at different sites, i.e. PE-CE case, DC provider sh= ould be able to build a L3VPN among vPEs at DC sites directly, in which it = seems necessary to have a tunnel between a pair of vPEs. This makes that DC= GW and WAN VPN are not aware of DC L3VPN existence, which creates a true v= irtual environment. vPE host address /32 is required to advertised from one= CE to another CE, will RFC4364 support this? Regards, Lucy =20 > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Wednesday, October 31, 2012 3:45 PM > To: Lucy yong > Cc: Robert Raszuk; nabil.bitar@verizon.com; l3vpn@ietf.org; > rex@cisco.com; wardd@cisco.com > Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 >=20 > I think there's a misunderstanding of the sentence from RFC4364: "This > procedure requires that there be a label switched path leading from a > packet's ingress PE to its egress PE." >=20 > If a VPN packet is traveling the following path: >=20 > PE1--->P1--->ASBR1--->ASBR2--->P2--->PE2 >=20 > where the ASBRs are supporting option B, then there is necessarily an > LSP > consisting of the following sequence of routers: . > What makes this sequence of routers an LSP is that they all operate on > the > "VPN label". (See section 3.15 of RFC 3031 for the precise definition > of > "Label Switched Path". Note that "LSP" is defined relative to the > position > of a particular label in the stack of a particular packet.) PE1 pushes > on > the label, ASBR1 swaps it with a label assigned by ASBR2, ASBR2 swaps > it > with a label assigned by PE2, PE2 pops it. We could call this the "VPN > LSP", because it follows the path of distribution of a VPN-IP route. >=20 > The cited text is intended to distinguish option B from option A; in > option > A, the sequence is not an LSP, because ASBR2 does > not > distribute labels to ASBR1. >=20 > > which requires two SPs pre-provisioning process that may not apply to > > here. >=20 > The LSP exists by virtue of the distribution of the labeled VPN-IP > routes. >=20 > Note that, although is an LSP according to the > definition in RFC 3031, each router in the sequence only has to know > which > router is next in the sequence; the ingress router does not need to > know how > to reach to the egress router. Also, there is no requirement that an > LSP is > used to carry packets from PE1 to ASBR1, or from ASBR2 to PE2. Either > or > both of those "hops" could be via a GRE tunnel, or any other method of > transport. >=20 > It's true that in a typical deployment, there is a "top-level" LSP > and another "top-level" LSP . Neither of > these > is the VPN LSP; rather, each is used to carry packets from one member > of the > VPN LSP to the next member in sequence. But option B is independent of > how > packets get between adjacent members of the VPN LSP. >=20 > > WAN may use MPLS LSP tunnel and DC may use IP based tunnel. >=20 > That is compatible with RFC4364 option B, because the LSP > still exists. >=20 > > This will be an issue when use IP GRE tunnels. >=20 > It's only an issue if you want to have a single GRE tunnel that goes > from > PE1 to PE2. If that is what you want, then you should probably be > using > option C. Option B does not tell the ingress PE who the egress PE is. > (Well, not unless RFC 6513/6514 is also in use ...) >=20 > > Option C request set up two LSP tunnel, one from ingress PE to egress > PE, > > second from ingress PE to ASBR to solve the issue in IGP. >=20 > In option C, the "VPN LSP" would be . If one wants to use > MPLS to > move the packets from PE1 to PE2, one needs a "top-level" LSP like > ; but this is not the "VPN LSP". I think > you > interpreted the text from RFC 4364 as requiring this top-level LSP for > option B, but it is only intended to require the VPN LSP > . >=20 > I'm not sure whether this makes things any clearer or not ... From rraszuk@gmail.com Wed Oct 31 15:07: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 D0B9821F883D for ; Wed, 31 Oct 2012 15:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 YYnBhZXG4MxB for ; Wed, 31 Oct 2012 15:07:14 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 19BCF21F883C for ; Wed, 31 Oct 2012 15:07:14 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id x24so1639018iak.31 for ; Wed, 31 Oct 2012 15:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QCb8pO7d6VjYIoixjybx4quk26yuQh6H1MhVzBMrCZU=; b=iV1Dgyxy/2Prl9K6lAI2Rgxfhafc0Otqe2WfwrxUbW9FepthjY/RwWVyht8deUrW6Y ie44Jk4aVvn5FhSDr6texalv3aq/K2EsIauYukxxFnpFbTOKV0RbcEXtx2Uui9lE2+Hy XUFAMLSAbh8p3mJQCgAI5zsQbF6P+7762lMaHI/LRgRXlB2IVj/PJUlBkKpEvHIIWXpa 8hT8P0C2Bx/+b+aAxc8nL3BnBKv4S5UOVVxspdL+9EnY5GeW637Jv2YHDxVzlmqE6dFU 5RR6r/NMKXG9z63NOFke+B4L2t0segx5KTzrnXwpMrpx4dKaGac3otXLI1C2Q1LmmKXA 3liA== MIME-Version: 1.0 Received: by 10.42.68.203 with SMTP id y11mr33256517ici.26.1351721233710; Wed, 31 Oct 2012 15:07:13 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Wed, 31 Oct 2012 15:07:13 -0700 (PDT) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482B705@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D4482B57E@dfweml505-mbx> <21624.1351716281@erosen-linux> <2691CE0099834E4A9C5044EEC662BB9D4482B705@dfweml505-mbx> Date: Wed, 31 Oct 2012 23:07:13 +0100 X-Google-Sender-Auth: iUWk1OtPZgvVcpoyytJIeRJri5s Message-ID: Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 From: Robert Raszuk To: Lucy yong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rex@cisco.com" , "nabil.bitar@verizon.com" , "erosen@cisco.com" , "l3vpn@ietf.org" , "wardd@cisco.com" 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, 31 Oct 2012 22:07:14 -0000 Hi Lucy, To your below question the answer is yes. This is a flavor of CSC which standard 4364 supports just fine. Best regards, R. > For another scenario is that, if a WAN VPN is used to interconnect DC pro= vider underlying networks at different sites, i.e. PE-CE case, DC provider = should be able to build a L3VPN among vPEs at DC sites directly, in which i= t seems necessary to have a tunnel between a pair of vPEs. This makes that = DC GW and WAN VPN are not aware of DC L3VPN existence, which creates a true= virtual environment. vPE host address /32 is required to advertised from o= ne CE to another CE, will RFC4364 support this? On Wed, Oct 31, 2012 at 10:59 PM, Lucy yong wrote: > Hi, Eric, Robert, and Ali, > > Thank you very much for the explanations. They are very helpful. > > You are right. The label switch path in the text means the VPN label. Ind= ividual labels are used over each segment and swapped at ASBR in option B. = This is not related to underlying tunnel mechanism at all. ASBR1 is the nex= t hop for the PE1, a tunnel is terminated at ASBR. Option A, B, C are about= VPN interworking (or say virtual overlay network). > > For another scenario is that, if a WAN VPN is used to interconnect DC pro= vider underlying networks at different sites, i.e. PE-CE case, DC provider = should be able to build a L3VPN among vPEs at DC sites directly, in which i= t seems necessary to have a tunnel between a pair of vPEs. This makes that = DC GW and WAN VPN are not aware of DC L3VPN existence, which creates a true= virtual environment. vPE host address /32 is required to advertised from o= ne CE to another CE, will RFC4364 support this? > > Regards, > Lucy > > > > > > > >> -----Original Message----- >> From: Eric Rosen [mailto:erosen@cisco.com] >> Sent: Wednesday, October 31, 2012 3:45 PM >> To: Lucy yong >> Cc: Robert Raszuk; nabil.bitar@verizon.com; l3vpn@ietf.org; >> rex@cisco.com; wardd@cisco.com >> Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 >> >> I think there's a misunderstanding of the sentence from RFC4364: "This >> procedure requires that there be a label switched path leading from a >> packet's ingress PE to its egress PE." >> >> If a VPN packet is traveling the following path: >> >> PE1--->P1--->ASBR1--->ASBR2--->P2--->PE2 >> >> where the ASBRs are supporting option B, then there is necessarily an >> LSP >> consisting of the following sequence of routers: . >> What makes this sequence of routers an LSP is that they all operate on >> the >> "VPN label". (See section 3.15 of RFC 3031 for the precise definition >> of >> "Label Switched Path". Note that "LSP" is defined relative to the >> position >> of a particular label in the stack of a particular packet.) PE1 pushes >> on >> the label, ASBR1 swaps it with a label assigned by ASBR2, ASBR2 swaps >> it >> with a label assigned by PE2, PE2 pops it. We could call this the "VPN >> LSP", because it follows the path of distribution of a VPN-IP route. >> >> The cited text is intended to distinguish option B from option A; in >> option >> A, the sequence is not an LSP, because ASBR2 does >> not >> distribute labels to ASBR1. >> >> > which requires two SPs pre-provisioning process that may not apply to >> > here. >> >> The LSP exists by virtue of the distribution of the labeled VPN-IP >> routes. >> >> Note that, although is an LSP according to the >> definition in RFC 3031, each router in the sequence only has to know >> which >> router is next in the sequence; the ingress router does not need to >> know how >> to reach to the egress router. Also, there is no requirement that an >> LSP is >> used to carry packets from PE1 to ASBR1, or from ASBR2 to PE2. Either >> or >> both of those "hops" could be via a GRE tunnel, or any other method of >> transport. >> >> It's true that in a typical deployment, there is a "top-level" LSP >> and another "top-level" LSP . Neither of >> these >> is the VPN LSP; rather, each is used to carry packets from one member >> of the >> VPN LSP to the next member in sequence. But option B is independent of >> how >> packets get between adjacent members of the VPN LSP. >> >> > WAN may use MPLS LSP tunnel and DC may use IP based tunnel. >> >> That is compatible with RFC4364 option B, because the LSP >> still exists. >> >> > This will be an issue when use IP GRE tunnels. >> >> It's only an issue if you want to have a single GRE tunnel that goes >> from >> PE1 to PE2. If that is what you want, then you should probably be >> using >> option C. Option B does not tell the ingress PE who the egress PE is. >> (Well, not unless RFC 6513/6514 is also in use ...) >> >> > Option C request set up two LSP tunnel, one from ingress PE to egress >> PE, >> > second from ingress PE to ASBR to solve the issue in IGP. >> >> In option C, the "VPN LSP" would be . If one wants to use >> MPLS to >> move the packets from PE1 to PE2, one needs a "top-level" LSP like >> ; but this is not the "VPN LSP". I think >> you >> interpreted the text from RFC 4364 as requiring this top-level LSP for >> option B, but it is only intended to require the VPN LSP >> . >> >> I'm not sure whether this makes things any clearer or not ... From lucy.yong@huawei.com Wed Oct 31 15:18: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 A231721F85E1 for ; Wed, 31 Oct 2012 15:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 irTZMYF+rTyz for ; Wed, 31 Oct 2012 15:18:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 24CA721F847F for ; Wed, 31 Oct 2012 15:18:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALC55016; Wed, 31 Oct 2012 22:18:00 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 31 Oct 2012 22:17:31 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 31 Oct 2012 22:17:59 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Wed, 31 Oct 2012 15:17:58 -0700 From: Lucy yong To: Robert Raszuk Subject: RE: comment on draft-fang-l3vpn-virtual-pe-framework-01 Thread-Topic: comment on draft-fang-l3vpn-virtual-pe-framework-01 Thread-Index: Ac23hctPiQHvGKzWS4ms8LiAALc6opfT5u2A6Czq/oCAAHKj8A== Date: Wed, 31 Oct 2012 22:17:57 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482B744@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D4482B57E@dfweml505-mbx> <21624.1351716281@erosen-linux> <2691CE0099834E4A9C5044EEC662BB9D4482B705@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rex@cisco.com" , "nabil.bitar@verizon.com" , "erosen@cisco.com" , "l3vpn@ietf.org" , "wardd@cisco.com" 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, 31 Oct 2012 22:18:03 -0000 Another silly question, What does CSC stand for? Lucy > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > Raszuk > Sent: Wednesday, October 31, 2012 5:07 PM > To: Lucy yong > Cc: erosen@cisco.com; nabil.bitar@verizon.com; l3vpn@ietf.org; > rex@cisco.com; wardd@cisco.com > Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 >=20 > Hi Lucy, >=20 > To your below question the answer is yes. This is a flavor of CSC > which standard 4364 supports just fine. >=20 > Best regards, > R. >=20 > > For another scenario is that, if a WAN VPN is used to interconnect DC > provider underlying networks at different sites, i.e. PE-CE case, DC > provider should be able to build a L3VPN among vPEs at DC sites > directly, in which it seems necessary to have a tunnel between a pair > of vPEs. This makes that DC GW and WAN VPN are not aware of DC L3VPN > existence, which creates a true virtual environment. vPE host address > /32 is required to advertised from one CE to another CE, will RFC4364 > support this? >=20 >=20 >=20 >=20 >=20 > On Wed, Oct 31, 2012 at 10:59 PM, Lucy yong > wrote: > > Hi, Eric, Robert, and Ali, > > > > Thank you very much for the explanations. They are very helpful. > > > > You are right. The label switch path in the text means the VPN label. > Individual labels are used over each segment and swapped at ASBR in > option B. This is not related to underlying tunnel mechanism at all. > ASBR1 is the next hop for the PE1, a tunnel is terminated at ASBR. > Option A, B, C are about VPN interworking (or say virtual overlay > network). > > > > For another scenario is that, if a WAN VPN is used to interconnect DC > provider underlying networks at different sites, i.e. PE-CE case, DC > provider should be able to build a L3VPN among vPEs at DC sites > directly, in which it seems necessary to have a tunnel between a pair > of vPEs. This makes that DC GW and WAN VPN are not aware of DC L3VPN > existence, which creates a true virtual environment. vPE host address > /32 is required to advertised from one CE to another CE, will RFC4364 > support this? > > > > Regards, > > Lucy > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: Eric Rosen [mailto:erosen@cisco.com] > >> Sent: Wednesday, October 31, 2012 3:45 PM > >> To: Lucy yong > >> Cc: Robert Raszuk; nabil.bitar@verizon.com; l3vpn@ietf.org; > >> rex@cisco.com; wardd@cisco.com > >> Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 > >> > >> I think there's a misunderstanding of the sentence from RFC4364: > "This > >> procedure requires that there be a label switched path leading from > a > >> packet's ingress PE to its egress PE." > >> > >> If a VPN packet is traveling the following path: > >> > >> PE1--->P1--->ASBR1--->ASBR2--->P2--->PE2 > >> > >> where the ASBRs are supporting option B, then there is necessarily > an > >> LSP > >> consisting of the following sequence of routers: > . > >> What makes this sequence of routers an LSP is that they all operate > on > >> the > >> "VPN label". (See section 3.15 of RFC 3031 for the precise > definition > >> of > >> "Label Switched Path". Note that "LSP" is defined relative to the > >> position > >> of a particular label in the stack of a particular packet.) PE1 > pushes > >> on > >> the label, ASBR1 swaps it with a label assigned by ASBR2, ASBR2 > swaps > >> it > >> with a label assigned by PE2, PE2 pops it. We could call this the > "VPN > >> LSP", because it follows the path of distribution of a VPN-IP route. > >> > >> The cited text is intended to distinguish option B from option A; in > >> option > >> A, the sequence is not an LSP, because ASBR2 > does > >> not > >> distribute labels to ASBR1. > >> > >> > which requires two SPs pre-provisioning process that may not apply > to > >> > here. > >> > >> The LSP exists by virtue of the distribution of the labeled VPN-IP > >> routes. > >> > >> Note that, although is an LSP according to > the > >> definition in RFC 3031, each router in the sequence only has to know > >> which > >> router is next in the sequence; the ingress router does not need to > >> know how > >> to reach to the egress router. Also, there is no requirement that > an > >> LSP is > >> used to carry packets from PE1 to ASBR1, or from ASBR2 to PE2. > Either > >> or > >> both of those "hops" could be via a GRE tunnel, or any other method > of > >> transport. > >> > >> It's true that in a typical deployment, there is a "top-level" LSP > >> and another "top-level" LSP . Neither > of > >> these > >> is the VPN LSP; rather, each is used to carry packets from one > member > >> of the > >> VPN LSP to the next member in sequence. But option B is independent > of > >> how > >> packets get between adjacent members of the VPN LSP. > >> > >> > WAN may use MPLS LSP tunnel and DC may use IP based tunnel. > >> > >> That is compatible with RFC4364 option B, because the LSP > >> still exists. > >> > >> > This will be an issue when use IP GRE tunnels. > >> > >> It's only an issue if you want to have a single GRE tunnel that goes > >> from > >> PE1 to PE2. If that is what you want, then you should probably be > >> using > >> option C. Option B does not tell the ingress PE who the egress PE > is. > >> (Well, not unless RFC 6513/6514 is also in use ...) > >> > >> > Option C request set up two LSP tunnel, one from ingress PE to > egress > >> PE, > >> > second from ingress PE to ASBR to solve the issue in IGP. > >> > >> In option C, the "VPN LSP" would be . If one wants to use > >> MPLS to > >> move the packets from PE1 to PE2, one needs a "top-level" LSP like > >> ; but this is not the "VPN LSP". I think > >> you > >> interpreted the text from RFC 4364 as requiring this top-level LSP > for > >> option B, but it is only intended to require the VPN LSP > >> . > >> > >> I'm not sure whether this makes things any clearer or not ... From rraszuk@gmail.com Wed Oct 31 15:19: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 285C121F881F for ; Wed, 31 Oct 2012 15:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 fYHs+xH8eAkS for ; Wed, 31 Oct 2012 15:19:46 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43A9721F8771 for ; Wed, 31 Oct 2012 15:19:46 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so3207299iec.31 for ; Wed, 31 Oct 2012 15:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UWzd7plplEh6ZjMzBzO7UZu7hYWVV2K+m7qnbCcl9q8=; b=O8uKeBXyicqOo4p0R27KNgPhKGbQetc8YWWBKSWPPhlwM6DyYALiid1cxf8IT7xFWy ys9aNuYoA2+ErToRbmqN96RZREhoZ7Hzu6eFLPOPq5xo0kTLHGvW4jMnw4Eqv9boDpn8 o2LnIXHXh4+0Zz8MlR77u15Q6Sql0lu8qf5DsWWZttcwdLPwu3fPaSVXnl3FCwbvwK4g jeHUWzA5yaSxTgAqlr0Z/LAHuaGxRavkxWihgH3rmrKlzg4pQbCVO8mi1BYfG5ZHNqsu nzM/f6hJBQjT35qjdQGREqIi+o/WwaRR+5eJOxzytJLysxxzJX2VB6XAwpolL6W6wnSS 9Bkw== MIME-Version: 1.0 Received: by 10.50.217.169 with SMTP id oz9mr3203330igc.15.1351721985886; Wed, 31 Oct 2012 15:19:45 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Wed, 31 Oct 2012 15:19:45 -0700 (PDT) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482B744@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D4482B57E@dfweml505-mbx> <21624.1351716281@erosen-linux> <2691CE0099834E4A9C5044EEC662BB9D4482B705@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D4482B744@dfweml505-mbx> Date: Wed, 31 Oct 2012 23:19:45 +0100 X-Google-Sender-Auth: WacEf-zardgjWehLI5f70a20zLI Message-ID: Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 From: Robert Raszuk To: Lucy yong Content-Type: text/plain; charset=ISO-8859-1 Cc: "rex@cisco.com" , "nabil.bitar@verizon.com" , "erosen@cisco.com" , "l3vpn@ietf.org" , "wardd@cisco.com" 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, 31 Oct 2012 22:19:47 -0000 Section 9. Carriers' Carriers Best, R. On Wed, Oct 31, 2012 at 11:17 PM, Lucy yong wrote: > Another silly question, What does CSC stand for? > Lucy > >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >> Raszuk >> Sent: Wednesday, October 31, 2012 5:07 PM >> To: Lucy yong >> Cc: erosen@cisco.com; nabil.bitar@verizon.com; l3vpn@ietf.org; >> rex@cisco.com; wardd@cisco.com >> Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 >> >> Hi Lucy, >> >> To your below question the answer is yes. This is a flavor of CSC >> which standard 4364 supports just fine. >> >> Best regards, >> R. >> >> > For another scenario is that, if a WAN VPN is used to interconnect DC >> provider underlying networks at different sites, i.e. PE-CE case, DC >> provider should be able to build a L3VPN among vPEs at DC sites >> directly, in which it seems necessary to have a tunnel between a pair >> of vPEs. This makes that DC GW and WAN VPN are not aware of DC L3VPN >> existence, which creates a true virtual environment. vPE host address >> /32 is required to advertised from one CE to another CE, will RFC4364 >> support this? >> >> >> >> >> >> On Wed, Oct 31, 2012 at 10:59 PM, Lucy yong >> wrote: >> > Hi, Eric, Robert, and Ali, >> > >> > Thank you very much for the explanations. They are very helpful. >> > >> > You are right. The label switch path in the text means the VPN label. >> Individual labels are used over each segment and swapped at ASBR in >> option B. This is not related to underlying tunnel mechanism at all. >> ASBR1 is the next hop for the PE1, a tunnel is terminated at ASBR. >> Option A, B, C are about VPN interworking (or say virtual overlay >> network). >> > >> > For another scenario is that, if a WAN VPN is used to interconnect DC >> provider underlying networks at different sites, i.e. PE-CE case, DC >> provider should be able to build a L3VPN among vPEs at DC sites >> directly, in which it seems necessary to have a tunnel between a pair >> of vPEs. This makes that DC GW and WAN VPN are not aware of DC L3VPN >> existence, which creates a true virtual environment. vPE host address >> /32 is required to advertised from one CE to another CE, will RFC4364 >> support this? >> > >> > Regards, >> > Lucy >> > >> > >> > >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: Eric Rosen [mailto:erosen@cisco.com] >> >> Sent: Wednesday, October 31, 2012 3:45 PM >> >> To: Lucy yong >> >> Cc: Robert Raszuk; nabil.bitar@verizon.com; l3vpn@ietf.org; >> >> rex@cisco.com; wardd@cisco.com >> >> Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 >> >> >> >> I think there's a misunderstanding of the sentence from RFC4364: >> "This >> >> procedure requires that there be a label switched path leading from >> a >> >> packet's ingress PE to its egress PE." >> >> >> >> If a VPN packet is traveling the following path: >> >> >> >> PE1--->P1--->ASBR1--->ASBR2--->P2--->PE2 >> >> >> >> where the ASBRs are supporting option B, then there is necessarily >> an >> >> LSP >> >> consisting of the following sequence of routers: >> . >> >> What makes this sequence of routers an LSP is that they all operate >> on >> >> the >> >> "VPN label". (See section 3.15 of RFC 3031 for the precise >> definition >> >> of >> >> "Label Switched Path". Note that "LSP" is defined relative to the >> >> position >> >> of a particular label in the stack of a particular packet.) PE1 >> pushes >> >> on >> >> the label, ASBR1 swaps it with a label assigned by ASBR2, ASBR2 >> swaps >> >> it >> >> with a label assigned by PE2, PE2 pops it. We could call this the >> "VPN >> >> LSP", because it follows the path of distribution of a VPN-IP route. >> >> >> >> The cited text is intended to distinguish option B from option A; in >> >> option >> >> A, the sequence is not an LSP, because ASBR2 >> does >> >> not >> >> distribute labels to ASBR1. >> >> >> >> > which requires two SPs pre-provisioning process that may not apply >> to >> >> > here. >> >> >> >> The LSP exists by virtue of the distribution of the labeled VPN-IP >> >> routes. >> >> >> >> Note that, although is an LSP according to >> the >> >> definition in RFC 3031, each router in the sequence only has to know >> >> which >> >> router is next in the sequence; the ingress router does not need to >> >> know how >> >> to reach to the egress router. Also, there is no requirement that >> an >> >> LSP is >> >> used to carry packets from PE1 to ASBR1, or from ASBR2 to PE2. >> Either >> >> or >> >> both of those "hops" could be via a GRE tunnel, or any other method >> of >> >> transport. >> >> >> >> It's true that in a typical deployment, there is a "top-level" LSP >> >> and another "top-level" LSP . Neither >> of >> >> these >> >> is the VPN LSP; rather, each is used to carry packets from one >> member >> >> of the >> >> VPN LSP to the next member in sequence. But option B is independent >> of >> >> how >> >> packets get between adjacent members of the VPN LSP. >> >> >> >> > WAN may use MPLS LSP tunnel and DC may use IP based tunnel. >> >> >> >> That is compatible with RFC4364 option B, because the LSP >> >> still exists. >> >> >> >> > This will be an issue when use IP GRE tunnels. >> >> >> >> It's only an issue if you want to have a single GRE tunnel that goes >> >> from >> >> PE1 to PE2. If that is what you want, then you should probably be >> >> using >> >> option C. Option B does not tell the ingress PE who the egress PE >> is. >> >> (Well, not unless RFC 6513/6514 is also in use ...) >> >> >> >> > Option C request set up two LSP tunnel, one from ingress PE to >> egress >> >> PE, >> >> > second from ingress PE to ASBR to solve the issue in IGP. >> >> >> >> In option C, the "VPN LSP" would be . If one wants to use >> >> MPLS to >> >> move the packets from PE1 to PE2, one needs a "top-level" LSP like >> >> ; but this is not the "VPN LSP". I think >> >> you >> >> interpreted the text from RFC 4364 as requiring this top-level LSP >> for >> >> option B, but it is only intended to require the VPN LSP >> >> . >> >> >> >> I'm not sure whether this makes things any clearer or not ... From lufang@cisco.com Wed Oct 31 19:36: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 82C4B21F8554 for ; Wed, 31 Oct 2012 19:36:09 -0700 (PDT) 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 pJi34rb1PtlB for ; Wed, 31 Oct 2012 19:36:08 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D270B21F8545 for ; Wed, 31 Oct 2012 19:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7233; q=dns/txt; s=iport; t=1351737366; x=1352946966; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=RnEPXi/1/LaHrZLG50NlxsjbtfTkDSUm5OUOYYRgs0c=; b=UQtlgkiEnobiXUfWmN0ST7QjwXtoi2Za/iS5svPQWGBbnzD/tqRFxQY/ jNvEia5jaz8s3fzEBAMOJHkVeTV3lHhJIh+93brtEeyuPACqdUV7WbK5i 8WCZJEY1i4JW40pakOTwLDxu6JmouE5HA9VW7VjWw079wP4e+YLmXKT8Y w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAM6+kVCtJXG8/2dsb2JhbABEw1+BCIIeAQEBAwESARQTLRIMBgEIEQQBAQEKFAkoERQJCAIEAQ0FCBqHUgMJBpsclksNiVSLEWcbhT9hA5QhjQaDJoFrghdYghk X-IronPort-AV: E=Sophos;i="4.80,688,1344211200"; d="scan'208";a="134555170" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 01 Nov 2012 02:13:52 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA12Dqil024564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 02:13:52 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.215]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 21:13:51 -0500 From: "Luyuan Fang (lufang)" To: Robert Raszuk , Lucy yong Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 Thread-Topic: comment on draft-fang-l3vpn-virtual-pe-framework-01 Thread-Index: AQHNt6iMiQHvGKzWS4ms8LiAALc6opfUSoYAgAACI4CAAAMAgIAAAIGA///+V4A= Date: Thu, 1 Nov 2012 02:13:50 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD930F5443DF@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.82.209.112] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--58.202300-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-ID: <16068BE3CC50104E80472FFA6530B653@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rex Fernando \(rex\)" , "nabil.bitar@verizon.com" , "Eric Rosen \(erosen\)" , "l3vpn@ietf.org" , "David Ward \(wardd\)" 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, 01 Nov 2012 02:36:09 -0000 Hi Lucy, Robert, Eric, Ali, and all, Thanks for your comments. We got hit by Hurricane Sandy very hard in NJ. We've been out of power since Monday, with many roads blocked by downed power lines and trees, and extensive flooding. We have no cell phones and no landlines working. Lucy, I'll get to your comments as soon as the situation is under control. Thanks for your understanding. Luyuan On 10/31/12 6:19 PM, "Robert Raszuk" wrote: >Section 9. Carriers' Carriers > >Best, >R. > >On Wed, Oct 31, 2012 at 11:17 PM, Lucy yong wrote: >> Another silly question, What does CSC stand for? >> Lucy >> >>> -----Original Message----- >>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >>> Raszuk >>> Sent: Wednesday, October 31, 2012 5:07 PM >>> To: Lucy yong >>> Cc: erosen@cisco.com; nabil.bitar@verizon.com; l3vpn@ietf.org; >>> rex@cisco.com; wardd@cisco.com >>> Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 >>> >>> Hi Lucy, >>> >>> To your below question the answer is yes. This is a flavor of CSC >>> which standard 4364 supports just fine. >>> >>> Best regards, >>> R. >>> >>> > For another scenario is that, if a WAN VPN is used to interconnect DC >>> provider underlying networks at different sites, i.e. PE-CE case, DC >>> provider should be able to build a L3VPN among vPEs at DC sites >>> directly, in which it seems necessary to have a tunnel between a pair >>> of vPEs. This makes that DC GW and WAN VPN are not aware of DC L3VPN >>> existence, which creates a true virtual environment. vPE host address >>> /32 is required to advertised from one CE to another CE, will RFC4364 >>> support this? >>> >>> >>> >>> >>> >>> On Wed, Oct 31, 2012 at 10:59 PM, Lucy yong >>> wrote: >>> > Hi, Eric, Robert, and Ali, >>> > >>> > Thank you very much for the explanations. They are very helpful. >>> > >>> > You are right. The label switch path in the text means the VPN label. >>> Individual labels are used over each segment and swapped at ASBR in >>> option B. This is not related to underlying tunnel mechanism at all. >>> ASBR1 is the next hop for the PE1, a tunnel is terminated at ASBR. >>> Option A, B, C are about VPN interworking (or say virtual overlay >>> network). >>> > >>> > For another scenario is that, if a WAN VPN is used to interconnect DC >>> provider underlying networks at different sites, i.e. PE-CE case, DC >>> provider should be able to build a L3VPN among vPEs at DC sites >>> directly, in which it seems necessary to have a tunnel between a pair >>> of vPEs. This makes that DC GW and WAN VPN are not aware of DC L3VPN >>> existence, which creates a true virtual environment. vPE host address >>> /32 is required to advertised from one CE to another CE, will RFC4364 >>> support this? >>> > >>> > Regards, >>> > Lucy >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> >> -----Original Message----- >>> >> From: Eric Rosen [mailto:erosen@cisco.com] >>> >> Sent: Wednesday, October 31, 2012 3:45 PM >>> >> To: Lucy yong >>> >> Cc: Robert Raszuk; nabil.bitar@verizon.com; l3vpn@ietf.org; >>> >> rex@cisco.com; wardd@cisco.com >>> >> Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 >>> >> >>> >> I think there's a misunderstanding of the sentence from RFC4364: >>> "This >>> >> procedure requires that there be a label switched path leading from >>> a >>> >> packet's ingress PE to its egress PE." >>> >> >>> >> If a VPN packet is traveling the following path: >>> >> >>> >> PE1--->P1--->ASBR1--->ASBR2--->P2--->PE2 >>> >> >>> >> where the ASBRs are supporting option B, then there is necessarily >>> an >>> >> LSP >>> >> consisting of the following sequence of routers: >>> . >>> >> What makes this sequence of routers an LSP is that they all operate >>> on >>> >> the >>> >> "VPN label". (See section 3.15 of RFC 3031 for the precise >>> definition >>> >> of >>> >> "Label Switched Path". Note that "LSP" is defined relative to the >>> >> position >>> >> of a particular label in the stack of a particular packet.) PE1 >>> pushes >>> >> on >>> >> the label, ASBR1 swaps it with a label assigned by ASBR2, ASBR2 >>> swaps >>> >> it >>> >> with a label assigned by PE2, PE2 pops it. We could call this the >>> "VPN >>> >> LSP", because it follows the path of distribution of a VPN-IP route. >>> >> >>> >> The cited text is intended to distinguish option B from option A; in >>> >> option >>> >> A, the sequence is not an LSP, because ASBR2 >>> does >>> >> not >>> >> distribute labels to ASBR1. >>> >> >>> >> > which requires two SPs pre-provisioning process that may not apply >>> to >>> >> > here. >>> >> >>> >> The LSP exists by virtue of the distribution of the labeled VPN-IP >>> >> routes. >>> >> >>> >> Note that, although is an LSP according to >>> the >>> >> definition in RFC 3031, each router in the sequence only has to know >>> >> which >>> >> router is next in the sequence; the ingress router does not need to >>> >> know how >>> >> to reach to the egress router. Also, there is no requirement that >>> an >>> >> LSP is >>> >> used to carry packets from PE1 to ASBR1, or from ASBR2 to PE2. >>> Either >>> >> or >>> >> both of those "hops" could be via a GRE tunnel, or any other method >>> of >>> >> transport. >>> >> >>> >> It's true that in a typical deployment, there is a "top-level" LSP >>> >> and another "top-level" LSP . Neither >>> of >>> >> these >>> >> is the VPN LSP; rather, each is used to carry packets from one >>> member >>> >> of the >>> >> VPN LSP to the next member in sequence. But option B is independent >>> of >>> >> how >>> >> packets get between adjacent members of the VPN LSP. >>> >> >>> >> > WAN may use MPLS LSP tunnel and DC may use IP based tunnel. >>> >> >>> >> That is compatible with RFC4364 option B, because the LSP >>> >> still exists. >>> >> >>> >> > This will be an issue when use IP GRE tunnels. >>> >> >>> >> It's only an issue if you want to have a single GRE tunnel that goes >>> >> from >>> >> PE1 to PE2. If that is what you want, then you should probably be >>> >> using >>> >> option C. Option B does not tell the ingress PE who the egress PE >>> is. >>> >> (Well, not unless RFC 6513/6514 is also in use ...) >>> >> >>> >> > Option C request set up two LSP tunnel, one from ingress PE to >>> egress >>> >> PE, >>> >> > second from ingress PE to ASBR to solve the issue in IGP. >>> >> >>> >> In option C, the "VPN LSP" would be . If one wants to use >>> >> MPLS to >>> >> move the packets from PE1 to PE2, one needs a "top-level" LSP like >>> >> ; but this is not the "VPN LSP". I think >>> >> you >>> >> interpreted the text from RFC 4364 as requiring this top-level LSP >>> for >>> >> option B, but it is only intended to require the VPN LSP >>> >> . >>> >> >>> >> I'm not sure whether this makes things any clearer or not ... From jeff.tantsura@ericsson.com Wed Oct 31 19:50:49 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 2906A21F8D84 for ; Wed, 31 Oct 2012 19:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[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 hhCNArKMOKNi for ; Wed, 31 Oct 2012 19:50:48 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id DB2F121F8C35 for ; Wed, 31 Oct 2012 19:50:47 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qA12oeQF029274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 21:50:40 -0500 Received: from EUSAAHC005.ericsson.se (147.117.188.87) by eusaamw0706.eamcs.ericsson.se (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 31 Oct 2012 22:50:40 -0400 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 22:50:39 -0400 From: Jeff Tantsura To: "Luyuan Fang (lufang)" Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 Thread-Topic: comment on draft-fang-l3vpn-virtual-pe-framework-01 Thread-Index: AQHNt6iMiQHvGKzWS4ms8LiAALc6opfUOcIAgAACJICAAAL/gIAAAIGAgABBZwD//8c81g== Date: Thu, 1 Nov 2012 02:50:39 +0000 Message-ID: References: , <0DB8F45437AB844CBB5102F807A0AD930F5443DF@xmb-rcd-x03.cisco.com> In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD930F5443DF@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nabil.bitar@verizon.com" , "l3vpn@ietf.org" , Robert Raszuk , "Rex Fernando \(rex\)" , "David Ward \(wardd\)" , "Eric Rosen \(erosen\)" 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, 01 Nov 2012 02:50:49 -0000 Luyuan - good luck! Lucy - CsC stands for Carrier supporting Carrier Regards, Jeff On Oct 31, 2012, at 22:36, "Luyuan Fang (lufang)" wrote: > Hi Lucy, Robert, Eric, Ali, and all, >=20 > Thanks for your comments. >=20 > We got hit by Hurricane Sandy very hard in NJ. We've been out of power > since Monday, with many roads blocked by downed power lines and trees, an= d > extensive flooding. > We have no cell phones and no landlines working. >=20 > Lucy, I'll get to your comments as soon as the situation is under control= . > Thanks for your understanding. >=20 > Luyuan >=20 >=20 > On 10/31/12 6:19 PM, "Robert Raszuk" wrote: >=20 >> Section 9. Carriers' Carriers >>=20 >> Best, >> R. >>=20 >> On Wed, Oct 31, 2012 at 11:17 PM, Lucy yong wrote= : >>> Another silly question, What does CSC stand for? >>> Lucy >>>=20 >>>> -----Original Message----- >>>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >>>> Raszuk >>>> Sent: Wednesday, October 31, 2012 5:07 PM >>>> To: Lucy yong >>>> Cc: erosen@cisco.com; nabil.bitar@verizon.com; l3vpn@ietf.org; >>>> rex@cisco.com; wardd@cisco.com >>>> Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 >>>>=20 >>>> Hi Lucy, >>>>=20 >>>> To your below question the answer is yes. This is a flavor of CSC >>>> which standard 4364 supports just fine. >>>>=20 >>>> Best regards, >>>> R. >>>>=20 >>>>> For another scenario is that, if a WAN VPN is used to interconnect DC >>>> provider underlying networks at different sites, i.e. PE-CE case, DC >>>> provider should be able to build a L3VPN among vPEs at DC sites >>>> directly, in which it seems necessary to have a tunnel between a pair >>>> of vPEs. This makes that DC GW and WAN VPN are not aware of DC L3VPN >>>> existence, which creates a true virtual environment. vPE host address >>>> /32 is required to advertised from one CE to another CE, will RFC4364 >>>> support this? >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Oct 31, 2012 at 10:59 PM, Lucy yong >>>> wrote: >>>>> Hi, Eric, Robert, and Ali, >>>>>=20 >>>>> Thank you very much for the explanations. They are very helpful. >>>>>=20 >>>>> You are right. The label switch path in the text means the VPN label. >>>> Individual labels are used over each segment and swapped at ASBR in >>>> option B. This is not related to underlying tunnel mechanism at all. >>>> ASBR1 is the next hop for the PE1, a tunnel is terminated at ASBR. >>>> Option A, B, C are about VPN interworking (or say virtual overlay >>>> network). >>>>>=20 >>>>> For another scenario is that, if a WAN VPN is used to interconnect DC >>>> provider underlying networks at different sites, i.e. PE-CE case, DC >>>> provider should be able to build a L3VPN among vPEs at DC sites >>>> directly, in which it seems necessary to have a tunnel between a pair >>>> of vPEs. This makes that DC GW and WAN VPN are not aware of DC L3VPN >>>> existence, which creates a true virtual environment. vPE host address >>>> /32 is required to advertised from one CE to another CE, will RFC4364 >>>> support this? >>>>>=20 >>>>> Regards, >>>>> Lucy >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Eric Rosen [mailto:erosen@cisco.com] >>>>>> Sent: Wednesday, October 31, 2012 3:45 PM >>>>>> To: Lucy yong >>>>>> Cc: Robert Raszuk; nabil.bitar@verizon.com; l3vpn@ietf.org; >>>>>> rex@cisco.com; wardd@cisco.com >>>>>> Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01 >>>>>>=20 >>>>>> I think there's a misunderstanding of the sentence from RFC4364: >>>> "This >>>>>> procedure requires that there be a label switched path leading from >>>> a >>>>>> packet's ingress PE to its egress PE." >>>>>>=20 >>>>>> If a VPN packet is traveling the following path: >>>>>>=20 >>>>>> PE1--->P1--->ASBR1--->ASBR2--->P2--->PE2 >>>>>>=20 >>>>>> where the ASBRs are supporting option B, then there is necessarily >>>> an >>>>>> LSP >>>>>> consisting of the following sequence of routers: >>>> . >>>>>> What makes this sequence of routers an LSP is that they all operate >>>> on >>>>>> the >>>>>> "VPN label". (See section 3.15 of RFC 3031 for the precise >>>> definition >>>>>> of >>>>>> "Label Switched Path". Note that "LSP" is defined relative to the >>>>>> position >>>>>> of a particular label in the stack of a particular packet.) PE1 >>>> pushes >>>>>> on >>>>>> the label, ASBR1 swaps it with a label assigned by ASBR2, ASBR2 >>>> swaps >>>>>> it >>>>>> with a label assigned by PE2, PE2 pops it. We could call this the >>>> "VPN >>>>>> LSP", because it follows the path of distribution of a VPN-IP route. >>>>>>=20 >>>>>> The cited text is intended to distinguish option B from option A; in >>>>>> option >>>>>> A, the sequence is not an LSP, because ASBR2 >>>> does >>>>>> not >>>>>> distribute labels to ASBR1. >>>>>>=20 >>>>>>> which requires two SPs pre-provisioning process that may not apply >>>> to >>>>>>> here. >>>>>>=20 >>>>>> The LSP exists by virtue of the distribution of the labeled VPN-IP >>>>>> routes. >>>>>>=20 >>>>>> Note that, although is an LSP according to >>>> the >>>>>> definition in RFC 3031, each router in the sequence only has to know >>>>>> which >>>>>> router is next in the sequence; the ingress router does not need to >>>>>> know how >>>>>> to reach to the egress router. Also, there is no requirement that >>>> an >>>>>> LSP is >>>>>> used to carry packets from PE1 to ASBR1, or from ASBR2 to PE2. >>>> Either >>>>>> or >>>>>> both of those "hops" could be via a GRE tunnel, or any other method >>>> of >>>>>> transport. >>>>>>=20 >>>>>> It's true that in a typical deployment, there is a "top-level" LSP >>>>>> and another "top-level" LSP . Neither >>>> of >>>>>> these >>>>>> is the VPN LSP; rather, each is used to carry packets from one >>>> member >>>>>> of the >>>>>> VPN LSP to the next member in sequence. But option B is independent >>>> of >>>>>> how >>>>>> packets get between adjacent members of the VPN LSP. >>>>>>=20 >>>>>>> WAN may use MPLS LSP tunnel and DC may use IP based tunnel. >>>>>>=20 >>>>>> That is compatible with RFC4364 option B, because the LSP >>>>>> still exists. >>>>>>=20 >>>>>>> This will be an issue when use IP GRE tunnels. >>>>>>=20 >>>>>> It's only an issue if you want to have a single GRE tunnel that goes >>>>>> from >>>>>> PE1 to PE2. If that is what you want, then you should probably be >>>>>> using >>>>>> option C. Option B does not tell the ingress PE who the egress PE >>>> is. >>>>>> (Well, not unless RFC 6513/6514 is also in use ...) >>>>>>=20 >>>>>>> Option C request set up two LSP tunnel, one from ingress PE to >>>> egress >>>>>> PE, >>>>>>> second from ingress PE to ASBR to solve the issue in IGP. >>>>>>=20 >>>>>> In option C, the "VPN LSP" would be . If one wants to use >>>>>> MPLS to >>>>>> move the packets from PE1 to PE2, one needs a "top-level" LSP like >>>>>> ; but this is not the "VPN LSP". I think >>>>>> you >>>>>> interpreted the text from RFC 4364 as requiring this top-level LSP >>>> for >>>>>> option B, but it is only intended to require the VPN LSP >>>>>> . >>>>>>=20 >>>>>> I'm not sure whether this makes things any clearer or not ... >=20