From jeff.tantsura@ericsson.com Sun May 1 22:14:13 2011 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 8FD4EE0691 for ; Sun, 1 May 2011 22:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.619 X-Spam-Level: X-Spam-Status: No, score=-4.619 tagged_above=-999 required=5 tests=[AWL=1.380, 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 2VibCtWBm2A5 for ; Sun, 1 May 2011 22:14:13 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id F21D4E066E for ; Sun, 1 May 2011 22:14:12 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p425E6gs030790; Mon, 2 May 2011 00:14:07 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 2 May 2011 01:14:01 -0400 From: Jeff Tantsura To: Ben Niven-Jenkins , L3VPN WG mailing list Date: Mon, 2 May 2011 01:14:00 -0400 Subject: RE: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document Thread-Topic: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document Thread-Index: AcwHFUbxoycQ4hXsRTK7FaK/2nyLkgBckaMg Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CABF49B32@EUSAACMS0701.eamcs.ericsson.se> References: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> In-Reply-To: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> 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 Cc: "l3vpn-chairs@tools.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, 02 May 2011 05:14:13 -0000 Yes/support (in Maya calendar :)) Regards, Jeff =20 -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of B= en Niven-Jenkins Sent: Saturday, April 30, 2011 02:02 To: L3VPN WG mailing list Cc: l3vpn-chairs@tools.ietf.org Subject: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG docume= nt Colleagues, =20 This e-mail is to start a poll on whether the L3VPN WG should adopt draft-r= osen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document. =20 Please indicate your support or otherwise by responding to this message (wi= th yes/support or no/do not support) or e-mailing the WG chairs privately. If you do not support the adoption of the document it would be useful if yo= u could also state the reason for your objection. =20 Please send your responses by midnight August 15th May PDT. FYI Eric has outlined his view on the need for this document on the mailing= list previously which you can read here: http://www.ietf.org/mail-archive/web/l3vpn/current/msg02901.html Thanks Ben From mn1921@att.com Mon May 2 07:21:19 2011 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 5335BE06A3 for ; Mon, 2 May 2011 07:21:19 -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 hERtbcXOTvBk for ; Mon, 2 May 2011 07:21:18 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id BCE18E0678 for ; Mon, 2 May 2011 07:21:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1304346077!7714675!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 27645 invoked from network); 2 May 2011 14:21:18 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-6.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2011 14:21:18 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p42EKEmF029279; Mon, 2 May 2011 10:20:15 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p42EKBkd029261; Mon, 2 May 2011 10:20:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document Date: Mon, 2 May 2011 10:21:11 -0400 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A2008DA4D9C@misout7msgusr7e.ugd.att.com> In-Reply-To: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document Thread-Index: AcwHFUvOWwyB+m6OR3KmICqipaJfoABvteRQ References: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> From: "NAPIERALA, MARIA H (ATTSI)" To: "Ben Niven-Jenkins" , "L3VPN WG mailing list" Cc: l3vpn-chairs@tools.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, 02 May 2011 14:21:19 -0000 Yes/support Maria > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Ben Niven-Jenkins > Sent: Saturday, April 30, 2011 5:02 AM > To: L3VPN WG mailing list > Cc: l3vpn-chairs@tools.ietf.org > Subject: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG > document >=20 > Colleagues, >=20 > This e-mail is to start a poll on whether the L3VPN WG should adopt > draft-rosen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document. >=20 > Please indicate your support or otherwise by responding to this message > (with yes/support or no/do not support) or e-mailing the WG chairs > privately. >=20 > If you do not support the adoption of the document it would be useful > if you could also state the reason for your objection. >=20 > Please send your responses by midnight August 15th May PDT. >=20 > FYI Eric has outlined his view on the need for this document on the > mailing list previously which you can read here: > http://www.ietf.org/mail-archive/web/l3vpn/current/msg02901.html >=20 > Thanks > Ben From bashandy@cisco.com Mon May 2 07:34:44 2011 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 3586EE0760 for ; Mon, 2 May 2011 07:34:44 -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 yszzvS30xqsA for ; Mon, 2 May 2011 07:34:43 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id A4B24E074C for ; Mon, 2 May 2011 07:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=1556; q=dns/txt; s=iport; t=1304346883; x=1305556483; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=4CIwUxtjBlHZ2CCbfeaxuRT/rwxwQEPr+LVJ9w8CtZw=; b=jz5QW+gt2WZcalEuav/+c8pzIJHUDeWvtOQ2UZS9P/IgpTuR6/w2uZdZ w/R7A5nFp8ky24zq3O46P3nOHJ9F8/1BJVRL2nvFCxTakFZkqhuQqfov1 /1efNVBUrdGhaBy+30cOhpS3af0y67j53E8k+rfDLKV+geznvLizJ794P g=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.64,303,1301875200"; d="asc'?scan'208";a="306537703" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 02 May 2011 14:34:43 +0000 Received: from [10.21.64.80] (sjc-vpn3-80.cisco.com [10.21.64.80]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p42EYe5W019375; Mon, 2 May 2011 14:34:41 GMT Message-ID: <4DBEC0FD.9030604@cisco.com> Date: Mon, 02 May 2011 16:34:37 +0200 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ben Niven-Jenkins Subject: Re: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document References: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> In-Reply-To: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig266204D140A1DFB18D34FA25" Cc: l3vpn-chairs@tools.ietf.org, L3VPN WG mailing list X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bashandy@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 14:34:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig266204D140A1DFB18D34FA25 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, Support Thanks Ahmed On 4/30/2011 11:01 AM, Ben Niven-Jenkins wrote: > Colleagues, > =20 > This e-mail is to start a poll on whether the L3VPN WG should adopt dra= ft-rosen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document. > =20 > Please indicate your support or otherwise by responding to this message= (with yes/support or no/do not support) or e-mailing the WG chairs priva= tely. > > If you do not support the adoption of the document it would be useful i= f you could also state the reason for your objection. > =20 > Please send your responses by midnight August 15th May PDT. > > FYI Eric has outlined his view on the need for this document on the mai= ling list previously which you can read here: > http://www.ietf.org/mail-archive/web/l3vpn/current/msg02901.html > > Thanks > Ben > --------------enig266204D140A1DFB18D34FA25 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFNvsD9+G19kFA5zIYRAttOAJ41GdrdMq19NdvrGn1TbiCiDpidywCcDj0E 3TZKjZcqIwEN3sxWxtqrxqI= =6xGd -----END PGP SIGNATURE----- --------------enig266204D140A1DFB18D34FA25-- From stephane.litkowski@orange-ftgroup.com Mon May 2 08:10:43 2011 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 398BBE06C5; Mon, 2 May 2011 08:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.645 X-Spam-Level: X-Spam-Status: No, score=0.645 tagged_above=-999 required=5 tests=[AWL=2.494, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, 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 RjiM-4esjjtz; Mon, 2 May 2011 08:10:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF0AE06C3; Mon, 2 May 2011 08:10:42 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id BE03D2DC1FD; Mon, 2 May 2011 17:10:40 +0200 (CEST) Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A38A423805E; Mon, 2 May 2011 17:10:40 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 May 2011 17:10:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Date: Mon, 2 May 2011 17:10:39 +0200 Message-ID: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Thread-Index: AcwF4xMNaOSs+Mi2QQqHLdJ4+RW5JAArQrpgAJJk9JA= References: From: To: "DECRAENE Bruno RD-CORE" , X-OriginalArrivalTime: 02 May 2011 15:10:40.0974 (UTC) FILETIME=[19BF76E0:01CC08DB] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.2.132417 Cc: idr@ietf.org, 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, 02 May 2011 15:10:43 -0000 Hi, Still a point regarding interAS case. What about the option d) behavior ? (= draft-kulmala-l3vpn-interas-option-d) As the VPN IPv4 route coming from AS1 is imported in ASBR VRF context as IP= v4 and then advertised as a new VPN IPv4 route (different RT/RD) to AS2, I = suppose that the ATTR_SET should be lost as for option a) even if we still = have an inet-vpn route between ASBRs. Could you confirm ? Regards, Stephane =20 -----Message d'origine----- De : l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] De la part de b= runo.decraene@orange-ftgroup.com Envoy=E9 : vendredi 29 avril 2011 19:14 =C0 : pedro.r.marques@gmail.com Cc : idr@ietf.org; l3vpn@ietf.org Objet : RE: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Pedro, Thanks for the clarification text that you have added on inter AS VPN. New draft (-04) addresses all my comments. Thanks, Regards, Bruno > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] >=20 > Bruno, >=20 > On Thu, Apr 28, 2011 at 5:41 AM, wrote: >=20 > >> In both cases the ATTR_SET attribute will be "poped". The ATTR_SET=20 > >> attribute is only propagated as long as the route is an "inet-vpn" > >> route... once imported into a VRF it disappears. > > > > Yes. With iBGP, the ATTR_SET attribute will be "poped" but only after copying the BGP attributes of > the customer route (e.g. LOCAL_PREF) on the regular iBGP attributes. Then the next ASBR would "push" > them back in a new ATTR_SET attribute. Hence BGP attributes of the customer are propagated end to end. >=20 > But that wouldn't be inter-as option A, would it ? Option A is defined=20 > as using eBGP on a per VRF basis. >=20 > I believe that one needs to consider what is the design of the=20 > "customer" AS... while their may be topologies where you can get away=20 > with the scenario you suggest, i'm now aware of a generic scenario=20 > where this would work correctly. >=20 >=20 > > > > Given that l3vpn-ibgp comes after inter AS, I would assume that inter AS interconnection pre-exist > when the first iBGP PE-CE customer comes. >=20 >=20 > > So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face it. That's fine for me if l3vpn- > ibgp does not work with inter AS option A >=20 > There is no way i'm aware off to achieve VPN network transparency when=20 > the provider interconnect is based on converting VPN routes to IP=20 > route passing it through an eBGP peering and back. >=20 > The motivation to do iBGP is to provide VPN network transparency. In=20 > inter-as cases to achieve transparency iBGP is not the only=20 > requirement. You also need to exchange this customer routes via option=20 > B (or C). >=20 > >, but I still believe this should be indicated in the "deployment considerations" section of the > document. You can also add that to be able to provide iBGP PE-CE, SP should favor inter AS option B > (over A). > > >=20 > Will do. >=20 > Pedro. ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From pedro.r.marques@gmail.com Mon May 2 09:01:44 2011 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 E8E6CE06F3; Mon, 2 May 2011 09:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] 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 39jP5-Tw7nEg; Mon, 2 May 2011 09:01:39 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80B8EE06ED; Mon, 2 May 2011 09:01:38 -0700 (PDT) Received: by iwn39 with SMTP id 39so6111841iwn.31 for ; Mon, 02 May 2011 09:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7PbTaIfdmyaa3q/DO2eWa2PTTx4xWhnZUm84Rm+fg1c=; b=wWoFupF0dvJ9QS8EVeXgRfL9Z2woIQz4iW6WQ8NzctiJ4WOQyERh8Ta/wHvzhm7uuL QRU9ncUCnVaud4kff4YZfGarPw1L9IByWoZ7RJ0Pf+6yNuuKVzaxxR2PTEUlJKqhxqLr VG9xbFf+11q06Stv5K3Kp7i9wyR5OxkFcgsU4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=A0lztBQ9+5gal2lLQ7fATBTgw4kdmju/okh3L1pI+tnQY3pBjRv+JVfz1QqlghfYWU UIvGg3XqPF5vRee+ReqzPfvE+OWjnDFeZij4K2jR9iK1gP4Cul8Iap0EHTkVak4dUGNO HnCLT6+CWmmYgGDp2ih9V4+zn+3Rht66knEm8= MIME-Version: 1.0 Received: by 10.43.48.130 with SMTP id uw2mr10148739icb.312.1304352096931; Mon, 02 May 2011 09:01:36 -0700 (PDT) Received: by 10.42.171.132 with HTTP; Mon, 2 May 2011 09:01:36 -0700 (PDT) In-Reply-To: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> Date: Mon, 2 May 2011 09:01:36 -0700 Message-ID: Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 From: Pedro Marques To: stephane.litkowski@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr@ietf.org, 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, 02 May 2011 16:01:45 -0000 Stephane, My reading of the document that you quote is that routes are advertised between ASBRs as "inet-vpn" routes. That is certainly the case when option B is used with per VRF forwarding, which is the scenario that i've seen deployed. In both scenarios the ATTR_SET attribute is propagated since the "inet" route is of local significance only. regards, Pedro. On Mon, May 2, 2011 at 8:10 AM, wr= ote: > Hi, > > Still a point regarding interAS case. What about the option d) behavior ?= (draft-kulmala-l3vpn-interas-option-d) > As the VPN IPv4 route coming from AS1 is imported in ASBR VRF context as = IPv4 and then advertised as a new VPN IPv4 route (different RT/RD) to AS2, = I suppose that the ATTR_SET should be lost as for option a) even if we stil= l have an inet-vpn route between ASBRs. Could you confirm ? > > Regards, > > Stephane > > > > -----Message d'origine----- > De : l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] De la part de= bruno.decraene@orange-ftgroup.com > Envoy=E9 : vendredi 29 avril 2011 19:14 > =C0 : pedro.r.marques@gmail.com > Cc : idr@ietf.org; l3vpn@ietf.org > Objet : RE: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 > > Pedro, > > Thanks for the clarification text that you have added on inter AS VPN. > New draft (-04) addresses all my comments. > > Thanks, > Regards, > Bruno > > > >> From: Pedro Marques [mailto:pedro.r.marques@gmail.com] >> >> Bruno, >> >> On Thu, Apr 28, 2011 at 5:41 AM, =A0 > wrote: >> >> >> In both cases the ATTR_SET attribute will be "poped". The ATTR_SET >> >> attribute is only propagated as long as the route is an "inet-vpn" >> >> route... once imported into a VRF it disappears. >> > >> > Yes. With iBGP, the ATTR_SET attribute will be "poped" but only > after copying the BGP attributes of >> the customer route (e.g. LOCAL_PREF) on the regular iBGP attributes. > Then the next ASBR would "push" >> them back in a new ATTR_SET attribute. Hence BGP attributes of the > customer are propagated end to end. >> >> But that wouldn't be inter-as option A, would it ? Option A is defined >> as using eBGP on a per VRF basis. >> >> I believe that one needs to consider what is the design of the >> "customer" AS... while their may be topologies where you can get away >> with the scenario you suggest, i'm now aware of a generic scenario >> where this would work correctly. >> >> >> > >> > Given that l3vpn-ibgp comes after inter AS, I would assume that > inter AS interconnection pre-exist >> when the first iBGP PE-CE customer comes. >> >> >> > So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face > it. That's fine for me if l3vpn- >> ibgp does not work with inter AS option A >> >> There is no way i'm aware off to achieve VPN network transparency when >> the provider interconnect is based on converting VPN routes to IP >> route passing it through an eBGP peering and back. >> >> The motivation to do iBGP is to provide VPN network transparency. In >> inter-as cases to achieve transparency iBGP is not the only >> requirement. You also need to exchange this customer routes via option >> B (or C). >> >> >, but I still believe this should be indicated in the "deployment > considerations" section of the >> document. You can also add that to be able to provide iBGP PE-CE, SP > should favor inter AS option B >> (over A). >> > >> >> Will do. >> >> =A0 Pedro. > > *************************************************************************= ******* > IMPORTANT.Les informations contenues dans ce message electronique y compr= is les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) destinataire(s) m= entionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas destine, = veuillez immediatement le signaler =A0a l expediteur et effacer ce message > et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues da= ns ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite notamme= nt s il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de tout = virus. > > IMPORTANT.This e-mail message and any attachments are strictly confidenti= al and may be protected by law. This message is > intended only for the named recipient(s) above. > If you have received this message in error, or are not the named recipien= t(s), please immediately notify the sender and delete this e-mail message. > Any unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall not= be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > *************************************************************************= ******* > > From Internet-Drafts@ietf.org Mon May 2 09:30:02 2011 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 0E8A8E0722; Mon, 2 May 2011 09:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.119 X-Spam-Level: X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 VaD9KStbptZ4; Mon, 2 May 2011 09:30:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B504AE06AD; Mon, 2 May 2011 09:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l3vpn-ibgp-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110502163001.6499.79197.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2011 09:30:01 -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, 02 May 2011 16:30:02 -0000 --NextPart 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 Group of the IETF. Title : Internal BGP as PE-CE protocol Author(s) : P. Marques, et al. Filename : draft-ietf-l3vpn-ibgp-05.txt Pages : 19 Date : 2011-05-02 This document defines protocol extensions and procedures for BGP PE-CE router iteration in BGP/MPLS IP VPN [RFC4364] networks. These have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ibgp-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l3vpn-ibgp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-02091950.I-D@ietf.org> --NextPart-- From stephane.litkowski@orange-ftgroup.com Wed May 4 02:41:22 2011 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 04A65E0688; Wed, 4 May 2011 02:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.491 X-Spam-Level: X-Spam-Status: No, score=0.491 tagged_above=-999 required=5 tests=[AWL=1.340, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, SARE_SUB_RAND_LETTRS4=0.799, 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 3gSlEn91bnB2; Wed, 4 May 2011 02:41:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id D0351E072F; Wed, 4 May 2011 02:41:20 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 157A63741F2; Wed, 4 May 2011 11:41:19 +0200 (CEST) Received: from puexcc31.nanterre.francetelecom.fr (unknown [10.168.74.8]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id E847538403A; Wed, 4 May 2011 11:41:18 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc31.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 May 2011 11:41:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Date: Wed, 4 May 2011 11:41:17 +0200 Message-ID: <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Thread-Index: AcwI4jkFLf7sRdKkT7uq0ODMOmnHugBWsYew References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> From: To: X-OriginalArrivalTime: 04 May 2011 09:41:19.0113 (UTC) FILETIME=[6B964790:01CC0A3F] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.3.100316 Cc: idr@ietf.org, 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, 04 May 2011 09:41:22 -0000 Pedro, It's quite different here from standard option B behavior. >From my understanding, if we consider the following topology for a VPN : PE1 having VRF1 with RD1, RT1 as import/export ASBR1 having VRF2 with RD2, RT1 as import/export ASBR2 having VRF3 with RD3, RT1 as import/export PE2 having VRF4 with RD4, RT1 as import/export ASBR1 and ASBR2 have one interface in GRT with MPeBGP session (we consider = shared interface forwarding case). PE1 advertise CE route with RD1:X/Y RT1 ASBR1 imports it in VRF2, removes RD and RT, compute best path, export VRF = RIB route to MPeBGP by adding RD2 and RT1 (morever there is no constraint t= o use the same RT in each AS ...), the prefix exported is a new VPN route := RD2:X/Y RT1 ASBR2 imports it in VRF3, removes RD and RT, compute best path, export VRF = RIB route to MPIBGP by adding RD3 and RT1, the prefix exported is a new VPN= route : RD3:X/Y RT1 PE2 imports it in VRF4 Considering this, are you sure that ATTR_SET should be kept ? As BGP-LOC RI= B used by ASBRs for exporting routes are inet ones and not inet-vpn. Please= correct me if I'm wrong. Thanks, Stephane =20 -----Message d'origine----- De : Pedro Marques [mailto:pedro.r.marques@gmail.com]=20 Envoy=E9 : lundi 2 mai 2011 18:02 =C0 : LITKOWSKI Stephane DTF/DERX Cc : idr@ietf.org; l3vpn@ietf.org Objet : Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Stephane, My reading of the document that you quote is that routes are advertised bet= ween ASBRs as "inet-vpn" routes. That is certainly the case when option B i= s used with per VRF forwarding, which is the scenario that i've seen deploy= ed. In both scenarios the ATTR_SET attribute is propagated since the "inet"= route is of local significance only. regards, Pedro. On Mon, May 2, 2011 at 8:10 AM, wr= ote: > Hi, > > Still a point regarding interAS case. What about the option d)=20 > behavior ? (draft-kulmala-l3vpn-interas-option-d) > As the VPN IPv4 route coming from AS1 is imported in ASBR VRF context as = IPv4 and then advertised as a new VPN IPv4 route (different RT/RD) to AS2, = I suppose that the ATTR_SET should be lost as for option a) even if we stil= l have an inet-vpn route between ASBRs. Could you confirm ? > > Regards, > > Stephane > > > > -----Message d'origine----- > De : l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] De la part=20 > de bruno.decraene@orange-ftgroup.com Envoy=E9 : vendredi 29 avril 2011=20 > 19:14 =C0 : pedro.r.marques@gmail.com Cc : idr@ietf.org; l3vpn@ietf.org= =20 > Objet : RE: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 > > Pedro, > > Thanks for the clarification text that you have added on inter AS VPN. > New draft (-04) addresses all my comments. > > Thanks, > Regards, > Bruno > > > >> From: Pedro Marques [mailto:pedro.r.marques@gmail.com] >> >> Bruno, >> >> On Thu, Apr 28, 2011 at 5:41 AM, =A0 > wrote: >> >> >> In both cases the ATTR_SET attribute will be "poped". The ATTR_SET=20 >> >> attribute is only propagated as long as the route is an "inet-vpn" >> >> route... once imported into a VRF it disappears. >> > >> > Yes. With iBGP, the ATTR_SET attribute will be "poped" but only > after copying the BGP attributes of >> the customer route (e.g. LOCAL_PREF) on the regular iBGP attributes. > Then the next ASBR would "push" >> them back in a new ATTR_SET attribute. Hence BGP attributes of the > customer are propagated end to end. >> >> But that wouldn't be inter-as option A, would it ? Option A is=20 >> defined as using eBGP on a per VRF basis. >> >> I believe that one needs to consider what is the design of the=20 >> "customer" AS... while their may be topologies where you can get away=20 >> with the scenario you suggest, i'm now aware of a generic scenario=20 >> where this would work correctly. >> >> >> > >> > Given that l3vpn-ibgp comes after inter AS, I would assume that > inter AS interconnection pre-exist >> when the first iBGP PE-CE customer comes. >> >> >> > So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face > it. That's fine for me if l3vpn- >> ibgp does not work with inter AS option A >> >> There is no way i'm aware off to achieve VPN network transparency=20 >> when the provider interconnect is based on converting VPN routes to=20 >> IP route passing it through an eBGP peering and back. >> >> The motivation to do iBGP is to provide VPN network transparency. In=20 >> inter-as cases to achieve transparency iBGP is not the only=20 >> requirement. You also need to exchange this customer routes via=20 >> option B (or C). >> >> >, but I still believe this should be indicated in the "deployment > considerations" section of the >> document. You can also add that to be able to provide iBGP PE-CE, SP > should favor inter AS option B >> (over A). >> > >> >> Will do. >> >> =A0 Pedro. > > ********************************************************************** > ********** IMPORTANT.Les informations contenues dans ce message=20 > electronique y compris les fichiers attaches sont strictement=20 > confidentielles et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) destinataire(s) m= entionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas=20 > destine, veuillez immediatement le signaler =A0a l expediteur et effacer = ce message et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues da= ns ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite notamme= nt s il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de tout = virus. > > IMPORTANT.This e-mail message and any attachments are strictly=20 > confidential and may be protected by law. This message is intended only f= or the named recipient(s) above. > If you have received this message in error, or are not the named recipien= t(s), please immediately notify the sender and delete this e-mail message. > Any unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall not= be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > ********************************************************************** > ********** > > ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From raszuk@cisco.com Wed May 4 05:18:53 2011 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 113C0E0781; Wed, 4 May 2011 05:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.825 X-Spam-Level: X-Spam-Status: No, score=-9.825 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] 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 MjW1qfUpqa8I; Wed, 4 May 2011 05:18:51 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id DF3A8E0748; Wed, 4 May 2011 05:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=9183; q=dns/txt; s=iport; t=1304511531; x=1305721131; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7Y+2dU3ZPr8pzuaZolPzvZC5VNLDRFtaInKs8yM+Lkk=; b=BWu0NKfkhslOymLLapR5D+rWYyCKFl0WYfY4GrxPmhDWLsUPXeC4ZJRw 8fIacWAjsgNw9IN7K4/5Kd06V8jyqhzLNPHqyF71GHVMRgzlGZe01X1yl ElhIgTocRWvH4Bklc0d04sZM6Voq4jDG3PKFrYFlQP5gAz0BmsZF6wdbE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFlDwU2rRDoJ/2dsb2JhbACmF3eIcp08gngPAZsmhgcEjzWEHIQPhhE X-IronPort-AV: E=Sophos;i="4.64,314,1301875200"; d="scan'208";a="308114982" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 04 May 2011 12:18:51 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p44CImpI013442; Wed, 4 May 2011 12:18:49 GMT Message-ID: <4DC14427.7010809@cisco.com> Date: Wed, 04 May 2011 14:18:47 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: stephane.litkowski@orange-ftgroup.com Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: idr@ietf.org, l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 12:18:53 -0000 Hi Stephane, The behaviour of option d is really dependent on the implementation. Remember that as general rule imported routes should not be exported again. I think draft-kulmala-l3vpn-interas-option-d describes the concept not the actual implementation. So some implementation may just copy RD1:NET RT1 to RD2:NET RT1,RT2 while leaving all other attributes as is including ATTR_SET. In the same time the prefix will be imported into vrf. IMHO draft-ietf-l3vpn-ibgp-02 should not mandate what BGP implementations of various flavors of inter-as VPN peering should result in (options C+, C- or D ...) in regards of keeping or not ATTR_SET. In fact the same applies to option B and C too. It is up to provider to pass this attribute and the draft may only recommend default behaviour. Many thx, R. > Pedro, > > It's quite different here from standard option B behavior. >> From my understanding, if we consider the following topology for a VPN : > PE1 having VRF1 with RD1, RT1 as import/export > ASBR1 having VRF2 with RD2, RT1 as import/export > ASBR2 having VRF3 with RD3, RT1 as import/export > PE2 having VRF4 with RD4, RT1 as import/export > ASBR1 and ASBR2 have one interface in GRT with MPeBGP session (we consider shared interface forwarding case). > > PE1 advertise CE route with RD1:X/Y RT1 > ASBR1 imports it in VRF2, removes RD and RT, compute best path, export VRF RIB route to MPeBGP by adding RD2 and RT1 (morever there is no constraint to use the same RT in each AS ...), the prefix exported is a new VPN route : RD2:X/Y RT1 > ASBR2 imports it in VRF3, removes RD and RT, compute best path, export VRF RIB route to MPIBGP by adding RD3 and RT1, the prefix exported is a new VPN route : RD3:X/Y RT1 > PE2 imports it in VRF4 > > Considering this, are you sure that ATTR_SET should be kept ? As BGP-LOC RIB used by ASBRs for exporting routes are inet ones and not inet-vpn. Please correct me if I'm wrong. > > Thanks, > > Stephane > > > > -----Message d'origine----- > De : Pedro Marques [mailto:pedro.r.marques@gmail.com] > Envoyé : lundi 2 mai 2011 18:02 > À : LITKOWSKI Stephane DTF/DERX > Cc : idr@ietf.org; l3vpn@ietf.org > Objet : Re: [Idr] Joint L3VPN& IDR WG LC for draft-ietf-l3vpn-ibgp-02 > > Stephane, > My reading of the document that you quote is that routes are advertised between ASBRs as "inet-vpn" routes. That is certainly the case when option B is used with per VRF forwarding, which is the scenario that i've seen deployed. In both scenarios the ATTR_SET attribute is propagated since the "inet" route is of local significance only. > > regards, > Pedro. > > On Mon, May 2, 2011 at 8:10 AM, wrote: >> Hi, >> >> Still a point regarding interAS case. What about the option d) >> behavior ? (draft-kulmala-l3vpn-interas-option-d) >> As the VPN IPv4 route coming from AS1 is imported in ASBR VRF context as IPv4 and then advertised as a new VPN IPv4 route (different RT/RD) to AS2, I suppose that the ATTR_SET should be lost as for option a) even if we still have an inet-vpn route between ASBRs. Could you confirm ? >> >> Regards, >> >> Stephane >> >> >> >> -----Message d'origine----- >> De : l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] De la part >> de bruno.decraene@orange-ftgroup.com Envoyé : vendredi 29 avril 2011 >> 19:14 À : pedro.r.marques@gmail.com Cc : idr@ietf.org; l3vpn@ietf.org >> Objet : RE: [Idr] Joint L3VPN& IDR WG LC for draft-ietf-l3vpn-ibgp-02 >> >> Pedro, >> >> Thanks for the clarification text that you have added on inter AS VPN. >> New draft (-04) addresses all my comments. >> >> Thanks, >> Regards, >> Bruno >> >> >> >>> From: Pedro Marques [mailto:pedro.r.marques@gmail.com] >>> >>> Bruno, >>> >>> On Thu, Apr 28, 2011 at 5:41 AM, >> wrote: >>> >>>>> In both cases the ATTR_SET attribute will be "poped". The ATTR_SET >>>>> attribute is only propagated as long as the route is an "inet-vpn" >>>>> route... once imported into a VRF it disappears. >>>> >>>> Yes. With iBGP, the ATTR_SET attribute will be "poped" but only >> after copying the BGP attributes of >>> the customer route (e.g. LOCAL_PREF) on the regular iBGP attributes. >> Then the next ASBR would "push" >>> them back in a new ATTR_SET attribute. Hence BGP attributes of the >> customer are propagated end to end. >>> >>> But that wouldn't be inter-as option A, would it ? Option A is >>> defined as using eBGP on a per VRF basis. >>> >>> I believe that one needs to consider what is the design of the >>> "customer" AS... while their may be topologies where you can get away >>> with the scenario you suggest, i'm now aware of a generic scenario >>> where this would work correctly. >>> >>> >>>> >>>> Given that l3vpn-ibgp comes after inter AS, I would assume that >> inter AS interconnection pre-exist >>> when the first iBGP PE-CE customer comes. >>> >>> >>>> So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face >> it. That's fine for me if l3vpn- >>> ibgp does not work with inter AS option A >>> >>> There is no way i'm aware off to achieve VPN network transparency >>> when the provider interconnect is based on converting VPN routes to >>> IP route passing it through an eBGP peering and back. >>> >>> The motivation to do iBGP is to provide VPN network transparency. In >>> inter-as cases to achieve transparency iBGP is not the only >>> requirement. You also need to exchange this customer routes via >>> option B (or C). >>> >>>> , but I still believe this should be indicated in the "deployment >> considerations" section of the >>> document. You can also add that to be able to provide iBGP PE-CE, SP >> should favor inter AS option B >>> (over A). >>>> >>> >>> Will do. >>> >>> Pedro. >> >> ********************************************************************** >> ********** IMPORTANT.Les informations contenues dans ce message >> electronique y compris les fichiers attaches sont strictement >> confidentielles et peuvent etre protegees par la loi. >> Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. >> Si vous avez recu ce message par erreur ou s il ne vous est pas >> destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. >> Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. >> Tout message electronique est susceptible d alteration. >> A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. >> De meme, il appartient au destinataire de s assurer de l absence de tout virus. >> >> IMPORTANT.This e-mail message and any attachments are strictly >> confidential and may be protected by law. This message is intended only for the named recipient(s) above. >> If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. >> Any unauthorized view, usage or disclosure ofthis message is prohibited. >> Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. >> Additionally the recipient should ensure they are actually virus free. >> ********************************************************************** >> ********** >> >> > > ******************************************************************************** > IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message > et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de tout virus. > > IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is > intended only for the named recipient(s) above. > If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. > Any unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > ******************************************************************************** > > From yakov@juniper.net Wed May 4 06:57:55 2011 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 6BE3EE0753 for ; Wed, 4 May 2011 06:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.224 X-Spam-Level: X-Spam-Status: No, score=-106.224 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 7uhDaS35J1No for ; Wed, 4 May 2011 06:57:54 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id ABEA3E06A4 for ; Wed, 4 May 2011 06:57:49 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTcFbW9RrpsI6ZtAFvIESR2Ij5IdTEzHi@postini.com; Wed, 04 May 2011 06:57:53 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 4 May 2011 06:55:10 -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 p44DtAv66249; Wed, 4 May 2011 06:55:10 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201105041355.p44DtAv66249@magenta.juniper.net> To: Ben Niven-Jenkins Subject: Re: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document In-Reply-To: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> References: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> X-MH-In-Reply-To: Ben Niven-Jenkins message dated "Sat, 30 Apr 2011 10:01:52 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <97068.1304517310.1@juniper.net> Date: Wed, 4 May 2011 06:55:10 -0700 From: Yakov Rekhter Cc: l3vpn-chairs@tools.ietf.org, L3VPN WG mailing list 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, 04 May 2011 13:57:55 -0000 Ben, > Colleagues, > > This e-mail is to start a poll on whether the L3VPN WG should adopt > draft-rosen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document. > > Please indicate your support or otherwise by responding to this message (with > yes/support or no/do not support) or e-mailing the WG chairs privately. > > If you do not support the adoption of the document it would be useful if you > could also state the reason for your objection. > > Please send your responses by midnight August 15th May PDT. > > FYI Eric has outlined his view on the need for this document on the > mailing list previously which you can read here: > http://www.ietf.org/mail-archive/web/l3vpn/current/msg02901.html It is premature to discuss adoption of draft-rosen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document, and here is why. There was already a discussion in L3VPN WG about adopting draft-rosen-l3vpn-mvpn-bidir as an L3VPN WG document. From your e-mail on 10/29/2010: To follow-up on this, from comments on the mailing list and private conversations between the chairs and some participants it would appear that for BiDir P-tunnels at least: - There is interest in the work and some loose agreement among the people that we spoke with that the existing specifications only minimally specify solutions using BiDir P-tunnels - But that there are some quite different views on what the scope of any work on BiDir P-tunnels should be. We already have draft-rosen-l3vpn-mvpn-bidir on the table which has received some debate. It would be useful if one or more of the people that are not happy with the scope of draft-rosen-l3vpn-mvpn-bidir were to make alternative proposal(s) for the scope of work required to address BiDir P-tunnels so we can see where the common ground may be as a start to see if we can progress a specification for BiDir P-tunnels. In response to your request to put an alternative proposal for the scope of the work required to address Bidir P-tunnels, I proposed the following (in my e-mail on 11/22/2010): The scope of work in support of mp2mp P-tunnels should be guided by draft-ietf-l3vpn-mvpn-considerations. From draft-ietf-l3vpn-mvpn-considerations: The use of MP2MP P-tunnels may provide some scaling benefits to the service provider as only a single MP2MP P-tunnel need be deployed per VPN, thus reducing by an order of magnitude the amount of multicast state that needs to be maintained by P routers. Therefore, the scope of work should be limited to the cases where mp2mp P-tunnels do provide scaling benefits in conjunction with the C-multicast routing schemes defined in [MVPN]. Specifically, the scope of work should be limited to (1) use of mp2mp P-tunnels for I-PMSI, and (2) support of C-bidir with the "Partitioned Sets of PEs" method using a partial mesh of mp2mp P-tunnels (as discussed in section 11.2.3 of [MVPN]). From draft-ietf-l3vpn-mvpn-considerations: 5. Avoiding duplicates It is recommended that implementations support the procedures described in section 9.1.1 of [I-D.ietf-l3vpn-2547bis-mcast] "Discarding Packets from Wrong PE", allowing fully avoiding duplicates. Therefore, use of mp2mp P-tunnels for I-PMSI must fully specify procedures to support 9.1.1 of [MVPN]. New work must not change/modify the existing procedures specified in [MVPN] and [BGP-MVPN]. New work must not introduce new mechanisms and/or procedures unless it shows that the mechanisms/procedures specified in [MVPN] and [BGP-MVPN] are insufficient for the purpose of delivering what is within the scope (as described above). There was some subsequent e-mails on the list, but the L3VPN WG never reached a consensus on the scope of this work. Therefore, before discussing adopting of draft-rosen-l3vpn-mvpn-bidir as an L3VPN WG document, the L3VPN WG must first reach a consensus on the scope of the work related to the use of Bidir P-tunnels. Yakov. From michaellundberg.ietf@gmail.com Wed May 4 07:22:18 2011 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 96D73E0719 for ; Wed, 4 May 2011 07:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 sg4bDwoLHVzT for ; Wed, 4 May 2011 07:22:17 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2893DE06A4 for ; Wed, 4 May 2011 07:22:17 -0700 (PDT) Received: by iyn15 with SMTP id 15so1224412iyn.31 for ; Wed, 04 May 2011 07:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=it2Qo+rNBC4Fzik9VVSE65wLbmVxG1Z7c4niSSZ9Xr8=; b=UkQe4560jiEb7a/Kwoz6zXg82rCEqzV0/VP7A8dkoYkqKgpY6b22+wXtozUA6MKS9C B1aSo0Bj8JN2Npv10Fjs+giQ/jJPPYvHB6f03Y0ySf21hhcMOwuKTuRvqyvvJMyVsA3J 6euCzmx4QRDBPB76pg51gYweoQERr81o30Mlo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=seWDoTf9rVmmTtiaRfrBGWt/E88eF7nBBqhQqK5lssBxI44K3U+FqrtoMYGRFaTMJl X9yLhguEakUyKpUAMWUdsO73YRtXcg4h0n8Lz7thf7lH/9CSBwV/Vfp9nImCInI9r1ZD tV05tZPatib6VTvYadtKnLFcmYvwgnR8aVy3Q= MIME-Version: 1.0 Received: by 10.231.41.4 with SMTP id m4mr253852ibe.125.1304518936648; Wed, 04 May 2011 07:22:16 -0700 (PDT) Received: by 10.231.173.205 with HTTP; Wed, 4 May 2011 07:22:16 -0700 (PDT) In-Reply-To: <44EE1E31095AE349AC6C3C0B69FFBF02A68694905C@ENFIMBOX1.ad.datcon.co.uk> References: <44EE1E31095AE349AC6C3C0B69FFBF02A684BC09A4@ENFIMBOX1.ad.datcon.co.uk> <44EE1E31095AE349AC6C3C0B69FFBF02A68512484B@ENFIMBOX1.ad.datcon.co.uk> <44EE1E31095AE349AC6C3C0B69FFBF02A6866D8B74@ENFIMBOX1.ad.datcon.co.uk> <44EE1E31095AE349AC6C3C0B69FFBF02A68694905C@ENFIMBOX1.ad.datcon.co.uk> Date: Wed, 4 May 2011 10:22:16 -0400 Message-ID: Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07 From: Michael Lundberg To: Nick Weeds Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-l3vpn-ospfv3-pece@tools.ietf.org" , "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, 04 May 2011 14:22:18 -0000 Hi Nick, We will make both updates, as well as the update suggested by Acee in the next version. Thanks for both of your comments. Thanks, Michael On Thu, Apr 28, 2011 at 9:15 AM, Nick Weeds wro= te: > Hi Michael, > > Thanks for getting back to me. > > You suggest removing the =A0"No OSPFv3 route to the same prefix exists in= the VRF" and specifying that the route will be redistributed into OSPF bas= ed on local policy. =A0Yes, that would address my concerns. =A0Obviously fo= r the VPN function to work we need routes to be redistributed to OSPF, but = network administrators might want greater control to restrict VPN routing i= n some cases. > > My email of 31st March also raised a separate point about section 4.3.2.3= text on comparing OSPFv3 Domain Ids, and your reply of 8th April said you'= d update the text. =A0If you're batching up the updates then please remembe= r this earlier point. > > =A0 =A0 =A0 =A0Nick. > >> -----Original Message----- >> From: Michael Lundberg [mailto:michaellundberg.ietf@gmail.com] >> Sent: 27 April 2011 17:16 >> To: Nick Weeds >> Cc: Acee Lindem; draft-ietf-l3vpn-ospfv3-pece@tools.ietf.org; >> l3vpn@ietf.org >> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07 >> >> Hi Nick, >> >> Sorry i didn't get to your comment earlier. I agree with the behavior >> you are describing and the problem with saying the OSPF route will >> always be preferred. Given the routes within the VRF are from >> different protocols, I believe the only way to chose the route you >> want is through local policy (e.g., admin distance, route preference). >> >> We can remove the =A0"No OSPFv3 route to the same prefix exists in the >> VRF," and specify that the route will be redistributed into OSPF based >> on local policy. =A0Will this address your concerns? >> >> Acee - we can also update the word "distance" and change it to >> "metric", good comment. >> >> Regards, >> Michael >> >> On Fri, Apr 15, 2011 at 12:19 PM, Nick Weeds >> wrote: >> > Hi Acee, >> > >> > We don't seem to be thinking of the same use case - please see below >> ... >> > >> >> -----Original Message----- >> >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> >> Sent: 15 April 2011 16:51 >> >> To: Nick Weeds >> >> Cc: Michael Lundberg; draft-ietf-l3vpn-ospfv3-pece@ietf.org; >> >> l3vpn@ietf.org >> >> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07 >> >> >> >> Hi Nick, >> >> See inline. >> >> On Apr 11, 2011, at 8:50 AM, Nick Weeds wrote: >> >> >> >> > Hi Michael, >> >> > >> >> > Thanks for your reply - please see further comments below. >> >> > >> >> >> -----Original Message----- >> >> >> From: Michael Lundberg [mailto:michaellundberg.ietf@gmail.com] >> >> >> Sent: 08 April 2011 20:44 >> >> >> To: Nick Weeds >> >> >> Cc: draft-ietf-l3vpn-ospfv3-pece@ietf.org; l3vpn@ietf.org >> >> >> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07 >> >> >> >> >> >> Hi Nick, >> >> >> >> >> >> Thanks for your review and comments. Please see below for my >> >> comments. >> >> >> >> >> >> On Thu, Mar 31, 2011 at 6:47 AM, Nick Weeds >> >> >> >> >> wrote: >> >> >>> Hi, >> >> >>> >> >> >>> The changes in the new draft-ietf-l3vpn-ospfv3-07.txt draft look >> >> >> good, but I >> >> >>> do have a couple of specific comments. >> >> >>> >> >> >>> >> >> >>> >> >> >>> Section 4.3.2 / top of p10 >> >> >>> >> >> >>> The text says that a PE advertises the IPv6 route learned from >> MP- >> >> BGP >> >> >> to >> >> >>> attached CEs via OSPFv3 if various conditions hold, including: >> >> >>> >> >> >>> =A0 =A0 =A0 =A0 "No OSPFv3 route to the same prefix exists in the= VRF." >> >> >>> >> >> >>> I think this is too restrictive. =A0The aim is to allow a choice >> >> >> between >> >> >>> routing over the VPN and routing over an OSPF backdoor link. >> =A0The >> >> >> condition >> >> >>> above would prevent routing over the VPN if there was already a >> >> route >> >> >> over >> >> >>> an OSPF backdoor link. >> >> >>> >> >> >>> I believe the correct condition would be that the OSPFv3 >> decision >> >> >> process >> >> >>> selects the VPN route as the preferred route. >> >> >> >> >> >> I believe our text is consistent with 4577, which says "If a VRF >> >> >> contains both an OSPF-distributed route and a VPN-IPv4 route for >> the >> >> >> same IPv4 prefix, then the OSPF-distributed route is preferred." >> >> >> Therefore, as described in the text above, if an OSPFv3 route is >> >> >> installed in the VRF for the same prefix as the IPv6 route >> learned >> >> via >> >> >> MP-BGP, the OSPFv3 route will be preferred, and the MP-BGP route >> >> will >> >> >> not be redistributed into OSPF. >> >> >> >> >> >> To get the behavior you are describing, where you want the OSPF >> >> >> decision process to prefer either the backbone or the backdoor >> link, >> >> >> requires sham links. =A0In this case, the OSPF routes from one PE >> are >> >> >> 'tunneled' via MPLS to the other PE and do not appear in the VRF >> as >> >> >> MP-BGP routes. =A0Therefore, the rules above do not hold as you ar= e >> >> only >> >> >> comparing OSPF routes, not MP-BGP to OSPF. >> >> >> >> >> > >> >> > >> >> > Unfortunately the text you refer to in RFC 4577 also seems to >> gloss >> >> over the complexities involved... >> >> > >> >> > Stepping back, the main function of RFC 4577 and draft-ietf-l3vpn- >> >> ospfv3-pece is to allow a choice between VPN routes and OSPF >> backdoor >> >> routes rather than force traffic onto OSPF backdoor routes. >> >> > >> >> > There are two cases: (1) when the backdoor route is an inter-area >> >> route (2) when the backdoor route is an intra-area route. >> >> > >> >> > In the inter-area case (1) the solution is to map VPN routes to >> OSPF >> >> inter-area prefix LSAs rather than AS-external LSAs according to the >> >> OSPF Domain ID configuration (as described in RFC 4577 section >> 4.2.8). >> >> This allows the OSPF decision process to choose between the VPN >> route >> >> (viewed as an OSPF inter-area route) and any inter-area OSPF >> backdoor >> >> route. =A0If the OSPF decision process selects the mapped VPN route >> then >> >> the intent is for the VRF to use the VPN route (complete with >> BGP/MPLS >> >> VPN labels) rather than the OSPF backdoor route. =A0As they stand the >> >> statements in RFC 4577 and draft-ietf-l3vpn-ospfv3-pece both seem to >> >> contradict this - taken at face value they both seem to say that the >> PE >> >> router should always use the OSPF (backdoor) route rather than BGP >> >> (VPN) route. >> >> > >> >> > In the intra-area case (2) the solution is to use a sham link. >> =A0This >> >> is more complicated but less subject to ambiguity about VPN routes >> >> mapped to OSPF inter-area prefix routes. >> >> > >> >> > If OSPF (backdoor) routes are always preferred to BGP (VPN) routes >> >> except in the sham link case, how can the inter-area case possibly >> >> allow a choice between the two on the PE router? >> >> > (And if it doesn't allow a choice, what is the point of specifying >> >> OSPF Domain ID configuration and mapping of VPN routes to OSPF >> inter- >> >> area prefix LSAs?) >> >> >> >> I agree that this is possible but it would be strange area topology >> >> indeed. Since the metric is not carried in BGP, it is a matter of >> local >> >> policy in the PE and one could have some subset of the site using >> the >> >> inter-area path over the backdoor link and another using the VPN >> path. >> >> But again, I don't believe this is a common use case. >> >> >> >> Thanks, >> >> Acee >> > >> > A couple of points: >> > >> > (1) The metric is carried in the BGP Multi-Exit Descriminator, as >> specified at the end of draft section 4.3.1 (and also in RFC 4577). =A0I >> believe the point of RFC 4577 and of the draft is that extra >> information carried on the VPN route allows the BGP (VPN) route to be >> mapped to an OSPF route, so that the VPN route can be preferred to the >> OSPF backdoor route. =A0This function would be broken if the OSPF >> backdoor route is always preferred to the BGP (VPN) route. >> > >> > (2) I don't understand why you say the area topology is strange. =A0As >> far as I can see it's the only area topology where mapping of BGP >> routes to OSPF inter-area routes has any effect on routing, and >> therefore it is the mainline case for much of the draft. >> > >> > =A0 =A0 =A0 =A0Nick. >> > >> >> >> >> >> >> >> >> > >> >> > Hopefully if we can answer that then we'll understand how to make >> the >> >> draft-ietf-l3vpn-ospfv3-pece text clearer. >> >> > >> >> > =A0 =A0 Nick. >> >> > >> >> >>> Section 4.3.2.3 / p11 >> >> >>> >> >> >>> The rules 1 and 2 for comparing OSPFv3 Domain IDs state how to >> >> >> compare the 6 >> >> >>> value bytes but not how to compare the 2 type bytes. =A0I believe >> the >> >> >> rules >> >> >>> should match RFC 4577 section 4.2.8.1 rules 1 and 3. =A0In other >> >> words, >> >> >> either >> >> >>> (1) all 8 (not 6) bytes match, or (2) the 6 byte value fields of >> >> both >> >> >>> attributes are all zeroes and the type bytes are ignored. =A0Note >> >> that >> >> >> in the >> >> >>> first case the 2 type bytes must match and in the latter case >> they >> >> >> are >> >> >>> ignored. >> >> >> >> >> >> This is a good point. =A0We will update the text. This text should >> >> have >> >> >> been updated when we removed the use of the single BGP extended >> >> >> community and reverted back to the OSPF Domain ID extended >> community >> >> >> attribute. >> >> >> >> >> >> Thanks, >> >> >> Michael >> >> >> >> >> >>> >> >> >>> =A0 =A0 =A0 =A0 Nick. >> >> >>> >> >> >>> Nick Weeds >> >> >>> Software Engineer, Network Technologies Division >> >> >>> Metaswitch Networks >> >> >>> >> >> >>> nick.weeds@metaswitch.com >> >> >>> +44 (0) 20 8366 1177 >> >> >>> www.metaswitch.com >> > >> > > From pedro.r.marques@gmail.com Wed May 4 10:12:35 2011 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 94D4BE0684; Wed, 4 May 2011 10:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] 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 8IqVEV8aNyZD; Wed, 4 May 2011 10:12:35 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E7521E07CE; Wed, 4 May 2011 10:12:34 -0700 (PDT) Received: by iwn39 with SMTP id 39so1390023iwn.31 for ; Wed, 04 May 2011 10:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FV9BoLyBY9Lnr3FSuEyYJ4SvIC2PRajRjgtwOn3yWJw=; b=r5sxvD263ndyV5fd5uD8AWK0y/wFtFBqqMOXjQH4rG4Jx9iSBTGDlYH1lLOonUcxiE 8UV0pW+E5g+MbaIEtFKSajBx4pDKUV7Km0ERTbQR3xp27OaVXbA4x9oMcA2Z2BRmWsOV ouEuOAkhsYmCIa2tq9A5YL/aWqEglS3ZicLBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=obpF4NQTJ5+VXY14AQKX7ASuXVYzX7uTYUkn6ldPOJvzFTqOOe7NCmfdOixQUyIcvn +kgN3w6++0PexD4GJWR7oATlJfUxCaqDmGaTt2v9GzsVr2wrmOuCspgDpuRNKRM4qTSs DjT/ZLAcisERL1gCoXUk/1drd8mHa0FPUJkOM= MIME-Version: 1.0 Received: by 10.43.135.6 with SMTP id ie6mr2089537icc.44.1304529154343; Wed, 04 May 2011 10:12:34 -0700 (PDT) Received: by 10.42.171.132 with HTTP; Wed, 4 May 2011 10:12:34 -0700 (PDT) In-Reply-To: <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> Date: Wed, 4 May 2011 10:12:34 -0700 Message-ID: Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 From: Pedro Marques To: stephane.litkowski@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org, 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, 04 May 2011 17:12:35 -0000 Stephane, On Wed, May 4, 2011 at 2:41 AM, wrote: > Pedro, > > It's quite different here from standard option B behavior. > From my understanding, if we consider the following topology for a VPN : > PE1 having VRF1 with RD1, RT1 as import/export > ASBR1 having VRF2 with RD2, RT1 as import/export > ASBR2 having VRF3 with RD3, RT1 as import/export > PE2 having VRF4 with RD4, RT1 as import/export > ASBR1 and ASBR2 have one interface in GRT with MPeBGP session (we consider shared interface forwarding case). > > PE1 advertise CE route with RD1:X/Y RT1 > ASBR1 imports it in VRF2, removes RD and RT, compute best path, export VRF RIB route to MPeBGP by adding RD2 and RT1 (morever there is no constraint to use the same RT in each AS ...), the prefix exported is a new VPN route : RD2:X/Y RT1 I don't share your assumption. You are assuming that the VRF route is re-advertised from the main instance to a VRF and then back. Indeed in this case ATTR_SET should not be kept. But that is not the only issue with this scenario. In my view the routes in the VRFs are used for forwarding only and should not be used for routing exchanges. That would allow one to have forwarding entries for some VRFs and not others purely as a local matter. I believe this is taking us into an entirely different discussion on how to do inter-as. Which is quite orthogonal to the document we are discussing. I think that it is generally agreed that for inter-as the scalability of option B is desirable but that SP sometimes need the type of control that can get out of an option A interconnect. In my view that is functionality that can exist as a matter of local forwarding behavior (It has been demonstrated). The "option d" document that has been quoted in this thread does deserve credit for correctly identifying the problem. The solution in this space however should be transparent to both ends of the peering session. i.e. provider A should be able to deploy per VRF traffic forwarding behavior without coordinating with provider B. That in my view requires that the format for route and traffic exchanges is the same as defined by option B today. > ASBR2 imports it in VRF3, removes RD and RT, compute best path, export VRF RIB route to MPIBGP by adding RD3 and RT1, the prefix exported is a new VPN route : RD3:X/Y RT1 > PE2 imports it in VRF4 > > Considering this, are you sure that ATTR_SET should be kept ? As BGP-LOC RIB used by ASBRs for exporting routes are inet ones and not inet-vpn. Please correct me if I'm wrong. > regards, Pedro. From ice@cisco.com Wed May 4 23:59:10 2011 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 88704E06F6 for ; Wed, 4 May 2011 23:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 WTXptq977E8a for ; Wed, 4 May 2011 23:59:10 -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 DC15FE06D1 for ; Wed, 4 May 2011 23:59:09 -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 p456x81q022734; Thu, 5 May 2011 08:59:08 +0200 (CEST) Received: from ams-iwijnand-8717.cisco.com (ams-iwijnand-8717.cisco.com [10.55.191.152]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p456x37p021339; Thu, 5 May 2011 08:59:04 +0200 (CEST) Subject: Re: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands In-Reply-To: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> Date: Thu, 5 May 2011 08:59:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1081) Cc: l3vpn-chairs@tools.ietf.org, L3VPN WG mailing list 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, 05 May 2011 06:59:10 -0000 yes/support On 30 Apr 2011, at 11:01, Ben Niven-Jenkins wrote: > Colleagues, >=20 > This e-mail is to start a poll on whether the L3VPN WG should adopt = draft-rosen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document. >=20 > Please indicate your support or otherwise by responding to this = message (with yes/support or no/do not support) or e-mailing the WG = chairs privately. >=20 > If you do not support the adoption of the document it would be useful = if you could also state the reason for your objection. >=20 > Please send your responses by midnight August 15th May PDT. >=20 > FYI Eric has outlined his view on the need for this document on the = mailing list previously which you can read here: > http://www.ietf.org/mail-archive/web/l3vpn/current/msg02901.html >=20 > Thanks > Ben >=20 From stephane.litkowski@orange-ftgroup.com Thu May 5 06:16:35 2011 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 127F5E0780; Thu, 5 May 2011 06:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[AWL=1.099, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, SARE_SUB_RAND_LETTRS4=0.799, 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 l6Idhv1g34ei; Thu, 5 May 2011 06:16:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB7EE06DC; Thu, 5 May 2011 06:16:33 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 38B39C03DA; Thu, 5 May 2011 15:16:32 +0200 (CEST) Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 147A615805A; Thu, 5 May 2011 15:16:32 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 May 2011 15:16:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Date: Thu, 5 May 2011 15:16:31 +0200 Message-ID: <28466_1304601392_4DC2A330_28466_1215602_1_4FC3556A36EE3646A09DAA60429F533506521675@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <4DC14427.7010809@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Thread-Index: AcwKVW+XwfcwHS5ySGKBvFIr2LlEIgAzot2A References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> <4DC14427.7010809@cisco.com> From: To: , X-OriginalArrivalTime: 05 May 2011 13:16:32.0456 (UTC) FILETIME=[A6F3CC80:01CC0B26] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.5.124517 Cc: idr@ietf.org, 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, 05 May 2011 13:16:35 -0000 Robert, Pedro, =20 [R] >So some implementation may just copy RD1:NET RT1 to RD2:NET RT1,RT2 wh= ile leaving all other=20 [R] >attributes as is including ATTR_SET. In the same time the prefix will = be imported into vrf. Is your implementation at CISCO works like this ? The text in the draft seems to mention that routes are taken from VRF RIBs = to be exported, not from VPN IPv4 BGP LOCAL-RIB : =A74.1.2 (for shared if fwding as example) : "ASBR1 exports routes associat= ed to VPN-1 from VRF2's RIB to BGP where RD and RT attributes, plus label bindings are attached to these routes. These labeled VPN-IPv4 routes are advertised across interface 'b' to ASBR2 via BGP, with a next-hop set to ASBR1. ASBR2 imports the VRF2 exported routes into VRF3's RIB where the routes RT and RD attributes are removed." VRF BGP LOC-RIB will not have the ATTR_SET attribute anymore as attributes = are changed during import from L3VPN route to the VRF. [P] >In my view the routes in the VRFs are used for forwarding only and sho= uld not be used for routing exchanges. That would allow one to have forward= ing entries for some VRFs and not others purely as a local matter. The sentence "ASBR1 exports routes associated to VPN-1 from VRF2's RIB to B= GP where RD and RT attributes, plus label bindings are attached to these routes." is not pretty clear, and I understand that inet routes in VRF a= re used for routing too. =A75.1 talks about "IPv4 routes that are converted by the ASBR to labeled V= PN-IPV4 routes", this lead to think too that IPv4 VRF RIB is used as a base= for exporting routes at ASBR level. Moreover the draft option D permits aggregation of VPN routes (=A75.3), imo= VRFs are not only used for forwarding but also for routing [P] >I think that it is generally agreed that for inter-as the scalability = of option B is desirable but that SP sometimes need the type of control tha= t can get out of an option A interconnect. I agree on that Thanks, Stephane -----Message d'origine----- De : Robert Raszuk [mailto:raszuk@cisco.com]=20 Envoy=E9 : mercredi 4 mai 2011 14:19 =C0 : LITKOWSKI Stephane DTF/DERX Cc : pedro.r.marques@gmail.com; idr@ietf.org; l3vpn@ietf.org Objet : Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Hi Stephane, The behaviour of option d is really dependent on the implementation. Remember that as general rule imported routes should not be exported again.= I think draft-kulmala-l3vpn-interas-option-d describes the concept not the= actual implementation. So some implementation may just copy RD1:NET RT1 to RD2:NET RT1,RT2 while l= eaving all other attributes as is including ATTR_SET. In the same time the = prefix will be imported into vrf. IMHO draft-ietf-l3vpn-ibgp-02 should not mandate what BGP implementations o= f various flavors of inter-as VPN peering should result in (options C+, C- = or D ...) in regards of keeping or not ATTR_SET. In fact the same applies t= o option B and C too. It is up to provider to pass this attribute and the d= raft may only recommend default behaviour. Many thx, R. > Pedro, > > It's quite different here from standard option B behavior. >> From my understanding, if we consider the following topology for a VPN : > PE1 having VRF1 with RD1, RT1 as import/export > ASBR1 having VRF2 with RD2, RT1 as import/export > ASBR2 having VRF3 with RD3, RT1 as import/export > PE2 having VRF4 with RD4, RT1 as import/export > ASBR1 and ASBR2 have one interface in GRT with MPeBGP session (we conside= r shared interface forwarding case). > > PE1 advertise CE route with RD1:X/Y RT1 > ASBR1 imports it in VRF2, removes RD and RT, compute best path, export=20 > VRF RIB route to MPeBGP by adding RD2 and RT1 (morever there is no=20 > constraint to use the same RT in each AS ...), the prefix exported is=20 > a new VPN route : RD2:X/Y RT1 > ASBR2 imports it in VRF3, removes RD and RT, compute best path, export=20 > VRF RIB route to MPIBGP by adding RD3 and RT1, the prefix exported is=20 > a new VPN route : RD3:X/Y RT1 > PE2 imports it in VRF4 > > Considering this, are you sure that ATTR_SET should be kept ? As BGP-LOC = RIB used by ASBRs for exporting routes are inet ones and not inet-vpn. Plea= se correct me if I'm wrong. > > Thanks, > > Stephane > > > > -----Message d'origine----- > De : Pedro Marques [mailto:pedro.r.marques@gmail.com] > Envoy=E9 : lundi 2 mai 2011 18:02 > =C0 : LITKOWSKI Stephane DTF/DERX > Cc : idr@ietf.org; l3vpn@ietf.org > Objet : Re: [Idr] Joint L3VPN& IDR WG LC for draft-ietf-l3vpn-ibgp-02 > > Stephane, > My reading of the document that you quote is that routes are advertised b= etween ASBRs as "inet-vpn" routes. That is certainly the case when option B= is used with per VRF forwarding, which is the scenario that i've seen depl= oyed. In both scenarios the ATTR_SET attribute is propagated since the "ine= t" route is of local significance only. > > regards, > Pedro. > > On Mon, May 2, 2011 at 8:10 AM, w= rote: >> Hi, >> >> Still a point regarding interAS case. What about the option d)=20 >> behavior ? (draft-kulmala-l3vpn-interas-option-d) >> As the VPN IPv4 route coming from AS1 is imported in ASBR VRF context as= IPv4 and then advertised as a new VPN IPv4 route (different RT/RD) to AS2,= I suppose that the ATTR_SET should be lost as for option a) even if we sti= ll have an inet-vpn route between ASBRs. Could you confirm ? >> >> Regards, >> >> Stephane >> >> >> >> -----Message d'origine----- >> De : l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] De la=20 >> part de bruno.decraene@orange-ftgroup.com Envoy=E9 : vendredi 29 avril= =20 >> 2011 >> 19:14 =C0 : pedro.r.marques@gmail.com Cc : idr@ietf.org; l3vpn@ietf.org= =20 >> Objet : RE: [Idr] Joint L3VPN& IDR WG LC for=20 >> draft-ietf-l3vpn-ibgp-02 >> >> Pedro, >> >> Thanks for the clarification text that you have added on inter AS VPN. >> New draft (-04) addresses all my comments. >> >> Thanks, >> Regards, >> Bruno >> >> >> >>> From: Pedro Marques [mailto:pedro.r.marques@gmail.com] >>> >>> Bruno, >>> >>> On Thu, Apr 28, 2011 at 5:41 AM, >> wrote: >>> >>>>> In both cases the ATTR_SET attribute will be "poped". The ATTR_SET=20 >>>>> attribute is only propagated as long as the route is an "inet-vpn" >>>>> route... once imported into a VRF it disappears. >>>> >>>> Yes. With iBGP, the ATTR_SET attribute will be "poped" but only >> after copying the BGP attributes of >>> the customer route (e.g. LOCAL_PREF) on the regular iBGP attributes. >> Then the next ASBR would "push" >>> them back in a new ATTR_SET attribute. Hence BGP attributes of the >> customer are propagated end to end. >>> >>> But that wouldn't be inter-as option A, would it ? Option A is=20 >>> defined as using eBGP on a per VRF basis. >>> >>> I believe that one needs to consider what is the design of the=20 >>> "customer" AS... while their may be topologies where you can get=20 >>> away with the scenario you suggest, i'm now aware of a generic=20 >>> scenario where this would work correctly. >>> >>> >>>> >>>> Given that l3vpn-ibgp comes after inter AS, I would assume that >> inter AS interconnection pre-exist >>> when the first iBGP PE-CE customer comes. >>> >>> >>>> So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face >> it. That's fine for me if l3vpn- >>> ibgp does not work with inter AS option A >>> >>> There is no way i'm aware off to achieve VPN network transparency=20 >>> when the provider interconnect is based on converting VPN routes to=20 >>> IP route passing it through an eBGP peering and back. >>> >>> The motivation to do iBGP is to provide VPN network transparency. In=20 >>> inter-as cases to achieve transparency iBGP is not the only=20 >>> requirement. You also need to exchange this customer routes via=20 >>> option B (or C). >>> >>>> , but I still believe this should be indicated in the "deployment >> considerations" section of the >>> document. You can also add that to be able to provide iBGP PE-CE, SP >> should favor inter AS option B >>> (over A). >>>> >>> >>> Will do. >>> >>> Pedro. >> >> ********************************************************************* >> * >> ********** IMPORTANT.Les informations contenues dans ce message=20 >> electronique y compris les fichiers attaches sont strictement=20 >> confidentielles et peuvent etre protegees par la loi. >> Ce message electronique est destine exclusivement au(x) destinataire(s) = mentionne(s) ci-dessus. >> Si vous avez recu ce message par erreur ou s il ne vous est pas=20 >> destine, veuillez immediatement le signaler a l expediteur et effacer c= e message et tous les fichiers eventuellement attaches. >> Toute lecture, exploitation ou transmission des informations contenues d= ans ce message est interdite. >> Tout message electronique est susceptible d alteration. >> A ce titre, le Groupe France Telecom decline toute responsabilite notamm= ent s il a ete altere, deforme ou falsifie. >> De meme, il appartient au destinataire de s assurer de l absence de tout= virus. >> >> IMPORTANT.This e-mail message and any attachments are strictly=20 >> confidential and may be protected by law. This message is intended only = for the named recipient(s) above. >> If you have received this message in error, or are not the named recipie= nt(s), please immediately notify the sender and delete this e-mail message. >> Any unauthorized view, usage or disclosure ofthis message is prohibited. >> Since e-mail messages may not be reliable, France Telecom Group shall no= t be liable for any message if modified, changed or falsified. >> Additionally the recipient should ensure they are actually virus free. >> ********************************************************************* >> * >> ********** >> >> > > ********************************************************************** > ********** IMPORTANT.Les informations contenues dans ce message=20 > electronique y compris les fichiers attaches sont strictement=20 > confidentielles et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) destinataire(s) m= entionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas=20 > destine, veuillez immediatement le signaler a l expediteur et effacer ce= message et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues da= ns ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite notamme= nt s il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de tout = virus. > > IMPORTANT.This e-mail message and any attachments are strictly=20 > confidential and may be protected by law. This message is intended only f= or the named recipient(s) above. > If you have received this message in error, or are not the named recipien= t(s), please immediately notify the sender and delete this e-mail message. > Any unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall not= be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > ********************************************************************** > ********** > > ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From raszuk@cisco.com Thu May 5 07:22:57 2011 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 1A596E06B0; Thu, 5 May 2011 07:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.7 X-Spam-Level: X-Spam-Status: No, score=-9.7 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] 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 Aa+UUXYcucik; Thu, 5 May 2011 07:22:56 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5AACDE0682; Thu, 5 May 2011 07:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=876; q=dns/txt; s=iport; t=1304605376; x=1305814976; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=bevA2M+uUCRBeqW2NuV1aFGh3qeEdlShkAwpWCoUYBY=; b=b2mWYOId7DoVKvKpZ4x1/9RhbwAc08aomsduG1JCQucTg9LfD2gjnR66 D6N7Whhv5GdBMty8V7wCmPUAdW5Hg5sakSPsM199arnEc/EgkcsbMRHuH eiVT5oZFBqtbt2wBddPrzRAqRnNMEoSwYvuQVKAXkcLvynowVuLYmPUJK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8HADCywk2rRDoI/2dsb2JhbACYUY1ld4hyniyCeA8BmyuGBwSPSoQjii4 X-IronPort-AV: E=Sophos;i="4.64,319,1301875200"; d="scan'208";a="442320986" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 05 May 2011 14:22:56 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p45EMsSg007521; Thu, 5 May 2011 14:22:54 GMT Message-ID: <4DC2B2BC.30704@cisco.com> Date: Thu, 05 May 2011 16:22:52 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: stephane.litkowski@orange-ftgroup.com Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> <4DC14427.7010809@cisco.com> <28466_1304601392_4DC2A330_28466_1215602_1_4FC3556A36EE3646A09DAA60429F533506521675@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <28466_1304601392_4DC2A330_28466_1215602_1_4FC3556A36EE3646A09DAA60429F533506521675@PUEXCBL0.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 14:22:57 -0000 Hi Stephane, > Robert, Pedro, > > [R]>So some implementation may just copy RD1:NET RT1 to RD2:NET RT1,RT2 while leaving all other > [R]>attributes as is including ATTR_SET. In the same time the prefix will be imported into vrf. > > Is your implementation at CISCO works like this ? In IOS the default implementation of option D is to follow the draft literally that means to export the imported prefix from the ASBR's VRF - exactly as you have interpreted by reading the draft. However due to operator requests we also by configuration allow to advertise the original src routes (and not those imported to ASBR's VRFs) and therefor treat VRF only to be used for forwarding. So to conclude, since you asked, Cisco IOS supports both options in option D inter-as configuration. Clearly the second mode will propagate ATTR_SET unchanged. Thx, R. From stephane.litkowski@orange-ftgroup.com Thu May 5 07:36:28 2011 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 3C505E067C; Thu, 5 May 2011 07:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[AWL=1.871, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, 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 Ucx95yBRrXiR; Thu, 5 May 2011 07:36:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 20CB8E0593; Thu, 5 May 2011 07:36:26 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 2351B2643CC; Thu, 5 May 2011 16:36:25 +0200 (CEST) Received: from puexcc31.nanterre.francetelecom.fr (unknown [10.168.74.8]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 086AE4C024; Thu, 5 May 2011 16:36:25 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc31.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 May 2011 16:36:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Date: Thu, 5 May 2011 16:36:23 +0200 Message-ID: <673_1304606185_4DC2B5E9_673_31287_1_4FC3556A36EE3646A09DAA60429F53350652172C@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <4DC2B2BC.30704@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Thread-Index: AcwLL+8rBacCNJwUSV2n71EbYArBcAAAcmSg References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> <4DC14427.7010809@cisco.com> <28466_1304601392_4DC2A330_28466_1215602_1_4FC3556A36EE3646A09DAA60429F533506521675@PUEXCBL0.nanterre.francetelecom.fr> <4DC2B2BC.30704@cisco.com> From: To: X-OriginalArrivalTime: 05 May 2011 14:36:25.0384 (UTC) FILETIME=[CFC29280:01CC0B31] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.5.140027 Cc: idr@ietf.org, 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, 05 May 2011 14:36:28 -0000 Thanks for the clarification. Regards, Stephane =20 -----Message d'origine----- De : Robert Raszuk [mailto:raszuk@cisco.com]=20 Envoy=E9 : jeudi 5 mai 2011 16:23 =C0 : LITKOWSKI Stephane DTF/DERX Cc : pedro.r.marques@gmail.com; idr@ietf.org; l3vpn@ietf.org Objet : Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Hi Stephane, > Robert, Pedro, > > [R]>So some implementation may just copy RD1:NET RT1 to RD2:NET=20 > RT1,RT2 while leaving all other [R]>attributes as is including ATTR_SET. = In the same time the prefix will be imported into vrf. > > Is your implementation at CISCO works like this ? In IOS the default implementation of option D is to follow the draft litera= lly that means to export the imported prefix from the ASBR's VRF - exactly = as you have interpreted by reading the draft. However due to operator requests we also by configuration allow to advertis= e the original src routes (and not those imported to ASBR's VRFs) and therefor treat VRF only to be used for forwarding. So to conclude, since you asked, Cisco IOS supports both options in option = D inter-as configuration. Clearly the second mode will propagate ATTR_SET u= nchanged. Thx, R. ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From pedro.r.marques@gmail.com Thu May 5 08:50:07 2011 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 A4842E06A6; Thu, 5 May 2011 08:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] 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 T1wpslsHrJ9M; Thu, 5 May 2011 08:50:06 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 52878E06A4; Thu, 5 May 2011 08:50:06 -0700 (PDT) Received: by iwn39 with SMTP id 39so2415461iwn.31 for ; Thu, 05 May 2011 08:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/XD45Dc9AP0MeGTI6517gH2el83OZWIGWC/eQLUjJcY=; b=s6Zuo01lD2LXd+K1z6VBAnTqAT579Br97pnOgEayopixamN/o7y+6yzrhwfwwwLWPi ghMdgbBOjVMeM3KZaVs9uZ2qbh7Xfo5GH/HBh9H26gIG02HB0+i75N1TYcZIHM4iIXoT cpFvpYkGkv3VjNgpi8Ri33vg7ObMMBAY1iSgM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=S3d5Oy8z53HNNt7fN4VL/EMtA09rwOQ/70CsPJGyBTMkupN9uA22RcuslkG/p4F6wi fo37Pyakt4S/0FvMC3i4mPSubMYKPx7pdMwscScTXxW1zVitk42tpNRc2yl9MK05o7vu ynyQwWDnlJyr/I1spanKhvTBcMSo8bbiFOC8U= MIME-Version: 1.0 Received: by 10.42.96.135 with SMTP id j7mr1217182icn.245.1304610605599; Thu, 05 May 2011 08:50:05 -0700 (PDT) Received: by 10.42.171.132 with HTTP; Thu, 5 May 2011 08:50:05 -0700 (PDT) In-Reply-To: <28466_1304601392_4DC2A330_28466_1215602_1_4FC3556A36EE3646A09DAA60429F533506521675@PUEXCBL0.nanterre.francetelecom.fr> References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> <4DC14427.7010809@cisco.com> <28466_1304601392_4DC2A330_28466_1215602_1_4FC3556A36EE3646A09DAA60429F533506521675@PUEXCBL0.nanterre.francetelecom.fr> Date: Thu, 5 May 2011 08:50:05 -0700 Message-ID: Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 From: Pedro Marques To: stephane.litkowski@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: raszuk@cisco.com, idr@ietf.org, 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, 05 May 2011 15:50:07 -0000 Stephane, With option B), ASBR peering happens at the inet-vpn address family (1, 128). In this case ATTR_SET attribute is propagated. It is still possible to import routes into VRFs, these routes are forwarding-only routes not used for routing exchanges and thus not important for this discussion. These forwarding entries can be used to apply fine grain control over the traffic without exposing this local functionality to the peer. Pedro. On Thu, May 5, 2011 at 6:16 AM, wr= ote: > Robert, Pedro, > > > [R] >So some implementation may just copy RD1:NET RT1 to RD2:NET RT1,RT2 = while leaving all other > [R] >attributes as is including ATTR_SET. In the same time the prefix wil= l be imported into vrf. > > Is your implementation at CISCO works like this ? > > The text in the draft seems to mention that routes are taken from VRF RIB= s to be exported, not from VPN IPv4 BGP LOCAL-RIB : > > =A74.1.2 (for shared if fwding as example) : "ASBR1 exports routes associ= ated to VPN-1 from VRF2's RIB to BGP where > =A0 RD and RT attributes, plus label bindings are attached to these > =A0 routes. These labeled VPN-IPv4 routes are advertised across interface > =A0 'b' to ASBR2 via BGP, with a next-hop set to ASBR1. ASBR2 imports the > =A0 VRF2 exported routes into VRF3's RIB where the routes RT and RD > =A0 attributes are removed." > > VRF BGP LOC-RIB will not have the ATTR_SET attribute anymore as attribute= s are changed during import from L3VPN route to the VRF. > > > [P] >In my view the routes in the VRFs are used for forwarding only and s= hould not be used for routing exchanges. That would allow one to have forwa= rding entries for some VRFs and not others purely as a local matter. > > The sentence "ASBR1 exports routes associated to VPN-1 from VRF2's RIB to= BGP where > =A0 RD and RT attributes, plus label bindings are attached to these > =A0 routes." is not pretty clear, and I understand that inet routes in VR= F are used for routing too. > > =A75.1 talks about "IPv4 routes that are converted by the ASBR to labeled= VPN-IPV4 routes", this lead to think too that IPv4 VRF RIB is used as a ba= se for exporting routes at ASBR level. > > Moreover the draft option D permits aggregation of VPN routes (=A75.3), i= mo =A0VRFs are not only used for forwarding but also for routing > > [P] >I think that it is generally agreed that for inter-as the scalabilit= y of option B is desirable but that SP sometimes need the type of control t= hat can get out of an option A interconnect. > > I agree on that > > > Thanks, > > Stephane > > > -----Message d'origine----- > De : Robert Raszuk [mailto:raszuk@cisco.com] > Envoy=E9 : mercredi 4 mai 2011 14:19 > =C0 : LITKOWSKI Stephane DTF/DERX > Cc : pedro.r.marques@gmail.com; idr@ietf.org; l3vpn@ietf.org > Objet : Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 > > Hi Stephane, > > The behaviour of option d is really dependent on the implementation. > > Remember that as general rule imported routes should not be exported agai= n. I think draft-kulmala-l3vpn-interas-option-d describes the concept not t= he actual implementation. > > So some implementation may just copy RD1:NET RT1 to RD2:NET RT1,RT2 while= leaving all other attributes as is including ATTR_SET. In the same time th= e prefix will be imported into vrf. > > IMHO draft-ietf-l3vpn-ibgp-02 should not mandate what BGP implementations= of various flavors of inter-as VPN peering should result in (options C+, C= - or D ...) in regards of keeping or not ATTR_SET. In fact the same applies= to option B and C too. It is up to provider to pass this attribute and the= draft may only recommend default behaviour. > > Many thx, > R. > > >> Pedro, >> >> It's quite different here from standard option B behavior. >>> From my understanding, if we consider the following topology for a VPN = : >> PE1 having VRF1 with RD1, RT1 as import/export >> ASBR1 having VRF2 with RD2, RT1 as import/export >> ASBR2 having VRF3 with RD3, RT1 as import/export >> PE2 having VRF4 with RD4, RT1 as import/export >> ASBR1 and ASBR2 have one interface in GRT with MPeBGP session (we consid= er shared interface forwarding case). >> >> PE1 advertise CE route with RD1:X/Y RT1 >> ASBR1 imports it in VRF2, removes RD and RT, compute best path, export >> VRF RIB route to MPeBGP by adding RD2 and RT1 (morever there is no >> constraint to use the same RT in each AS ...), the prefix exported is >> a new VPN route : RD2:X/Y RT1 >> ASBR2 imports it in VRF3, removes RD and RT, compute best path, export >> VRF RIB route to MPIBGP by adding RD3 and RT1, the prefix exported is >> a new VPN route : RD3:X/Y RT1 >> PE2 imports it in VRF4 >> >> Considering this, are you sure that ATTR_SET should be kept ? As BGP-LOC= RIB used by ASBRs for exporting routes are inet ones and not inet-vpn. Ple= ase correct me if I'm wrong. >> >> Thanks, >> >> Stephane >> >> >> >> -----Message d'origine----- >> De : Pedro Marques [mailto:pedro.r.marques@gmail.com] >> Envoy=E9 : lundi 2 mai 2011 18:02 >> =C0 : LITKOWSKI Stephane DTF/DERX >> Cc : idr@ietf.org; l3vpn@ietf.org >> Objet : Re: [Idr] Joint L3VPN& =A0IDR WG LC for draft-ietf-l3vpn-ibgp-02 >> >> Stephane, >> My reading of the document that you quote is that routes are advertised = between ASBRs as "inet-vpn" routes. That is certainly the case when option = B is used with per VRF forwarding, which is the scenario that i've seen dep= loyed. In both scenarios the ATTR_SET attribute is propagated since the "in= et" route is of local significance only. >> >> regards, >> =A0 =A0Pedro. >> >> On Mon, May 2, 2011 at 8:10 AM, = =A0wrote: >>> Hi, >>> >>> Still a point regarding interAS case. What about the option d) >>> behavior ? (draft-kulmala-l3vpn-interas-option-d) >>> As the VPN IPv4 route coming from AS1 is imported in ASBR VRF context a= s IPv4 and then advertised as a new VPN IPv4 route (different RT/RD) to AS2= , I suppose that the ATTR_SET should be lost as for option a) even if we st= ill have an inet-vpn route between ASBRs. Could you confirm ? >>> >>> Regards, >>> >>> Stephane >>> >>> >>> >>> -----Message d'origine----- >>> De : l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] De la >>> part de bruno.decraene@orange-ftgroup.com Envoy=E9 : vendredi 29 avril >>> 2011 >>> 19:14 =C0 : pedro.r.marques@gmail.com Cc : idr@ietf.org; l3vpn@ietf.org >>> Objet : RE: [Idr] Joint L3VPN& =A0IDR WG LC for >>> draft-ietf-l3vpn-ibgp-02 >>> >>> Pedro, >>> >>> Thanks for the clarification text that you have added on inter AS VPN. >>> New draft (-04) addresses all my comments. >>> >>> Thanks, >>> Regards, >>> Bruno >>> >>> >>> >>>> From: Pedro Marques [mailto:pedro.r.marques@gmail.com] >>>> >>>> Bruno, >>>> >>>> On Thu, Apr 28, 2011 at 5:41 AM, >>> wrote: >>>> >>>>>> In both cases the ATTR_SET attribute will be "poped". The ATTR_SET >>>>>> attribute is only propagated as long as the route is an "inet-vpn" >>>>>> route... once imported into a VRF it disappears. >>>>> >>>>> Yes. With iBGP, the ATTR_SET attribute will be "poped" but only >>> after copying the BGP attributes of >>>> the customer route (e.g. LOCAL_PREF) on the regular iBGP attributes. >>> Then the next ASBR would "push" >>>> them back in a new ATTR_SET attribute. Hence BGP attributes of the >>> customer are propagated end to end. >>>> >>>> But that wouldn't be inter-as option A, would it ? Option A is >>>> defined as using eBGP on a per VRF basis. >>>> >>>> I believe that one needs to consider what is the design of the >>>> "customer" AS... while their may be topologies where you can get >>>> away with the scenario you suggest, i'm now aware of a generic >>>> scenario where this would work correctly. >>>> >>>> >>>>> >>>>> Given that l3vpn-ibgp comes after inter AS, I would assume that >>> inter AS interconnection pre-exist >>>> when the first iBGP PE-CE customer comes. >>>> >>>> >>>>> So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face >>> it. That's fine for me if l3vpn- >>>> ibgp does not work with inter AS option A >>>> >>>> There is no way i'm aware off to achieve VPN network transparency >>>> when the provider interconnect is based on converting VPN routes to >>>> IP route passing it through an eBGP peering and back. >>>> >>>> The motivation to do iBGP is to provide VPN network transparency. In >>>> inter-as cases to achieve transparency iBGP is not the only >>>> requirement. You also need to exchange this customer routes via >>>> option B (or C). >>>> >>>>> , but I still believe this should be indicated in the "deployment >>> considerations" section of the >>>> document. You can also add that to be able to provide iBGP PE-CE, SP >>> should favor inter AS option B >>>> (over A). >>>>> >>>> >>>> Will do. >>>> >>>> =A0 =A0Pedro. >>> >>> ********************************************************************* >>> * >>> ********** IMPORTANT.Les informations contenues dans ce message >>> electronique y compris les fichiers attaches sont strictement >>> confidentielles et peuvent etre protegees par la loi. >>> Ce message electronique est destine exclusivement au(x) destinataire(s)= mentionne(s) ci-dessus. >>> Si vous avez recu ce message par erreur ou s il ne vous est pas >>> destine, veuillez immediatement le signaler =A0a l expediteur et efface= r ce message et tous les fichiers eventuellement attaches. >>> Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite. >>> Tout message electronique est susceptible d alteration. >>> A ce titre, le Groupe France Telecom decline toute responsabilite notam= ment s il a ete altere, deforme ou falsifie. >>> De meme, il appartient au destinataire de s assurer de l absence de tou= t virus. >>> >>> IMPORTANT.This e-mail message and any attachments are strictly >>> confidential and may be protected by law. This message is intended only= for the named recipient(s) above. >>> If you have received this message in error, or are not the named recipi= ent(s), please immediately notify the sender and delete this e-mail message= . >>> Any unauthorized view, usage or disclosure ofthis message is prohibited= . >>> Since e-mail messages may not be reliable, France Telecom Group shall n= ot be liable for any message if modified, changed or falsified. >>> Additionally the recipient should ensure they are actually virus free. >>> ********************************************************************* >>> * >>> ********** >>> >>> >> >> ********************************************************************** >> ********** IMPORTANT.Les informations contenues dans ce message >> electronique y compris les fichiers attaches sont strictement >> confidentielles et peuvent etre protegees par la loi. >> Ce message electronique est destine exclusivement au(x) destinataire(s) = mentionne(s) ci-dessus. >> Si vous avez recu ce message par erreur ou s il ne vous est pas >> destine, veuillez immediatement le signaler =A0a l expediteur et effacer= ce message et tous les fichiers eventuellement attaches. >> Toute lecture, exploitation ou transmission des informations contenues d= ans ce message est interdite. >> Tout message electronique est susceptible d alteration. >> A ce titre, le Groupe France Telecom decline toute responsabilite notamm= ent s il a ete altere, deforme ou falsifie. >> De meme, il appartient au destinataire de s assurer de l absence de tout= virus. >> >> IMPORTANT.This e-mail message and any attachments are strictly >> confidential and may be protected by law. This message is intended only = for the named recipient(s) above. >> If you have received this message in error, or are not the named recipie= nt(s), please immediately notify the sender and delete this e-mail message. >> Any unauthorized view, usage or disclosure ofthis message is prohibited. >> Since e-mail messages may not be reliable, France Telecom Group shall no= t be liable for any message if modified, changed or falsified. >> Additionally the recipient should ensure they are actually virus free. >> ********************************************************************** >> ********** >> >> > > > *************************************************************************= ******* > IMPORTANT.Les informations contenues dans ce message electronique y compr= is les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) destinataire(s) m= entionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas destine, = veuillez immediatement le signaler =A0a l expediteur et effacer ce message > et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues da= ns ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite notamme= nt s il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de tout = virus. > > IMPORTANT.This e-mail message and any attachments are strictly confidenti= al and may be protected by law. This message is > intended only for the named recipient(s) above. > If you have received this message in error, or are not the named recipien= t(s), please immediately notify the sender and delete this e-mail message. > Any unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall not= be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > *************************************************************************= ******* > > From stephane.litkowski@orange-ftgroup.com Fri May 6 00:51:46 2011 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 3EDE2E06B4; Fri, 6 May 2011 00:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=1.496, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, 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 WR6K-8VpCyoc; Fri, 6 May 2011 00:51:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2DAE0663; Fri, 6 May 2011 00:51:44 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2945E22C66A; Fri, 6 May 2011 09:51:43 +0200 (CEST) Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0B437238048; Fri, 6 May 2011 09:51:43 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 May 2011 09:51:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Date: Fri, 6 May 2011 09:51:42 +0200 Message-ID: <28885_1304668303_4DC3A88F_28885_74166_1_4FC3556A36EE3646A09DAA60429F533506521903@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Thread-Index: AcwLPBwcECVBJ9abTaSOqe3Cl5CZVgAhjNEg References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr><6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr><4DC14427.7010809@cisco.com><28466_1304601392_4DC2A330_28466_1215602_1_4FC3556A36EE3646A09DAA60429F533506521675@PUEXCBL0.nanterre.francetelecom.fr> From: To: "Pedro Marques" X-OriginalArrivalTime: 06 May 2011 07:51:43.0455 (UTC) FILETIME=[7103FEF0:01CC0BC2] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.6.73315 Cc: raszuk@cisco.com, idr@ietf.org, l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 07:51:46 -0000 Yes you are right for this case. Thanks for your feedback. Regards, Stephane =20 -----Message d'origine----- De : Pedro Marques [mailto:pedro.r.marques@gmail.com]=20 Envoy=E9 : jeudi 5 mai 2011 17:50 =C0 : LITKOWSKI Stephane DTF/DERX Cc : raszuk@cisco.com; idr@ietf.org; l3vpn@ietf.org Objet : Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Stephane, With option B), ASBR peering happens at the inet-vpn address family (1, 128= ). In this case ATTR_SET attribute is propagated. It is still possible to i= mport routes into VRFs, these routes are forwarding-only routes not used fo= r routing exchanges and thus not important for this discussion. These forwa= rding entries can be used to apply fine grain control over the traffic with= out exposing this local functionality to the peer. Pedro. On Thu, May 5, 2011 at 6:16 AM, wr= ote: > Robert, Pedro, > > > [R] >So some implementation may just copy RD1:NET RT1 to RD2:NET=20 > RT1,RT2 while leaving all other [R] >attributes as is including ATTR_SET.= In the same time the prefix will be imported into vrf. > > Is your implementation at CISCO works like this ? > > The text in the draft seems to mention that routes are taken from VRF RIB= s to be exported, not from VPN IPv4 BGP LOCAL-RIB : > > =A74.1.2 (for shared if fwding as example) : "ASBR1 exports routes=20 > associated to VPN-1 from VRF2's RIB to BGP where > =A0 RD and RT attributes, plus label bindings are attached to these > =A0 routes. These labeled VPN-IPv4 routes are advertised across=20 > interface > =A0 'b' to ASBR2 via BGP, with a next-hop set to ASBR1. ASBR2 imports=20 > the > =A0 VRF2 exported routes into VRF3's RIB where the routes RT and RD > =A0 attributes are removed." > > VRF BGP LOC-RIB will not have the ATTR_SET attribute anymore as attribute= s are changed during import from L3VPN route to the VRF. > > > [P] >In my view the routes in the VRFs are used for forwarding only and s= hould not be used for routing exchanges. That would allow one to have forwa= rding entries for some VRFs and not others purely as a local matter. > > The sentence "ASBR1 exports routes associated to VPN-1 from VRF2's RIB=20 > to BGP where > =A0 RD and RT attributes, plus label bindings are attached to these > =A0 routes." is not pretty clear, and I understand that inet routes in VR= F are used for routing too. > > =A75.1 talks about "IPv4 routes that are converted by the ASBR to labeled= VPN-IPV4 routes", this lead to think too that IPv4 VRF RIB is used as a ba= se for exporting routes at ASBR level. > > Moreover the draft option D permits aggregation of VPN routes (=A75.3),= =20 > imo =A0VRFs are not only used for forwarding but also for routing > > [P] >I think that it is generally agreed that for inter-as the scalabilit= y of option B is desirable but that SP sometimes need the type of control t= hat can get out of an option A interconnect. > > I agree on that > > > Thanks, > > Stephane > > > -----Message d'origine----- > De : Robert Raszuk [mailto:raszuk@cisco.com] Envoy=E9 : mercredi 4 mai=20 > 2011 14:19 =C0 : LITKOWSKI Stephane DTF/DERX Cc :=20 > pedro.r.marques@gmail.com; idr@ietf.org; l3vpn@ietf.org Objet : Re:=20 > [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 > > Hi Stephane, > > The behaviour of option d is really dependent on the implementation. > > Remember that as general rule imported routes should not be exported agai= n. I think draft-kulmala-l3vpn-interas-option-d describes the concept not t= he actual implementation. > > So some implementation may just copy RD1:NET RT1 to RD2:NET RT1,RT2 while= leaving all other attributes as is including ATTR_SET. In the same time th= e prefix will be imported into vrf. > > IMHO draft-ietf-l3vpn-ibgp-02 should not mandate what BGP implementations= of various flavors of inter-as VPN peering should result in (options C+, C= - or D ...) in regards of keeping or not ATTR_SET. In fact the same applies= to option B and C too. It is up to provider to pass this attribute and the= draft may only recommend default behaviour. > > Many thx, > R. > > >> Pedro, >> >> It's quite different here from standard option B behavior. >>> From my understanding, if we consider the following topology for a VPN : >> PE1 having VRF1 with RD1, RT1 as import/export >> ASBR1 having VRF2 with RD2, RT1 as import/export >> ASBR2 having VRF3 with RD3, RT1 as import/export >> PE2 having VRF4 with RD4, RT1 as import/export >> ASBR1 and ASBR2 have one interface in GRT with MPeBGP session (we consid= er shared interface forwarding case). >> >> PE1 advertise CE route with RD1:X/Y RT1 >> ASBR1 imports it in VRF2, removes RD and RT, compute best path,=20 >> export VRF RIB route to MPeBGP by adding RD2 and RT1 (morever there=20 >> is no constraint to use the same RT in each AS ...), the prefix=20 >> exported is a new VPN route : RD2:X/Y RT1 >> ASBR2 imports it in VRF3, removes RD and RT, compute best path,=20 >> export VRF RIB route to MPIBGP by adding RD3 and RT1, the prefix=20 >> exported is a new VPN route : RD3:X/Y RT1 >> PE2 imports it in VRF4 >> >> Considering this, are you sure that ATTR_SET should be kept ? As BGP-LOC= RIB used by ASBRs for exporting routes are inet ones and not inet-vpn. Ple= ase correct me if I'm wrong. >> >> Thanks, >> >> Stephane >> >> >> >> -----Message d'origine----- >> De : Pedro Marques [mailto:pedro.r.marques@gmail.com] >> Envoy=E9 : lundi 2 mai 2011 18:02 >> =C0 : LITKOWSKI Stephane DTF/DERX >> Cc : idr@ietf.org; l3vpn@ietf.org >> Objet : Re: [Idr] Joint L3VPN& =A0IDR WG LC for=20 >> draft-ietf-l3vpn-ibgp-02 >> >> Stephane, >> My reading of the document that you quote is that routes are advertised = between ASBRs as "inet-vpn" routes. That is certainly the case when option = B is used with per VRF forwarding, which is the scenario that i've seen dep= loyed. In both scenarios the ATTR_SET attribute is propagated since the "in= et" route is of local significance only. >> >> regards, >> =A0 =A0Pedro. >> >> On Mon, May 2, 2011 at 8:10 AM, = =A0wrote: >>> Hi, >>> >>> Still a point regarding interAS case. What about the option d)=20 >>> behavior ? (draft-kulmala-l3vpn-interas-option-d) >>> As the VPN IPv4 route coming from AS1 is imported in ASBR VRF context a= s IPv4 and then advertised as a new VPN IPv4 route (different RT/RD) to AS2= , I suppose that the ATTR_SET should be lost as for option a) even if we st= ill have an inet-vpn route between ASBRs. Could you confirm ? >>> >>> Regards, >>> >>> Stephane >>> >>> >>> >>> -----Message d'origine----- >>> De : l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] De la=20 >>> part de bruno.decraene@orange-ftgroup.com Envoy=E9 : vendredi 29 avril >>> 2011 >>> 19:14 =C0 : pedro.r.marques@gmail.com Cc : idr@ietf.org;=20 >>> l3vpn@ietf.org Objet : RE: [Idr] Joint L3VPN& =A0IDR WG LC for >>> draft-ietf-l3vpn-ibgp-02 >>> >>> Pedro, >>> >>> Thanks for the clarification text that you have added on inter AS VPN. >>> New draft (-04) addresses all my comments. >>> >>> Thanks, >>> Regards, >>> Bruno >>> >>> >>> >>>> From: Pedro Marques [mailto:pedro.r.marques@gmail.com] >>>> >>>> Bruno, >>>> >>>> On Thu, Apr 28, 2011 at 5:41 AM, >>> wrote: >>>> >>>>>> In both cases the ATTR_SET attribute will be "poped". The=20 >>>>>> ATTR_SET attribute is only propagated as long as the route is an "in= et-vpn" >>>>>> route... once imported into a VRF it disappears. >>>>> >>>>> Yes. With iBGP, the ATTR_SET attribute will be "poped" but only >>> after copying the BGP attributes of >>>> the customer route (e.g. LOCAL_PREF) on the regular iBGP attributes. >>> Then the next ASBR would "push" >>>> them back in a new ATTR_SET attribute. Hence BGP attributes of the >>> customer are propagated end to end. >>>> >>>> But that wouldn't be inter-as option A, would it ? Option A is=20 >>>> defined as using eBGP on a per VRF basis. >>>> >>>> I believe that one needs to consider what is the design of the=20 >>>> "customer" AS... while their may be topologies where you can get=20 >>>> away with the scenario you suggest, i'm now aware of a generic=20 >>>> scenario where this would work correctly. >>>> >>>> >>>>> >>>>> Given that l3vpn-ibgp comes after inter AS, I would assume that >>> inter AS interconnection pre-exist >>>> when the first iBGP PE-CE customer comes. >>>> >>>> >>>>> So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face >>> it. That's fine for me if l3vpn- >>>> ibgp does not work with inter AS option A >>>> >>>> There is no way i'm aware off to achieve VPN network transparency=20 >>>> when the provider interconnect is based on converting VPN routes to=20 >>>> IP route passing it through an eBGP peering and back. >>>> >>>> The motivation to do iBGP is to provide VPN network transparency.=20 >>>> In inter-as cases to achieve transparency iBGP is not the only=20 >>>> requirement. You also need to exchange this customer routes via=20 >>>> option B (or C). >>>> >>>>> , but I still believe this should be indicated in the "deployment >>> considerations" section of the >>>> document. You can also add that to be able to provide iBGP PE-CE,=20 >>>> SP >>> should favor inter AS option B >>>> (over A). >>>>> >>>> >>>> Will do. >>>> >>>> =A0 =A0Pedro. >>> >>> ******************************************************************** >>> * >>> * >>> ********** IMPORTANT.Les informations contenues dans ce message=20 >>> electronique y compris les fichiers attaches sont strictement=20 >>> confidentielles et peuvent etre protegees par la loi. >>> Ce message electronique est destine exclusivement au(x) destinataire(s)= mentionne(s) ci-dessus. >>> Si vous avez recu ce message par erreur ou s il ne vous est pas=20 >>> destine, veuillez immediatement le signaler =A0a l expediteur et efface= r ce message et tous les fichiers eventuellement attaches. >>> Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite. >>> Tout message electronique est susceptible d alteration. >>> A ce titre, le Groupe France Telecom decline toute responsabilite notam= ment s il a ete altere, deforme ou falsifie. >>> De meme, il appartient au destinataire de s assurer de l absence de tou= t virus. >>> >>> IMPORTANT.This e-mail message and any attachments are strictly=20 >>> confidential and may be protected by law. This message is intended only= for the named recipient(s) above. >>> If you have received this message in error, or are not the named recipi= ent(s), please immediately notify the sender and delete this e-mail message. >>> Any unauthorized view, usage or disclosure ofthis message is prohibited. >>> Since e-mail messages may not be reliable, France Telecom Group shall n= ot be liable for any message if modified, changed or falsified. >>> Additionally the recipient should ensure they are actually virus free. >>> ******************************************************************** >>> * >>> * >>> ********** >>> >>> >> >> ********************************************************************* >> * >> ********** IMPORTANT.Les informations contenues dans ce message=20 >> electronique y compris les fichiers attaches sont strictement=20 >> confidentielles et peuvent etre protegees par la loi. >> Ce message electronique est destine exclusivement au(x) destinataire(s) = mentionne(s) ci-dessus. >> Si vous avez recu ce message par erreur ou s il ne vous est pas=20 >> destine, veuillez immediatement le signaler =A0a l expediteur et effacer= ce message et tous les fichiers eventuellement attaches. >> Toute lecture, exploitation ou transmission des informations contenues d= ans ce message est interdite. >> Tout message electronique est susceptible d alteration. >> A ce titre, le Groupe France Telecom decline toute responsabilite notamm= ent s il a ete altere, deforme ou falsifie. >> De meme, il appartient au destinataire de s assurer de l absence de tout= virus. >> >> IMPORTANT.This e-mail message and any attachments are strictly=20 >> confidential and may be protected by law. This message is intended only = for the named recipient(s) above. >> If you have received this message in error, or are not the named recipie= nt(s), please immediately notify the sender and delete this e-mail message. >> Any unauthorized view, usage or disclosure ofthis message is prohibited. >> Since e-mail messages may not be reliable, France Telecom Group shall no= t be liable for any message if modified, changed or falsified. >> Additionally the recipient should ensure they are actually virus free. >> ********************************************************************* >> * >> ********** >> >> > > > ********************************************************************** > ********** IMPORTANT.Les informations contenues dans ce message=20 > electronique y compris les fichiers attaches sont strictement=20 > confidentielles et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) destinataire(s) m= entionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas=20 > destine, veuillez immediatement le signaler =A0a l expediteur et effacer = ce message et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues da= ns ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite notamme= nt s il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de tout = virus. > > IMPORTANT.This e-mail message and any attachments are strictly=20 > confidential and may be protected by law. This message is intended only f= or the named recipient(s) above. > If you have received this message in error, or are not the named recipien= t(s), please immediately notify the sender and delete this e-mail message. > Any unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall not= be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > ********************************************************************** > ********** > > ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From saku@ytti.fi Fri May 6 01:53:39 2011 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 79394E0659; Fri, 6 May 2011 01:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] 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 OHwvCxlyWHPB; Fri, 6 May 2011 01:53:38 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 72687E068C; Fri, 6 May 2011 01:53:38 -0700 (PDT) Received: by qwc23 with SMTP id 23so2541935qwc.31 for ; Fri, 06 May 2011 01:53:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.26.67 with SMTP id d3mr2318071qcc.227.1304672017514; Fri, 06 May 2011 01:53:37 -0700 (PDT) Received: by 10.229.79.2 with HTTP; Fri, 6 May 2011 01:53:37 -0700 (PDT) In-Reply-To: References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> Date: Fri, 6 May 2011 11:53:37 +0300 Message-ID: Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 From: Saku Ytti To: Pedro Marques Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: l3vpn@ietf.org, idr@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 08:53:39 -0000 On 4 May 2011 20:12, Pedro Marques wrote: > I think that it is generally agreed that for inter-as the scalability > of option B is desirable but that SP sometimes need the type of > control that can get out of an option A interconnect. In my view that > is functionality that can exist as a matter of local forwarding > behavior (It has been demonstrated). Sorry to butt in with off-topic. But this is one of my larger pet peevees, no vendor supports RFC4364 page 31 last sentence. Which means OptB cannot be used in inter-AS environments if full trust does not exist. In RFC compliant implementation risk is same as in OptA, i.e. neighbor can leak traffic between customers shared in NNI, but cannot inject traffic to arbitrary VRF. It would be very nice way to multiplex connections between CE and PE too, instead of configuration overhead of Opt A (and no need to be have circuit which can support PVC/VLAN multiplexing). So vendors, please implement this as described in RFC. --=20 =C2=A0 ++ytti From raszuk@cisco.com Fri May 6 02:03:22 2011 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 460F7E068C for ; Fri, 6 May 2011 02:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.316 X-Spam-Level: X-Spam-Status: No, score=-10.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 BLPLhwC7WVFw for ; Fri, 6 May 2011 02:03:21 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 82B6BE0659 for ; Fri, 6 May 2011 02:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=542; q=dns/txt; s=iport; t=1304672601; x=1305882201; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=hpoGZ9DQm9QIMu5SDT61P90rP8Nc9AVKT0mHHgWUKOA=; b=KxJCfFlgHYLdZXJVVMvzvh2N8cUKExJ3PJ5/5opqzRyFX1z6t2xo7vHj wyg0G2rlB3ElOyzd8We1XWYRlMAJltwd1sYisDNpe+BZFonQBek9GptKz Q/kPptRaQIi/sVwksTBzRjrsYXd+BEsNQ/+zAPyLa3Q8oNA//PBm0Awm+ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALm4w02rRDoG/2dsb2JhbACEU6Fvd4hynWCCeA8BiXmRH4Eqg16BAQSPVYQjijI X-IronPort-AV: E=Sophos;i="4.64,325,1301875200"; d="scan'208";a="442898603" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 06 May 2011 09:03:21 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4693JCH025964; Fri, 6 May 2011 09:03:20 GMT Message-ID: <4DC3B95B.1080503@cisco.com> Date: Fri, 06 May 2011 11:03:23 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: l3vpn@ietf.org, saku@ytti.fi Subject: Option B References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: 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 Reply-To: raszuk@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 09:03:22 -0000 Hi Saku, > Sorry to butt in with off-topic. But this is one of my larger pet > peevees, no vendor supports RFC4364 page 31 last sentence. Can you quote this sentence ? My page 31 talks about CSC .... > It would be very nice way to multiplex connections between CE and PE > too, instead of configuration overhead of Opt A (and no need to be > have circuit which can support PVC/VLAN multiplexing). How can you multiplex control plane which is coming from N CEs to one PE ? Thx, R. From saku@ytti.fi Fri May 6 02:13:00 2011 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 2E204E0715 for ; Fri, 6 May 2011 02:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.700, 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 P-LKUbP+F--d for ; Fri, 6 May 2011 02:12:59 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92C07E0659 for ; Fri, 6 May 2011 02:12:59 -0700 (PDT) Received: by qwc23 with SMTP id 23so2554515qwc.31 for ; Fri, 06 May 2011 02:12:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.95.144 with SMTP id d16mr2337956qcn.37.1304673178713; Fri, 06 May 2011 02:12:58 -0700 (PDT) Received: by 10.229.79.2 with HTTP; Fri, 6 May 2011 02:12:58 -0700 (PDT) In-Reply-To: <4DC3B95B.1080503@cisco.com> References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> <4DC3B95B.1080503@cisco.com> Date: Fri, 6 May 2011 12:12:58 +0300 Message-ID: Subject: Re: Option B From: Saku Ytti To: raszuk@cisco.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 09:13:00 -0000 On 6 May 2011 12:03, Robert Raszuk wrote: >> Sorry to butt in with off-topic. But this is one of my larger pet >> peevees, no vendor supports RFC4364 page 31 last sentence. > > Can you quote this sentence ? My page 31 talks about CSC .... I Think I was off by one. -- An ASBR should never accept a labeled packet from an EBGP peer unless it has actually distributed the top label to that peer. -- > How can you multiplex control plane which is coming from N CEs to one PE = ? No I mean single CE, where you'd today to vrf-lite and multplex VLAN or PVC to deliver them, if you have good number of VRF per CE, OptB would be nicer, especially as relatively low-end CPE today have MPLS capability. Of course greater benefit would be NNI. But no one wants to do OptB, due to security issues. --=20 =C2=A0 ++ytti From stephane.litkowski@orange-ftgroup.com Fri May 6 02:54:02 2011 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 81C8AE0723 for ; Fri, 6 May 2011 02:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[AWL=1.947, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, 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 jEpQ16hxhRft for ; Fri, 6 May 2011 02:54:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id AEA7BE067B for ; Fri, 6 May 2011 02:54:00 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id CE902264169; Fri, 6 May 2011 11:53:59 +0200 (CEST) Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id B247F238048; Fri, 6 May 2011 11:53:59 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 May 2011 11:54:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Option B Date: Fri, 6 May 2011 11:53:58 +0200 Message-ID: <28871_1304675639_4DC3C537_28871_1839_1_4FC3556A36EE3646A09DAA60429F533506521A23@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Option B Thread-Index: AcwLzdL6l3wYk0ZESjSnXx2ChA+0PwABS8zw References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr><6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr><4DC3B95B.1080503@cisco.com> From: To: "Saku Ytti" , X-OriginalArrivalTime: 06 May 2011 09:54:00.0331 (UTC) FILETIME=[86226DB0:01CC0BD3] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.31.105417 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 09:54:02 -0000 Saku, For single PE - single CE with multiple VPNs, imo option D should fit the n= eed. Regards, Stephane -----Message d'origine----- De : l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] De la part de S= aku Ytti Envoy=E9 : vendredi 6 mai 2011 11:13 =C0 : raszuk@cisco.com Cc : l3vpn@ietf.org Objet : Re: Option B On 6 May 2011 12:03, Robert Raszuk wrote: >> Sorry to butt in with off-topic. But this is one of my larger pet=20 >> peevees, no vendor supports RFC4364 page 31 last sentence. > > Can you quote this sentence ? My page 31 talks about CSC .... I Think I was off by one. -- An ASBR should never accept a labeled packet from an EBGP peer unless it ha= s actually distributed the top label to that peer. -- > How can you multiplex control plane which is coming from N CEs to one PE ? No I mean single CE, where you'd today to vrf-lite and multplex VLAN or PVC= to deliver them, if you have good number of VRF per CE, OptB would be nice= r, especially as relatively low-end CPE today have MPLS capability. Of course greater benefit would be NNI. But no one wants to do OptB, due to= security issues. -- =A0 ++ytti ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From saku@ytti.fi Fri May 6 03:40:55 2011 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 8714CE0723 for ; Fri, 6 May 2011 03:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.350, 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 Msrc9RHiiw3h for ; Fri, 6 May 2011 03:40:55 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1F39E071E for ; Fri, 6 May 2011 03:40:54 -0700 (PDT) Received: by qwc23 with SMTP id 23so2611771qwc.31 for ; Fri, 06 May 2011 03:40:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.37.137 with SMTP id x9mr2428071qcd.151.1304678453956; Fri, 06 May 2011 03:40:53 -0700 (PDT) Received: by 10.229.79.2 with HTTP; Fri, 6 May 2011 03:40:53 -0700 (PDT) In-Reply-To: <28871_1304675639_4DC3C537_28871_1839_1_4FC3556A36EE3646A09DAA60429F533506521A23@PUEXCBL0.nanterre.francetelecom.fr> References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> <4DC3B95B.1080503@cisco.com> <28871_1304675639_4DC3C537_28871_1839_1_4FC3556A36EE3646A09DAA60429F533506521A23@PUEXCBL0.nanterre.francetelecom.fr> Date: Fri, 6 May 2011 13:40:53 +0300 Message-ID: Subject: Re: Option B From: Saku Ytti To: stephane.litkowski@orange-ftgroup.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: raszuk@cisco.com, l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 10:40:55 -0000 On 6 May 2011 12:53, wrote: > For single PE - single CE with multiple VPNs, imo option D should fit the= need. If you are labeling in D you have the same exact problem as far as I can see as with B, i.e. you cannot use it due to incomplete implementation by the vendors, unless you have full trust. --=20 =C2=A0 ++ytti From stephane.litkowski@orange-ftgroup.com Fri May 6 06:21:51 2011 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 EFC06E0694 for ; Fri, 6 May 2011 06:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[AWL=1.725, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 ZmF8K+7IC2Wa for ; Fri, 6 May 2011 06:21:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 23478E0691 for ; Fri, 6 May 2011 06:21:45 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 21E252AC4E3; Fri, 6 May 2011 15:21:42 +0200 (CEST) Received: from PUEXCC51.nanterre.francetelecom.fr (unknown [10.168.74.61]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 05D1C18003E; Fri, 6 May 2011 15:21:42 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC51.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 May 2011 15:21:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Option B Date: Fri, 6 May 2011 15:21:20 +0200 Message-ID: <6488_1304688102_4DC3F5E6_6488_50058_1_4FC3556A36EE3646A09DAA60429F533506521BBD@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Option B Thread-Index: AcwL2hTLWFAmA0NZTJKu2FaDoU+vwgAFjEyw References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr><6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr><4DC3B95B.1080503@cisco.com><28871_1304675 639_4DC3 C537_28871_1 839_1_4FC3556A36EE3646A09DAA60429F533506521A23@PUEXCBL0.nanterre.francetelecom.fr> From: To: "Saku Ytti" X-OriginalArrivalTime: 06 May 2011 13:21:40.0656 (UTC) FILETIME=[89112300:01CC0BF0] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.6.115416 Cc: raszuk@cisco.com, l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 13:21:52 -0000 Your concern is about the CE being able to use a crafted label stack permit= ting him to access to another VPN than his own ? Pls confirm my understandi= ng. =20 -----Message d'origine----- De : Saku Ytti [mailto:saku@ytti.fi]=20 Envoy=E9 : vendredi 6 mai 2011 12:41 =C0 : LITKOWSKI Stephane DTF/DERX Cc : raszuk@cisco.com; l3vpn@ietf.org Objet : Re: Option B On 6 May 2011 12:53, wrote: > For single PE - single CE with multiple VPNs, imo option D should fit the= need. If you are labeling in D you have the same exact problem as far as I can se= e as with B, i.e. you cannot use it due to incomplete implementation by the= vendors, unless you have full trust. -- =A0 ++ytti ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From raszuk@cisco.com Fri May 6 06:27:43 2011 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 23924E0737 for ; Fri, 6 May 2011 06:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.356 X-Spam-Level: X-Spam-Status: No, score=-10.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 tL5sD+7I8Mj5 for ; Fri, 6 May 2011 06:27:40 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC35E067A for ; Fri, 6 May 2011 06:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=947; q=dns/txt; s=iport; t=1304688460; x=1305898060; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9adzbSZaKMuVI5hAjE/CyZAS9V0sDPl82euyBNf4Nuk=; b=Ko2r7MM6YClx1Ubb9KK1+oovgSkCcH3zA+BEZeNzpLUezo+AJo5OOvTr bY6EhaXf+ei/gBhPB++Id1jLpHblbR0Y62ZKI0J+lFYAP4AjBvRCOGmCb Mi2WVmFY2cgVVqMMXh6EkZ7ZnTE8Qtz9D2nPLxCPoftej3EqrgIbCPFMH A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAv2w02rRDoI/2dsb2JhbACEU6Fwd4hxniOCeA8BiXmRCoEqg16BAQSPWIQkijI X-IronPort-AV: E=Sophos;i="4.64,326,1301875200"; d="scan'208";a="351788057" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 06 May 2011 13:27:40 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p46DRcrf023999; Fri, 6 May 2011 13:27:39 GMT Message-ID: <4DC3F748.7060707@cisco.com> Date: Fri, 06 May 2011 15:27:36 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Saku Ytti Subject: Re: Option B References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> <4DC3B95B.1080503@cisco.com> <28871_1304675639_4DC3C537_28871_1839_1_4FC3556A36EE3646A09DAA60429F533506521A23@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 13:27:43 -0000 Hi Saku, Well I am not sure which vendor you are referring to but one vendor I checked does seem to support label verification in inter-as option D. As a rule of thumb if the packets are coming to a VRF either from CE or from inter-as ASBR the VPN label is verified against the one which has been advertised to a peer. However you are right that for plain option B where packets are coming not to a VRF, but to a global LFIB such verification is not currently enabled. Rgs, R. PS. For vendor specifics let's talk offline not to spam the list too much ;-). > On 6 May 2011 12:53, wrote: > >> For single PE - single CE with multiple VPNs, imo option D should fit the need. > > If you are labeling in D you have the same exact problem as far as I > can see as with B, i.e. you cannot use it due to incomplete > implementation by the vendors, unless you have full trust. From saku@ytti.fi Fri May 6 10:32:52 2011 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 CD61AE075E for ; Fri, 6 May 2011 10:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.744 X-Spam-Level: X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=0.233, 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 e9EgkZLZcFhO for ; Fri, 6 May 2011 10:32:51 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id C4243E075D for ; Fri, 6 May 2011 10:32:51 -0700 (PDT) Received: by qyk7 with SMTP id 7so2721093qyk.10 for ; Fri, 06 May 2011 10:32:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.95.144 with SMTP id d16mr2771613qcn.37.1304703171150; Fri, 06 May 2011 10:32:51 -0700 (PDT) Received: by 10.229.79.2 with HTTP; Fri, 6 May 2011 10:32:51 -0700 (PDT) In-Reply-To: <4DC3F748.7060707@cisco.com> References: <20908_1304349040_4DBEC970_20908_9009_1_4FC3556A36EE3646A09DAA60429F5335064CDA56@PUEXCBL0.nanterre.francetelecom.fr> <6997_1304502079_4DC11F3E_6997_3034_1_4FC3556A36EE3646A09DAA60429F5335064CE1A1@PUEXCBL0.nanterre.francetelecom.fr> <4DC3B95B.1080503@cisco.com> <28871_1304675639_4DC3C537_28871_1839_1_4FC3556A36EE3646A09DAA60429F533506521A23@PUEXCBL0.nanterre.francetelecom.fr> <4DC3F748.7060707@cisco.com> Date: Fri, 6 May 2011 20:32:51 +0300 Message-ID: Subject: Re: Option B From: Saku Ytti To: raszuk@cisco.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 17:32:52 -0000 On 6 May 2011 16:27, Robert Raszuk wrote: > Well I am not sure which vendor you are referring to but one vendor I > checked does seem to support label verification in inter-as option D. Ok, I assumed D would be more or less same as B, tbh haven't really investigated D support. For option B at least Alcatel, Huawei, Juniper and Cisco do not support as per their RFP responses. And I've been asking CSCO for maybe decade, bit less from JNPR. > However you are right that for plain option B where packets are coming no= t > to a VRF, but to a global LFIB such verification is not currently enabled= . I'm curious why not, I'm sure that some older 'pure ASIC' hardware can't do it, but more modern stuff like ezchip, xelerated, trio, qfp/cpp10 etc I'm confident are all able to do it. I know people want it, many SP to whom I've talked, would swap their MPLS NNI from OptA to OptB were it standard compliant. --=20 =C2=A0 ++ytti From Internet-Drafts@ietf.org Mon May 9 08:00:03 2011 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 E3795E0806; Mon, 9 May 2011 08:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 rtx-g7QgZnGo; Mon, 9 May 2011 08:00:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02BEE0801; Mon, 9 May 2011 08:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l3vpn-mvpn-infra-addrs-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110509150001.6850.35021.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2011 08:00:01 -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, 09 May 2011 15:00:03 -0000 --NextPart 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 Group of the IETF. Title : IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN Author(s) : R. Aggarwal, E. Rosen Filename : draft-ietf-l3vpn-mvpn-infra-addrs-04.txt Pages : 9 Date : 2011-05-09 To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN") BGP routes; they also originate unicast VPN routes that carry MVPN- specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider's address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses. To ensure interoperability, this document specifies that provider IPv4 addresses are always encoded in these update messages as four- octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-infra-addrs-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l3vpn-mvpn-infra-addrs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-09075510.I-D@ietf.org> --NextPart-- From jsmith4112003@yahoo.co.uk Tue May 10 22:49:07 2011 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 7223FE06FA for ; Tue, 10 May 2011 22:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 qqtACccRSrKh for ; Tue, 10 May 2011 22:49:07 -0700 (PDT) Received: from nm11.bullet.mail.ukl.yahoo.com (nm11.bullet.mail.ukl.yahoo.com [217.146.183.185]) by ietfa.amsl.com (Postfix) with SMTP id B9BBBE068B for ; Tue, 10 May 2011 22:48:52 -0700 (PDT) Received: from [217.146.183.208] by nm11.bullet.mail.ukl.yahoo.com with NNFMP; 11 May 2011 05:48:49 -0000 Received: from [217.146.183.160] by tm1.bullet.mail.ukl.yahoo.com with NNFMP; 11 May 2011 05:48:49 -0000 Received: from [127.0.0.1] by omp1001.mail.ukl.yahoo.com with NNFMP; 11 May 2011 05:48:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 273715.4776.bm@omp1001.mail.ukl.yahoo.com Received: (qmail 86952 invoked by uid 60001); 11 May 2011 05:48:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1305092929; bh=2IGns+OES6fQ5pqs1Z3hDzUHDIjJDRbrRP387dG33EA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DU2XJSd6zOhj1cfTPPEFpaDwowr4tR/3BlT3d1cDVqSlyVLaUVwpvXPz7E2DXUJcnpX21U/b1Kq0VVB71izYN2Jl4HIZiA46Sl6VUjkvyGU8N1fcCAMwtS5pTDLBX6Qs9gXnyH1xEi2iRKuTGawEUdvVQbmyatS3XGwku/zzXgM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Kjh/aM0Dyv9qoiM1D+rsEhbtF1JhThBVEI+UeafCR8ofAuPWJYKAIQxxsv1mHSUp/IWsRYSWhYTbBUINeA+yzVTu+N/ciHbF0vMKMc0O4g/suEsi3ffnpOd/O73RwTZgcJT/KRTzyooz3sEP8L4zecFzrExVdu459hM90Dpz238=; Message-ID: <99933.69660.qm@web27204.mail.ukl.yahoo.com> X-YMail-OSG: zI8x8TMVM1m3d6SjtfHaShMLpa.GUpN2WqzW.gWoGxDv66B tu2mB_pVURNcljg44MzyKXwO9Le8a3lTxVnR3DxplFbSqLAmCpqqEPiz8b4u pz410HGvjKXisIxIK7Stwv0_mleHptf6unZlRypTBV99_cSwSMdMt6hl.24s jcJ4adw8NyA3Mh_LRqrVANLullirggjU_W.XfYlOYzWy0DhvFk2rI15H2q5_ 8U6mHD_xWQa0_gqFWZCda2UHcL0j.Ztt8Vzq9XdGVb2i77RrkyjOe1D2kD9K QJytgujKc2xPiavDRpbQf5ymYWcg8IlTbdEnZejYoxk2K1aG1fKpGii4ZgC8 mZBE8BY0xWEvcuoJD3GXc.6KzTT7h4Q-- Received: from [135.245.168.34] by web27204.mail.ukl.yahoo.com via HTTP; Wed, 11 May 2011 06:48:48 BST X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.111.303096 Date: Wed, 11 May 2011 06:48:48 +0100 (BST) From: John Smith Subject: Question on NG MVPN To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 11 May 2011 05:49:07 -0000 Hi,=0A=0AAll the documents that explain the Next Generation (NG) MVPN menti= on using P2MP =0ALSPs for transmitting the multicast vpn data across the ne= twork. My question is =0Athat is it mandatory to support P2MP LSPs for this= or is it just an optimization =0Athat routers could use. Can we not set up= multiple point-to-point RSVP tunnels =0Ato each remote PE and still get th= e NG solution to work?=0A=0AWhile Sec 3.2.2 of draft-ietf-l3vpn-2547bis-mca= st-10 does seem to allude to the =0Apossibility of using unicast p2p RSVP t= unnels, the draft still keeps referring =0Ato P2MP tunnels.=0A=0AIs it then= fair to say that by using unicast p2p RSVP tunnels we cannot =0Aimplement = UI-PMSIs and S-PMSIs?=0A=0AThanks, John From yakov@juniper.net Wed May 11 04:55:35 2011 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 E6392E07E4 for ; Wed, 11 May 2011 04:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYmTLJwVUOZv for ; Wed, 11 May 2011 04:55:35 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id C976DE07E3 for ; Wed, 11 May 2011 04:55:34 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTcp5Nb6VyH6nj8KN1DETY3F9+Htk68uA@postini.com; Wed, 11 May 2011 04:55:34 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 11 May 2011 04:53:52 -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 p4BBrqv06172; Wed, 11 May 2011 04:53:52 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201105111153.p4BBrqv06172@magenta.juniper.net> To: John Smith Subject: Re: Question on NG MVPN In-Reply-To: <99933.69660.qm@web27204.mail.ukl.yahoo.com> References: <99933.69660.qm@web27204.mail.ukl.yahoo.com> X-MH-In-Reply-To: John Smith message dated "Wed, 11 May 2011 06:48:48 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <60095.1305114832.1@juniper.net> Date: Wed, 11 May 2011 04:53:52 -0700 From: Yakov Rekhter 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, 11 May 2011 11:55:36 -0000 John, > Hi, > > All the documents that explain the Next Generation (NG) MVPN mention > using P2MP LSPs for transmitting the multicast vpn data across the network. > My question is that is it mandatory to support P2MP LSPs for this or is > it just an optimization that routers could use. Can we not set up > multiple point-to-point RSVP tunnels to each remote PE and still get > the NG solution to work? One can certainly set up multiple point-to-point RSVP tunnels to each remote PE and get the NG solution to work - this is ingress replication. > While Sec 3.2.2 of draft-ietf-l3vpn-2547bis-mcast-10 does seem to > allude to the possibility of using unicast p2p RSVP tunnels, the draft > still keeps referring to P2MP tunnels. Please look at draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt for more on ingress replication. > Is it then fair to say that by using unicast p2p RSVP tunnels we cannot > implement UI-PMSIs and S-PMSIs? No, this is incorrect. One can certainly implement both UI-PMSI and S-PMSI with ingress replication using p2p RSVP tunnels. Yakov. From jsmith4112003@yahoo.co.uk Wed May 11 05:36:48 2011 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 006E1E0746 for ; Wed, 11 May 2011 05:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 QNxCFeBINVWU for ; Wed, 11 May 2011 05:36:47 -0700 (PDT) Received: from nm1-vm0.bullet.mail.ukl.yahoo.com (nm1-vm0.bullet.mail.ukl.yahoo.com [217.146.183.224]) by ietfa.amsl.com (Postfix) with SMTP id 3E480E06D1 for ; Wed, 11 May 2011 05:36:47 -0700 (PDT) Received: from [217.146.183.212] by nm1.bullet.mail.ukl.yahoo.com with NNFMP; 11 May 2011 12:36:46 -0000 Received: from [217.146.183.164] by tm5.bullet.mail.ukl.yahoo.com with NNFMP; 11 May 2011 12:36:46 -0000 Received: from [127.0.0.1] by omp1005.mail.ukl.yahoo.com with NNFMP; 11 May 2011 12:36:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 512122.14575.bm@omp1005.mail.ukl.yahoo.com Received: (qmail 95889 invoked by uid 60001); 11 May 2011 12:36:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1305117406; bh=Xe/1U3DlXo2LfMmxzPJUXSUoIZRDebxxwZbji8Wn5aM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Qoz2B7aR52/LQEHB8guEiQrK3IXrfDXx6dDK4q2Uyvl2H7aAT6IZayI7mraT0kiZ5UqdVE4X3I+fEaf5OFUBUuRJWK1xs0AcBgX5iQ5YwvF9ZIlqMYGy2J+bYFRwSFlZXHPOLSo2eucCa0csHtPnmDTbZlqPg4Dx9TtYQV1fWS8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jZFw7czdYj5DCbI9+WJ5Zce98MFS1fbuGzn/6iCBkW5goNgvKjpy8wnCa2oiZjx0YHHeoM6YW5XPfGOogcQDo/f36jWkVnmFxiDOupCZssUjyXcTS+iKCOL4485ws5B1YGObz4FED6bXIc55jwIcbaJX62FvGDmkaU1g2Lbql4o=; Message-ID: <400283.93117.qm@web27204.mail.ukl.yahoo.com> X-YMail-OSG: 6ER1MFYVM1lCPQGPt6oqJiVuWA0a90JElFWv_McqtgdI1Oy uFi62r_sqLQWa4oQ28npxnZTgFSzoamhLaTF76YsBG8ulwbNbMFqVk4KmWrn QUCHJEGicVzybcpwnHlkgp3Q3lQTk.y.hsoACzo64kIkJrgnDXr3_DNj3wr0 X.yiRITOMQCmGBMOPSm1QjBTqIan1L6Wvay0ule75SBNNCJoOiGLfE95Ed9v XxSY9wclgEvSKj_m7cLWS4xI2C4G3CtT5pkyg903RB3tKYxvAWQWTeRzSirq dFkFdGqAf1LiGI.n25YCHDsUS84Twxk_1XZVOnoA.JqBpMfybj5n5.tecXGq .m2I_Ik6M_8vqoplKAk9Cv_8N0ODRVw-- Received: from [122.172.178.24] by web27204.mail.ukl.yahoo.com via HTTP; Wed, 11 May 2011 13:36:46 BST X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.111.303096 References: <99933.69660.qm@web27204.mail.ukl.yahoo.com> <201105111153.p4BBrqv06172@magenta.juniper.net> Date: Wed, 11 May 2011 13:36:46 +0100 (BST) From: John Smith Subject: Re: Question on NG MVPN To: Yakov Rekhter In-Reply-To: <201105111153.p4BBrqv06172@magenta.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 11 May 2011 12:36:48 -0000 Thank You Yakov for your answers.=0A=0AThen this really means that the data= plane is exactly the same as L3 VPN for =0AUnicasts. Is this correct?=0A= =0AThe only difference being that the MPLS labelled packet that comes from = the =0Anetwork side will undergo a (S,G, VRF) lookup after decapsulation in= stead of a =0Anormal L3 lookup thats done for regular L3 VPNs.=0A=0A> Pleas= e look at draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt for=0A> more on ingress= replication. =0A=0A=0AI did and it actually confused me.=0A=0ASec 5 only s= eems to refer to P2MP LSPs and i was wondering if P2P LSPs are =0Asupported= or not.=0A=0AThanks, John From yakov@juniper.net Wed May 11 06:05:28 2011 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 28114E07EB for ; Wed, 11 May 2011 06:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 wM5N33URH4SJ for ; Wed, 11 May 2011 06:05:27 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFB8E06E0 for ; Wed, 11 May 2011 06:05:27 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTcqJlViSFeWIJ8/VaX9KaE5U27G93jYt@postini.com; Wed, 11 May 2011 06:05:27 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 11 May 2011 06:04:41 -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 p4BD4fv49196; Wed, 11 May 2011 06:04:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201105111304.p4BD4fv49196@magenta.juniper.net> To: John Smith Subject: Re: Question on NG MVPN In-Reply-To: <400283.93117.qm@web27204.mail.ukl.yahoo.com> References: <99933.69660.qm@web27204.mail.ukl.yahoo.com> <201105111153.p4BBrqv06172@magenta.juniper.net> <400283.93117.qm@web27204.mail.ukl.yahoo.com> X-MH-In-Reply-To: John Smith message dated "Wed, 11 May 2011 13:36:46 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62751.1305119080.1@juniper.net> Date: Wed, 11 May 2011 06:04:40 -0700 From: Yakov Rekhter 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, 11 May 2011 13:05:28 -0000 John, > Thank You Yakov for your answers. Welcome. > Then this really means that the data plane is exactly the same as L3 VPN for > Unicasts. Is this correct? The data plane on all the P routers is exactly the same as L3VPN for unicast. The data plane on the PE routers is not the same (you pointed to the difference below). > The only difference being that the MPLS labelled packet that comes from the > network side will undergo a (S,G, VRF) lookup after decapsulation instead of > a normal L3 lookup thats done for regular L3 VPNs. Correct. > > Please look at draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt for > > more on ingress replication. > > I did and it actually confused me. > > Sec 5 only seems to refer to P2MP LSPs and i was wondering if P2P LSPs are > supported or not. >From section 5: + 0 - No tunnel information present + 1 - RSVP-TE P2MP LSP + 2 - mLDP P2MP LSP + 3 - PIM-SSM Tree + 4 - PIM-SM Tree + 5 - PIM-Bidir Tree + 6 - Ingress Replication + 7 - mLDP MP2MP LSP .... When the type is set to Ingress Replication the Tunnel Identifier carries the unicast tunnel endpoint IP address of the local PE that is to be this PE's receiving endpoint address for the tunnel. Ingress replication in the above uses unicast LSPs (either p2p with RSVP-TE or mp2p with LDP). Yakov. From yakov@juniper.net Wed May 11 06:58:47 2011 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 68DB6E06F6 for ; Wed, 11 May 2011 06:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 jrjBFQSldDR0 for ; Wed, 11 May 2011 06:58:46 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 8691CE06D1 for ; Wed, 11 May 2011 06:58:46 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTcqWEwkHdclU9EOtB1dSpFt9avvOpGZl@postini.com; Wed, 11 May 2011 06:58:46 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 11 May 2011 06:55:58 -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 p4BDtwv68817; Wed, 11 May 2011 06:55:58 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201105111355.p4BDtwv68817@magenta.juniper.net> To: "ASIF, SAUD (ATTSI)" Subject: Re: Question on NG MVPN In-Reply-To: <27B9675D1C5A164E93E87BD2FE248B84092C1E14@gaalpa1msgusr7e.ugd.att.com> References: <99933.69660.qm@web27204.mail.ukl.yahoo.com><201105111153.p4BBrqv06172@magenta.juniper.net><400283.93117.qm@web27204.mail.ukl.yahoo.com> <201105111304.p4BD4fv49196@magenta.juniper.net> <27B9675D1C5A164E93E87BD2FE248B84092C1E14@gaalpa1msgusr7e.ugd.att.com> X-MH-In-Reply-To: "ASIF, SAUD (ATTSI)" message dated "Wed, 11 May 2011 09:27:00 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64258.1305122158.1@juniper.net> Date: Wed, 11 May 2011 06:55:58 -0700 From: Yakov Rekhter Cc: John Smith , 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, 11 May 2011 13:58:47 -0000 Saud, > Yakov, > > Regarding your last point. Isn't there a provision to have Ingress > Replication using P2P LSPs with LDP? I am not sure what you mean by "P2P LSPs with LDP". Could you please elaborate. Yakov. > > Saud > > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Yakov Rekhter > Sent: Wednesday, May 11, 2011 9:05 AM > To: John Smith > Cc: l3vpn@ietf.org > Subject: Re: Question on NG MVPN > > John, > > > Thank You Yakov for your answers. > > Welcome. > > > Then this really means that the data plane is exactly the same as L3 > VPN for > > Unicasts. Is this correct? > > The data plane on all the P routers is exactly the same as L3VPN for > unicast. The data plane on the PE routers is not the same (you pointed > to the difference below). > > > The only difference being that the MPLS labelled packet that comes > from the > > network side will undergo a (S,G, VRF) lookup after decapsulation > instead of > > a normal L3 lookup thats done for regular L3 VPNs. > > Correct. > > > > Please look at draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt for > > > more on ingress replication. > > > > I did and it actually confused me. > > > > Sec 5 only seems to refer to P2MP LSPs and i was wondering if P2P LSPs > are > > supported or not. > > >From section 5: > > + 0 - No tunnel information present > + 1 - RSVP-TE P2MP LSP > + 2 - mLDP P2MP LSP > + 3 - PIM-SSM Tree > + 4 - PIM-SM Tree > + 5 - PIM-Bidir Tree > + 6 - Ingress Replication > + 7 - mLDP MP2MP LSP > .... > > When the type is set to Ingress Replication the Tunnel Identifier > carries the unicast tunnel endpoint IP address of the local PE that > is to be this PE's receiving endpoint address for the tunnel. > > Ingress replication in the above uses unicast LSPs (either p2p with > RSVP-TE or mp2p with LDP). > > Yakov. > From jsmith4112003@yahoo.co.uk Wed May 11 07:34:20 2011 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 622BCE0704 for ; Wed, 11 May 2011 07:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.000, 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 d2DQIGam7toR for ; Wed, 11 May 2011 07:34:19 -0700 (PDT) Received: from nm19-vm1.bullet.mail.ukl.yahoo.com (nm19-vm1.bullet.mail.ukl.yahoo.com [217.146.183.114]) by ietfa.amsl.com (Postfix) with SMTP id 52C8AE06F6 for ; Wed, 11 May 2011 07:34:19 -0700 (PDT) Received: from [217.146.183.181] by nm19.bullet.mail.ukl.yahoo.com with NNFMP; 11 May 2011 14:34:15 -0000 Received: from [217.146.183.72] by tm12.bullet.mail.ukl.yahoo.com with NNFMP; 11 May 2011 14:34:15 -0000 Received: from [127.0.0.1] by omp1033.mail.ukl.yahoo.com with NNFMP; 11 May 2011 14:34:15 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 598512.43496.bm@omp1033.mail.ukl.yahoo.com Received: (qmail 63356 invoked by uid 60001); 11 May 2011 14:34:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1305124455; bh=L7qTwRwTadHtYuz4Gd2TQnJ8a46UvsW23NSoawOFpeE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UlNuFNJPHiwKUP2/KXM9mCl6cecK1LvwvxxrVfjFBifSK0Y12w7hpMssPxZFAq1nGxGQ0Z5S/zij82zOqIII7419virWGn+QRWHrXSg4Zc56onIqAvp7OJME9ojYRB5KYD2M7/3VGSvphhQp+WEfG1TMya2A/Ie28luC9t4ffTk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=g4hvY21i2j87L+pgnoHXL191rkZRCHCvbrJriuJ8vDLM26nuhgRf/Gz2ncP5Um7GDPzqcpvtlKYZsWKce6ZK+K1Z7Swscei468pzhKb17/nob5iuNjZNWXnSNRA2p4Er5HfCME76qe8iqGFz2vOQKFtf6qIPrG9mnllVoCSAiLE=; Message-ID: <509827.63055.qm@web27204.mail.ukl.yahoo.com> X-YMail-OSG: _N0jahMVM1nNSy2nkYoAy22Lij3EjvONraCTD8Dp1AHmolg ccMAW_33_IHb85onHUQejhB5XG_CWu6x9MlHnzD0xnfLgdQp7UBTFfLwBkcB UyAW_yHQFYkyQEMft29gTOVpaLSY0_jz69WpuvAf2h_rRGfeDLeBB6SQw7Za 82ku68EXYzkbkM_wkKyGXdO6iY..xvGVVa_lmcnndVCMCG8jMxhCo9Ahpmho BosxWfnkJlFnpZN_wBpCvgYASDeZNFSp1GZL86iKL7j.JbZL1z26YXFR._T6 cMEADQAHuGZiF2cRVAqmQTAQUG8Y5s9NIx0GjwyRTeieS1C_30aFmuMCQB0P H8Oa3coqFdmECMqCLLP3WraCZywsg6w-- Received: from [135.245.168.36] by web27204.mail.ukl.yahoo.com via HTTP; Wed, 11 May 2011 15:34:15 BST X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.111.303096 References: <99933.69660.qm@web27204.mail.ukl.yahoo.com><201105111153.p4BBrqv06172@magenta.juniper.net><400283.93117.qm@web27204.mail.ukl.yahoo.com> <201105111304.p4BD4fv49196@magenta.juniper.net> <27B9675D1C5A164E93E87BD2FE248B84092C1E14@gaalpa1msgusr7e.ugd.att.com> <201105111355.p4BDtwv68817@magenta.juniper.net> <27B9675D1C5A164E93E87BD2FE248B84092C1ED0@gaalpa1msgusr7e.ugd.att.com> Date: Wed, 11 May 2011 15:34:15 +0100 (BST) From: John Smith Subject: Re: Question on NG MVPN To: "ASIF, SAUD \(ATTSI\)" In-Reply-To: <27B9675D1C5A164E93E87BD2FE248B84092C1ED0@gaalpa1msgusr7e.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 11 May 2011 14:34:20 -0000 Saud,=0A=0AThats probably because there is no tunnel to speak of with LDP.= =0A=0AThanks, John=0A=0A=0A----- Original Message ----=0AFrom: "ASIF, SAUD = (ATTSI)" =0ATo: Yakov Rekhter =0ACc: Joh= n Smith ; l3vpn@ietf.org=0ASent: Wed, 11 May, 20= 11 19:50:47=0ASubject: RE: Question on NG MVPN =0A=0AYakov,=0A=0AYou mentio= ned "Ingress replication in the above uses unicast LSPs=0A(either p2p with = RSVP-TE or mp2p with LDP)". =0A=0AMy question was can't we have IR using Un= icast LSPs:=0A=0A1. p2p with LDP OR =0A2. p2p with RSVP-TE=0A=0ASaud=0A=0A= =0A-----Original Message-----=0AFrom: Yakov Rekhter [mailto:yakov@juniper.n= et] =0ASent: Wednesday, May 11, 2011 9:56 AM=0ATo: ASIF, SAUD (ATTSI)=0ACc:= John Smith; l3vpn@ietf.org=0ASubject: Re: Question on NG MVPN =0A=0ASaud,= =0A=0A> Yakov,=0A> =0A> Regarding your last point. Isn't there a provision = to have Ingress=0A> Replication using P2P LSPs with LDP?=0A=0AI am not sure= what you mean by "P2P LSPs with LDP". Could you please=0Aelaborate.=0A=0AY= akov.=0A=0A> =0A> Saud=0A> =0A> -----Original Message-----=0A> From: l3vpn-= bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf=0A> Of Yakov Rek= hter=0A> Sent: Wednesday, May 11, 2011 9:05 AM=0A> To: John Smith=0A> Cc: l= 3vpn@ietf.org=0A> Subject: Re: Question on NG MVPN =0A> =0A> John,=0A> =0A>= > Thank You Yakov for your answers.=0A> =0A> Welcome.=0A> =0A> > Then this= really means that the data plane is exactly the same as L3=0A> VPN for =0A= > > Unicasts. Is this correct?=0A> =0A> The data plane on all the P routers= is exactly the same as L3VPN for=0A> unicast. The data plane on the PE rou= ters is not the same (you pointed=0A> to the difference below).=0A> =0A> > = The only difference being that the MPLS labelled packet that comes=0A> from= the =0A> > network side will undergo a (S,G, VRF) lookup after decapsulati= on=0A> instead of =0A> > a normal L3 lookup thats done for regular L3 VPNs.= =0A> =0A> Correct.=0A> =0A> > > Please look at draft-ietf-l3vpn-2547bis-mca= st-bgp-08.txt for=0A> > > more on ingress replication. =0A> > =0A> > I did = and it actually confused me.=0A> > =0A> > Sec 5 only seems to refer to P2MP= LSPs and i was wondering if P2P=0ALSPs=0A> are =0A> > supported or not.=0A= > =0A> >From section 5:=0A> =0A> + 0 - No tunnel information present= =0A> + 1 - RSVP-TE P2MP LSP=0A> + 2 - mLDP P2MP LSP=0A> + 3 = - PIM-SSM Tree=0A> + 4 - PIM-SM Tree=0A> + 5 - PIM-Bidir Tree=0A>= + 6 - Ingress Replication=0A> + 7 - mLDP MP2MP LSP=0A> ....= =0A> =0A> When the type is set to Ingress Replication the Tunnel Identif= ier=0A> carries the unicast tunnel endpoint IP address of the local PE t= hat=0A> is to be this PE's receiving endpoint address for the tunnel.=0A= > =0A> Ingress replication in the above uses unicast LSPs (either p2p with= =0A> RSVP-TE or mp2p with LDP).=0A> =0A> Yakov.=0A> =0A From erosen@cisco.com Wed May 11 08:05:06 2011 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 E3C9CE081C for ; Wed, 11 May 2011 08:05:06 -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 VZHTSqJSTQGT for ; Wed, 11 May 2011 08:05:06 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCE3E0819 for ; Wed, 11 May 2011 08:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=243; q=dns/txt; s=iport; t=1305126306; x=1306335906; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=EAL/u0VcG66OrtFnVV0QMzGl2m+iCx1UWvGTIEXIvFY=; b=mQ/wsg3sI8Q8Ahk4Rp4mkiHts5J+iNR5kdl6KySoR653nC0P3JghMeDu fTXk0KpQNK/GZfnxi+pv16y2VPz+f+K5mlu54W/DOTIsj6llh9IzL7Vmg U/ZZNu1FXJ2YBnkuZO69iw1pX2ld9e8tYgkUn61lM0UfdkcmBUdIVEOz6 Q=; X-IronPort-AV: E=Sophos;i="4.64,353,1301875200"; d="scan'208";a="354863737" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 11 May 2011 15:05:06 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4BF558M020343; Wed, 11 May 2011 15:05:05 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 p4BF55aS013788; Wed, 11 May 2011 11:05:05 -0400 To: "ASIF, SAUD \(ATTSI\)" Subject: Re: Question on NG MVPN In-reply-to: Your message of Wed, 11 May 2011 15:34:15 +0100. <509827.63055.qm@web27204.mail.ukl.yahoo.com> Date: Wed, 11 May 2011 11:05:05 -0400 Message-ID: <13787.1305126305@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, 11 May 2011 15:05:07 -0000 Saud> My question was can't we have IR using Unicast LSPs: Saud> 1. p2p with LDP OR Saud> 2. p2p with RSVP-TE The unicast LSPs created by LDP are multipoint-to-point (mp2p), not point-to-point. Please don't confuse mp2p with p2mp! From thomas.morin@orange-ftgroup.com Wed May 11 09:21:39 2011 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 01DCBE0843 for ; Wed, 11 May 2011 09:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.649 X-Spam-Level: X-Spam-Status: No, score=-101.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 CQzoiSVnyamF for ; Wed, 11 May 2011 09:21:38 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 57C02E0840 for ; Wed, 11 May 2011 09:21:38 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E247EFC400B for ; Wed, 11 May 2011 18:21:36 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id DA52DFC4006 for ; Wed, 11 May 2011 18:21:36 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 18:21:36 +0200 Received: from [10.193.71.121] ([10.193.71.121]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 18:21:36 +0200 Message-ID: <4DCAB791.6020908@orange-ftgroup.com> Date: Wed, 11 May 2011 18:21:37 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; ; ; ) Gecko/2010 Thunderbird/3.1.x MIME-Version: 1.0 To: L3VPN Subject: Re: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document References: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> In-Reply-To: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> X-TagToolbar-Keys: D20110511182137429 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 May 2011 16:21:36.0387 (UTC) FILETIME=[7FE3B530:01CC0FF7] 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, 11 May 2011 16:21:39 -0000 Hi Ben, working group, There have been on-list and off-list discussions in the past 10 months or so, and we still haven't a consensus what's needed for bidir-PIM tunnels. Obviously, this is not the best starting point to gather consensus on a solution draft. I support the idea that a prerequisite for considering adopting a draft on bidir P-tunnels would be to clarify the exact things that needs to be solved and have a consensus on this. A key reason why I would not support the adoption of this draft as-is, is specifically the lack of a clearly bounded scope. -Thomas Ben Niven-Jenkins a écrit : > Colleagues, > > This e-mail is to start a poll on whether the L3VPN WG should adopt draft-rosen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document. > > Please indicate your support or otherwise by responding to this message (with yes/support or no/do not support) or e-mailing the WG chairs privately. > > If you do not support the adoption of the document it would be useful if you could also state the reason for your objection. > > Please send your responses by midnight August 15th May PDT. > > FYI Eric has outlined his view on the need for this document on the mailing list previously which you can read here: > http://www.ietf.org/mail-archive/web/l3vpn/current/msg02901.html > > Thanks > Ben > From Internet-Drafts@ietf.org Wed May 11 09:30:03 2011 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 1F72DE0679; Wed, 11 May 2011 09:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.731 X-Spam-Level: X-Spam-Status: No, score=-101.731 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 ZG8NgCFpUbga; Wed, 11 May 2011 09:30:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44BDE077E; Wed, 11 May 2011 09:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l3vpn-ibgp-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110511163002.4379.26514.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2011 09:30:02 -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, 11 May 2011 16:30:03 -0000 --NextPart 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 Group of the IETF. Title : Internal BGP as PE-CE protocol Author(s) : P. Marques, et al. Filename : draft-ietf-l3vpn-ibgp-06.txt Pages : 19 Date : 2011-05-11 This document defines protocol extensions and procedures for BGP PE-CE router iteration in BGP/MPLS IP VPN [RFC4364] networks. These have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ibgp-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l3vpn-ibgp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-11092718.I-D@ietf.org> --NextPart-- From ben@niven-jenkins.co.uk Wed May 11 15:34:34 2011 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 E3B2CE08CA for ; Wed, 11 May 2011 15:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 xADjun6FK9lh for ; Wed, 11 May 2011 15:34:34 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id 17F30E0870 for ; Wed, 11 May 2011 15:34:34 -0700 (PDT) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.2]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QKHzD-0001Nm-Jz; Wed, 11 May 2011 23:34:32 +0100 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: WG Last Call for draft-ietf-l3vpn-mvpn-infra-addrs-04 Date: Wed, 11 May 2011 23:34:30 +0100 Message-Id: <584CF5BA-FE66-4103-8B21-A83B3BCFFFA1@niven-jenkins.co.uk> To: L3VPN WG mailing list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: l3vpn-chairs@tools.ietf.org, draft-ietf-l3vpn-mvpn-infra-addrs@tools.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, 11 May 2011 22:34:35 -0000 Colleagues, Back in December we forwarded draft-ietf-l3vpn-mvpn-infra-addrs-02 to = the IESG for publication. Following IESG evaluation a number of small changes were made to the = document and it was felt that they required a further WG Last Call to = give the group a chance to comment on those changes before progressing = the document further. Therefore this e-mail starts a 2 week WG Last Call for = draft-ietf-l3vpn-mvpn-infra-addrs-04. http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-infra-addrs-04 The scope of the WG Last Call is limited to the changes changes between = the -02 and -04 versions, which can be seen here: http://goo.gl/IuZNn [ietf.org] and can be summarised as: - The document now "officially" updates = draft-ietf-l3vpn-2547bis-mcast-bgp. - The previous version suggested erroneously that the "VRF Route Import Extended Community" is an attribute of an MVPN route, when actually it = is an attribute of a unicast route. To correct this, some changes were = made to the title, the abstract, and section 1.3. Also, the VRF Route = Import Extended Community is now discussed in its own section, instead of in = the section on MVPN routes. - A new IANA action was added, requesting the assignment of a codepoint = for "VRF Route Import" in the "IPv6 address specific extended community" registry. Feedback should be provided to the mailing list and/or the authors. The Last Call ends midnight PDT 25th May 2011. Thanks Ben From internet-drafts@ietf.org Wed May 11 15:37:11 2011 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 64A5EE08D6; Wed, 11 May 2011 15:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 9dPgStMA-TkS; Wed, 11 May 2011 15:37:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10699E08B5; Wed, 11 May 2011 15:37:11 -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-ibgp-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110511223711.18840.50544.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2011 15:37:11 -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, 11 May 2011 22:37:11 -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 Work= ing Group of the IETF. Title : Internal BGP as Provider/Customer Edge Protocol for BGP/= MPLS IP Virtual Private Networks (VPNs) Author(s) : Pedro Marques Robert Raszuk Keyur Patel Kenji Kumaki Tomohiro Yamagata Filename : draft-ietf-l3vpn-ibgp-07.txt Pages : 19 Date : 2011-05-11 This document defines protocol extensions and procedures for BGP Provider/Customer edge router iteration in BGP/MPLS IP VPN [RFC4364] networks. These have the objective of making the usage of the BGP/ MPLS IP VPN transparent to the customer network, as far as routing information is concerned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ibgp-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l3vpn-ibgp-07.txt From ben@niven-jenkins.co.uk Wed May 11 15:49:47 2011 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 B244BE08E7 for ; Wed, 11 May 2011 15:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.833 X-Spam-Level: X-Spam-Status: No, score=-103.833 tagged_above=-999 required=5 tests=[AWL=-1.633, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, 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 HkrfUuLsHuGO for ; Wed, 11 May 2011 15:49:46 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 79893E08E6 for ; Wed, 11 May 2011 15:49:46 -0700 (PDT) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.2]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QKIDx-0003Oj-91; Wed, 11 May 2011 23:49:45 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Fwd: Please publish draft-ietf-l3vpn-ibgp-07 From: Ben Niven-Jenkins Date: Wed, 11 May 2011 23:49:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1119EDB9-2285-433A-9C37-17FE51230B3C@niven-jenkins.co.uk> References: <2C8356DF-C33C-4B5D-9FBF-5F4EBD0C1D1C@niven-jenkins.co.uk> To: L3VPN WG mailing list X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: draft-ietf-l3vpn-ibgp@tools.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, 11 May 2011 22:49:47 -0000 FYI. Ben Begin forwarded message: > From: Ben Niven-Jenkins > Date: 11 May 2011 23:48:28 GMT+01:00 > To: Stewart Bryant > Cc: iesg-secretary@ietf.org > Subject: Please publish draft-ietf-l3vpn-ibgp-07 >=20 > Stewart, >=20 > I've included the document shepherd write up for = draft-ietf-l3vpn-ibgp-07 below. I will be the document shepherd. >=20 > Thanks > Ben >=20 >=20 > Intended Status: Proposed Standard >=20 > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the=20 > document and, in particular, does he or she believe this=20 > version is ready for forwarding to the IESG for publication?=20 >=20 > Ben Niven-Jenkins is the Document Shepherd for draft-ietf-l3vpn-ibgp. = I have personally reviewed the -07 version of the document and believe = that this version is ready for forwarding to the IESG for publication as = a Standards Track RFC. >=20 > (1.b) Has the document had adequate review both from key WG members=20 > and from key non-WG members? Does the Document Shepherd have=20 > any concerns about the depth or breadth of the reviews that=20 > have been performed? =20 >=20 > The document was jointly WG Last Called in the L3VPN and IDR WGs which = led to some small changes to the specification. >=20 > No outstanding comments exist and it is my opinion that the document = has received sufficient review and is now ready to be published. >=20 > (1.c) Does the Document Shepherd have concerns that the document=20 > needs more review from a particular or broader perspective,=20 > e.g., security, operational complexity, someone familiar with=20 > AAA, internationalization or XML?=20 >=20 > No >=20 > (1.d) Does the Document Shepherd have any specific concerns or=20 > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he=20 > or she is uncomfortable with certain parts of the document, or=20 > has concerns whether there really is a need for it. In any=20 > event, if the WG has discussed those issues and has indicated=20 > that it still wishes to advance the document, detail those=20 > concerns here. Has an IPR disclosure related to this document=20 > been filed? If so, please include a reference to the=20 > disclosure and summarize the WG discussion and conclusion on=20 > this issue.=20 >=20 > No concerns and no IPR disclosures have been filed. >=20 > (1.e) How solid is the WG consensus behind this document? Does it=20 > represent the strong concurrence of a few individuals, with=20 > others being silent, or does the WG as a whole understand and=20 > agree with it? =20 >=20 > There were no objections during the joint L3VPN and IDR WG Last Calls = on the document. >=20 > (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20= > discontent? If so, please summarise the areas of conflict in=20 > separate email messages to the Responsible Area Director. (It=20 > should be in a separate email because this questionnaire is=20 > entered into the ID Tracker.)=20 >=20 > No, not to my knowledge. >=20 > (1.g) Has the Document Shepherd personally verified that the=20 > document satisfies all ID nits? (See the Internet-Drafts Checklist=20= > and http://tools.ietf.org/tools/idnits/). Boilerplate checks are=20 > not enough; this check needs to be thorough. Has the document=20 > met all formal review criteria it needs to, such as the MIB=20 > Doctor, media type and URI type reviews?=20 >=20 > The draft passes the idnits tools with one error that a single line is = greater than 72 characters. >=20 > Instead of submitting a new version with just that edit it is my = opinion that it can either be tackled at the same time as any IETF LC = comments or fixed by the RFC Editor prior to publication. >=20 > There are no MIB or other elements in the document that would warrant = review. As such, I have no concerns here. >=20 > (1.h) Has the document split its references into normative and=20 > informative? Are there normative references to documents that=20 > are not ready for advancement or are otherwise in an unclear=20 > state? If such normative references exist, what is the=20 > strategy for their completion? Are there normative references=20 > that are downward references, as described in [RFC3967]? If=20 > so, list these downward references to support the Area=20 > Director in the Last Call procedure for them [RFC3967].=20 >=20 > The document splits it references into normative and informative. All = normative references are to published RFCs. There are no downward = references. >=20 >=20 > (1.i) Has the Document Shepherd verified that the document IANA=20 > consideration section exists and is consistent with the body=20 > of the document? If the document specifies protocol=20 > extensions, are reservations requested in appropriate IANA=20 > registries? Are the IANA registries clearly identified? If=20 > the document creates a new registry, does it define the=20 > proposed initial contents of the registry and an allocation=20 > procedure for future registrations? Does it suggest a=20 > reasonable name for the new registry? See [RFC5226]. If the=20 > document describes an Expert Review process has Shepherd=20 > conferred with the Responsible Area Director so that the IESG=20 > can appoint the needed Expert during the IESG Evaluation?=20 >=20 > The document contains an IANA Considerations section and requests a = code point in the BGP Path Attributes registry. An early allocation of = the requested code point has already been assigned by IANA. >=20 > (1.j) Has the Document Shepherd verified that sections of the=20 > document that are written in a formal language, such as XML=20 > code, BNF rules, MIB definitions, etc., validate correctly in=20 > an automated checker?=20 >=20 > No section of this document is written in a formal language. >=20 > (1.k) The IESG approval announcement includes a Document=20 > Announcement Write-Up. Please provide such a Document=20 > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval=20 > announcement contains the following sections:=20 >=20 > Technical Summary=20 > Relevant content can frequently be found in the abstract=20 > and/or introduction of the document. If not, this may be=20 > an indication that there are deficiencies in the abstract=20 > or introduction.=20 >=20 > In current RFC4364 deployments, when BGP is used as the PE-CE routing = protocol, BGP peering sessions are typically configured as an external = peering between the VPN provider AS and the customer network AS. >=20 > While this technique works well in situations where there are no BGP = routing exchanges between the client network and other networks, it does = have drawbacks for customer networks that use BGP internally for = purposes other than interaction between CE and PE routers. >=20 > In order to make the usage of BGP/MPLS VPN services as transparent as = possible to any external interaction, it is desirable to define a = mechanism by which PE-CE routers can exchange BGP routes by means other = than external BGP. >=20 > This document specifies a means to use Internal BGP for the purpose of = exchanging PE-CE routes. >=20 >=20 > Working Group Summary=20 > Was there anything in WG process that is worth noting? For=20 > example, was there controversy about particular points or=20 > were there decisions where the consensus was particularly=20 > rough?=20 >=20 > This document is a product of L3VPN WG. The document underwent WG Last = Call in both the L3VPN and IDR WGs. >=20 > Document Quality=20 > Are there existing implementations of the protocol? >=20 > I am aware of two existing implementations. >=20 > Have a significant number of vendors indicated their plan > to implement the specification? >=20 > I do not know. However there are already two implementations that I am = aware of. >=20 > Are there any reviewers that merit special mention as > having done a thorough review, e.g., one that resulted in > important changes or a conclusion that the document had no > substantive issues? >=20 > Not to the best of my knowledge. >=20 > If there was a MIB Doctor, Media Type or other expert > review, what was its course (briefly)? In the case of a > Media Type review, on what date was the request posted? >=20 > No such review was conducted as it was not considered necessary. From jeff.tantsura@ericsson.com Thu May 12 15:24:13 2011 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 A1D9CE0759 for ; Thu, 12 May 2011 15:24:13 -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, 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 nGQj-D9HNyGY for ; Thu, 12 May 2011 15:24:12 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id A4492E0758 for ; Thu, 12 May 2011 15:24:12 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p4CMO8U2020327; Thu, 12 May 2011 17:24:12 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 12 May 2011 18:24:02 -0400 From: Jeff Tantsura To: Ben Niven-Jenkins , L3VPN WG mailing list Date: Thu, 12 May 2011 18:24:01 -0400 Subject: RE: WG Last Call for draft-ietf-l3vpn-mvpn-infra-addrs-04 Thread-Topic: WG Last Call for draft-ietf-l3vpn-mvpn-infra-addrs-04 Thread-Index: AcwQK5/U9SjFHxvhTGSSFQioTdZIgAAx6Szw Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CAC0F910B@EUSAACMS0701.eamcs.ericsson.se> References: <584CF5BA-FE66-4103-8B21-A83B3BCFFFA1@niven-jenkins.co.uk> In-Reply-To: <584CF5BA-FE66-4103-8B21-A83B3BCFFFA1@niven-jenkins.co.uk> 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 Cc: "l3vpn-chairs@tools.ietf.org" , "draft-ietf-l3vpn-mvpn-infra-addrs@tools.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, 12 May 2011 22:24:13 -0000 Yes/support Regards, Jeff =20 -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of B= en Niven-Jenkins Sent: Wednesday, May 11, 2011 15:35 To: L3VPN WG mailing list Cc: l3vpn-chairs@tools.ietf.org; draft-ietf-l3vpn-mvpn-infra-addrs@tools.ie= tf.org Subject: WG Last Call for draft-ietf-l3vpn-mvpn-infra-addrs-04 Colleagues, Back in December we forwarded draft-ietf-l3vpn-mvpn-infra-addrs-02 to the I= ESG for publication. Following IESG evaluation a number of small changes were made to the docume= nt and it was felt that they required a further WG Last Call to give the gr= oup a chance to comment on those changes before progressing the document fu= rther. Therefore this e-mail starts a 2 week WG Last Call for draft-ietf-l3vpn-mvp= n-infra-addrs-04. http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-infra-addrs-04 The scope of the WG Last Call is limited to the changes changes between the= -02 and -04 versions, which can be seen here: http://goo.gl/IuZNn [ietf.org] and can be summarised as: - The document now "officially" updates draft-ietf-l3vpn-2547bis-mcast-bgp. - The previous version suggested erroneously that the "VRF Route Import Extended Community" is an attribute of an MVPN route, when actually it is an attribute of a unicast route. To correct this, some changes were made to the title, the abstract, and section 1.3. Also, the VRF Route Import Extended Community is now discussed in its own section, instead of in the section on MVPN routes. - A new IANA action was added, requesting the assignment of a codepoint for "VRF Route Import" in the "IPv6 address specific extended community" registry. Feedback should be provided to the mailing list and/or the authors. The Last Call ends midnight PDT 25th May 2011. Thanks Ben From iesg-secretary@ietf.org Mon May 16 13:20:55 2011 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 11200E07C9; Mon, 16 May 2011 13:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 8mHAPHJdBKMv; Mon, 16 May 2011 13:20:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F622E07AA; Mon, 16 May 2011 13:20:54 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Internal BGP as Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110516202054.2377.32472.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2011 13:20:54 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 20:20:55 -0000 The IESG has received a request from the Layer 3 Virtual Private Networks WG (l3vpn) to consider the following document: - 'Internal BGP as Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-05-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines protocol extensions and procedures for BGP Provider/Customer edge router iteration in BGP/MPLS IP VPN [RFC4364] networks. These have the objective of making the usage of the BGP/ MPLS IP VPN transparent to the customer network, as far as routing information is concerned. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ibgp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ibgp/ No IPR disclosures have been submitted directly on draft-ietf-l3vpn-ibgp, but there are disclosures on a related document. Search result on draft-marques-l3vpn-ibgp, "Internal BGP as PE-CE protocol", that was replaced by draft-ietf-l3vpn-ibgp, "Internal BGP as Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)" ID # 1146 "Juniper's Statement of IPR related to draft-marques-l3vpn-ibgp-01" From rahul@juniper.net Tue May 17 15:10:37 2011 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 EDA33E07B0 for ; Tue, 17 May 2011 15:10:37 -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 fFAH2gdZoAiu for ; Tue, 17 May 2011 15:10:28 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 85439E07A4 for ; Tue, 17 May 2011 15:10:28 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTdLyU1a9Yyugs6rv+JQ1g3LjoCI4PleL@postini.com; Tue, 17 May 2011 15:10:28 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 17 May 2011 15:05:27 -0700 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p4HM5Rv41089 for ; Tue, 17 May 2011 15:05:27 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Tue, 17 May 2011 15:05:26 -0700 From: Rahul Aggarwal To: Subject: Re: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document In-Reply-To: <4DCAB791.6020908@orange-ftgroup.com> Message-ID: <20110517150207.J26290@sapphire.juniper.net> References: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> <4DCAB791.6020908@orange-ftgroup.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1402346118-1305669926=:26290" 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, 17 May 2011 22:10:38 -0000 --0-1402346118-1305669926=:26290 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Ben, working group, I oppose the adoption of this draft as a WG draft. This is because despite several discussions in the past few months, there= =20 is no consensus on precisely what bidir-PIM tunnel specific issues need to= =20 be addressed by the WG. rahul On Wed, 11 May 2011, Thomas Morin wrote: > Hi Ben, working group, > > There have been on-list and off-list discussions in the past 10 months or= so,=20 > and we still haven't a consensus what's needed for bidir-PIM tunnels.=20 > Obviously, this is not the best starting point to gather consensus on a= =20 > solution draft. I support the idea that a prerequisite for considering=20 > adopting a draft on bidir P-tunnels would be to clarify the exact things = that=20 > needs to be solved and have a consensus on this. > > A key reason why I would not support the adoption of this draft as-is, is= =20 > specifically the lack of a clearly bounded scope. > > -Thomas > > > Ben Niven-Jenkins a =C3=A9crit : >> Colleagues, >>=20 >> This e-mail is to start a poll on whether the L3VPN WG should adopt=20 >> draft-rosen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document. >>=20 >> Please indicate your support or otherwise by responding to this message= =20 >> (with yes/support or no/do not support) or e-mailing the WG chairs=20 >> privately. >>=20 >> If you do not support the adoption of the document it would be useful if= =20 >> you could also state the reason for your objection. >>=20 >> Please send your responses by midnight August 15th May PDT. >>=20 >> FYI Eric has outlined his view on the need for this document on the mail= ing=20 >> list previously which you can read here: >> http://www.ietf.org/mail-archive/web/l3vpn/current/msg02901.html >>=20 >> Thanks >> Ben >>=20 > --0-1402346118-1305669926=:26290-- From ccie15672@yahoo.com Fri May 27 08:36:20 2011 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 29096E0805 for ; Fri, 27 May 2011 08:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] 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 Ityx6EuQuWlH for ; Fri, 27 May 2011 08:36:19 -0700 (PDT) Received: from nm9-vm1.bullet.mail.bf1.yahoo.com (nm9-vm1.bullet.mail.bf1.yahoo.com [98.139.213.75]) by ietfa.amsl.com (Postfix) with SMTP id 7B730E0804 for ; Fri, 27 May 2011 08:36:19 -0700 (PDT) Received: from [98.139.212.149] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2011 15:36:15 -0000 Received: from [98.139.212.202] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2011 15:36:15 -0000 Received: from [127.0.0.1] by omp1011.mail.bf1.yahoo.com with NNFMP; 27 May 2011 15:36:15 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 473914.66581.bm@omp1011.mail.bf1.yahoo.com Received: (qmail 34365 invoked by uid 60001); 27 May 2011 15:36:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306510575; bh=eMOfzWeKM6NU0ON3e7MgtjGoY/f0EYarBlf+hzQyYjk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=MJo2zyyisnCV7Y1CdORCpLGm2mrsM2C6zlYWlwkVfKgCbCOH+qvlgW8tcSbB70eD+mv7l3KqadTRJPlu4Ely4Jibz9P5tPyIt+MG5cYD9o1aSeWURZsBWziR57FuzT4hhnoKnN3gG6sWKZEupi9/ysQhtPYWKrqktMFynMNRu4g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=c7qeRGSp6IsMqluvOK/lTVV4EGbwxpUowGcilY4M6glnC1Bu2HfM7Xmvmu12U+NM8P6kgzBYiSG4WW1SzmyjxImIFW1+RdiYbhCMx2kIFSxpr2T/otOAlgovc9urY/FFeDl5S/ZgitKPGx6dG7K6o52jC4kK33eJY61KYFqT3Tc=; Message-ID: <325769.32976.qm@web161819.mail.bf1.yahoo.com> X-YMail-OSG: HMncVXUVM1mEkoe5X_QsHijtkCp_HrQ7ZVPnH6VsnL8xog9 27Yj8dy4dgtNeK.cl0WcUQs9_86.c0lp2To_C43e0nSBFPTXuEf.yC0x.yu3 Y.I.HSo5RpNCTZItm2sVEfjEQfKGn51IlDK_j.TS0XEOO97e1ZnUTd9MFbfU 1CdDuwBHsn6AoA520AJvHPcpar_Dt8DJDKggLxFZzZD4xlfv5ff4J7QIW0ZN iJueHcLBP9ESPb4Y_fDxuF1zBW33pAvanzWuJCGh.m7rp0md4FipyZurx1l. rW3_sj6lWm9ViiCE2GJZAtYerXHuvK7zE25GRIHreWJcynhLGEldIDA8g_.c 0xmOiUtStucAXbzeoAuHWQFRCa2s- Received: from [76.194.43.66] by web161819.mail.bf1.yahoo.com via HTTP; Fri, 27 May 2011 08:36:15 PDT X-Mailer: YahooMailRC/567 YahooMailWebService/0.8.111.303096 Date: Fri, 27 May 2011 08:36:15 -0700 (PDT) From: Derick Winkworth Subject: Re: draft-ietf-l3vpn-ibgp To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-104062156-1306510575=:32976" 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, 27 May 2011 15:36:20 -0000 --0-104062156-1306510575=:32976 Content-Type: text/plain; charset=us-ascii All: I see no mention of peering to a CE device using the provider's global AS. I see potential use cases for this where a service-provider puts a non-MPLS aware device in between PEs. For instance, a firewall with an "inside VRF" and an "outside VRF." The service-provider owns and manages this device. The device supports BGP and whatever service it is providing, routes are passed through it (either PE to PE or the device itself reflects the routes from one PE to another). This could be WAAS, IPS, firewall, a router performing NAT services, etc. I think this possibility should be addressed as there are issues with the "service PEs" on either side of a device peering with an MP-BGP route-reflector. Specifically, as routes pass from MP-BGP to regular inet iBGP back into the opposite PE, it may be desirable to remove cluster and originator ID info. Derick --0-104062156-1306510575=:32976 Content-Type: text/html; charset=us-ascii
All:

