From kent@bbn.com Sun May 1 13:01:29 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5BFE0697 for ; Sun, 1 May 2011 13:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=0.337, 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 Gbkv5AxPtxq7 for ; Sun, 1 May 2011 13:01:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 77FC1E0674 for ; Sun, 1 May 2011 13:01:28 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49620 helo=[10.242.22.94]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QGcpY-0002Zy-1l; Sun, 01 May 2011 16:01:24 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201104152312.p3FNCJNO077701@harbor.orleans.occnc.com> References: <201104152312.p3FNCJNO077701@harbor.orleans.occnc.com> Date: Sun, 1 May 2011 13:59:46 -0400 To: curtis@occnc.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: raszuk@cisco.com, john heasley , idr@ietf.org Subject: Re: [Idr] [sidr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 20:01:29 -0000 At 7:12 PM -0400 4/15/11, Curtis Villamizar wrote: >... > >Steve, > >I would venture to guess that almost everyone on this thread knows of >this motivation for extended-message. Well, at least one individual found the arithmetic analysis helpful, even I swapped B for b! Steve From curtis@occnc.com Sun May 1 16:59:58 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB1EE06D0 for ; Sun, 1 May 2011 16:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpNPeKI9AeIb for ; Sun, 1 May 2011 16:59:58 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id BFE5DE062A for ; Sun, 1 May 2011 16:59:57 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p41NxsKv030957; Sun, 1 May 2011 19:59:54 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201105012359.p41NxsKv030957@harbor.orleans.occnc.com> To: "t.petch" From: Curtis Villamizar In-reply-to: Your message of "Sat, 30 Apr 2011 12:40:33 +0200." <00c501cc0723$0cd90220$4001a8c0@gateway.2wire.net> Date: Sun, 01 May 2011 19:59:54 -0400 Sender: curtis@occnc.com Cc: idr@ietf.org Subject: Re: [Idr] I-D Action:draft-ietf-idr-deprecate-as-sets-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 23:59:58 -0000 In message <00c501cc0723$0cd90220$4001a8c0@gateway.2wire.net> "t.petch" writes: > > Um. The trouble with tinkering is that the text may lose its coherence; > I know, I've done it too often myself. > > Two points. > > "Without AS_SET aggregates must always contain only > less specific prefixes (not less than or equal to), and must never > aggregate an exact match. " > I find a clear, easy to apply statement of what to do, whereas I > easily get lost in Appendix A, so I would be happy not to have > Appendix A. By contrast, I would like to give this sentence more > emphasis and would do so by making it the start of a new > paragraph. > > But > " Route > aggregation is possible under some conditions without the use of > AS_SETs (please see Appendix A for relevant discussion and > suggestions)." > I think prone to mislead. OK, it is a part of a paragraph about > using AS-SET but still think that it overstates the case. We don't > want everyone to de-aggregate everything! > Suggest > " Route > aggregation > that was previously performed by proxy aggregation is still > possible under some conditions without the use of > AS_SETs (please see Appendix A for relevant discussion and > suggestions)." > > Tom Petch Tom, I think the reference to Appendix A may have been before Appendix A was completely replaced with an attempt to bash any use of AS_SET by giving an example of where it could go completely wrong if incopetently configured. So maybe the sentence could remain and the reference to Appendix A removed. I also feel that Appendix A should be removed. Aggregation was never meant to be automatic or foolproof. It was always assumed that whoever was forming aggregates very well knew what they were doing. Curtis > ----- Original Message ----- > From: > To: > Cc: > Sent: Sunday, April 24, 2011 7:00 PM > Subject: [Idr] I-D Action:draft-ietf-idr-deprecate-as-sets-03.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Inter-Domain Routing Working Group of the > IETF. > > > > > > Title : Deprecation of the use of BGP AS_SET, AS_CONFED_SET. > > Author(s) : W. Kumari, K. Sriram > > Filename : draft-ietf-idr-deprecate-as-sets-03.txt > > Pages : 8 > > Date : 2011-04-24 > > > > This document deprecates the use of the AS_SET and AS_CONFED_SET > > types of the AS_PATH in BGPv4. This is done to simplify the design > > and implementation of the BGP protocol and to make the semantics of > > the originator of a route more clear. This will also simplify the > > design, implementation and deployment of ongoing work in the Secure > > Inter-Domain Routing Working Group. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-idr-deprecate-as-sets-03.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. From stephane.litkowski@orange-ftgroup.com Mon May 2 08:10:43 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@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 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 Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing 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: idr@ietfa.amsl.com Delivered-To: idr@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: 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 Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing 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 warren@kumari.net Mon May 2 14:14:52 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D8DE0755 for ; Mon, 2 May 2011 14:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.209 X-Spam-Level: X-Spam-Status: No, score=-102.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_15=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 3IGRTo7zXvvp for ; Mon, 2 May 2011 14:14:52 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 14440E0618 for ; Mon, 2 May 2011 14:14:49 -0700 (PDT) Received: from [172.19.118.237] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 497751B40150; Mon, 2 May 2011 17:14:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari X-Priority: 3 In-Reply-To: <00c501cc0723$0cd90220$4001a8c0@gateway.2wire.net> Date: Mon, 2 May 2011 17:14:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110424170001.26672.2832.idtracker@ietfc.amsl.com> <00c501cc0723$0cd90220$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org Subject: Re: [Idr] I-D Action:draft-ietf-idr-deprecate-as-sets-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 21:14:52 -0000 On Apr 30, 2011, at 6:40 AM, t.petch wrote: > Um. The trouble with tinkering is that the text may lose its = coherence; > I know, I've done it too often myself. >=20 > Two points. >=20 > "Without AS_SET aggregates must always contain only > less specific prefixes (not less than or equal to), and must never > aggregate an exact match. " > I find a clear, easy to apply statement of what to do, whereas I > easily get lost in Appendix A, so I would be happy not to have > Appendix A. Thank you -- Appendix A has been removed as a number of folk didn't = think it helped. > By contrast, I would like to give this sentence more > emphasis and would do so by making it the start of a new > paragraph. Done. >=20 > But > " Route > aggregation is possible under some conditions without the use of > AS_SETs (please see Appendix A for relevant discussion and > suggestions)." > I think prone to mislead. OK, it is a part of a paragraph about > using AS-SET but still think that it overstates the case. We don't > want everyone to de-aggregate everything! > Suggest > " Route > aggregation > that was previously performed by proxy aggregation is still > possible under some conditions without the use of > AS_SETs (please see Appendix A for relevant discussion and > suggestions)." >=20 Done (well, with the reference to Appendix A removed :-P) New rev posted..... I'd like to take a second to thank you for all of your time, input, = comments and review on this doc -- I *really* appreciate it.... W > Tom Petch >=20 > ----- Original Message ----- > From: > To: > Cc: > Sent: Sunday, April 24, 2011 7:00 PM > Subject: [Idr] I-D Action:draft-ietf-idr-deprecate-as-sets-03.txt >=20 >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the Inter-Domain Routing Working Group = of the > IETF. >>=20 >>=20 >> Title : Deprecation of the use of BGP AS_SET, = AS_CONFED_SET. >> Author(s) : W. Kumari, K. Sriram >> Filename : draft-ietf-idr-deprecate-as-sets-03.txt >> Pages : 8 >> Date : 2011-04-24 >>=20 >> This document deprecates the use of the AS_SET and AS_CONFED_SET >> types of the AS_PATH in BGPv4. This is done to simplify the design >> and implementation of the BGP protocol and to make the semantics of >> the originator of a route more clear. This will also simplify the >> design, implementation and deployment of ongoing work in the Secure >> Inter-Domain Routing Working Group. >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-idr-deprecate-as-sets-03.tx= t >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >>=20 >=20 >=20 > = --------------------------------------------------------------------------= ------ >=20 >=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >>=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From Internet-Drafts@ietf.org Mon May 2 14:15:13 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B9BE0786; Mon, 2 May 2011 14:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 irVvFNSztHsW; Mon, 2 May 2011 14:15:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5F5E077D; Mon, 2 May 2011 14:15:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110502211504.27541.12919.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2011 14:15:04 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-deprecate-as-sets-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 21:15:13 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Deprecation of the use of BGP AS_SET, AS_CONFED_SET. Author(s) : W. Kumari, K. Sriram Filename : draft-ietf-idr-deprecate-as-sets-04.txt Pages : 5 Date : 2011-05-02 This document deprecates the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of the BGP protocol and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-deprecate-as-sets-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-idr-deprecate-as-sets-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-02141025.I-D@ietf.org> --NextPart-- From warren@kumari.net Mon May 2 14:24:48 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749F4E07BA for ; Mon, 2 May 2011 14:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_15=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 WvJzBAMp1jEG for ; Mon, 2 May 2011 14:24:47 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 5B812E07B8 for ; Mon, 2 May 2011 14:24:39 -0700 (PDT) Received: from [172.19.118.237] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 54B271B40150; Mon, 2 May 2011 17:24:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari X-Priority: 3 In-Reply-To: Date: Mon, 2 May 2011 17:24:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66CB2A50-D663-4331-8783-F420D538FEA1@kumari.net> References: <20110424170001.26672.2832.idtracker@ietfc.amsl.com> <00c501cc0723$0cd90220$4001a8c0@gateway.2wire.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org Subject: Re: [Idr] I-D Action:draft-ietf-idr-deprecate-as-sets-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 21:24:48 -0000 And I just realized that I forgot to do: s/will/may/ in "Future work will update the protocol to remove support = for the AS_SET path segment type of the AS_PATH attribute" Amazing how often you notice something like that as you click the = confirm button :-) W On May 2, 2011, at 5:14 PM, Warren Kumari wrote: >=20 >=20 > On Apr 30, 2011, at 6:40 AM, t.petch wrote: >=20 >> Um. The trouble with tinkering is that the text may lose its = coherence; >> I know, I've done it too often myself. >>=20 >> Two points. >>=20 >> "Without AS_SET aggregates must always contain only >> less specific prefixes (not less than or equal to), and must never >> aggregate an exact match. " >> I find a clear, easy to apply statement of what to do, whereas I >> easily get lost in Appendix A, so I would be happy not to have >> Appendix A. >=20 > Thank you -- Appendix A has been removed as a number of folk didn't = think it helped. >=20 >=20 >> By contrast, I would like to give this sentence more >> emphasis and would do so by making it the start of a new >> paragraph. >=20 > Done. >=20 >>=20 >> But >> " Route >> aggregation is possible under some conditions without the use of >> AS_SETs (please see Appendix A for relevant discussion and >> suggestions)." >> I think prone to mislead. OK, it is a part of a paragraph about >> using AS-SET but still think that it overstates the case. We don't >> want everyone to de-aggregate everything! >> Suggest >> " Route >> aggregation >> that was previously performed by proxy aggregation is still >> possible under some conditions without the use of >> AS_SETs (please see Appendix A for relevant discussion and >> suggestions)." >>=20 >=20 > Done (well, with the reference to Appendix A removed :-P) >=20 > New rev posted..... >=20 > I'd like to take a second to thank you for all of your time, input, = comments and review on this doc -- I *really* appreciate it.... >=20 >=20 > W >> Tom Petch >>=20 >> ----- Original Message ----- >> From: >> To: >> Cc: >> Sent: Sunday, April 24, 2011 7:00 PM >> Subject: [Idr] I-D Action:draft-ietf-idr-deprecate-as-sets-03.txt >>=20 >>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the Inter-Domain Routing Working Group = of the >> IETF. >>>=20 >>>=20 >>> Title : Deprecation of the use of BGP AS_SET, = AS_CONFED_SET. >>> Author(s) : W. Kumari, K. Sriram >>> Filename : draft-ietf-idr-deprecate-as-sets-03.txt >>> Pages : 8 >>> Date : 2011-04-24 >>>=20 >>> This document deprecates the use of the AS_SET and AS_CONFED_SET >>> types of the AS_PATH in BGPv4. This is done to simplify the design >>> and implementation of the BGP protocol and to make the semantics of >>> the originator of a route more clear. This will also simplify the >>> design, implementation and deployment of ongoing work in the Secure >>> Inter-Domain Routing Working Group. >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-ietf-idr-deprecate-as-sets-03.tx= t >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>>=20 >>=20 >>=20 >> = --------------------------------------------------------------------------= ------ >>=20 >>=20 >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>>=20 >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >>=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From jgs@juniper.net Mon May 2 14:37:53 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0EEE07A6 for ; Mon, 2 May 2011 14:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se8c7M1PKpcR for ; Mon, 2 May 2011 14:37:52 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2BAE07CC for ; Mon, 2 May 2011 14:37:52 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTb8kKy26Rn/jEH9QLjo31BjpUMgDjolp@postini.com; Mon, 02 May 2011 14:37:52 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 2 May 2011 14:36:34 -0700 From: John Scudder To: "idr@ietf.org List" Date: Mon, 2 May 2011 14:36:32 -0700 Thread-Topic: WGLC for draft-ietf-idr-deprecate-as-sets-04 Thread-Index: AcwJEQGjYtQDVxSWSiOhsQgF2KKmbg== Message-ID: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.net> 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 Subject: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 21:37:53 -0000 Folks, This is to start a (new) working group last call for draft-ietf-idr-depreca= te-as-sets-04. Please send comments by May 17, 2011. http://tools.ietf.org/html/draft-ietf-idr-deprecate-as-sets-04 Thanks, --John From housley@vigilsec.com Tue May 3 00:15:42 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BFCE0780 for ; Tue, 3 May 2011 00:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 o9AVckAQMALI for ; Tue, 3 May 2011 00:15:42 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id EC16EE06E1 for ; Tue, 3 May 2011 00:15:41 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id B27F2F24019; Tue, 3 May 2011 03:15:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 8OYRCA+meRux; Tue, 3 May 2011 03:15:40 -0400 (EDT) Received: from dhcp-guest-ams5-144-254-113-104.cisco.com (dhcp-guest-ams5-144-254-113-104.cisco.com [144.254.113.104]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7D8579A472B; Tue, 3 May 2011 03:15:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.net> Date: Tue, 3 May 2011 03:15:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 07:15:42 -0000 I have read the document, and I support publication as an RFC. Russ On May 2, 2011, at 5:36 PM, John Scudder wrote: > Folks, >=20 > This is to start a (new) working group last call for = draft-ietf-idr-deprecate-as-sets-04. Please send comments by May 17, = 2011. >=20 > http://tools.ietf.org/html/draft-ietf-idr-deprecate-as-sets-04 >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From fweimer@bfk.de Tue May 3 01:45:20 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBFDE0742 for ; Tue, 3 May 2011 01:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik0fwbWM-mZH for ; Tue, 3 May 2011 01:45:20 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A61DE06E1 for ; Tue, 3 May 2011 01:45:16 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QHBEH-00032R-EK; Tue, 03 May 2011 08:45:13 +0000 Received: by bfk.de with local id 1QHBEH-0000Pl-AF; Tue, 03 May 2011 08:45:13 +0000 To: John Scudder References: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.net> From: Florian Weimer Date: Tue, 03 May 2011 08:45:13 +0000 In-Reply-To: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.net> (John Scudder's message of "Mon\, 2 May 2011 14\:36\:32 -0700") Message-ID: <824o5cxjdy.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "idr@ietf.org List" Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 08:45:20 -0000 * John Scudder: > This is to start a (new) working group last call for draft-ietf-idr-depre= cate-as-sets-04. Please send comments by May 17, 2011. > > http://tools.ietf.org/html/draft-ietf-idr-deprecate-as-sets-04 The MAY is used slightly incorrectly because RFC 2119 refers to implementations, not specifications. But I think the intent is clear. I still support the idea of this draft, but I would rather prefer a document which isn't a no-op. As it stands, it is possible to be fully compliant with this document without changing anything, no matter what you do today. In this sense, this document is not a deprecation, but the announcement of a further deprecation. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From randy@psg.com Tue May 3 02:34:39 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E7CE06F2 for ; Tue, 3 May 2011 02:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.323 X-Spam-Level: X-Spam-Status: No, score=-5.323 tagged_above=-999 required=5 tests=[AWL=1.276, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w59nVLvEYZf for ; Tue, 3 May 2011 02:34:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 86852E06AA for ; Tue, 3 May 2011 02:34:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-27-124.ripemtg.ripe.net.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QHBys-000LQM-8I; Tue, 03 May 2011 09:33:22 +0000 Date: Tue, 03 May 2011 11:34:32 +0200 Message-ID: From: Randy Bush To: John Scudder In-Reply-To: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.net> References: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org List" Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 09:34:39 -0000 > This is to start a (new) working group last call for > draft-ietf-idr-deprecate-as-sets-04. i confess to having rescanned, not completely reread. but i support still. rndy From warren@kumari.net Tue May 3 14:01:12 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD12DE071D for ; Tue, 3 May 2011 14:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 PPOMnwDiSKga for ; Tue, 3 May 2011 14:01:12 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id F41A9E0713 for ; Tue, 3 May 2011 14:01:11 -0700 (PDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 5163F1B4066F; Tue, 3 May 2011 17:01:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Warren Kumari In-Reply-To: <824o5cxjdy.fsf@mid.bfk.de> Date: Tue, 3 May 2011 17:01:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <34C0EF7E-E4F1-48F4-87C9-F3960707386C@kumari.net> References: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.net> <824o5cxjdy.fsf@mid.bfk.de> To: Florian Weimer X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 21:01:13 -0000 On May 3, 2011, at 4:45 AM, Florian Weimer wrote: > * John Scudder: >=20 >> This is to start a (new) working group last call for = draft-ietf-idr-deprecate-as-sets-04. Please send comments by May 17, = 2011. >>=20 >> http://tools.ietf.org/html/draft-ietf-idr-deprecate-as-sets-04 >=20 > The MAY is used slightly incorrectly because RFC 2119 refers to > implementations, not specifications. But I think the intent is clear. >=20 > I still support the idea of this draft, but I would rather prefer a > document which isn't a no-op. As it stands, it is possible to be > fully compliant with this document without changing anything, no > matter what you do today. In this sense, this document is not a > deprecation, but the announcement of a further deprecation. Yes, you are right - it is close to announcement of a further = deprecation. Originally this was supposed to deprecate as-sets, but = there were objections that you cannot deprecate a feature that is = currently in use (even if just by a small number of folk), so this = provides notice / advice to operators that this feature should be = avoided[0]. After this has been out for a short while I'm planning on = writing another document that actually deprecates the feature itself[1]. W [0]: Just aggregation that creates as-sets (and that because it causes = issues / confusion), not aggregation in general -- aggregation (fairly = obviously) is still the Right Thing to do, but it should be done right, = and apparently that means "as simply as possible"! >=20 > --=20 > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra=DFe 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From christopher.morrow@gmail.com Tue May 3 14:31:37 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DF5E06A0 for ; Tue, 3 May 2011 14:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 8OGZxzJE3i0T for ; Tue, 3 May 2011 14:31:36 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50C43E069D for ; Tue, 3 May 2011 14:31:36 -0700 (PDT) Received: by wwa36 with SMTP id 36so395892wwa.13 for ; Tue, 03 May 2011 14:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jvctjn09AGDI895karDv670zU8cLWRsnvl34MOpeqXg=; b=rXzRcz48V3n65og9CRS6xpm9+5VrGDQXOO84/zQWYR8EuwV/5Qyzulihgw3eL7hlUT HA/ivFmeGnXyC+5DZf8U1i9EM0pyixaFRdmbYhWXuBcRhC6Q/Yc9lNZSVRikuR1Sijkt lOzGLrvLN1JkwczG1tz7RKb33NFFTrEs660qM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=YZ1Ki2nn9cT6n5b5XNlnhExX26OFH+lTvkXVx/jS7C2beKQC53VkrOxM39KvYPissr ab6XHbu7OnAW7EKgnJb6m1KKTdkzgXc8/eC8fxaaVf17AxC93uAiutO7LT/wQrCWW/mq M+pyYkfZlp2bkzLD1/xxk3qTqhP+t68QGXlYw= MIME-Version: 1.0 Received: by 10.216.158.131 with SMTP id q3mr4038542wek.99.1304458295263; Tue, 03 May 2011 14:31:35 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.241.136 with HTTP; Tue, 3 May 2011 14:31:34 -0700 (PDT) In-Reply-To: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.net> References: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.net> Date: Tue, 3 May 2011 17:31:34 -0400 X-Google-Sender-Auth: rhMmtcba7RAG6lPewWGJEeFTEhw Message-ID: From: Christopher Morrow To: John Scudder Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "idr@ietf.org List" Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 21:31:37 -0000 On Mon, May 2, 2011 at 5:36 PM, John Scudder wrote: > Folks, > > This is to start a (new) working group last call for draft-ietf-idr-depre= cate-as-sets-04. =A0Please send comments by May 17, 2011. > > http://tools.ietf.org/html/draft-ietf-idr-deprecate-as-sets-04 I support this draft, pls. -chris From stephane.litkowski@orange-ftgroup.com Wed May 4 02:41:22 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@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 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 Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing 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 ietfc@btconnect.com Wed May 4 04:20:15 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6BCE0756 for ; Wed, 4 May 2011 04:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.681 X-Spam-Level: X-Spam-Status: No, score=-1.681 tagged_above=-999 required=5 tests=[AWL=0.918, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPJs9+BaccVS for ; Wed, 4 May 2011 04:20:14 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA19E073E for ; Wed, 4 May 2011 04:20:13 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2bthomr09.btconnect.com with SMTP id CTN07627; Wed, 04 May 2011 12:20:09 +0100 (BST) Message-ID: <038801cc0a44$ac0d2be0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "John Scudder" , References: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.net> Date: Wed, 4 May 2011 12:18:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4DC13668.00DD, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.5.4.103916:17:7.586, ip=217.43.155.221, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __CP_URI_IN_BODY, BODY_SIZE_600_699, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, BODY_SIZE_1000_LESS, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4DC13669.024B,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 11:20:15 -0000 I support publication of this as an RFC. Tom Petch ----- Original Message ----- From: "John Scudder" To: Sent: Monday, May 02, 2011 11:36 PM Subject: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 > Folks, > > This is to start a (new) working group last call for draft-ietf-idr-deprecate-as-sets-04. Please send comments by May 17, 2011. > > http://tools.ietf.org/html/draft-ietf-idr-deprecate-as-sets-04 > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From raszuk@cisco.com Wed May 4 05:18:53 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@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 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 Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing 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 pedro.r.marques@gmail.com Wed May 4 10:12:35 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@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: From: Pedro Marques To: stephane.litkowski@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org, l3vpn@ietf.org Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing 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 internet-drafts@ietf.org Wed May 4 16:08:40 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBC7E07A4; Wed, 4 May 2011 16:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 DP-PHLyDWb3s; Wed, 4 May 2011 16:08:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CFEE0730; Wed, 4 May 2011 16:08:40 -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 X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110504230840.15739.39001.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2011 16:08:40 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-identifier-14.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 23:08:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : AS-wide Unique BGP Identifier for BGP-4 Author(s) : Enke Chen Jenny Yuan Filename : draft-ietf-idr-bgp-identifier-14.txt Pages : 5 Date : 2011-05-04 To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet unsigned, non-zero integer, and relaxes the "uniqueness" requirement so that only AS-wide uniq= ueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-identifier-14.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-idr-bgp-identifier-14.txt From stephane.litkowski@orange-ftgroup.com Thu May 5 06:16:35 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@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 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 Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing 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: idr@ietfa.amsl.com Delivered-To: idr@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 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 Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing 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: idr@ietfa.amsl.com Delivered-To: idr@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 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 Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing 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: idr@ietfa.amsl.com Delivered-To: idr@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: 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 Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing 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 Internet-Drafts@ietf.org Thu May 5 18:15:02 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFA3E06C3; Thu, 5 May 2011 18:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 5KbanqCV+ZDK; Thu, 5 May 2011 18:15:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442F9E06CB; Thu, 5 May 2011 18:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110506011502.9655.39378.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 18:15:02 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-bgp-bestpath-selection-criteria-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 01:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Bestpath Selection Criteria Author(s) : R. Asati Filename : draft-ietf-idr-bgp-bestpath-selection-criteria-02.txt Pages : 9 Date : 2011-05-05 BGP specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-bestpath-selection-criteria-02.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-idr-bgp-bestpath-selection-criteria-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-05180640.I-D@ietf.org> --NextPart-- From stephane.litkowski@orange-ftgroup.com Fri May 6 00:51:46 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@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 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 Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing 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: idr@ietfa.amsl.com Delivered-To: idr@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: 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 Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing 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 Internet-Drafts@ietf.org Fri May 6 14:00:03 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E056E0819; Fri, 6 May 2011 14:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 qhSfR54Yxznq; Fri, 6 May 2011 14:00:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895DCE0821; Fri, 6 May 2011 14:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110506210002.32318.50975.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2011 14:00:02 -0700 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-best-external-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 21: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 Inter-Domain Routing Working Group of the IETF. Title : Advertisement of the best external route in BGP Author(s) : P. Marques, et al Filename : draft-ietf-idr-best-external-04.txt Pages : 21 Date : 2011-04-20 The current BGP-4 protocol specification [RFC4271] states that the selection process chooses the best path for a given route which is added to the Loc-Rib and advertised to all peers. Previous versions [RFC1771] of the specification defined a different rule for Internal BGP Updates. Given that Internal paths are not re- advertised to Internal peers, it was specified that the best of the external paths, as determined by the path selection tie breaking algorithm, would be advertised to Internal peers. This document extends that procedure to operate in environments where Route Reflection [RFC4456] or Confederations [RFC5065] are used and explains why advertising the additional routing information can improve convergence time without causing routing loops. Additional benefits include reduction of inter-domain churn and avoidance of permanent route oscillation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-best-external-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-idr-best-external-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-06135832.I-D@ietf.org> --NextPart-- From alvaro.retana@hp.com Mon May 9 12:55:11 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966B9E0803 for ; Mon, 9 May 2011 12:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SPuE9faDv00I for ; Mon, 9 May 2011 12:55:10 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by ietfa.amsl.com (Postfix) with ESMTP id 83D97E07C8 for ; Mon, 9 May 2011 12:55:10 -0700 (PDT) Received: from G4W3009.americas.hpqcorp.net (g4w3009.houston.hp.com [16.234.35.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTPS id 63B5F1C104; Mon, 9 May 2011 19:55:09 +0000 (UTC) Received: from G1W0395.americas.hpqcorp.net (16.236.31.0) by G4W3009.americas.hpqcorp.net (16.234.35.43) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 9 May 2011 19:53:53 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.11]) by G1W0395.americas.hpqcorp.net ([16.236.31.0]) with mapi; Mon, 9 May 2011 19:53:52 +0000 From: "Retana, Alvaro" To: "idr@ietf.org" Date: Mon, 9 May 2011 19:53:49 +0000 Thread-Topic: Adoption of "BGP Custom Decision" as WG Document Thread-Index: AcwOgtBmpBHH6qh0Sn+l9O7U4/U3cg== Message-ID: <24646CE17826CF4A8DF71F9856C7E65659240FE36F@GVW1338EXA.americas.hpqcorp.net> 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_24646CE17826CF4A8DF71F9856C7E65659240FE36FGVW1338EXAame_" MIME-Version: 1.0 Cc: "russwh@cisco.com" Subject: [Idr] Adoption of "BGP Custom Decision" as WG Document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 19:55:11 -0000 --_000_24646CE17826CF4A8DF71F9856C7E65659240FE36FGVW1338EXAame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! Following up on the meeting in Prague... http://tools.ietf.org/html/draft-retana-bgp-custom-decision We just published version -02. The only change from -01 is an update on th= e authors' contact information. As discussed during the meeting, this is the formal request for adoption of= this draft as a WG document. The intended status is Standards Track. Thoughts/comments? Thanks! Alvaro. --_000_24646CE17826CF4A8DF71F9856C7E65659240FE36FGVW1338EXAame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi!

 