I see no mention of peering to a CE device using the provider's global AS.  I see potential use cases for this where a service-provider puts a non-MPLS aware device in between PEs.  For instance, a firewall with an "inside VRF" and an "outside VRF."  

The service-provider owns and manages this device.  The device supports BGP and whatever service it is providing, routes are passed through it (either PE to PE or the device itself reflects the routes from one PE to another). This could be WAAS, IPS, firewall, a router performing NAT services, etc.

I think this possibility should be addressed as there are issues with the "service PEs" on either side of a device peering with an MP-BGP route-reflector.  Specifically, as routes pass from MP-BGP to regular inet iBGP back into the opposite PE, it may be desirable to remove cluster and originator ID info.

Derick


--0-104062156-1306510575=:32976-- From pedro.r.marques@gmail.com Fri May 27 09:10:34 2011 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 8720BE0815 for ; Fri, 27 May 2011 09:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] 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 IvAmr+8Iw8Un for ; Fri, 27 May 2011 09:10:28 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB832E0813 for ; Fri, 27 May 2011 09:10:27 -0700 (PDT) Received: by iyn15 with SMTP id 15so2419859iyn.31 for ; Fri, 27 May 2011 09:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Kvn1KLYPKEzf2wZbN/JdQ3Kk9gs8oTerCR9/TEqq0yQ=; b=fNM5/pdIyau65iPlpy+qzcvm9LH8NDCZW/1VxKDp+SAS5eVNe6il9fJLp8DMiYRM9L zwIVF4vW3T7MYmznNjGyOJHtFiZNpIWWkvgc32MG35fycXU7vTOurPAaG0xN1hCoPCHQ QJHk/QiUE0AqzB+q9eyhy6oz6WozwDq0PXcek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wDzgbZvlNy+YSNpcls59qbzGmX2B6pqWU4S0/LCikA4U0y/YFfriTZFUiE4a/hU4uo p3sno+h7JYUGqFPh9yJV6FZi50KdaTT/S7O+v4Szn4MJ6hxZXBP21WkMBE8MXwZgLiJ/ QqcnzAcsjPewOrcSRn0AibOuQeLVEIhzNUDtY= MIME-Version: 1.0 Received: by 10.43.59.140 with SMTP id wo12mr1555077icb.408.1306512627418; Fri, 27 May 2011 09:10:27 -0700 (PDT) Received: by 10.42.164.8 with HTTP; Fri, 27 May 2011 09:10:27 -0700 (PDT) In-Reply-To: <325769.32976.qm@web161819.mail.bf1.yahoo.com> References: <325769.32976.qm@web161819.mail.bf1.yahoo.com> Date: Fri, 27 May 2011 09:10:27 -0700 Message-ID: Subject: Re: draft-ietf-l3vpn-ibgp From: Pedro Marques To: Derick Winkworth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 16:10:34 -0000 Derick, Your email is rather vague in terms of the scenario that your are trying to address. You refer to service appliances such as firewall/nat. These are often deployed with a Hub & Spoke configuration in which spoke sites are not allowed to communicate directly and must traverse a Hub site. Hub & spoke configurations can be achieved by using 2 route target per VPN: an hub route target (exported by the hub site and imported by the spoke PEs) and a spoke RT (exported by the spoke sites and imported by the hub). There is no need to explicitly have the service appliance participate in routing in order to accomplish this. If you do wish the appliance to be an active component to the routing infrastructure that can also be achieved using two different VPNs (i.e. different route targets) for the "inside" and "outside" partition (these RTs can actually use the same customer as#). Using what is currently specified in this document it is possible to have a non BGP/MPLS VPN device be the Route Reflector between different clusters (such as an "inside" cluster and an "outside" cluster). These clusters have their routing information conveyed over a BGP/MPLS VPN. I'm not aware of any additional functionality required to make this happen other than what is already specified. BGP is a generic and flexible mechanism used in a very wide range of scenarios. With this document there is a standard to allow an iBGP cloud to use BGP/MPLS VPN as its internal connectivity. It maintains the same service model as iBGP over plain vanilla internal connectivity. I don't believe it would be useful to deviate from that. regards, Pedro. On Fri, May 27, 2011 at 8:36 AM, Derick Winkworth wro= te: > All: > I see no mention of peering to a CE device using the provider's global AS= . > =A0I see potential use cases for this where a service-provider puts a non= -MPLS > aware device in between PEs. =A0For instance, a firewall with an "inside = VRF" > and an "outside VRF." > The service-provider owns and manages this device. =A0The device supports= BGP > and whatever service it is providing, routes are passed through it (eithe= r > PE to PE or the device itself reflects the routes from one PE to another)= . > This could be WAAS, IPS, firewall, a router performing NAT services, etc. > I think this possibility should be addressed as there are issues with the > "service PEs" on either side of a device peering with an MP-BGP > route-reflector. =A0Specifically, as routes pass from MP-BGP to regular i= net > iBGP back into the opposite PE, it may be desirable to remove cluster and > originator ID info. > Derick > > From ccie15672@yahoo.com Fri May 27 09:35:05 2011 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 3D308E081D for ; Fri, 27 May 2011 09:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] 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 pb55d3SU2POx for ; Fri, 27 May 2011 09:35:04 -0700 (PDT) Received: from nm8-vm1.bullet.mail.bf1.yahoo.com (nm8-vm1.bullet.mail.bf1.yahoo.com [98.139.212.190]) by ietfa.amsl.com (Postfix) with SMTP id DB321E0711 for ; Fri, 27 May 2011 09:35:03 -0700 (PDT) Received: from [98.139.212.148] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2011 16:35:00 -0000 Received: from [98.139.212.228] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2011 16:35:00 -0000 Received: from [127.0.0.1] by omp1037.mail.bf1.yahoo.com with NNFMP; 27 May 2011 16:35:00 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 622842.2651.bm@omp1037.mail.bf1.yahoo.com Received: (qmail 73373 invoked by uid 60001); 27 May 2011 16:35:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306514100; bh=hBHb1AfPVFOXcTQKB3212cMyMi+JUQ1mDSVrvTNgU3s=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Hcvz1zlOG4I3k8F/e7t2rAS345bhninMD8r30u9uz0/JPQi+eLedKqt3sDhYal3c/oY2Yr9m3gXWudT/CUCV9vWJ8k4aDvc6v1Eu4nz5jaICEvhpJtQUOzz+DA0rH82A2pJKQaANpviIBU182du55MWaB0aeGtXq/NZv6EAjJq0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Q5shMm9VZlPa/aPN0phDVhvBczagmzrd++T1kolzJtkmRn/UjnWB6i6ol3sjv9Flbau4GKEsgxYyyLaTkRMSG+ExI11tsY2cCEyr8ICH7GRghHDeRKrT40ckNRa8jLjnEInXvVdD9/c8llM1m6Gt+stc+pVeZ8TMBrtxWOpp2rk=; Message-ID: <431072.40507.qm@web161806.mail.bf1.yahoo.com> X-YMail-OSG: mY0WUt0VM1k6lIDdTYVxcL8P1FZTN73dSNNBY4DZp_wA3JU lPu4ONPnY55Vt0ENtLBIqzTob7cQrqM2jVBMg25CYxIB.oMMrc0XW8RFKhad Jn58H8bdT92Eilxzjjl.RiAV.YXuvjSHNlchkKe.M0Rl1iue.loDoKaarIPA tf_cnzI86DemVUWX_7nOVMwy6ewLtAcnM1X2gr9BRzGurDVqU.7bg8wPrqNU kPBahmzuL.hmTlM9H3S58qvxg0B6y.Jv9KAriv3WeeTNg9QUxnyHgMQNv0vh jL8ntzQmyfsXOhFATG.h1pxwEa.4J2D0qc42UMJFAr2cAEhM3tfEFi_BpvQ0 r80O1GFlTxoDivENrKWsXlqjkaQ-- Received: from [76.194.43.66] by web161806.mail.bf1.yahoo.com via HTTP; Fri, 27 May 2011 09:35:00 PDT X-Mailer: YahooMailRC/567 YahooMailWebService/0.8.111.303096 References: <325769.32976.qm@web161819.mail.bf1.yahoo.com> Date: Fri, 27 May 2011 09:35:00 -0700 (PDT) From: Derick Winkworth Subject: Re: draft-ietf-l3vpn-ibgp To: Pedro Marques In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-236356033-1306514100=:40507" Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 16:35:05 -0000 --0-236356033-1306514100=:40507 Content-Type: text/plain; charset=us-ascii Well, let me put it a different way. If you use the SP's global AS to peer via iBGP to a "CE" device and that route passes to another PE in the same provider AS, and that other PE VRF has a different RD and route-targets, is it not a different route at that point? I guess what I'm suggesting is that in the case of using the service-provider's AS in a PE-CE peering the passing of route-reflector info should be optional as it may be desirable to pass the route back into the same cluster but "originating" from the second PE with different RD/RT. I think this would actually be simpler than maintaining multiple clusters with redundant RRs. Technically, a RR-client should not peer to more than one cluster anyway. What if VRF "A" on a PE wants transitivity to VRF "B" on the same PE through such a device? The route would pass from VRF "A" on PE1 into MP-BGP, through RR "A" to the inside VRF PE, through the device, to the outside VRF PE, then to RR "B" (if the cluster-id is the same on RRs "A" and "B" the route dies here), and then back to the PE hopefully to be imported into VRF "B." The originator ID would prevent this. ________________________________ From: Pedro Marques To: Derick Winkworth Cc: l3vpn@ietf.org Sent: Fri, May 27, 2011 11:10:27 AM Subject: Re: draft-ietf-l3vpn-ibgp Derick, Your email is rather vague in terms of the scenario that your are trying to address. You refer to service appliances such as firewall/nat. These are often deployed with a Hub & Spoke configuration in which spoke sites are not allowed to communicate directly and must traverse a Hub site. Hub & spoke configurations can be achieved by using 2 route target per VPN: an hub route target (exported by the hub site and imported by the spoke PEs) and a spoke RT (exported by the spoke sites and imported by the hub). There is no need to explicitly have the service appliance participate in routing in order to accomplish this. If you do wish the appliance to be an active component to the routing infrastructure that can also be achieved using two different VPNs (i.e. different route targets) for the "inside" and "outside" partition (these RTs can actually use the same customer as#). Using what is currently specified in this document it is possible to have a non BGP/MPLS VPN device be the Route Reflector between different clusters (such as an "inside" cluster and an "outside" cluster). These clusters have their routing information conveyed over a BGP/MPLS VPN. I'm not aware of any additional functionality required to make this happen other than what is already specified. BGP is a generic and flexible mechanism used in a very wide range of scenarios. With this document there is a standard to allow an iBGP cloud to use BGP/MPLS VPN as its internal connectivity. It maintains the same service model as iBGP over plain vanilla internal connectivity. I don't believe it would be useful to deviate from that. regards, Pedro. On Fri, May 27, 2011 at 8:36 AM, Derick Winkworth wrote: > All: > I see no mention of peering to a CE device using the provider's global AS. > I see potential use cases for this where a service-provider puts a non-MPLS > aware device in between PEs. For instance, a firewall with an "inside VRF" > and an "outside VRF." > The service-provider owns and manages this device. The device supports BGP > and whatever service it is providing, routes are passed through it (either > PE to PE or the device itself reflects the routes from one PE to another). > This could be WAAS, IPS, firewall, a router performing NAT services, etc. > I think this possibility should be addressed as there are issues with the > "service PEs" on either side of a device peering with an MP-BGP > route-reflector. Specifically, as routes pass from MP-BGP to regular inet > iBGP back into the opposite PE, it may be desirable to remove cluster and > originator ID info. > Derick > > --0-236356033-1306514100=:40507 Content-Type: text/html; charset=us-ascii
Well, let me put it a different way.

If you use the SP's global AS to peer via iBGP to a "CE" device and that route passes to another PE in the same provider AS, and that other PE VRF has a different RD and route-targets, is it not a different route at that point?  I guess what I'm suggesting is that in the case of using the service-provider's AS in a PE-CE peering the passing of route-reflector info should be optional as it may be desirable to pass the route back into the same cluster but "originating" from the second PE with different RD/RT.

I think this would actually be simpler than maintaining multiple clusters with redundant RRs.  Technically, a RR-client should not peer to more than one cluster anyway. What if VRF "A" on a PE wants transitivity to VRF "B" on the same PE through such a device?  

The route would pass from VRF "A" on PE1 into MP-BGP, through RR "A" to the inside VRF PE, through the device, to the outside VRF PE, then to RR "B" (if the cluster-id is the same on RRs "A" and "B" the route dies here), and then back to the PE hopefully to be imported into VRF "B."  The originator ID would prevent this.




From: Pedro Marques <pedro.r.marques@gmail.com>
To: Derick Winkworth <ccie15672@yahoo.com>
Cc: l3vpn@ietf.org
Sent: Fri, May 27, 2011 11:10:27 AM
Subject: Re: draft-ietf-l3vpn-ibgp

Derick,
Your email is rather vague in terms of the scenario that your are
trying to address. You refer to service appliances such as
firewall/nat. These are often deployed with a Hub & Spoke
configuration in which spoke sites are not allowed to communicate
directly and must traverse a Hub site.

Hub & spoke configurations can be achieved by using 2 route target per
VPN: an hub route target (exported by the hub site and imported by the
spoke PEs) and a spoke RT (exported by the spoke sites and imported by
the hub). There is no need to explicitly have the service appliance
participate in routing in order to accomplish this.

If you do wish the appliance to be an active component to the routing
infrastructure that can also be achieved using two different VPNs
(i.e. different route targets) for the "inside" and "outside"
partition (these RTs can actually use the same customer as#).

Using what is currently specified in this document it is possible to
have a non BGP/MPLS VPN device be the Route Reflector between
different clusters (such as an "inside" cluster and an "outside"
cluster). These clusters have their routing information conveyed over
a BGP/MPLS VPN. I'm not aware of any additional functionality required
to make this happen other than what is already specified.

BGP is a generic and flexible mechanism used in a very wide range of
scenarios. With this document there is a standard to allow an iBGP
cloud to use BGP/MPLS VPN as its internal connectivity. It maintains
the same service model as iBGP over plain vanilla internal
connectivity. I don't believe it would be useful to deviate from that.

regards,
  Pedro.

On Fri, May 27, 2011 at 8:36 AM, Derick Winkworth <ccie15672@yahoo.com> wrote:
> All:
> I see no mention of peering to a CE device using the provider's global AS.
>  I see potential use cases for this where a service-provider puts a non-MPLS
> aware device in between PEs.  For instance, a firewall with an "inside VRF"
> and an "outside VRF."
> The service-provider owns and manages this device.  The device supports BGP
> and whatever service it is providing, routes are passed through it (either
> PE to PE or the device itself reflects the routes from one PE to another).
> This could be WAAS, IPS, firewall, a router performing NAT services, etc.
> I think this possibility should be addressed as there are issues with the
> "service PEs" on either side of a device peering with an MP-BGP
> route-reflector.  Specifically, as routes pass from MP-BGP to regular inet
> iBGP back into the opposite PE, it may be desirable to remove cluster and
> originator ID info.
> Derick
>
>
--0-236356033-1306514100=:40507-- From jakob.heitz@ericsson.com Fri May 27 10:17:38 2011 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 595FCE068D for ; Fri, 27 May 2011 10:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] 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 9FZ0xauvBM0m for ; Fri, 27 May 2011 10:17:37 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3BCE0675 for ; Fri, 27 May 2011 10:17:37 -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 p4RHHWuu018718; Fri, 27 May 2011 12:17:35 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 27 May 2011 13:17:31 -0400 From: Jakob Heitz To: Derick Winkworth , Pedro Marques Date: Fri, 27 May 2011 13:17:30 -0400 Subject: RE: draft-ietf-l3vpn-ibgp Thread-Topic: draft-ietf-l3vpn-ibgp Thread-Index: AcwcjBI66T0LKVeLRnC7bUf15/tKfQAAzIAw Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E406E3CAD@EUSAACMS0701.eamcs.ericsson.se> References: <325769.32976.qm@web161819.mail.bf1.yahoo.com> <431072.40507.qm@web161806.mail.bf1.yahoo.com> In-Reply-To: <431072.40507.qm@web161806.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7309FCBCAE981B43ABBE69B31C8D21390E406E3CADEUSAACMS0701e_" MIME-Version: 1.0 Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 17:17:38 -0000 --_000_7309FCBCAE981B43ABBE69B31C8D21390E406E3CADEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the cluster ID is the same (and the AS is the same), then it's the same cluster. If the AS is not the same, then the cluster list got removed on an ebgp hop. I'm confused. Can you draw a diagram? -- Jakob Heitz. ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of D= erick Winkworth Sent: Friday, May 27, 2011 9:35 AM To: Pedro Marques Cc: l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-ibgp Well, let me put it a different way. If you use the SP's global AS to peer via iBGP to a "CE" device and that ro= ute passes to another PE in the same provider AS, and that other PE VRF has= a different RD and route-targets, is it not a different route at that poin= t? I guess what I'm suggesting is that in the case of using the service-pr= ovider's AS in a PE-CE peering the passing of route-reflector info should b= e optional as it may be desirable to pass the route back into the same clus= ter but "originating" from the second PE with different RD/RT. I think this would actually be simpler than maintaining multiple clusters w= ith redundant RRs. Technically, a RR-client should not peer to more than o= ne cluster anyway. What if VRF "A" on a PE wants transitivity to VRF "B" on= the same PE through such a device? The route would pass from VRF "A" on PE1 into MP-BGP, through RR "A" to the= inside VRF PE, through the device, to the outside VRF PE, then to RR "B" (= if the cluster-id is the same on RRs "A" and "B" the route dies here), and = then back to the PE hopefully to be imported into VRF "B." The originator = ID would prevent this. ________________________________ From: Pedro Marques To: Derick Winkworth Cc: l3vpn@ietf.org Sent: Fri, May 27, 2011 11:10:27 AM Subject: Re: draft-ietf-l3vpn-ibgp Derick, Your email is rather vague in terms of the scenario that your are trying to address. You refer to service appliances such as firewall/nat. These are often deployed with a Hub & Spoke configuration in which spoke sites are not allowed to communicate directly and must traverse a Hub site. Hub & spoke configurations can be achieved by using 2 route target per VPN: an hub route target (exported by the hub site and imported by the spoke PEs) and a spoke RT (exported by the spoke sites and imported by the hub). There is no need to explicitly have the service appliance participate in routing in order to accomplish this. If you do wish the appliance to be an active component to the routing infrastructure that can also be achieved using two different VPNs (i.e. different route targets) for the "inside" and "outside" partition (these RTs can actually use the same customer as#). Using what is currently specified in this document it is possible to have a non BGP/MPLS VPN device be the Route Reflector between different clusters (such as an "inside" cluster and an "outside" cluster). These clusters have their routing information conveyed over a BGP/MPLS VPN. I'm not aware of any additional functionality required to make this happen other than what is already specified. BGP is a generic and flexible mechanism used in a very wide range of scenarios. With this document there is a standard to allow an iBGP cloud to use BGP/MPLS VPN as its internal connectivity. It maintains the same service model as iBGP over plain vanilla internal connectivity. I don't believe it would be useful to deviate from that. regards, Pedro. On Fri, May 27, 2011 at 8:36 AM, Derick Winkworth > wrote: > All: > I see no mention of peering to a CE device using the provider's global AS= . > I see potential use cases for this where a service-provider puts a non-M= PLS > aware device in between PEs. For instance, a firewall with an "inside VR= F" > and an "outside VRF." > The service-provider owns and manages this device. The device supports B= GP > and whatever service it is providing, routes are passed through it (eithe= r > PE to PE or the device itself reflects the routes from one PE to another)= . > This could be WAAS, IPS, firewall, a router performing NAT services, etc. > I think this possibility should be addressed as there are issues with the > "service PEs" on either side of a device peering with an MP-BGP > route-reflector. Specifically, as routes pass from MP-BGP to regular ine= t > iBGP back into the opposite PE, it may be desirable to remove cluster and > originator ID info. > Derick > > --_000_7309FCBCAE981B43ABBE69B31C8D21390E406E3CADEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
If the cluster ID is the s= ame (and=20 the AS is the same),
then it's the same=20 cluster.
If the AS is not the same,= then the=20 cluster list got removed
on an ebgp hop.
 
I'm confused.
Can=20 you draw a diagram?

--
Jakob Heitz.


From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Derick=20 Winkworth
Sent: Friday, May 27, 2011 9:35 AM
To: Pedr= o=20 Marques
Cc: l3vpn@ietf.org
Subject: Re:=20 draft-ietf-l3vpn-ibgp

Well, let me put it a different way.

If you use the SP's global AS to peer via iBGP to a "CE" device and = that=20 route passes to another PE in the same provider AS, and that other PE VRF= has=20 a different RD and route-targets, is it not a different route at that poi= nt?=20  I guess what I'm suggesting is that in the case of using the=20 service-provider's AS in a PE-CE peering the passing of route-reflector i= nfo=20 should be optional as it may be desirable to pass the route back into the= same=20 cluster but "originating" from the second PE with different RD/RT.

I think this would actually be simpler than maintaining multiple clu= sters=20 with redundant RRs.  Technically, a RR-client should not peer to mor= e=20 than one cluster anyway. What if VRF "A" on a PE wants transitivity to VR= F "B"=20 on the same PE through such a device?  

The route would pass from VRF "A" on PE1 into MP-BGP, through RR "A"= to=20 the inside VRF PE, through the device, to the outside VRF PE, then to RR = "B"=20 (if the cluster-id is the same on RRs "A" and "B" the route dies here), a= nd=20 then back to the PE hopefully to be imported into VRF "B."  The=20 originator ID would prevent this.




From: Pedro Marques=20 <pedro.r.marques@gmail.com>
To: Derick Winkworth=20 <ccie15672@yahoo.com>
Cc: l3vpn@ietf.org
Sent: Fri, May 27, 2011 11:10:27=20 AM
Subject: Re:=20 draft-ietf-l3vpn-ibgp

Derick,
Your email is rather vague= in=20 terms of the scenario that your are
trying to address. You refer to se= rvice=20 appliances such as
firewall/nat. These are often deployed with a Hub &= amp;=20 Spoke
configuration in which spoke sites are not allowed to=20 communicate
directly and must traverse a Hub site.

Hub & sp= oke=20 configurations can be achieved by using 2 route target per
VPN: an hub= =20 route target (exported by the hub site and imported by the
spoke PEs) = and a=20 spoke RT (exported by the spoke sites and imported by
the hub). There = is no=20 need to explicitly have the service appliance
participate in routing i= n=20 order to accomplish this.

If you do wish the appliance to be an ac= tive=20 component to the routing
infrastructure that can also be achieved usin= g two=20 different VPNs
(i.e. different route targets) for the "inside" and=20 "outside"
partition (these RTs can actually use the same customer=20 as#).

Using what is currently specified in this document it is pos= sible=20 to
have a non BGP/MPLS VPN device be the Route Reflector=20 between
different clusters (such as an "inside" cluster and an=20 "outside"
cluster). These clusters have their routing information conv= eyed=20 over
a BGP/MPLS VPN. I'm not aware of any additional functionality=20 required
to make this happen other than what is already=20 specified.

BGP is a generic and flexible mechanism used in a very = wide=20 range of
scenarios. With this document there is a standard to allow an= =20 iBGP
cloud to use BGP/MPLS VPN as its internal connectivity. It=20 maintains
the same service model as iBGP over plain vanilla=20 internal
connectivity. I don't believe it would be useful to deviate f= rom=20 that.

regards,
  Pedro.

On Fri, May 27, 2011 at 8:3= 6 AM,=20 Derick Winkworth <ccie15672@yahoo.com>=20 wrote:
> All:
> I see no mention of peering to a CE device us= ing=20 the provider's global AS.
>  I see potential use cases for thi= s=20 where a service-provider puts a non-MPLS
> aware device in between = PEs.=20  For instance, a firewall with an "inside VRF"
> and an "outsi= de=20 VRF."
> The service-provider owns and manages this device.  Th= e=20 device supports BGP
> and whatever service it is providing, routes = are=20 passed through it (either
> PE to PE or the device itself reflects = the=20 routes from one PE to another).
> This could be WAAS, IPS, firewall= , a=20 router performing NAT services, etc.
> I think this possibility sho= uld=20 be addressed as there are issues with the
> "service PEs" on either= side=20 of a device peering with an MP-BGP
> route-reflector.=20  Specifically, as routes pass from MP-BGP to regular inet
> iB= GP=20 back into the opposite PE, it may be desirable to remove cluster and
&= gt;=20 originator ID info.
> Derick
>
>
--_000_7309FCBCAE981B43ABBE69B31C8D21390E406E3CADEUSAACMS0701e_-- From pedro.r.marques@gmail.com Fri May 27 10:59:23 2011 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 A6835E07D5 for ; Fri, 27 May 2011 10:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] 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 p7Uv1iaVA-hy for ; Fri, 27 May 2011 10:59:20 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 998A8E066A for ; Fri, 27 May 2011 10:59:20 -0700 (PDT) Received: by iwn39 with SMTP id 39so2460829iwn.31 for ; Fri, 27 May 2011 10:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9V7VOutiICE6lQSVKPkceJSD8hIjsj5L1fIgNTpQzSk=; b=vsunSNu29wna9sBIYQEYqB5bdJHpLN/2wS7MSUoy6i+7M4YiqlPeCmfyJCivPWV+Ls GLpu+OhkxKbFwDHaTeYBQseOweCSKN/ugCgA07W0nAeI2qb+6+k32if8krHbt3MRq02r JqXuat1yCA1UQ9cAfRrzu7hR0vyDqDW4WyQUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VuSg9L71xs4SAeITRa5qRZRtZc++UVOJ0mOECfV5j3d0+ES0r9xD8Bu0LMM+SK4ODm 120D4A2PnXtLowhUNShGCp2oxxtI99OQ3f9jHnoT2cTBqpe4/l8MuGj03bjhzynZ0x+5 ZM5odI30pKh4KVBCY9v9+Ncxw4CzGzgmsvN6s= MIME-Version: 1.0 Received: by 10.42.134.129 with SMTP id l1mr3673736ict.73.1306519160235; Fri, 27 May 2011 10:59:20 -0700 (PDT) Received: by 10.42.164.8 with HTTP; Fri, 27 May 2011 10:59:20 -0700 (PDT) In-Reply-To: <431072.40507.qm@web161806.mail.bf1.yahoo.com> References: <325769.32976.qm@web161819.mail.bf1.yahoo.com> <431072.40507.qm@web161806.mail.bf1.yahoo.com> Date: Fri, 27 May 2011 10:59:20 -0700 Message-ID: Subject: Re: draft-ietf-l3vpn-ibgp From: Pedro Marques To: Derick Winkworth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 17:59:23 -0000 I'm not able to follow. Please see inline. On Fri, May 27, 2011 at 9:35 AM, Derick Winkworth wro= te: > Well, let me put it a different way. > If you use the SP's global AS to peer via iBGP to a "CE" device and that > route passes to another PE in the same provider AS, and that other PE VRF > has a different RD and route-targets, It is unclear which AS#s are involved in your scenario and whether the peering sessions are internal or external. > is it not a different route at that point? That sounds like one of those existential questions such as "what is the meaning of life ?". > =A0I guess what I'm suggesting is that in the case of using the > service-provider's AS in a PE-CE peering The draft in question is intended to allow the use of the customer AS is PE-CE peering. > the passing of route-reflector info > should be optional as it may be desirable to pass the route back into the > same cluster but "originating" from the second PE with different RD/RT. I'm not sure if you are referring to VPN route attributes or to the customer route attributes. > I think this would actually be simpler than maintaining multiple clusters > with redundant RRs. =A0Technically, a RR-client should not peer to more t= han > one cluster anyway. What if VRF "A" on a PE wants transitivity to VRF "B"= on > the same PE through such a device? I don't understand the issue you are trying to point out. It is unclear to me whether you are referring to the status quo before this document or the document support for extranets. The document does have a section on extranet support. I'm not aware of an issue with the mechanism. > The route would pass from VRF "A" on PE1 into MP-BGP, through RR "A" to t= he > inside VRF PE, through the device, to the outside VRF PE, then to RR "B" = (if > the cluster-id is the same on RRs "A" and "B" the route dies here), and t= hen > back to the PE hopefully to be imported into VRF "B." =A0The originator I= D > would prevent this. It may be preferable to describe a specific scenario that you are trying to validate. It would then be possible to evaluate that scenario against the current set of standards (minus this doc) and this proposal. Pedro. From ccie15672@yahoo.com Fri May 27 11:59:27 2011 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 CF653E0730 for ; Fri, 27 May 2011 11:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_40=-0.185, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] 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 58ZmUuS2sscR for ; Fri, 27 May 2011 11:59:27 -0700 (PDT) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) by ietfa.amsl.com (Postfix) with SMTP id D47FEE06A2 for ; Fri, 27 May 2011 11:59:26 -0700 (PDT) Received: from [98.139.212.153] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2011 18:59:23 -0000 Received: from [98.139.212.232] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2011 18:59:23 -0000 Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP; 27 May 2011 18:59:23 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 568805.53564.bm@omp1041.mail.bf1.yahoo.com Received: (qmail 41412 invoked by uid 60001); 27 May 2011 18:59:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306522763; bh=4pmbN+G028F/uzfQk+A1VyH2CrJy4mqWSlm7fao69ZI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=v5VxVKC+KwzjFDJvqAGIPnOrXBdQ5kVloUT4DSkwM3Qs3uy/kPSRS3NJhYmZXVTlMogxkt6J3CxzLhyN0L728kKQdKuc9YYSZv/M3i+uuzuyxpNfqWYVt0i1OE/jflOX/5A+mLsKcaHWmnbsMkWzeNwjre1pPW2o/xSsot1t5EM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=RtHNPUa43l3mfiXiPUfxTDIPsloBwjMXQ7Jt2cKQPQt/m7hv5o4pCmyVqQinKJ/jY6bv1ytHYZVkVSwYifuxVH4Chz/rueuNkEvRkmanZKBKsbCP8nYsMfQaINgYiN4gHsX8d/4fp8Wl2auJ2nxGF+8Ozi+WAOI2vCvvD4J8bOk=; Message-ID: <477385.37484.qm@web161812.mail.bf1.yahoo.com> X-YMail-OSG: IxG4eQ8VM1nU4WUanHKIRMTiKOqXVRreYRTGaVD9cj6Jq8m e7X5MBSPKRF.zoIBlBnAIACvbYDh4qXNubq_OLXGHXxfjVebFVTQpm.x9tLB hTbsF85sfVUdAUH.n07.ZvTc3l498Vaul.5jd.0F_qP3rx1Aj.ENmGtATwCG .TMcGSbJGTZ6Cz_D_.NODuHnUY_UNbQ69FyReONgaatlR9A2SWn6ow05VIbX Kk77O6L9c0SApPQBVcyjNf8nnWj5nJjNIcItngS5dOz3huVQdoyw7TWYjCNc 0mhhEN3HfU5DhKQJR8OI5nEfNL9kwHkOVBdyR4eaPvdb.bg8FbK8cCpwvW1Y gU.TMkUKaW8UPyaFQ.Mad7WAsfXwQr.FZxujncMzRL2qoc0YIEIBEvGVms5Y wWDgDLnxVi614T2Po.utKomm0FPskE_uOz7AS7HaaEoQZpOY5Do0YJA-- Received: from [76.194.43.66] by web161812.mail.bf1.yahoo.com via HTTP; Fri, 27 May 2011 11:59:23 PDT X-Mailer: YahooMailRC/567 YahooMailWebService/0.8.111.303096 References: <325769.32976.qm@web161819.mail.bf1.yahoo.com> <431072.40507.qm@web161806.mail.bf1.yahoo.com> Date: Fri, 27 May 2011 11:59:23 -0700 (PDT) From: Derick Winkworth Subject: Re: draft-ietf-l3vpn-ibgp To: l3vpn@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-760373910-1306522763=:37484" 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, 27 May 2011 18:59:27 -0000 --0-760373910-1306522763=:37484 Content-Type: text/plain; charset=us-ascii ############## The draft in question is intended to allow the use of the customer AS is PE-CE peering. ################ Ok, then my concern is not relevant to the draft. Nevertheless, I'll clarify with a diagram. I did this ascii diagram in courier new size 8... I hope the list-server doesn't mangle it. _______ /PE2 \ | ___ | | / \ | | | C | |--------\ | \___/ | \ \___|___/ \ | | _______ | | /PE1 \ ___|____ ___|____ | ___ | / \ / \ | / \ | | iBGP | | iBGP | | | A |-+---[10.1.1.0/24] | ipv4 | | vpn-v4 |-----| \___/ | | RR | | RR | | ___ | \________/ \________/ | / \ | | | | | B |-+---[10.2.2.0/24] | | | \___/ | ___|___ | \_______/ / _|_ \ / | / \ | / | | D | |--------/ | \___/ | | | \PE3____/ All depicted devices are using the same ASN. The "ipv4 RR" device is the firewall/IPS/WAAS etc. This device could be a pass-thru L2 device that does not actually run BGP. In that case the the "C" and "D" VRFs peer directly with each other. Either way, the problem is the same. 10.1.1.0/24 is learnt by PE1 in VRF "A" and this route is reflected via the "vpnv4 RR" to PE2 where VRF "C" imports it. The route is then advertised down to the "ipv4 RR" device via regular ipv4 iBGP. Again, the device is using the same ASN as the service-provider's global ASN. This route is then reflected down to VRF "D" on PE2. Here the route is exported to MP-BGP and reflected by the "vpn-v4 RR" back to PE1 where hopefully VRF "B" will import it. What I'm proposing is that in this scenario the transmission of cluster-list and originator ID info to the "ipv4 RR" device be optional. Actually exactly where this information gets stripped is irrelevant to me. It could be when VRF "C" imports the route from the global table of PE2. We are essentially converting the route from a VPNv4 route to an IPv4 route and then back again but with a different RD and route-targets. This is what I mean when I say that the route at this point is essentially a new route, and therefore the cluster-list and originator ID info that were attached to the route when it was reflected from PE1 to PE2 no longer applies or is relevant. --0-760373910-1306522763=:37484 Content-Type: text/html; charset=us-ascii
##############
The draft in question is intended to allow the use of the customer AS
is PE-CE peering.
################

Ok, then my concern is not relevant to the draft.  Nevertheless, I'll clarify with a diagram.  I did this ascii diagram in courier new size 8... I hope the list-server doesn't mangle it.

 _______
/PE2    \
|  ___  |
| /   \ |
| | C | |--------\
| \___/ |         \
\___|___/          \
    |              |           _______
    |              |          /PE1    \
 ___|____       ___|____      |  ___  |
/        \     /        \     | /   \ |
|  iBGP  |     |  iBGP  |     | | A |-+---[10.1.1.0/24]
|  ipv4  |     | vpn-v4 |-----| \___/ |
|   RR   |     |   RR   |     |  ___  |
\________/     \________/     | /   \ |
    |              |          | | B |-+---[10.2.2.0/24]
    |              |          | \___/ |
 ___|___           |          \_______/
/  _|_  \          /
| /   \ |         /
| | D | |--------/
| \___/ |
|       |
\PE3____/       



All depicted devices are using the same ASN.  The "ipv4 RR" device is the firewall/IPS/WAAS etc.  This device could be a pass-thru L2 device that does not actually run BGP.  In that case the the "C" and "D" VRFs peer directly with each other.  Either way, the problem is the same.

10.1.1.0/24 is learnt by PE1 in VRF "A" and this route is reflected via the "vpnv4 RR" to PE2 where VRF "C" imports it.  The route is then advertised down to the "ipv4 RR" device via regular ipv4 iBGP.   Again, the device is using the same ASN as the service-provider's global ASN.  

This route is then reflected down to VRF "D" on PE2.  Here the route is exported to MP-BGP and reflected by the "vpn-v4 RR" back to PE1 where hopefully VRF "B" will import it.



What I'm proposing is that in this scenario the transmission of cluster-list and originator ID info to the "ipv4 RR" device be optional.  Actually exactly where this information gets stripped is irrelevant to me.  It could be when VRF "C" imports the route from the global table of PE2.  

We are essentially converting the route from a VPNv4 route to an IPv4 route and then back again but with a different RD and route-targets.  This is what I mean when I say that the route at this point is essentially a new route, and therefore the cluster-list and originator ID info that were attached to the route when it was reflected from PE1 to PE2 no longer applies or is relevant.









--0-760373910-1306522763=:37484-- From pedro.r.marques@gmail.com Fri May 27 15:25:49 2011 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 B634DE0671 for ; Fri, 27 May 2011 15:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] 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 YxSMtQl3rgoR for ; Fri, 27 May 2011 15:25:48 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9398EE068D for ; Fri, 27 May 2011 15:25:48 -0700 (PDT) Received: by iyn15 with SMTP id 15so2741602iyn.31 for ; Fri, 27 May 2011 15:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=laO47A8CGS3a656VCiYqTM42nzP2dawQFumzn7hOjBQ=; b=ClmaM3Pyo91q9XkO+bxQY0wgIJyQv9KzCB5inJhtISSjn6vLWDvrvNFUeK8m3rcS1u oIAKqADAC7lLX2gaMmIS8IBVM/aaRKatgukoyKnewlS/mjI6UDnzBAYE27reHMLI4zQ+ oJa2QPz6Lrb5gnfkSSTsOBzq9YaDU+mxVBBe8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SNcafQ8pAiPqvfT1wjwqlPNulL2XHk8/mlKzLLoQnxxXduVLqRJXqgp3hJ2djVMF8n pL7WBORRZMuUS5QnPOfdmrfDRkS/17rT36K1W3ZLK1TSKeQgikIQGYnghgYwDH5cLghH D8XzUYJ/3+TeZx77/FoKZw9VyDJ464wxuHtRE= MIME-Version: 1.0 Received: by 10.42.135.65 with SMTP id o1mr666336ict.207.1306535147800; Fri, 27 May 2011 15:25:47 -0700 (PDT) Received: by 10.42.164.8 with HTTP; Fri, 27 May 2011 15:25:47 -0700 (PDT) In-Reply-To: <477385.37484.qm@web161812.mail.bf1.yahoo.com> References: <325769.32976.qm@web161819.mail.bf1.yahoo.com> <431072.40507.qm@web161806.mail.bf1.yahoo.com> <477385.37484.qm@web161812.mail.bf1.yahoo.com> Date: Fri, 27 May 2011 15:25:47 -0700 Message-ID: Subject: Re: draft-ietf-l3vpn-ibgp From: Pedro Marques To: Derick Winkworth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 22:25:49 -0000 Derick, The diagram came out just fine. Thanks for the effort you put in clarifying your scenario for us. The scenario you describe is traditionally referred to as Hub and Spoke. There are two variants: A. appliance does not participate in routing (most common since the network people wouldn't trust the secops guys to be involved in routing or vice-versa); B. the appliance does participate in routing. In scenario A, the typical configuration is: - define 2 RTs per customer: customer-spoke, customer-hub. - In VRF C, advertise a default route with the customer-hub RT. - Configure the service appliance to send all traffic from C to D. - In VRF D, import customer-spoke routes. - In VRF A, B import customer-hub routes and export customer-spoke. This is widely used and rather unrelated with the document being discussed. Lets go to scenario B. The difference to the scenario above is that instead of advertising a default route from VRF C, the box-in-the-middle is configured as an RR and advertises routing information between the 2 VRFs. Without this document, one can assume that the PE-CE peering is EBGP and that all IBGP attributes do get dropped, at the edges. The only drawback is that the AS used for the box-in-the-middle shows up again in the AS_PATH. With this document it is possible to have the box-in-the-middle be part of the customer AS. Since it would be configured as an RR, the cluster ID it imposes on routes would be maintained (a good thing in case of loops). But that would not in any way prevent this scenario from working. I hope that the text above is reasonably clear. Given the clarifications above do you have objections to the publication of this document ? thanks, Pedro. On Fri, May 27, 2011 at 11:59 AM, Derick Winkworth wr= ote: > ############## > The draft in question is intended to allow the use of the customer AS > is PE-CE peering. > ################ > > Ok, then my concern is not relevant to the draft. =A0Nevertheless, I'll > clarify with a diagram. =A0I did this ascii diagram in courier new size 8= ... I > hope the list-server doesn't mangle it. > =A0_______ > /PE2 =A0 =A0\ > | =A0___ =A0| > | / =A0 \ | > | | C | |--------\ > | \___/ | =A0 =A0 =A0 =A0 \ > \___|___/ =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 _______ > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0/PE1 =A0 =A0\ > =A0___|____ =A0 =A0 =A0 ___|____ =A0 =A0 =A0| =A0___ =A0| > / =A0 =A0 =A0 =A0\ =A0 =A0 / =A0 =A0 =A0 =A0\ =A0 =A0 | / =A0 \ | > | =A0iBGP =A0| =A0 =A0 | =A0iBGP =A0| =A0 =A0 | | A |-+---[10.1.1.0/24] > | =A0ipv4 =A0| =A0 =A0 | vpn-v4 |-----| \___/ | > | =A0 RR =A0 | =A0 =A0 | =A0 RR =A0 | =A0 =A0 | =A0___ =A0| > \________/ =A0 =A0 \________/ =A0 =A0 | / =A0 \ | > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0| | B |-+---[10= .2.2.0/24] > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0| \___/ | > =A0___|___ =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0\_______/ > / =A0_|_ =A0\ =A0 =A0 =A0 =A0 =A0/ > | / =A0 \ | =A0 =A0 =A0 =A0 / > | | D | |--------/ > | \___/ | > | =A0 =A0 =A0 | > \PE3____/ > > > All depicted devices are using the same ASN. =A0The "ipv4 RR" device is t= he > firewall/IPS/WAAS etc. =A0This device could be a pass-thru L2 device that= does > not actually run BGP. =A0In that case the the "C" and "D" VRFs peer direc= tly > with each other. =A0Either way, the problem is the same. > 10.1.1.0/24 is learnt by PE1 in VRF "A" and this route is reflected via t= he > "vpnv4 RR" to PE2 where VRF "C" imports it. =A0The route is then advertis= ed > down to the "ipv4 RR" device via regular ipv4 iBGP. =A0 Again, the device= is > using the same ASN as the service-provider's global ASN. > This route is then reflected down to VRF "D" on PE2. =A0Here the route is > exported to MP-BGP and reflected by the "vpn-v4 RR" back to PE1 where > hopefully VRF "B" will import it. > > > What I'm proposing is that in this scenario the transmission of cluster-l= ist > and originator ID info to the "ipv4 RR" device be optional. =A0Actually > exactly where this information gets stripped is irrelevant to me. =A0It c= ould > be when VRF "C" imports the route from the global table of PE2. > We are essentially converting the route from a VPNv4 route to an IPv4 rou= te > and then back again but with a different RD and route-targets. =A0This is= what > I mean when I say that the route at this point is essentially a new route= , > and therefore the cluster-list and originator ID info that were attached = to > the route when it was reflected from PE1 to PE2 no longer applies or is > relevant. > > > > > > > > > From ccie15672@yahoo.com Fri May 27 19:57:50 2011 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 B1B60E0618 for ; Fri, 27 May 2011 19:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[AWL=0.983, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] 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 9T8Pkca7nSqi for ; Fri, 27 May 2011 19:57:49 -0700 (PDT) Received: from nm29.bullet.mail.bf1.yahoo.com (nm29.bullet.mail.bf1.yahoo.com [98.139.212.188]) by ietfa.amsl.com (Postfix) with SMTP id 3502CE068C for ; Fri, 27 May 2011 19:57:49 -0700 (PDT) Received: from [98.139.212.151] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 28 May 2011 02:57:48 -0000 Received: from [98.139.212.246] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 28 May 2011 02:57:48 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 28 May 2011 02:57:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 675087.65936.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 13358 invoked by uid 60001); 28 May 2011 02:57:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306551468; bh=v4RMuoVISMqwy5YFFo4EYCcizx22claPd/WR13PBrJw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=BAa2YDhoCP+B8fU3sJmc7xOckm2k5rUGNZ8Ety1N/QpSEbOEKIQjgGuUuwfulNNFzYJUogttQ+LRkwe9Ow+cNWB6aRbH0ftu0djUfNXjNH8zbtsJd27JeqwJPUVvp09Xr731gdVCW6uxvU5UbX+OE5cEkE92GQkQzKiZw/37PN8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=aPYuJJ9Kchp6IrsNYg9FDaOIcm+kwD/6Nr0NTgQqpTHwxgF6Vl1Mi3/XpVFuPEPMLICCH7oRO0DAE5KGLGpcUehfYpIJwM+IVFtOegwB6EWUUCcemlUwc+IWa4lsQISj3BIJb8BDYj5QzcFwjG8oKmYClaE9AzY/6zytV0XL3nw=; Message-ID: <488700.12834.qm@web161812.mail.bf1.yahoo.com> X-YMail-OSG: fW.Ul2oVM1nu.3lQ3YxWNURvu4iGfvGBrJvnoKLONYZ7AA4 PMZpCL1KA7LR.UriQENno6h93pfYo1ubljk5ui7DSR_1Qx9R_mlqkeUkr1kC a9mOPwP8oNEdnlP33vWcqw6WFOlVLmPYQS3cklnXAZ0ZuinxUlbJEsGTcfDS M3vVTYMNlfPj5.A9xYLdDzgjikShc_bmQeXFJ5Ji93.71HFDpgz1XUAFYphQ XZmYNIKNaiHXMNpjD72K_f3c1Bnm.ljpTlaO4.cPCaDZvzmF_G2Ph2spDHE3 EO7Pu9JjcsFT_zwpMjjDH1WEqo6M6dLqeGaJjP6IlxPg2nqNXbYS6NJVuXN_ c1Cgeq0BbVVMDX8ZKKi6yH_QnLMMgZ9u7f4HQELziwdR7I_O4iCnAjvW40fE tLRx4ucSSs8wGFPlAwwlOM6ppVs6TPesFttvlMvTPjfbkB_I8vl1nLg-- Received: from [76.194.43.66] by web161812.mail.bf1.yahoo.com via HTTP; Fri, 27 May 2011 19:57:48 PDT X-Mailer: YahooMailRC/570 YahooMailWebService/0.8.111.303096 References: <325769.32976.qm@web161819.mail.bf1.yahoo.com> <431072.40507.qm@web161806.mail.bf1.yahoo.com> <477385.37484.qm@web161812.mail.bf1.yahoo.com> Date: Fri, 27 May 2011 19:57:48 -0700 (PDT) From: Derick Winkworth Subject: Re: draft-ietf-l3vpn-ibgp To: l3vpn@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-845716286-1306551468=:12834" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 02:57:50 -0000 --0-845716286-1306551468=:12834 Content-Type: text/plain; charset=us-ascii Pedro: I am OK with the document as it is. There are two ways to look at "iBGP between the PE and CE." One is as you describe it, using the Customer's AS. The other is using the service-provider's AS. The document in question only addresses the first variant. I am quite familiar with hub and spoke topologies. What I have drawn here looks similar, but its use is not the same. At any rate, I'd say the scenario I described is not relevant to to the document. It is, however, relevant to this working-group. In the scenario I described the device that is providing the service is owned by the service-provider and provides some function "in-the-cloud" and traffic is mapped to it via route-targets. We do this now in production without the route-reflector. We don't use eBGP because of the AS-PATH issue you describe. We really wish we could strip the cluster-list and originator ID before we export the route from the PE on the "other" side of the device (in the diagram I provided, before the route is exported to MP-BGP from VRF D on PE3). The fact of the matter is that even though its all the same AS, its a different route when it comes out of PE3 and should not have the vpnv4-RR info that was attached to it when the route propagated from PE1 to PE2. I also want to stress that there are cases where there is no intermediate device between PE2 and PE3 that can participate in BGP. For instance, a wide-area acceleration device, or an IPS, or a switch that port-mirrors traffic to a sniffer. In this case PE2 and PE3 peer directly with one another in VRFs "C" and "D." The issue is still the same. Another option is to not use BGP at all, but to redistribute into an IGP and then back again. However, I think we really would rather not do this and stick with BGP. We have an irrational attachment to BGP. :-) I got a little excited when I realized the document in question was out there because I thought I might be able to get some agreement on making the passing of the RR info optional when using iBGP and the service-provider's global AS... perhaps a separate proposal could be generated. Thanks for your time! Derick ________________________________ From: Pedro Marques To: Derick Winkworth Cc: l3vpn@ietf.org Sent: Fri, May 27, 2011 5:25:47 PM Subject: Re: draft-ietf-l3vpn-ibgp Derick, The diagram came out just fine. Thanks for the effort you put in clarifying your scenario for us. The scenario you describe is traditionally referred to as Hub and Spoke. There are two variants: A. appliance does not participate in routing (most common since the network people wouldn't trust the secops guys to be involved in routing or vice-versa); B. the appliance does participate in routing. In scenario A, the typical configuration is: - define 2 RTs per customer: customer-spoke, customer-hub. - In VRF C, advertise a default route with the customer-hub RT. - Configure the service appliance to send all traffic from C to D. - In VRF D, import customer-spoke routes. - In VRF A, B import customer-hub routes and export customer-spoke. This is widely used and rather unrelated with the document being discussed. Lets go to scenario B. The difference to the scenario above is that instead of advertising a default route from VRF C, the box-in-the-middle is configured as an RR and advertises routing information between the 2 VRFs. Without this document, one can assume that the PE-CE peering is EBGP and that all IBGP attributes do get dropped, at the edges. The only drawback is that the AS used for the box-in-the-middle shows up again in the AS_PATH. With this document it is possible to have the box-in-the-middle be part of the customer AS. Since it would be configured as an RR, the cluster ID it imposes on routes would be maintained (a good thing in case of loops). But that would not in any way prevent this scenario from working. I hope that the text above is reasonably clear. Given the clarifications above do you have objections to the publication of this document ? thanks, Pedro. On Fri, May 27, 2011 at 11:59 AM, Derick Winkworth wrote: > ############## > The draft in question is intended to allow the use of the customer AS > is PE-CE peering. > ################ > > Ok, then my concern is not relevant to the draft. Nevertheless, I'll > clarify with a diagram. I did this ascii diagram in courier new size 8... I > hope the list-server doesn't mangle it. > _______ > /PE2 \ > | ___ | > | / \ | > | | C | |--------\ > | \___/ | \ > \___|___/ \ > | | _______ > | | /PE1 \ > ___|____ ___|____ | ___ | > / \ / \ | / \ | > | iBGP | | iBGP | | | A |-+---[10.1.1.0/24] > | ipv4 | | vpn-v4 |-----| \___/ | > | RR | | RR | | ___ | > \________/ \________/ | / \ | > | | | | B |-+---[10.2.2.0/24] > | | | \___/ | > ___|___ | \_______/ > / _|_ \ / > | / \ | / > | | D | |--------/ > | \___/ | > | | > \PE3____/ > > > All depicted devices are using the same ASN. The "ipv4 RR" device is the > firewall/IPS/WAAS etc. This device could be a pass-thru L2 device that does > not actually run BGP. In that case the the "C" and "D" VRFs peer directly > with each other. Either way, the problem is the same. > 10.1.1.0/24 is learnt by PE1 in VRF "A" and this route is reflected via the > "vpnv4 RR" to PE2 where VRF "C" imports it. The route is then advertised > down to the "ipv4 RR" device via regular ipv4 iBGP. Again, the device is > using the same ASN as the service-provider's global ASN. > This route is then reflected down to VRF "D" on PE2. Here the route is > exported to MP-BGP and reflected by the "vpn-v4 RR" back to PE1 where > hopefully VRF "B" will import it. > > > What I'm proposing is that in this scenario the transmission of cluster-list > and originator ID info to the "ipv4 RR" device be optional. Actually > exactly where this information gets stripped is irrelevant to me. It could > be when VRF "C" imports the route from the global table of PE2. > We are essentially converting the route from a VPNv4 route to an IPv4 route > and then back again but with a different RD and route-targets. This is what > I mean when I say that the route at this point is essentially a new route, > and therefore the cluster-list and originator ID info that were attached to > the route when it was reflected from PE1 to PE2 no longer applies or is > relevant. > > > > > > > > > --0-845716286-1306551468=:12834 Content-Type: text/html; charset=us-ascii
Pedro:

I am OK with the document as it is.  There are two ways to look at "iBGP between the PE and CE."  One is as you describe it, using the Customer's AS.  The other is using the service-provider's AS.  The document in question only addresses the first variant.

I am quite familiar with hub and spoke topologies.  What I have drawn here looks similar, but its use is not the same.  At any rate, I'd say the scenario I described is not relevant to to the document.  It is, however, relevant to this working-group.

In the scenario I described the device that is providing the service is owned by the service-provider and provides some function "in-the-cloud" and traffic is mapped to it via route-targets. 

We do this now in production without the route-reflector.  We don't use eBGP because of the AS-PATH issue you describe.  We really wish we could strip the cluster-list and originator ID before we export the route from the PE on the "other" side of the device (in the diagram I provided, before the route is exported to MP-BGP from VRF D on PE3).  The fact of the matter is that even though its all the same AS, its a different route when it comes out of PE3 and should not have the vpnv4-RR info that was attached to it when the route propagated from PE1 to PE2. I also want to stress that there are cases where there is no intermediate device between PE2 and PE3 that can participate in BGP.  For instance, a wide-area acceleration device, or an IPS, or a switch that port-mirrors traffic to a sniffer.  In this case PE2 and PE3 peer directly with one another in VRFs "C" and "D."  The issue is still the same.

Another option is to not use BGP at all, but to redistribute into an IGP and then back again.  However, I think we really would rather not do this and stick with BGP. We have an irrational attachment to BGP. :-)

I got a little excited when I realized the document in question was out there because I thought I might be able to get some agreement on making the passing of the RR info optional when using iBGP and the service-provider's global AS...  perhaps a separate proposal could be generated.

Thanks for your time!

Derick


From: Pedro Marques <pedro.r.marques@gmail.com>
To: Derick Winkworth <ccie15672@yahoo.com>
Cc: l3vpn@ietf.org
Sent: Fri, May 27, 2011 5:25:47 PM
Subject: Re: draft-ietf-l3vpn-ibgp

Derick,
The diagram came out just fine. Thanks for the effort you put in
clarifying your scenario for us.

The scenario you describe is traditionally referred to as Hub and Spoke.

There are two variants:
  A. appliance does not participate in routing (most common since the
network people wouldn't trust the secops guys to be involved in
routing or vice-versa);
  B. the appliance does participate in routing.

In scenario A, the typical configuration is:
  - define 2 RTs per customer: customer-spoke, customer-hub.
  - In VRF C, advertise a default route with the customer-hub RT.
  - Configure the service appliance to send all traffic from C to D.
  - In VRF D, import customer-spoke routes.
  - In VRF A, B import customer-hub routes and export customer-spoke.

This is widely used and rather unrelated with the document being discussed.

Lets go to scenario B. The difference to the scenario above is that
instead of advertising a default route from VRF C, the
box-in-the-middle is configured as an RR and advertises routing
information between the 2 VRFs.

Without this document, one can assume that the PE-CE peering is EBGP
and that all IBGP attributes do get dropped, at the edges. The only
drawback is that the AS used for the box-in-the-middle shows up again
in the AS_PATH.

With this document it is possible to have the box-in-the-middle be
part of the customer AS. Since it would be configured as an RR, the
cluster ID it imposes on routes would be maintained (a good thing in
case of loops). But that would not in any way prevent this scenario
from working.

I hope that the text above is reasonably clear.

Given the clarifications above do you have objections to the
publication of this document ?

thanks,
  Pedro.

On Fri, May 27, 2011 at 11:59 AM, Derick Winkworth <ccie15672@yahoo.com> wrote:
> ##############
> The draft in question is intended to allow the use of the customer AS
> is PE-CE peering.
> ################
>
> Ok, then my concern is not relevant to the draft.  Nevertheless, I'll
> clarify with a diagram.  I did this ascii diagram in courier new size 8... I
> hope the list-server doesn't mangle it.
>  _______
> /PE2    \
> |  ___  |
> | /   \ |
> | | C | |--------\
> | \___/ |         \
> \___|___/          \
>     |              |           _______
>     |              |          /PE1    \
>  ___|____       ___|____      |  ___  |
> /        \     /        \     | /   \ |
> |  iBGP  |     |  iBGP  |     | | A |-+---[10.1.1.0/24]
> |  ipv4  |     | vpn-v4 |-----| \___/ |
> |   RR   |     |   RR   |     |  ___  |
> \________/     \________/     | /   \ |
>     |              |          | | B |-+---[10.2.2.0/24]
>     |              |          | \___/ |
>  ___|___           |          \_______/
> /  _|_  \          /
> | /   \ |         /
> | | D | |--------/
> | \___/ |
> |       |
> \PE3____/
>
>
> All depicted devices are using the same ASN.  The "ipv4 RR" device is the
> firewall/IPS/WAAS etc.  This device could be a pass-thru L2 device that does
> not actually run BGP.  In that case the the "C" and "D" VRFs peer directly
> with each other.  Either way, the problem is the same.
> 10.1.1.0/24 is learnt by PE1 in VRF "A" and this route is reflected via the
> "vpnv4 RR" to PE2 where VRF "C" imports it.  The route is then advertised
> down to the "ipv4 RR" device via regular ipv4 iBGP.   Again, the device is
> using the same ASN as the service-provider's global ASN.
> This route is then reflected down to VRF "D" on PE2.  Here the route is
> exported to MP-BGP and reflected by the "vpn-v4 RR" back to PE1 where
> hopefully VRF "B" will import it.
>
>
> What I'm proposing is that in this scenario the transmission of cluster-list
> and originator ID info to the "ipv4 RR" device be optional.  Actually
> exactly where this information gets stripped is irrelevant to me.  It could
> be when VRF "C" imports the route from the global table of PE2.
> We are essentially converting the route from a VPNv4 route to an IPv4 route
> and then back again but with a different RD and route-targets.  This is what
> I mean when I say that the route at this point is essentially a new route,
> and therefore the cluster-list and originator ID info that were attached to
> the route when it was reflected from PE1 to PE2 no longer applies or is
> relevant.
>
>
>
>
>
>
>
>
>
--0-845716286-1306551468=:12834-- From jakob.heitz@ericsson.com Fri May 27 20:36:41 2011 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 E522DE073F for ; Fri, 27 May 2011 20:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] 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 uO+fLN9ZtbMl for ; Fri, 27 May 2011 20:36:41 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 002EDE073C for ; Fri, 27 May 2011 20:36:40 -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 p4S3adH6032067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 May 2011 22:36:39 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 27 May 2011 23:36:38 -0400 From: Jakob Heitz To: Derick Winkworth , "l3vpn@ietf.org" Date: Fri, 27 May 2011 23:36:37 -0400 Subject: RE: draft-ietf-l3vpn-ibgp Thread-Topic: draft-ietf-l3vpn-ibgp Thread-Index: Acwc4w2u6Jjhs9nKSiiB5CTldM3TNwABM8NQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E406E3F4B@EUSAACMS0701.eamcs.ericsson.se> References: <325769.32976.qm@web161819.mail.bf1.yahoo.com> <431072.40507.qm@web161806.mail.bf1.yahoo.com> <477385.37484.qm@web161812.mail.bf1.yahoo.com> <488700.12834.qm@web161812.mail.bf1.yahoo.com> In-Reply-To: <488700.12834.qm@web161812.mail.bf1.yahoo.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: Sat, 28 May 2011 03:36:42 -0000 Derick, VRF B forwards a packet to 10.1.1.0, what path should the packet take? Does VRF D or VRF C need to see the packet at all?=20 --=20 Jakob Heitz. =20 ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of = Derick Winkworth Sent: Friday, May 27, 2011 7:58 PM To: l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-ibgp =09 =09 Pedro: I am OK with the document as it is. There are two ways to look at "iBGP b= etween the PE and CE." One is as you describe it, using the Customer's AS.= The other is using the service-provider's AS. The document in question o= nly addresses the first variant. I am quite familiar with hub and spoke topologies. What I have drawn here= looks similar, but its use is not the same. At any rate, I'd say the scen= ario I described is not relevant to to the document. It is, however, relev= ant to this working-group. In the scenario I described the device that is providing the service is ow= ned by the service-provider and provides some function "in-the-cloud" and t= raffic is mapped to it via route-targets.=20 We do this now in production without the route-reflector. We don't use eB= GP because of the AS-PATH issue you describe. We really wish we could stri= p the cluster-list and originator ID before we export the route from the PE= on the "other" side of the device (in the diagram I provided, before the r= oute is exported to MP-BGP from VRF D on PE3). The fact of the matter is t= hat even though its all the same AS, its a different route when it comes ou= t of PE3 and should not have the vpnv4-RR info that was attached to it when= the route propagated from PE1 to PE2. I also want to stress that there are= cases where there is no intermediate device between PE2 and PE3 that can p= articipate in BGP. For instance, a wide-area acceleration device, or an IP= S, or a switch that port-mirrors traffic to a sniffer. In this case PE2 an= d PE3 peer directly with one another in VRFs "C" and "D." The issue is sti= ll the same. Another option is to not use BGP at all, but to redistribute into an IGP a= nd then back again. However, I think we really would rather not do this an= d stick with BGP. We have an irrational attachment to BGP. :-) I got a little excited when I realized the document in question was out th= ere because I thought I might be able to get some agreement on making the p= assing of the RR info optional when using iBGP and the service-provider's g= lobal AS... perhaps a separate proposal could be generated. Thanks for your time! Derick ________________________________ From: Pedro Marques To: Derick Winkworth Cc: l3vpn@ietf.org Sent: Fri, May 27, 2011 5:25:47 PM Subject: Re: draft-ietf-l3vpn-ibgp =09 Derick, The diagram came out just fine. Thanks for the effort you put in clarifying your scenario for us. =09 The scenario you describe is traditionally referred to as Hub and Spoke. =09 There are two variants: A. appliance does not participate in routing (most common since the network people wouldn't trust the secops guys to be involved in routing or vice-versa); B. the appliance does participate in routing. =09 In scenario A, the typical configuration is: - define 2 RTs per customer: customer-spoke, customer-hub. - In VRF C, advertise a default route with the customer-hub RT. - Configure the service appliance to send all traffic from C to D. - In VRF D, import customer-spoke routes. - In VRF A, B import customer-hub routes and export customer-spoke. =09 This is widely used and rather unrelated with the document being discussed= . =09 Lets go to scenario B. The difference to the scenario above is that instead of advertising a default route from VRF C, the box-in-the-middle is configured as an RR and advertises routing information between the 2 VRFs. =09 Without this document, one can assume that the PE-CE peering is EBGP and that all IBGP attributes do get dropped, at the edges. The only drawback is that the AS used for the box-in-the-middle shows up again in the AS_PATH. =09 With this document it is possible to have the box-in-the-middle be part of the customer AS. Since it would be configured as an RR, the cluster ID it imposes on routes would be maintained (a good thing in case of loops). But that would not in any way prevent this scenario from working. =09 I hope that the text above is reasonably clear. =09 Given the clarifications above do you have objections to the publication of this document ? =09 thanks, Pedro. =09 On Fri, May 27, 2011 at 11:59 AM, Derick Winkworth w= rote: > ############## > The draft in question is intended to allow the use of the customer AS > is PE-CE peering. > ################ > > Ok, then my concern is not relevant to the draft. Nevertheless, I'll > clarify with a diagram. I did this ascii diagram in courier new size 8.= .. I > hope the list-server doesn't mangle it. > _______ > /PE2 \ > | ___ | > | / \ | > | | C | |--------\ > | \___/ | \ > \___|___/ \ > | | _______ > | | /PE1 \ > ___|____ ___|____ | ___ | > / \ / \ | / \ | > | iBGP | | iBGP | | | A |-+---[10.1.1.0/24] > | ipv4 | | vpn-v4 |-----| \___/ | > | RR | | RR | | ___ | > \________/ \________/ | / \ | > | | | | B |-+---[10.2.2.0/24] > | | | \___/ | > ___|___ | \_______/ > / _|_ \ / > | / \ | / > | | D | |--------/ > | \___/ | > | | > \PE3____/ > > > All depicted devices are using the same ASN. The "ipv4 RR" device is th= e > firewall/IPS/WAAS etc. This device could be a pass-thru L2 device that = does > not actually run BGP. In that case the the "C" and "D" VRFs peer direct= ly > with each other. Either way, the problem is the same. > 10.1.1.0/24 is learnt by PE1 in VRF "A" and this route is reflected via = the > "vpnv4 RR" to PE2 where VRF "C" imports it. The route is then advertise= d > down to the "ipv4 RR" device via regular ipv4 iBGP. Again, the device = is > using the same ASN as the service-provider's global ASN. > This route is then reflected down to VRF "D" on PE2. Here the route is > exported to MP-BGP and reflected by the "vpn-v4 RR" back to PE1 where > hopefully VRF "B" will import it. > > > What I'm proposing is that in this scenario the transmission of cluster-= list > and originator ID info to the "ipv4 RR" device be optional. Actually > exactly where this information gets stripped is irrelevant to me. It co= uld > be when VRF "C" imports the route from the global table of PE2. > We are essentially converting the route from a VPNv4 route to an IPv4 ro= ute > and then back again but with a different RD and route-targets. This is = what > I mean when I say that the route at this point is essentially a new rout= e, > and therefore the cluster-list and originator ID info that were attached= to > the route when it was reflected from PE1 to PE2 no longer applies or is > relevant. > > > > > > > > > =09 From ccie15672@yahoo.com Fri May 27 21:13:36 2011 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 E37A1E06F0 for ; Fri, 27 May 2011 21:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.062 X-Spam-Level: X-Spam-Status: No, score=-1.062 tagged_above=-999 required=5 tests=[AWL=0.737, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] 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 ukU9HoPK8Fss for ; Fri, 27 May 2011 21:13:35 -0700 (PDT) Received: from nm11.bullet.mail.bf1.yahoo.com (nm11.bullet.mail.bf1.yahoo.com [98.139.212.170]) by ietfa.amsl.com (Postfix) with SMTP id 58E13E0618 for ; Fri, 27 May 2011 21:13:35 -0700 (PDT) Received: from [98.139.212.152] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 28 May 2011 04:13:34 -0000 Received: from [98.139.212.207] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 28 May 2011 04:13:34 -0000 Received: from [127.0.0.1] by omp1016.mail.bf1.yahoo.com with NNFMP; 28 May 2011 04:13:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 805482.59422.bm@omp1016.mail.bf1.yahoo.com Received: (qmail 43465 invoked by uid 60001); 28 May 2011 04:13:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306556014; bh=oo+AQQm3nfc3Z2MQmm7xGCtKmTGH9K9R0gZrcUtfmrU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LoqXLDgf34Dc8WSadTwl9Us4aN1C1iOW2fv6sWPxe1wbj0asByZV0myh/GqnHjCyRfYe9t7JRkJ6k4zpoePOZez1Too9pbTIgyKP7xz9emrThRJ3QCkJoUYAX4G43qzdGTHeVUYu3aLiu+4YboGcSigOvjrcMJqmwjjQkCfQWas= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=6g2P4ddqp8nwiCoQBQGDB/D+3RnsogafrlZLh7rxVVNlKRL9YYbOJsZhhQPh5ttpWqEEj303Yfwmr1xt+ebAhHL3DI6oOwucJwHe7CqjyiadG1y+oSVDRrh2AGgm6SZz3lUi5ddHqTk3/JXApcmWtpUdSObW28mAgLOPl/flub8=; Message-ID: <704434.3735.qm@web161815.mail.bf1.yahoo.com> X-YMail-OSG: WsvYx7gVM1lJgeYn04xeU98DEQzMWaGPn4spBSgAWphiqW0 q0ZYN1kWbMJokS6sGV_ntO9uNKxG0DUUEQVawZuRpc2oDOI4hQg.RL.M9CnA USNC_4bb3UByc04nbGonighotXhV1mxcAsNzWAttRb5H.ZSm8FowMA.OTP34 XHMCcpbVptrV2rZ5N3ezkNYqbhDV6WRXrwOy19yCEZg6q7mqFRd_l77tk7rv fVRvKg4y0.gg5LlT6YFneFSkQHYb.ejK359BtW1xuiHlIWPfP4MBbUO23yOh sAG4HmQbn_Jtnamd3PuQeL_j4mO0gd7TdNV3drRWgczT2428r_WyDERbMFF6 6fRbiuOLK_lZv9GFXr9zCO2MFA5M.OafHHpdoGpSmg_s2OePfvK5AagEf27k 5F2ZhBhx8nLjqea_2JSCEGxfun67iYQ6eDgNnfXLstPTFdIM6L4CdIQs- Received: from [76.194.43.66] by web161815.mail.bf1.yahoo.com via HTTP; Fri, 27 May 2011 21:13:34 PDT X-Mailer: YahooMailRC/570 YahooMailWebService/0.8.111.303096 References: <325769.32976.qm@web161819.mail.bf1.yahoo.com> <431072.40507.qm@web161806.mail.bf1.yahoo.com> <477385.37484.qm@web161812.mail.bf1.yahoo.com> <488700.12834.qm@web161812.mail.bf1.yahoo.com> <7309FCBCAE981B43ABBE69B31C8D21390E406E3F4B@EUSAACMS0701.eamcs.ericsson.se> Date: Fri, 27 May 2011 21:13:34 -0700 (PDT) From: Derick Winkworth Subject: Re: draft-ietf-l3vpn-ibgp To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E406E3F4B@EUSAACMS0701.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1921710267-1306556014=:3735" 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: Sat, 28 May 2011 04:13:37 -0000 --0-1921710267-1306556014=:3735 Content-Type: text/plain; charset=us-ascii The packet would travel to PE3, out of VRF "D" up through the device, into VRF "C"... ________________________________ From: Jakob Heitz To: Derick Winkworth ; "l3vpn@ietf.org" Sent: Fri, May 27, 2011 10:36:37 PM Subject: RE: draft-ietf-l3vpn-ibgp Derick, VRF B forwards a packet to 10.1.1.0, what path should the packet take? Does VRF D or VRF C need to see the packet at all? -- Jakob Heitz. ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Derick Winkworth Sent: Friday, May 27, 2011 7:58 PM To: l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-ibgp Pedro: I am OK with the document as it is. There are two ways to look at "iBGP between the PE and CE." One is as you describe it, using the Customer's AS. The other is using the service-provider's AS. The document in question only addresses the first variant. I am quite familiar with hub and spoke topologies. What I have drawn here looks similar, but its use is not the same. At any rate, I'd say the scenario I described is not relevant to to the document. It is, however, relevant to this working-group. In the scenario I described the device that is providing the service is owned by the service-provider and provides some function "in-the-cloud" and traffic is mapped to it via route-targets. We do this now in production without the route-reflector. We don't use eBGP because of the AS-PATH issue you describe. We really wish we could strip the cluster-list and originator ID before we export the route from the PE on the "other" side of the device (in the diagram I provided, before the route is exported to MP-BGP from VRF D on PE3). The fact of the matter is that even though its all the same AS, its a different route when it comes out of PE3 and should not have the vpnv4-RR info that was attached to it when the route propagated from PE1 to PE2. I also want to stress that there are cases where there is no intermediate device between PE2 and PE3 that can participate in BGP. For instance, a wide-area acceleration device, or an IPS, or a switch that port-mirrors traffic to a sniffer. In this case PE2 and PE3 peer directly with one another in VRFs "C" and "D." The issue is still the same. Another option is to not use BGP at all, but to redistribute into an IGP and then back again. However, I think we really would rather not do this and stick with BGP. We have an irrational attachment to BGP. :-) I got a little excited when I realized the document in question was out there because I thought I might be able to get some agreement on making the passing of the RR info optional when using iBGP and the service-provider's global AS... perhaps a separate proposal could be generated. Thanks for your time! Derick ________________________________ From: Pedro Marques To: Derick Winkworth Cc: l3vpn@ietf.org Sent: Fri, May 27, 2011 5:25:47 PM Subject: Re: draft-ietf-l3vpn-ibgp Derick, The diagram came out just fine. Thanks for the effort you put in clarifying your scenario for us. The scenario you describe is traditionally referred to as Hub and Spoke. There are two variants: A. appliance does not participate in routing (most common since the network people wouldn't trust the secops guys to be involved in routing or vice-versa); B. the appliance does participate in routing. In scenario A, the typical configuration is: - define 2 RTs per customer: customer-spoke, customer-hub. - In VRF C, advertise a default route with the customer-hub RT. - Configure the service appliance to send all traffic from C to D. - In VRF D, import customer-spoke routes. - In VRF A, B import customer-hub routes and export customer-spoke. This is widely used and rather unrelated with the document being discussed. Lets go to scenario B. The difference to the scenario above is that instead of advertising a default route from VRF C, the box-in-the-middle is configured as an RR and advertises routing information between the 2 VRFs. Without this document, one can assume that the PE-CE peering is EBGP and that all IBGP attributes do get dropped, at the edges. The only drawback is that the AS used for the box-in-the-middle shows up again in the AS_PATH. With this document it is possible to have the box-in-the-middle be part of the customer AS. Since it would be configured as an RR, the cluster ID it imposes on routes would be maintained (a good thing in case of loops). But that would not in any way prevent this scenario from working. I hope that the text above is reasonably clear. Given the clarifications above do you have objections to the publication of this document ? thanks, Pedro. On Fri, May 27, 2011 at 11:59 AM, Derick Winkworth wrote: > ############## > The draft in question is intended to allow the use of the customer AS > is PE-CE peering. > ################ > > Ok, then my concern is not relevant to the draft. Nevertheless, I'll > clarify with a diagram. I did this ascii diagram in courier new size 8... I > hope the list-server doesn't mangle it. > _______ > /PE2 \ > | ___ | > | / \ | > | | C | |--------\ > | \___/ | \ > \___|___/ \ > | | _______ > | | /PE1 \ > ___|____ ___|____ | ___ | > / \ / \ | / \ | > | iBGP | | iBGP | | | A |-+---[10.1.1.0/24] > | ipv4 | | vpn-v4 |-----| \___/ | > | RR | | RR | | ___ | > \________/ \________/ | / \ | > | | | | B |-+---[10.2.2.0/24] > | | | \___/ | > ___|___ | \_______/ > / _|_ \ / > | / \ | / > | | D | |--------/ > | \___/ | > | | > \PE3____/ > > > All depicted devices are using the same ASN. The "ipv4 RR" device is the > firewall/IPS/WAAS etc. This device could be a pass-thru L2 device that does > not actually run BGP. In that case the the "C" and "D" VRFs peer directly > with each other. Either way, the problem is the same. > 10.1.1.0/24 is learnt by PE1 in VRF "A" and this route is reflected via the > "vpnv4 RR" to PE2 where VRF "C" imports it. The route is then advertised > down to the "ipv4 RR" device via regular ipv4 iBGP. Again, the device is > using the same ASN as the service-provider's global ASN. > This route is then reflected down to VRF "D" on PE2. Here the route is > exported to MP-BGP and reflected by the "vpn-v4 RR" back to PE1 where > hopefully VRF "B" will import it. > > > What I'm proposing is that in this scenario the transmission of cluster-list > and originator ID info to the "ipv4 RR" device be optional. Actually > exactly where this information gets stripped is irrelevant to me. It could > be when VRF "C" imports the route from the global table of PE2. > We are essentially converting the route from a VPNv4 route to an IPv4 route > and then back again but with a different RD and route-targets. This is what > I mean when I say that the route at this point is essentially a new route, > and therefore the cluster-list and originator ID info that were attached to > the route when it was reflected from PE1 to PE2 no longer applies or is > relevant. > > > > > > > > > --0-1921710267-1306556014=:3735 Content-Type: text/html; charset=us-ascii
The packet would travel to PE3, out of VRF "D" up through the device, into VRF "C"...


From: Jakob Heitz <jakob.heitz@ericsson.com>
To: Derick Winkworth <ccie15672@yahoo.com>; "l3vpn@ietf.org" <l3vpn@ietf.org>
Sent: Fri, May 27, 2011 10:36:37 PM
Subject: RE: draft-ietf-l3vpn-ibgp

Derick,

VRF B forwards a packet to 10.1.1.0, what path should the packet take?
Does VRF D or VRF C need to see the packet at all?

--
Jakob Heitz.




________________________________

    From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Derick Winkworth
    Sent: Friday, May 27, 2011 7:58 PM
    To: l3vpn@ietf.org
    Subject: Re: draft-ietf-l3vpn-ibgp
   
   
    Pedro:

    I am OK with the document as it is.  There are two ways to look at "iBGP between the PE and CE."  One is as you describe it, using the Customer's AS.  The other is using the service-provider's AS.  The document in question only addresses the first variant.

    I am quite familiar with hub and spoke topologies.  What I have drawn here looks similar, but its use is not the same.  At any rate, I'd say the scenario I described is not relevant to to the document.  It is, however, relevant to this working-group.

    In the scenario I described the device that is providing the service is owned by the service-provider and provides some function "in-the-cloud" and traffic is mapped to it via route-targets.

    We do this now in production without the route-reflector.  We don't use eBGP because of the AS-PATH issue you describe.  We really wish we could strip the cluster-list and originator ID before we export the route from the PE on the "other" side of the device (in the diagram I provided, before the route is exported to MP-BGP from VRF D on PE3).  The fact of the matter is that even though its all the same AS, its a different route when it comes out of PE3 and should not have the vpnv4-RR info that was attached to it when the route propagated from PE1 to PE2. I also want to stress that there are cases where there is no intermediate device between PE2 and PE3 that can participate in BGP.  For instance, a wide-area acceleration device, or an IPS, or a switch that port-mirrors traffic to a sniffer.  In this case PE2 and PE3 peer directly with one another in VRFs "C" and "D."  The issue is still the same.

    Another option is to not use BGP at all, but to redistribute into an IGP and then back again.  However, I think we really would rather not do this and stick with BGP. We have an irrational attachment to BGP. :-)

    I got a little excited when I realized the document in question was out there because I thought I might be able to get some agreement on making the passing of the RR info optional when using iBGP and the service-provider's global AS...  perhaps a separate proposal could be generated.

    Thanks for your time!

    Derick


    ________________________________

    From: Pedro Marques <pedro.r.marques@gmail.com>
    To: Derick Winkworth <ccie15672@yahoo.com>
    Cc: l3vpn@ietf.org
    Sent: Fri, May 27, 2011 5:25:47 PM
    Subject: Re: draft-ietf-l3vpn-ibgp
   
    Derick,
    The diagram came out just fine. Thanks for the effort you put in
    clarifying your scenario for us.
   
    The scenario you describe is traditionally referred to as Hub and Spoke.
   
    There are two variants:
      A. appliance does not participate in routing (most common since the
    network people wouldn't trust the secops guys to be involved in
    routing or vice-versa);
      B. the appliance does participate in routing.
   
    In scenario A, the typical configuration is:
      - define 2 RTs per customer: customer-spoke, customer-hub.
      - In VRF C, advertise a default route with the customer-hub RT.
      - Configure the service appliance to send all traffic from C to D.
      - In VRF D, import customer-spoke routes.
      - In VRF A, B import customer-hub routes and export customer-spoke.
   
    This is widely used and rather unrelated with the document being discussed.
   
    Lets go to scenario B. The difference to the scenario above is that
    instead of advertising a default route from VRF C, the
    box-in-the-middle is configured as an RR and advertises routing
    information between the 2 VRFs.
   
    Without this document, one can assume that the PE-CE peering is EBGP
    and that all IBGP attributes do get dropped, at the edges. The only
    drawback is that the AS used for the box-in-the-middle shows up again
    in the AS_PATH.
   
    With this document it is possible to have the box-in-the-middle be
    part of the customer AS. Since it would be configured as an RR, the
    cluster ID it imposes on routes would be maintained (a good thing in
    case of loops). But that would not in any way prevent this scenario
    from working.
   
    I hope that the text above is reasonably clear.
   
    Given the clarifications above do you have objections to the
    publication of this document ?
   
    thanks,
      Pedro.
   
    On Fri, May 27, 2011 at 11:59 AM, Derick Winkworth <ccie15672@yahoo.com> wrote:
    > ##############
    > The draft in question is intended to allow the use of the customer AS
    > is PE-CE peering.
    > ################
    >
    > Ok, then my concern is not relevant to the draft.  Nevertheless, I'll
    > clarify with a diagram.  I did this ascii diagram in courier new size 8... I
    > hope the list-server doesn't mangle it.
    >  _______
    > /PE2    \
    > |  ___  |
    > | /  \ |
    > | | C | |--------\
    > | \___/ |        \
    > \___|___/          \
    >    |              |          _______
    >    |              |          /PE1    \
    >  ___|____      ___|____      |  ___  |
    > /        \    /        \    | /  \ |
    > |  iBGP  |    |  iBGP  |    | | A |-+---[10.1.1.0/24]
    > |  ipv4  |    | vpn-v4 |-----| \___/ |
    > |  RR  |    |  RR  |    |  ___  |
    > \________/    \________/    | /  \ |
    >    |              |          | | B |-+---[10.2.2.0/24]
    >    |              |          | \___/ |
    >  ___|___          |          \_______/
    > /  _|_  \          /
    > | /  \ |        /
    > | | D | |--------/
    > | \___/ |
    > |      |
    > \PE3____/
    >
    >
    > All depicted devices are using the same ASN.  The "ipv4 RR" device is the
    > firewall/IPS/WAAS etc.  This device could be a pass-thru L2 device that does
    > not actually run BGP.  In that case the the "C" and "D" VRFs peer directly
    > with each other.  Either way, the problem is the same.
    > 10.1.1.0/24 is learnt by PE1 in VRF "A" and this route is reflected via the
    > "vpnv4 RR" to PE2 where VRF "C" imports it.  The route is then advertised
    > down to the "ipv4 RR" device via regular ipv4 iBGP.  Again, the device is
    > using the same ASN as the service-provider's global ASN.
    > This route is then reflected down to VRF "D" on PE2.  Here the route is
    > exported to MP-BGP and reflected by the "vpn-v4 RR" back to PE1 where
    > hopefully VRF "B" will import it.
    >
    >
    > What I'm proposing is that in this scenario the transmission of cluster-list
    > and originator ID info to the "ipv4 RR" device be optional.  Actually
    > exactly where this information gets stripped is irrelevant to me.  It could
    > be when VRF "C" imports the route from the global table of PE2.
    > We are essentially converting the route from a VPNv4 route to an IPv4 route
    > and then back again but with a different RD and route-targets.  This is what
    > I mean when I say that the route at this point is essentially a new route,
    > and therefore the cluster-list and originator ID info that were attached to
    > the route when it was reflected from PE1 to PE2 no longer applies or is
    > relevant.
    >
    >
    >
    >
    >
    >
    >
    >
    >
   