Following = up on the meeting in Prague…

=  

http://tools.ietf.org/html/draft-retana-b= gp-custom-decision

 =

We just published version -02.  The only chan= ge from -01 is an update on the authors’ contact information.

 

As di= scussed during the meeting, this is the formal request for adoption of this= draft as a WG document.

 

The intended status is Standards Track.

 

Though= ts/comments?

 

Thanks!

 =

Alvaro.

= --_000_24646CE17826CF4A8DF71F9856C7E65659240FE36FGVW1338EXAame_-- From sra@hactrn.net Fri May 13 11:38:33 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A979E0856 for ; Fri, 13 May 2011 11:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.186 X-Spam-Level: X-Spam-Status: No, score=-100.186 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5DRiuFKA7DR for ; Fri, 13 May 2011 11:38:33 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id A8FBBE0851 for ; Fri, 13 May 2011 11:38:32 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 3F48A28464 for ; Fri, 13 May 2011 18:38:29 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 12D8722829 for ; Fri, 13 May 2011 14:38:29 -0400 (EDT) Date: Fri, 13 May 2011 14:38:29 -0400 From: Rob Austein To: idr@ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110513183829.12D8722829@thrintun.hactrn.net> X-Mailman-Approved-At: Fri, 13 May 2011 11:40:47 -0700 Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 18:38:33 -0000 I have read this draft and support publication as an RFC. From jgs@juniper.net Fri May 13 17:46:11 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468C8E074B for ; Fri, 13 May 2011 17:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2fXFijJN-G4 for ; Fri, 13 May 2011 17:46:10 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 783FEE0728 for ; Fri, 13 May 2011 17:46:09 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTc3Q0Ed2qPHiCXpH+aBY89VSROXrD0oH@postini.com; Fri, 13 May 2011 17:46:10 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 13 May 2011 17:45:02 -0700 From: John Scudder To: "idr@ietf.org List" Date: Fri, 13 May 2011 17:45:00 -0700 Thread-Topic: IDR minutes for IETF-80 Thread-Index: AcwR0CiG46TqOMNCTE6p669eSN27EQ== Message-ID: <1BC56D47-5B8B-463B-8E93-6057C6DC7F5F@juniper.net> 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 Subject: [Idr] IDR minutes for IETF-80 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 00:46:11 -0000 Minutes have (finally!) been uploaded to http://www.ietf.org/proceedings/80= /minutes/idr.txt Please send any corrections. Thanks, --John= From kent@bbn.com Mon May 16 07:37:56 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27135E0733 for ; Mon, 16 May 2011 07:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 6CbByjEJlLyM for ; Mon, 16 May 2011 07:37:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 64292E0699 for ; Mon, 16 May 2011 07:37:55 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:60118 helo=[192.168.147.76]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QLyvi-0009E6-Tb for idr@ietf.org; Mon, 16 May 2011 10:37:55 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 16 May 2011 10:37:53 -0400 To: idr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Idr] draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 14:37:56 -0000 I support approval of this doc. Steve From turners@ieca.com Mon May 16 07:41:22 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EDEE0742 for ; Mon, 16 May 2011 07:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.516 X-Spam-Level: X-Spam-Status: No, score=-101.516 tagged_above=-999 required=5 tests=[AWL=-1.332, BAYES_40=-0.185, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p95UOIRGaJIC for ; Mon, 16 May 2011 07:41:22 -0700 (PDT) Received: from nm23-vm0.bullet.mail.sp2.yahoo.com (nm23-vm0.bullet.mail.sp2.yahoo.com [98.139.91.224]) by ietfa.amsl.com (Postfix) with SMTP id F1307E0699 for ; Mon, 16 May 2011 07:41:21 -0700 (PDT) Received: from [98.139.91.61] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 16 May 2011 14:41:19 -0000 Received: from [98.139.91.41] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 16 May 2011 14:41:19 -0000 Received: from [127.0.0.1] by omp1041.mail.sp2.yahoo.com with NNFMP; 16 May 2011 14:41:19 -0000 X-Yahoo-Newman-Id: 160692.86143.bm@omp1041.mail.sp2.yahoo.com Received: (qmail 29037 invoked from network); 16 May 2011 14:41:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1305556878; bh=fBbZHMc0LBhGUGYA+Qonda9dwDe6JKmo9eSMbbVC0o4=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=LAWp4shivxogvS2HD2epHH5HjDqKrExStRYvYEGw3/kvh/7n0y2ksCK26TaXKUOur8dnoAFIgzCpvlPV6YmrRqFhKquc/WvOKpGQNBK333NLVRn0NFKHems95mTAst5Ihv0NKue3HK7VHWQWGDKNVYxTwAQMO0SSvCn+LF5MmoM= Received: from thunderfish.local (turners@198.180.150.234 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 16 May 2011 07:41:18 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 0k1npuEVM1mBRw01IoBv_5F_g4UJ0ehFnj_Y.EbGfh1a5X9 moYZFxOEaT1l2F2pv6nrO2Zx5bYzxjCGQlSeOawbd1vOgWVWEDQO9RYlL1aN 0HhEYzUEUAyzDdSlPgrd.xgh5MNYqS6w6dstr1ut2rqBXhX8sh5hTfkqoAAy oHkZrd_TvZ5.x7QQL6a1rX1Jnp5eASb.Jlm4c7ybvlIsRF4uTutqMi4a63kW ress_YdoJs4LB0M8aURBLnpMEgxsHAseUhtBXs8HiqV2kZy1_UIY7n3ZN2f_ f8W9TgixYWywAJF7PZfVwaibGfGAt0MGTrC.ghcOMZo4LUI8WJZGAGKFnKXT 106mnwiZqKE.XqMgszwscv6LLcBeUVEHLDHtDK6Oajas- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DD13622.9050203@ieca.com> Date: Mon, 16 May 2011 10:35:14 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 16 May 2011 10:06:46 -0700 Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 14:41:22 -0000 I read this draft and support it's publication. Nits: 1. Abstract: r/This is done to simplify/This will simplify and r/and to make/and will make 2. Section 1, para 1: Expand AS. 3. Section 1, para 2: Is there a link for the analysis? I.e., can we include an informative reference to it? 4. Expand RPKI in Section 5. spt From turners@ieca.com Mon May 16 08:12:26 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96138E0772 for ; Mon, 16 May 2011 08:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.645 X-Spam-Level: X-Spam-Status: No, score=-102.645 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF+YJ4pFE8-E for ; Mon, 16 May 2011 08:12:26 -0700 (PDT) Received: from nm17.bullet.mail.bf1.yahoo.com (nm17.bullet.mail.bf1.yahoo.com [98.139.212.176]) by ietfa.amsl.com (Postfix) with SMTP id 009F9E076F for ; Mon, 16 May 2011 08:12:25 -0700 (PDT) Received: from [98.139.212.153] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 16 May 2011 15:12:25 -0000 Received: from [98.139.212.248] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 16 May 2011 15:12:25 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 16 May 2011 15:12:25 -0000 X-Yahoo-Newman-Id: 480844.4269.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 24026 invoked from network); 16 May 2011 14:35:06 -0000 Received: from thunderfish.local (turners@198.180.150.234 with plain) by smtp102.biz.mail.bf1.yahoo.com with SMTP; 16 May 2011 07:35:03 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: TEr_xzsVM1nHaWahkgxiycU88GKkItKcbHBAogJDnfR8aPn ryD9lT6IYFpB4Phwjd44fQolds3Hyjo036XKS1b1SJUW2TbsCt3dTi6hpo.A JGNgtuW5uYuBVG.1KHH0JDNuopCgwXSf9ZkJ3rr.Tl35fLGE0zIha4LvRUeu eT9dMJUcvrKRN1La78egruAqtQ4fu1kF1gleD_r1akJmO1MEGEMXSckAJH.I GpkZ1QPCirl_Bjj.hJadOhKGj2ToXLuo0kpXqAITxlYvxrt9bVNJDgPWMhxX 2q9u_h2rp2UjI5xSM0K0f__JTrIHUdm34mFF7AuXrWMHUVT35qS3ybiE7y52 .NkbEUnfMBc.iCggZZC7D1IFc X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DD1360E.4060205@ieca.com> Date: Mon, 16 May 2011 10:34:54 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 16 May 2011 10:06:46 -0700 Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 15:12:26 -0000 I read this draft and support it's publication. Nits: 1. Abstract: r/This is done to simplify/This will simplify and r/and to make/and will make 2. Section 1, para 1: Expand AS. 3. Section 1, para 2: Is there a link for the analysis? I.e., can we include an informative reference to it? 4. Expand RPKI in Section 5. spt From warren@kumari.net Mon May 16 11:15:03 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCFFE0719 for ; Mon, 16 May 2011 11:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 pq+Q-x6609i7 for ; Mon, 16 May 2011 11:15:02 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C9C6DE0771 for ; Mon, 16 May 2011 11:15:02 -0700 (PDT) Received: from [172.26.49.229] (unknown [72.14.228.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 89C541B40855; Mon, 16 May 2011 14:15:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4DD1360E.4060205@ieca.com> Date: Mon, 16 May 2011 14:14:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9956FACC-44C9-4261-B966-FEF214829379@kumari.net> References: <4DD1360E.4060205@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 18:15:04 -0000 On May 16, 2011, at 10:34 AM, Sean Turner wrote: > I read this draft and support it's publication. Thank you. >=20 > Nits: >=20 > 1. Abstract: r/This is done to simplify/This will simplify > and > r/and to make/and will make Will do.=09 >=20 > 2. Section 1, para 1: Expand AS. Will do. >=20 > 3. Section 1, para 2: Is there a link for the analysis? I.e., can we = include an informative reference to it? Er, should be, yes -- my co-author did (and published) much of the = analysis -- I'll ask for a stable reference..... >=20 > 4. Expand RPKI in Section 5. Will do. >=20 > spt >=20 W > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From rv@x37.NIC.DTAG.DE Mon May 16 11:37:00 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32240E0793 for ; Mon, 16 May 2011 11:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.608 X-Spam-Level: * X-Spam-Status: No, score=1.608 tagged_above=-999 required=5 tests=[AWL=2.409, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] 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 Vw4ryTzqFJNG for ; Mon, 16 May 2011 11:36:59 -0700 (PDT) Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE [194.25.1.113]) by ietfa.amsl.com (Postfix) with ESMTP id 31249E0681 for ; Mon, 16 May 2011 11:36:58 -0700 (PDT) Received: from x37.NIC.DTAG.DE (x37.NIC.DTAG.DE [194.25.1.186]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id UAA27013; Mon, 16 May 2011 20:36:53 +0200 (MET DST) From: "Ruediger Volk" To: idr@ietf.org Date: Mon, 16 May 2011 20:36:56 +0200 Message-ID: <27929.1305571016@x37.NIC.DTAG.DE> Sender: rv@x37.NIC.DTAG.DE Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 18:37:00 -0000 I read this draft and support it's publication. Ruediger From keyupate@cisco.com Mon May 16 13:03:33 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2985E06DB for ; Mon, 16 May 2011 13:03:33 -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 UzEuwuDjU1Wz for ; Mon, 16 May 2011 13:03:33 -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 5C992E06A4 for ; Mon, 16 May 2011 13:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=294; q=dns/txt; s=iport; t=1305576213; x=1306785813; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=DEyhM1o6E02rx30QT1tAMaMsIZvsUgA5Dh/1fsiterE=; b=ihGMrPf70gMuEF4anUcRZabJxRAJhUFokvCgVxNw7t3Mje+W3RAVzB1R pEdlPIliAT11wxXryoT+7nK+SRCGK9hrfehJByCFhn1fFbQIjmph2XH5Q pjUr6zzsrupkZiB3cjbUZGbxCWiVTEf5Q9wq7Q7OZUBfK28tOG3PI3ljm E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUHANCC0U2rRDoJ/2dsb2JhbACYC44Md4hwnUiBHZ4qhhkEhlCJQYQ4il0 X-IronPort-AV: E=Sophos;i="4.65,221,1304294400"; d="scan'208";a="448734564" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 16 May 2011 20:03:33 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4GK3TVh014448 for ; Mon, 16 May 2011 20:03:33 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 May 2011 13:03:31 -0700 Received: from 10.21.92.190 ([10.21.92.190]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([128.107.191.87]) with Microsoft Exchange Server HTTP-DAV ; Mon, 16 May 2011 20:03:31 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 16 May 2011 13:02:28 -0700 From: Keyur Patel To: Message-ID: Thread-Topic: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 Thread-Index: AcwUBC6IbPIDqH/3EeCHyAAbY71bnA== In-Reply-To: <27929.1305571016@x37.NIC.DTAG.DE> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 May 2011 20:03:31.0686 (UTC) FILETIME=[547DD860:01CC1404] Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 20:03:33 -0000 +1. Regards, -Keyur On 5/16/11 11:36 AM, "Ruediger Volk" wrote: > I read this draft and support it's publication. > > Ruediger > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From pmohapat@cisco.com Mon May 16 15:03:07 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFAEE069D for ; Mon, 16 May 2011 15:03:07 -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 TKTmtcCVyc7s for ; Mon, 16 May 2011 15:03:07 -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 3731BE0686 for ; Mon, 16 May 2011 15:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=1438; q=dns/txt; s=iport; t=1305583387; x=1306792987; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=4nmCY7ztc57N99lYDr9yQUErg+Y23xnisKckke5k9RM=; b=bsb+91ur3V2g1m7E82GS94BH9l1pcjLoOg7wgMSd79/zcJ67/uxiG6Rt 4LfUMZrY0ZbmNNMXQ6WJzqE4IBfUcyjSEwYrAM7UoE5mlS09RVoGccXVt t2swqV37HIcDTgWWEobksuHbWpw4tmTagYI1G4SNC4+tfgUIAwXDQ44ki Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJme0U2rRDoJ/2dsb2JhbACmF3endZ4vhhkEhlCJQY8V X-IronPort-AV: E=Sophos;i="4.65,221,1304294400"; d="scan'208";a="448814533" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 16 May 2011 22:03:06 +0000 Received: from dhcp-171-71-139-209.cisco.com (dhcp-171-71-139-209.cisco.com [171.71.139.209]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4GM36Lh002217 for ; Mon, 16 May 2011 22:03:06 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Pradosh Mohapatra In-Reply-To: Date: Mon, 16 May 2011 15:05:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "idr@ietf.org List" X-Mailer: Apple Mail (2.1081) Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 22:03:07 -0000 +1 Few editorial nits: a) Wouldn't hurt to mention that the applicability extends to AS4_PATH & refer to RFC4893. b) section 3: It is worth noting that new technologies (such as those that take advantage of the "X.509 Extensions for IP Addresses and AS Identifiers" ([RFC3779]) may not support routes with AS_SETs / AS_CONFED_SETs in them, and MAY treat as infeasible routes containing them. Future BGP implementations may also do the same. Is it just me that finds the above para a bit hard to read? :-) = Suggestion for a=20 minor tweak: It is worth noting that new technologies (such as those that take advantage of the "X.509 Extensions for IP Addresses and AS Identifiers" ([RFC3779]) may not support routes with AS_SETs / AS_CONFED_SETs in them. They MAY treat such routes as infeasible. Future BGP implementations may also do the same. - Pradosh On May 16, 2011, at 1:02 PM, Keyur Patel wrote: > +1. >=20 > Regards, > -Keyur >=20 >=20 > On 5/16/11 11:36 AM, "Ruediger Volk" wrote: >=20 >> I read this draft and support it's publication. >>=20 >> Ruediger >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From ilya@nobulus.com Mon May 16 23:43:39 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C343E069E for ; Mon, 16 May 2011 23:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, STOX_REPLY_TYPE=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 5rjuMFw9kVCr for ; Mon, 16 May 2011 23:43:39 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id B7A98E0682 for ; Mon, 16 May 2011 23:43:37 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 16FB217447; Tue, 17 May 2011 08:43:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zL1rcS0KT3U4; Tue, 17 May 2011 08:43:32 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:acd3:35f3:ca0c:24c]) by nobulus.com (Postfix) with ESMTPA id 331401747C; Tue, 17 May 2011 08:43:30 +0200 (CEST) Message-ID: <15685156ACD74E00B8A4485A0512B404@hnivarlas1> From: "iLya" To: "John Scudder" , References: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.net> In-Reply-To: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.net> Date: Tue, 17 May 2011 08:43:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 06:43:39 -0000 support /iLya -------------------------------------------------- From: "John Scudder" Sent: Monday, May 02, 2011 11:36 PM To: Subject: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 > Folks, > > This is to start a (new) working group last call for > draft-ietf-idr-deprecate-as-sets-04. Please send comments by May 17, > 2011. > > http://tools.ietf.org/html/draft-ietf-idr-deprecate-as-sets-04 > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From internet-drafts@ietf.org Mon May 23 08:24:10 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE4CE07AC; Mon, 23 May 2011 08:24:10 -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 SCEZkdYZ1L+U; Mon, 23 May 2011 08:24:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050A2E069E; Mon, 23 May 2011 08:24:10 -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 X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110523152410.5968.51112.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2011 08:24:10 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-reserved-extended-communities-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 15:24:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Assigned BGP extended communities Author(s) : Bruno Decraene Pierre Francois Filename : draft-ietf-idr-reserved-extended-communities-01.txt Pages : 5 Date : 2011-05-23 This document defines two IANA registries in order to assign transitive and non-transitive extended communities from. These are similar to the existing well-known BGP communities defined in RFC 1997 but provide an easier control of inter-AS community advertisement as a community could be chosen as transitive or non- transitive across ASes. For that purpose, this document defines the use of the reserved AS number 0 for the transitive and non-transitive generic four-octet AS specific extended community types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-reserved-extended-commun= ities-01.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-idr-reserved-extended-communi= ties-01.txt From bruno.decraene@orange-ftgroup.com Mon May 23 08:44:46 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFEEE07B7 for ; Mon, 23 May 2011 08:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yozHAofkP9oV for ; Mon, 23 May 2011 08:44:45 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id CD5EDE06A3 for ; Mon, 23 May 2011 08:44:44 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 935A16D8001 for ; Mon, 23 May 2011 17:40:18 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 8AE286C8003 for ; Mon, 23 May 2011 17:40:18 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 May 2011 17:39:02 +0200 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 Date: Mon, 23 May 2011 17:39:01 +0200 Message-ID: In-Reply-To: <20110523152410.5968.51112.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] I-D Action:draft-ietf-idr-reserved-extended-communities-01.txt Thread-Index: AcwZXZWznnBMemCkReqBZlvrG5UWhAAAC1vA References: <20110523152410.5968.51112.idtracker@ietfa.amsl.com> From: To: X-OriginalArrivalTime: 23 May 2011 15:39:02.0987 (UTC) FILETIME=[8AE6C9B0:01CC195F] Subject: Re: [Idr] I-D Action:draft-ietf-idr-reserved-extended-communities-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 15:44:47 -0000 Hi, Draft has been updated to reflect the two changes previously proposed on the mailing list: - Name changed from "Reserved extended communities" to "Assigned extended communities" - Instead of getting 2 new extended community types, use of the reserved AS number 0 in "generic four-octet AS specific" extended communities. As a reminder, the above changes have been proposed in the following emails: - http://www.ietf.org/mail-archive/web/idr/current/msg04893.html - http://www.ietf.org/mail-archive/web/idr/current/msg04883.html Thanks, Regards, Bruno >-----Original Message----- >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >Sent: Monday, May 23, 2011 5:24 PM >To: i-d-announce@ietf.org >Cc: idr@ietf.org >Subject: [Idr] I-D Action:draft-ietf-idr-reserved-extended-communities-01.txt > >A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work >item of the Inter-Domain Routing Working Group of the IETF. > > Title : Assigned BGP extended communities > Author(s) : Bruno Decraene > Pierre Francois > Filename : draft-ietf-idr-reserved-extended-communities-01.txt > Pages : 5 > Date : 2011-05-23 > > This document defines two IANA registries in order to assign > transitive and non-transitive extended communities from. These are > similar to the existing well-known BGP communities defined in RFC > 1997 but provide an easier control of inter-AS community > advertisement as a community could be chosen as transitive or non- > transitive across ASes. > > For that purpose, this document defines the use of the reserved AS > number 0 for the transitive and non-transitive generic four-octet AS > specific extended community types. > > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-idr-reserved-extended-co mmunities-01.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-idr-reserved-extended-com munities-01.txt >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From raszuk@cisco.com Mon May 23 12:30:26 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B70E0824 for ; Mon, 23 May 2011 12:30:26 -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 r6p9a-j1AQu0 for ; Mon, 23 May 2011 12:30:26 -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 193E8E06B6 for ; Mon, 23 May 2011 12:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1809; q=dns/txt; s=iport; t=1306179026; x=1307388626; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=GUbHsKN7Opvb/k+q+MlQzV8sCsV4ZwEgomf/z7sNhBg=; b=ZmOrfYdj+dLPy2CKL1ykgXRdyIgtbNQGRyLUAbv9PA0mVOd2bwtqE+Td JloqEPMdWmKnyviaB5MDqLjWvAyfbp0V4oQvzZs/Wrbu/tYKP9cV8ktX5 726PpMbPgDmCvqnR0iW7LW2pC1FxrtnLwXU8nJ7O47FoiBR3De2yw7qYT 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHS02k2rRDoI/2dsb2JhbACmJ3encYJ5DwGaToYZBJARhC+KSA X-IronPort-AV: E=Sophos;i="4.65,258,1304294400"; d="scan'208";a="362656757" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 23 May 2011 19:30:25 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4NJUOp4009579; Mon, 23 May 2011 19:30:25 GMT Message-ID: <4DDAB5D0.1010406@cisco.com> Date: Mon, 23 May 2011 21:30:24 +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: "shares@ndzh.com" , John Scudder Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: [Idr] Fwd: [SUMMARY] Fwd: Dissemination of Flow Specification Rules for IPv6 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 19:30:26 -0000 2nd try ... -------- Original Message -------- Subject: [Idr] [SUMMARY] Fwd: Dissemination of Flow Specification Rules for IPv6 Date: Fri, 15 Apr 2011 16:42:59 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com To: shares@ndzh.com , John Scudder CC: idr@ietf.org List , Burjiz Pithawala , Danny McPherson Dear IDR WG chairs, After over two weeks of WG call for adoption of "Dissemination of Flow Specification Rules for IPv6" draft here is the summary of the feedback received: Support: jeff.tantsura@ericsson.com jhaas@pfrc.org wim.henderickx@alcatel-lucent.com bashandy@cisco.com ilya@nobulus.com tom@someaddress.net hritter@cisco.com danny@tcb.net Torunn.Narvestad@telenor.com christian.jacquenet@orange-ftgroup.com shane@castlepoint.net No support: None. If I accidentally missed any vote please kindly let me know and the above list will be updated. Therefor the authors of the draft would like to ask chairs for the recommendation on next step for this document. Rgs, R. Raszuk B. Pithawala D. McPherson -------- Original Message -------- Subject: Dissemination of Flow Specification Rules for IPv6 Date: Thu, 31 Mar 2011 15:31:42 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com To: idr@ietf.org List Authors of "Dissemination of Flow Specification Rules for IPv6" draft document would like to propose the adoption of this work as the IDR WG item. Ref: http://tools.ietf.org/html/draft-raszuk-idr-flow-spec-v6-01 Rgs, R. Raszuk B. Pithawala D. McPherson _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From zhangmingui@huawei.com Thu May 26 04:20:51 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B250EE0664; Thu, 26 May 2011 04:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6iN3nMuBRZ7; Thu, 26 May 2011 04:20:51 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 37A89E06E2; Thu, 26 May 2011 04:20:50 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS00994VCI89@szxga04-in.huawei.com>; Thu, 26 May 2011 19:17:06 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS002ASVCITU@szxga04-in.huawei.com>; Thu, 26 May 2011 19:17:06 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 26 May 2011 19:16:56 +0800 Received: from SZXEML503-MBX.china.huawei.com ([169.254.7.71]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 26 May 2011 19:17:06 +0800 Date: Thu, 26 May 2011 11:17:05 +0000 From: "Zhangmingui, (Mingui)" X-Originating-IP: [10.110.98.83] To: "sidr@ietf.org" Message-id: <4552F0907735844E9204A62BBDD325E737F477@SZXEML503-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [SIDR][IDR]Does DBGP have to be contiguously deployed? Thread-index: AcwblnDrNvIQluMLSdaIOwAOFxKpTw== X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "idr@ietf.org" Subject: [Idr] [SIDR][IDR]Does DBGP have to be contiguously deployed? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 11:20:51 -0000 Hi all, The answer is that DBGP does NOT require contiguous deployment in order to be effective. The key purpose of DBGP is to recognize and propagate the suspicious path segment via the DAS-PATH. When the AS router at the far side obtain the UPDATE message with the DAS-PATH missing some intermediate AS numbers, it doesn't matter. This AS router can still use this path segment for detection/validation purpose. Let's use the example in Figure 5.1 to explain (http://tools.ietf.org/html/draft-zhang-idr-decoupling-02). The starter AS router of the DAS-PATH must have deployed DBGP. In this figure, "B" is the starter. "B" can recognize "X" as suspicious node and propagates this via DAS-PATH to "A". We suppose "A" has not deployed DBGP. When A's upstream AS router receives A's update message, it will find that the AS-PATH is "ABCO" and the DAS-PATH is "BX". The detection system just uses "BX" as the input. BTW, it is not recommended to complement the DAS-PATH according to the primary path contained in the same UDPATE message. You will easily find this kind of trick is in vain. Best regards, -- Mingui Zhang Huawei Technologies Co.,Ltd From internet-drafts@ietf.org Thu May 26 07:35:18 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5B0E0746; Thu, 26 May 2011 07:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 PZg-cEBkJdOq; Thu, 26 May 2011 07:35:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3D0E0657; Thu, 26 May 2011 07:35:17 -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 X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110526143517.21755.16088.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2011 07:35:17 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-add-paths-guidelines-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 14:35:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Best Practices for Advertisement of Multiple Paths in IB= GP Author(s) : Jim Uttaro Virginie Van den Schrieck Pierre Francois Roberto Fragassi Adam Simpson Pradosh Mohapatra Filename : draft-ietf-idr-add-paths-guidelines-01.txt Pages : 22 Date : 2011-05-26 Add-Paths is a BGP enhancement that allows a BGP router to advertise multiple distinct paths for the same prefix/NLRI. This provides a number of potential benefits, including reduced routing churn, faster convergence and better loadsharing. This document provides recommendations to implementers of Add-Paths so that network operators have the tools needed to address their specific applications and to manage the scalability impact of Add- Paths. A router implementing Add-Paths may learn many paths for a prefix and must decide which of these to advertise to peers. This document analyses different algorithms for making this selection and provides recommendations based on the target application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-add-paths-guidelines-01.= 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-idr-add-paths-guidelines-01.t= xt From iesg-secretary@ietf.org Tue May 31 08:31:25 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5ECE0749; Tue, 31 May 2011 08:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 Y2rM7P04x1cU; Tue, 31 May 2011 08:31:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45034E0818; Tue, 31 May 2011 08:31:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110531153116.449.24516.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2011 08:31:16 -0700 Cc: idr mailing list , idr chair , RFC Editor Subject: [Idr] Protocol Action: 'AS-wide Unique BGP Identifier for BGP-4' to Proposed Standard (draft-ietf-idr-bgp-identifier-14.txt) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 15:31:25 -0000 The IESG has approved the following document: - 'AS-wide Unique BGP Identifier for BGP-4' (draft-ietf-idr-bgp-identifier-14.txt) as a Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-identifier/ Technical Summary The base BGP specification defined the BGP Identifier as "a valid IPv4 host address". This is problematic in some contexts including IPv6-only networks. This document relaxes the definition to be a 4-octet unsigned, non-zero integer, and relaxes the "uniqueness" requirement so that only AS-wide uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issue. Working Group Summary The document has received extensive WG review and is generally non-controversial and clearly needed. Document Quality There are several existing implementations, and furthermore the document makes no on-the-wire protocol changes and is backward compatible. The document does not use RFC 2119 language but I don't view this as a problem. Personnel John Scudder is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. RFC Editor Note At the end of the abstract please add: This document updates RFC 4271. ========