--0-1921710267-1306556014=:3735-- From ben@niven-jenkins.co.uk Fri May 27 23:31:29 2011 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 33B77E06BD for ; Fri, 27 May 2011 23:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.824 X-Spam-Level: X-Spam-Status: No, score=-103.824 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 q4oYfaoABLT4 for ; Fri, 27 May 2011 23:31:28 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1E720E06AF for ; Fri, 27 May 2011 23:31:27 -0700 (PDT) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.2]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QQD3Y-0006df-24 for l3vpn@ietf.org; Sat, 28 May 2011 07:31:28 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: WG Last Call for draft-ietf-l3vpn-mvpn-infra-addrs-04 From: Ben Niven-Jenkins In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF60CAC0F910B@EUSAACMS0701.eamcs.ericsson.se> Date: Sat, 28 May 2011 07:31:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <584CF5BA-FE66-4103-8B21-A83B3BCFFFA1@niven-jenkins.co.uk> <0ED867EB33AB2B45AAB470D5A64CDBF60CAC0F910B@EUSAACMS0701.eamcs.ericsson.se> To: L3VPN WG mailing list X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 06:31:29 -0000 L3VPNers, This Last Call has now ended and no objections to the changes were made. Ben > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of Ben Niven-Jenkins > Sent: Wednesday, May 11, 2011 15:35 > To: L3VPN WG mailing list > Cc: l3vpn-chairs@tools.ietf.org; = draft-ietf-l3vpn-mvpn-infra-addrs@tools.ietf.org > Subject: WG Last Call for draft-ietf-l3vpn-mvpn-infra-addrs-04 >=20 > Colleagues, >=20 > Back in December we forwarded draft-ietf-l3vpn-mvpn-infra-addrs-02 to = the IESG for publication. >=20 > Following IESG evaluation a number of small changes were made to the = document and it was felt that they required a further WG Last Call to = give the group a chance to comment on those changes before progressing = the document further. >=20 > Therefore this e-mail starts a 2 week WG Last Call for = draft-ietf-l3vpn-mvpn-infra-addrs-04. >=20 > http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-infra-addrs-04 >=20 > The scope of the WG Last Call is limited to the changes changes = between the -02 and -04 versions, which can be seen here: >=20 > http://goo.gl/IuZNn [ietf.org] >=20 > and can be summarised as: > - The document now "officially" updates = draft-ietf-l3vpn-2547bis-mcast-bgp. >=20 > - The previous version suggested erroneously that the "VRF Route = Import > Extended Community" is an attribute of an MVPN route, when actually it = is > an attribute of a unicast route. To correct this, some changes were = made > to the title, the abstract, and section 1.3. Also, the VRF Route = Import > Extended Community is now discussed in its own section, instead of in = the > section on MVPN routes. >=20 > - A new IANA action was added, requesting the assignment of a = codepoint for > "VRF Route Import" in the "IPv6 address specific extended community" > registry. >=20 > Feedback should be provided to the mailing list and/or the authors. >=20 > The Last Call ends midnight PDT 25th May 2011. >=20 > Thanks > Ben >=20 From jsmith4112003@yahoo.co.uk Mon May 30 15:57:51 2011 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 57F62E0754 for ; Mon, 30 May 2011 15:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 ta7nA3bo271I for ; Mon, 30 May 2011 15:57:50 -0700 (PDT) Received: from nm18.bullet.mail.ukl.yahoo.com (nm18.bullet.mail.ukl.yahoo.com [217.146.183.192]) by ietfa.amsl.com (Postfix) with SMTP id C2CECE0740 for ; Mon, 30 May 2011 15:57:49 -0700 (PDT) Received: from [217.146.183.217] by nm18.bullet.mail.ukl.yahoo.com with NNFMP; 30 May 2011 22:57:46 -0000 Received: from [217.146.183.74] by tm10.bullet.mail.ukl.yahoo.com with NNFMP; 30 May 2011 22:57:46 -0000 Received: from [127.0.0.1] by omp1035.mail.ukl.yahoo.com with NNFMP; 30 May 2011 22:57:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 31267.63652.bm@omp1035.mail.ukl.yahoo.com Received: (qmail 62996 invoked by uid 60001); 30 May 2011 22:57:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1306796265; bh=0lWMuyNZABOUTsUeL5U04ZPaSyz5eK+yFZA1YEvM05Y=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cLNS5qPfwJVVMR3ZpznEvQ5+JuJMhsfesNKBESja4SJvtfrYvrGcsGCKzBvhBimcDuNrV+3NdPjdZd1b/xymalROlg1mGYxwWIJdQZZgFcDzRFIf0gVy33uqXY1XdR47qZrJmQcgh1snff8EnJBBwW/zLOXvXXgutHKHD+BBgj8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OnwfauXpNT+55rHSm/Mbm9x0Z1Mxt7LKjc/lbmTJoWIvVUNI0gXPNmr0b4Dm2E0ILgEQOX8QUcTremObbIi5zEKzLK96dj2Mvqhi1gUAiKIWCNHAUF3NfLXpjxCpzeksd60mvD78Ldums0k9/XhxNAjZMVtqC3myzU08p9ZhOwo=; Message-ID: <917871.15418.qm@web27201.mail.ukl.yahoo.com> X-YMail-OSG: rPQv2DkVM1ldbh_U0XXpkrU0sMAYClS2jfK7qtt8KQ2aBye duLuvUHmV.8fGESgcPaJ3Ic8Hxp.ERvz.IMAEsE4Ud1TS.Iv.NyvJCuBCUZV 0uhaZW7eEAZUftZMYF9U1TFg9ARSPISoPeZ1eVpOronjlDcszlmO1mFR5aU4 LT8rYjZA7unUA.U4Dl94wsNgOb7.SEBo9pQ5OYC4KcHXKdMbb9lP6L7lptxH olaueG8g._XEEp629_Hk5tM0PS6WGFGNf71NmKAm08J4nITWvkPpCevxu1oC y7wTvtXhTbKBJxENaDozL9D5cBNc3zJ6Qpjqp7B7cU60blxlqyags70j2hsY 5S4RwTVK8.ZKHyX.SOStbRENJ5XSR6Q-- Received: from [122.178.221.84] by web27201.mail.ukl.yahoo.com via HTTP; Mon, 30 May 2011 23:57:45 BST X-Mailer: YahooMailRC/570 YahooMailWebService/0.8.111.303096 Date: Mon, 30 May 2011 23:57:45 +0100 (BST) From: John Smith Subject: Different TTLs To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 30 May 2011 22:57:51 -0000 Hi,=0A=0AI would like to understand the relation between the TTL carried in= the BGP label =0Aand the IP payload in the L3 VPN scenarios. As per my und= erstanding it will =0Aalways be the same as IP TTL. Is there any scenario w= hen it will be different =0Afrom the IP TTL. I understand that there are di= fferent models for carrying the =0Atransport TTL. In one model the IP TTL i= s copied to the transport label, which =0Ais reduced by each P hop and is f= inally copied back to the IP TTL field at the =0Aegress PE router. In this = case the IP TTL gets decremented by as many hops as =0Aexist in the service= provider network. In another, the TTL of the transport =0Alabel is kept as= 255 and is decremented at each hop. The IP TTL is preserved and =0Athe cus= tomer is oblivious to the service provider topology.=0A=0AIs my understandi= ng of the two models correct?=0A=0ANow, my question is what do we do about = the TTL carried in the second label (the =0ABGP label)? Should it be kept a= s 255 or should we copy the IP TTL. Whats the use =0Aof setting any TTL the= re as this label is never exposed (unless someone is using =0Aimplicit null= at the egress that is).=0A=0AThanks, John From iesg-secretary@ietf.org Tue May 31 06:29:34 2011 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 D44C9E081F; Tue, 31 May 2011 06:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 uaz6WbLzmXWk; Tue, 31 May 2011 06:29:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F63E0729; Tue, 31 May 2011 06:29:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110531132930.28269.31380.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2011 06:29:30 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 13:29:35 -0000 The IESG has received a request from the Layer 3 Virtual Private Networks WG (l3vpn) to consider the following document: - 'IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN") BGP routes; they also originate unicast VPN routes that carry MVPN- specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider's address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses. To ensure interoperability, this document specifies that provider IPv4 addresses are always encoded in these update messages as four- octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-infra-addrs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-infra-addrs/ No IPR declarations have been submitted directly on this I-D.