Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Igor Bryskin <i_bryskin@yahoo.com> Wed, 03 September 2008 14:51 UTC
Return-Path: <owner-ccamp@ops.ietf.org>
X-Original-To: ietfarch-ccamp-archive@core3.amsl.com
Delivered-To: ietfarch-ccamp-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C69B3A6403 for <ietfarch-ccamp-archive@core3.amsl.com>; Wed, 3 Sep 2008 07:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.34
X-Spam-Level: **
X-Spam-Status: No, score=2.34 tagged_above=-999 required=5 tests=[AWL=-2.649, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_53=0.6, MANGLED_FROM=2.3, RDNS_NONE=0.1, SARE_OBFU_SPLIT_HR2=0.183]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELKFttF1+4oP for <ietfarch-ccamp-archive@core3.amsl.com>; Wed, 3 Sep 2008 07:51:41 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 70F4B3A6C4E for <ccamp-archive@ietf.org>; Wed, 3 Sep 2008 07:51:26 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KatUk-000Eqw-OP for ccamp-data@psg.com; Wed, 03 Sep 2008 14:38:06 +0000
Received: from [209.191.85.54] (helo=web36803.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from <i_bryskin@yahoo.com>) id 1KatUP-000EoE-Hl for ccamp@ops.ietf.org; Wed, 03 Sep 2008 14:37:59 +0000
Received: (qmail 19496 invoked by uid 60001); 3 Sep 2008 14:37:42 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=gxkwTN2micFrC+ZCcU4uAddBlvXSC1xOfIajtdA1Dvmcmd69Fi8i9CqvIXMVuEq8OASBRWxp0KM8aF2CJPR1x2yAqa9KJWwdaHQsHjXOxCeIufgB2z1ZIfYnTntYAYK4LBM7akDt6mUzoFnnGpVXiOAX+WADK1jfJ8MFaXNwSYI=;
X-YMail-OSG: apEY4wEVM1mJRxO1uQNfBuscp7S4tKbsG_VACyMMlQeQN2GoySZM_1PRtCt0xMV7HoaUfvEIfdJaPF2TesTzo7oBGldnP0vJad4a2WVS6or0lj6DS6FMPNyQaKeZYwmpg1oh1Srwv_ciLGFovT4-
Received: from [67.102.145.11] by web36803.mail.mud.yahoo.com via HTTP; Wed, 03 Sep 2008 07:37:42 PDT
X-Mailer: YahooMailRC/1096.28 YahooMailWebService/0.7.218.2
Date: Wed, 03 Sep 2008 07:37:42 -0700
From: Igor Bryskin <i_bryskin@yahoo.com>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
To: Yakov Rekhter <yakov@juniper.net>
Cc: "Drake, John E" <John.E.Drake2@boeing.com>, Lou Berger <lberger@labn.net>, Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org, softwires@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1852435290-1220452662=:19087"
Message-ID: <627706.19087.qm@web36803.mail.mud.yahoo.com>
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>
Yaokov, Please, see in-line. ----- Original Message ---- From: Yakov Rekhter <yakov@juniper.net> To: Igor Bryskin <i_bryskin@yahoo.com> Cc: "Drake, John E" <John.E.Drake2@boeing.com>; Lou Berger <lberger@labn.net>; Adrian Farrel <adrian@olddog.co.uk>; ccamp@ops.ietf.org; softwires@ietf.org Sent: Wednesday, September 3, 2008 9:55:49 AM Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) Igor, > And I am not arguing that sufficient redundancy must be provided. However you > said: > >For your suggested approach to work with sufficient > >redundancy, the topology of the overlay needs to be configured > >such that every selected P router is connected to at least two > >other selected P routers and every PE router needs to be > >connected to at least two selected P routers. > > If you just simply interconnect all VPN-aware PEs into a single > ring via IPin IP tunnels and run an instance of OSPF to distribute > VPN-related information between them, it will provide sufficient > redundancy and involve exactly *zero* Ps. > > So, I want you to drop your lecturing tone for a minute and simply > tell in what respect in your opinion this approach is not perfect > fo the L1VPN application. Otherwise, I am not interested in this > discussion any longer. I do like to hear comments from other people. Since you asked, one problem with using OSPF, as John correctly pointed out, is that you are left with a situation in which *every* PE router will have *all* L1VPN routes for all the L1VPNs. Of course, this is "perfect" in a sense that you can do no worse than that :-) IB>> Ok. Several points here. Note that neither Ps nor VPN-unaware PEs participate in the distribution/maintenance of VPN information, which is already significantly better than what you said about the OSPF solution in your previous mail: >... And while on the subject of scaling, please keep in mind that BGP > only stores L1VPN routes on PEs that have sites of that VPN > connected to them, and on an RR if used, but *not* on any of the P > routers. In contrast, rfc5252 (OSPF for L1VPN > autodiscovery) results in storing *all VPN TE information > for all the VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based > approach scales better than OSPF-based approach. > >>>>Yakov. I do agree that if you use a single ring overlay interconnecting all VPN aware PEs you will have LSDBs at all PEs contain VPN info about all VPNs. However, in case of L1VPN this is not VPN routes, rather VPN Provider-To-Customer port mappings which I believe will prove to be sugnifficantly smaller, so I am not sure yet how bad is that. In any case, if it does present a problem on a network with large number of VPNs, who said that it has to be a single overlay? Why not to configure several overlays - each containing a single ring that interconnects PEs participating in a common sub-set of VPNs, and run a seperate instance of OSPF in each overlay? Igor > > > > > ----- Original Message ---- > From: "Drake, John E" <John.E.Drake2@boeing.com> > To: Igor Bryskin <i_bryskin@yahoo.com>; Yakov Rekhter <yakov@juniper.net>; Lo u Berger <lberger@labn.net> > Cc: Yakov Rekhter <yakov@juniper.net>; Adrian Farrel <adrian@olddog.co.uk>; c camp@ops.ietf.org; softwires@ietf.org > Sent: Wednesday, September 3, 2008 8:10:07 AM > Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question) > > Igor, > > Actually, I am not sure that you do understand what I wrote, because you > are providing examples of the redundancy that I specified - every PE > router needs to have connectivity to two other routers in the IGP > instance. > > Thanks, > > John > > >-----Original Message----- > >From: Igor Bryskin [mailto:i_bryskin@yahoo.com] > >Sent: Tuesday, September 02, 2008 3:06 PM > >To: Drake, John E; Yakov Rekhter; Lou Berger > >Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org; > >softwires@ietf.org > >Subject: Re: [Softwires] BGP TE attr last call by softwires WG > >(2nd question) > > > >Hi John, > > > >I understand what you are saying and disagree. The overlay I > >am talking about logically is a separate network and as any > >network it should be sufficiently redundant to function. There > >is a number of ways how you can address the redundancy > >concerns. Look at the examples below: > > > >a) interconnect all VPN-aware PEs into a single ring: > >PE=======PE > > || || > >PE PE > >|| || > >PE PE > >|| || > >... .... > >PE=======PE > > > >b) connect each PE to two interconnected Ps > > > >PE P PE > > || > >PE || PE > > || > >PE || PE > > || > >... || .... > >PE P PE > > > > > >Note that tunnels can traverse any number of VPN-unaware Ps and PEs. > > > >Igor > > > > > >----- Original Message ---- > >From: "Drake, John E" <John.E.Drake2@boeing.com> > >To: Igor Bryskin <i_bryskin@yahoo.com>; Yakov Rekhter > ><yakov@juniper.net>; Lou Berger <lberger@labn.net> > >Cc: Yakov Rekhter <yakov@juniper.net>; Adrian Farrel > ><adrian@olddog.co.uk>; ccamp@ops.ietf.org; softwires@ietf.org > >Sent: Tuesday, September 2, 2008 2:24:26 PM > >Subject: RE: [Softwires] BGP TE attr last call by softwires WG > >(2nd question) > > > >Igor, > > > >Several years ago when OSPF was first proposed as an > >autodiscovery mechanism for L1VPNs, you were told that it was > >a bad idea due to its scaling properties and impact on the IGP. > > > >You are now tacitly agreeing with those who told you it was a bad idea. > > > >For your suggested approach to work with sufficient > >redundancy, the topology of the overlay needs to be configured > >such that every selected P router is connected to at least two > >other selected P routers and every PE router needs to be > >connected to at least two selected P routers. > > > >When you are done with this configuration, you are left with a > >situation in which *every* PE and selected P router will have > >*all* L1VPN routes. > > > >Thanks, > > > >John > > > >>-----Original Message----- > >>From: Igor Bryskin [mailto:i_bryskin@yahoo.com] > >>Sent: Friday, August 29, 2008 12:10 PM > >>To: Drake, John E; Yakov Rekhter; Lou Berger > >>Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org; > >>softwires@ietf.org > >>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd > >>question) > >> > >>Are you calling me silly? Are you coming to Minneapolis? :=) > >> > >>Seriously, what is wrong in your opinion with this approach? > >>Many people are talking about multi-instance IGPs. What they have in > >>mind is improving the IGP scalability: > >>a) by removing non-IP advertisements from the instance of IGP that > >>manages IP routing/forwarding tables into separate IGP instance(s); > >>b) by distributing non-IP information only to and via > >inerested parties > >>leaving the bulk of Ps out of the process. > >> > >>In my opinion this is exactly what is needed for the OSPF-based L1VPN > >>application. > >> > >>Igor > >> > >> > >> > >> > >> > >> > >>----- Original Message ---- > >>From: "Drake, John E" <John.E.Drake2@boeing.com> > >>To: Igor Bryskin <i_bryskin@yahoo.com>; Yakov Rekhter > >><yakov@juniper.net>; Lou Berger <lberger@labn.net> > >>Cc: Yakov Rekhter <yakov@juniper.net>; Adrian Farrel > >><adrian@olddog.co.uk>; ccamp@ops.ietf.org; softwires@ietf.org > >>Sent: Friday, August 29, 2008 2:31:36 PM > >>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd > >>question) > >> > >>So you are proposing an OSPF route reflector? At what point does the > >>silliness stop? > >> > >>>-----Original Message----- > >>>From: Igor Bryskin [mailto:i_bryskin@yahoo.com] > >>>Sent: Friday, August 29, 2008 11:29 AM > >>>To: Drake, John E; Yakov Rekhter; Lou Berger > >>>Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org; > >>>softwires@ietf.org > >>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd > >>>question) > >>> > >>>Hi John, > >>> > >>>No, not really. When you add a PE you configure local > >>interfaces, local > >>>VPN port mappings, stuff like that. While doing this you will also > >>>configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN > >>>OSPF instance on the tunnel. > >>>Once you did that the local VPN information will be flooded > >>accross the > >>>overlay, likewise, the new PE will get all the necessary information > >>>from other PEs. > >>> > >>>Cheers, > >>>Igor > >>> > >>> > >>>----- Original Message ---- > >>>From: "Drake, John E" <John.E.Drake2@boeing.com> > >>>To: Igor Bryskin <i_bryskin@yahoo.com>; Yakov Rekhter > >>><yakov@juniper.net>; Lou Berger <lberger@labn.net> > >>>Cc: Yakov Rekhter <yakov@juniper.net>; Adrian Farrel > >>><adrian@olddog.co.uk>; ccamp@ops.ietf.org; softwires@ietf.org > >>>Sent: Friday, August 29, 2008 11:20:16 AM > >>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd > >>>question) > >>> > >>>Igor, > >>> > >>>Doesn't this defeat auto-discovery? I.e., how is a new PE > >added to a > >>>given L1VPN? > >>> > >>>Thanks, > >>> > >>>John > >>> > >>>>-----Original Message----- > >>>>From: Igor Bryskin [mailto:i_bryskin@yahoo.com] > >>>>Sent: Friday, August 29, 2008 5:51 AM > >>>>To: Yakov Rekhter; Lou Berger > >>>>Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org; > >>>>softwires@ietf.org > >>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd > >>>>question) > >>>> > >>>>Yakov, > >>>> > >>>>You said: > >>>> > >>>> > >>>>... And while on the subject of scaling, please keep in mind > >>that BGP > >>>>only stores L1VPN routes on PEs that have sites of that VPN > >>connected > >>>>to them, and on an RR if used, but *not* on any of the P > >routers. In > >>>>contrast, rfc5252 (OSPF for L1VPN > >>>>autodiscovery) results in storing *all VPN TE information > >for all the > >>>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based > >>>>approach scales better than OSPF-based approach. > >>>> > >>>>Yakov. > >>>> > >>>>This is not true in case of multi-instance OSPF: one can build an > >>>>overlay interconnecting PEs via one or small number of Ps > >>>using IPinIP > >>>>tunnels and run in this overlay an instance of OSPF specifically > >>>>designated for distribution of L1VPN information. In this > >>>case the OSPF > >>>>solution won't scale any worse than the BGP approach. Note. > >>>that rfc252 > >>>>never said that the instance of OSPF used for flooding of the L1VPN > >>>>information must be the same instance that is used for the > >>>distribution > >>>>of IP-related LSAs. > >>>> > >>>>Regards, > >>>>Igor > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >> > >> > >> > > > > > > > > > > > > --0-1141253910-1220449648=:97601 > Content-Type: text/html; charset=us-ascii > > <html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head>< body><div style="font-family:times new roman, new york, times, serif;font-size: 12pt"><div>And I am not arguing that sufficient redundancy must be provided. Ho wever you said:<br>>For your suggested approach to work with sufficient <br> >redundancy, the topology of the overlay needs to be configured <br>>such that every selected P router is connected to at least two <br>>other select ed P routers and every PE router needs to be <br>>connected to at least two selected P routers.<br><br>If you just simply interconnect all VPN-aware PEs in to a single ring via IPinIP tunnels and run an instance of OSPF to distribute V PN-related information between them, it will provide sufficient redundancy and involve exactly *zero* Ps.<br>So, I want you to drop your lecturing tone for a minute and simply tell in what respect in your opinion this approach is not per fect fo the L1VPN > application. Otherwise, I am not interested in this discussion any longer. I do like to hear comments from other people.<br><br>Igor <br><br></div><div sty le="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><d iv style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Orig inal Message ----<br>From: "Drake, John E" <John.E.Drake2@boeing.com><br> To: Igor Bryskin <i_bryskin@yahoo.com>; Yakov Rekhter <yakov@juniper.n et>; Lou Berger <lberger@labn.net><br>Cc: Yakov Rekhter <yakov@juni per.net>; Adrian Farrel <adrian@olddog.co.uk>; ccamp@ops.ietf.org; sof twires@ietf.org<br>Sent: Wednesday, September 3, 2008 8:10:07 AM<br>Subject: RE : [Softwires] BGP TE attr last call by softwires WG (2nd question)<br><br> > Igor,<br><br>Actually, I am not sure that you do understand what I wrote, bec ause you<br>are providing examples of the redundancy that I specified - every P E<br>router needs to have connectivity to two other routers in the IGP<br>insta nce.<br><br>Thanks,<br><br>John <br><br>>-----Original Message-----<br>>F rom: Igor Bryskin [mailto:<a ymailto="mailto:i_bryskin@yahoo.com" href="mailto: i_bryskin@yahoo.com">i_bryskin@yahoo.com</a>] <br>>Sent: Tuesday, September 02, 2008 3:06 PM<br>>To: Drake, John E; Yakov Rekhter; Lou Berger<br>>Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:ccamp@ops.ietf.org" href="mai lto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a>; <br>><a ymailto="mailto:soft wires@ietf.org" href="mailto:softwires@ietf.org">softwires@ietf.org</a><br>> Subject: Re: [Softwires] BGP TE attr last call by softwires WG <br>>(2nd que stion)<br>><br>>Hi John,<br>><br>>I understand what you are saying and disagree. The > overlay I <br>>am talking about logically is a separate network and as an y <br>>network it should be sufficiently redundant to function. There <br>&g t;is a number of ways how you can address the redundancy <br>>concerns. Look at the examples below:<br>><br>>a) interconnect all VPN-aware PEs into a single ring: <br>>PE=======PE<br>> || ||<br>>PE &nbs p; PE <br>>|| ||<br>>PE PE <br>& gt;|| ||<br>> ... ....<br>>PE====== =PE<br>><br>>b) connect each PE to two interconnected Ps <br>><br>> PE P   ; > PE<br>> &n bsp; || < br>>PE || &nbs p; PE <br>> &n bsp; || &n bsp; <br>>PE & nbsp; || PE <br>>   ; || <br>>...& nbsp; || ....<br>>PE & nbsp; P & nbsp; > PE<br>><br>><br>>Note that tunnels can traverse any number of VPN-u naware Ps and PEs.<br>><br>>Igor<br>><br>><br>>----- Original Me ssage ----<br>>From: "Drake, John E" <<a ymailto="mailto:John.E.Drake2@bo eing.com" href="mailto:John.E.Drake2@boeing.com">John.E.Drake2@boeing.com</a>&g t;<br>>To: Igor Bryskin <<a ymailto="mailto:i_bryskin@yahoo.com" href="ma ilto:i_bryskin@yahoo.com">i_bryskin@yahoo.com</a>>; Yakov Rekhter <br>>&l t;<a ymailto="mailto:yakov@juniper.net" href="mailto:yakov@juniper.net">yakov@j uniper.net</a>>; Lou Berger <<a ymailto="mailto:lberger@labn.net" href="m ailto:lberger@labn.net">lberger@labn.net</a>><br>>Cc: Yakov Rekhter << a ymailto="mailto:yakov@juniper.net" href="mailto:yakov@juniper.net">yakov@juni per.net</a>>; Adrian Farrel <br>><<a ymailto="mailto:adrian@olddog.co. uk" href="mailto:adrian@olddog.co.uk">adrian@olddog.co.uk</a>>; <a > ymailto="mailto:ccamp@ops.ietf.org" href="mailto:ccamp@ops.ietf.org">ccamp@o ps.ietf.org</a>; <a ymailto="mailto:softwires@ietf.org" href="mailto:softwires@ ietf.org">softwires@ietf.org</a><br>>Sent: Tuesday, September 2, 2008 2:24:2 6 PM<br>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG <br> >(2nd question)<br>><br>>Igor,<br>><br>>Several years ago when O SPF was first proposed as an <br>>autodiscovery mechanism for L1VPNs, you we re told that it was <br>>a bad idea due to its scaling properties and impact on the IGP.<br>><br>>You are now tacitly agreeing with those who told yo u it was a bad idea.<br>><br>>For your suggested approach to work with su fficient <br>>redundancy, the topology of the overlay needs to be configured <br>>such that every selected P router is connected to at least two <br>> ;other selected P routers and every PE router needs to be <br>>connected to at least two selected > P routers.<br>><br>>When you are done with this configuration, you are left with a <br>>situation in which *every* PE and selected P router will h ave <br>>*all* L1VPN routes.<br>><br>>Thanks,<br>><br>>John <br> ><br>>>-----Original Message-----<br>>>From: Igor Bryskin [mailt o:<a ymailto="mailto:i_bryskin@yahoo.com" href="mailto:i_bryskin@yahoo.com">i_b ryskin@yahoo.com</a>]<br>>>Sent: Friday, August 29, 2008 12:10 PM<br>> >To: Drake, John E; Yakov Rekhter; Lou Berger<br>>>Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:ccamp@ops.ietf.org" href="mailto:ccamp@ops.ie tf.org">ccamp@ops.ietf.org</a>; <br>>><a ymailto="mailto:softwires@ietf.o rg" href="mailto:softwires@ietf.org">softwires@ietf.org</a><br>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd <br>>>questio n)<br>>><br>>>Are you calling me silly? Are you coming to Minneapol is? > :=)<br>>><br>>>Seriously, what is wrong in your opinion with thi s approach? <br>>>Many people are talking about multi-instance IGPs. What they have in <br>>>mind is improving the IGP scalability:<br>>>a) by removing non-IP advertisements from the instance of IGP that <br>>>man ages IP routing/forwarding tables into separate IGP instance(s);<br>>>b) by distributing non-IP information only to and via <br>>inerested parties <b r>>>leaving the bulk of Ps out of the process.<br>>><br>>>In my opinion this is exactly what is needed for the OSPF-based L1VPN <br>>> application.<br>>><br>>>Igor<br>>><br>>><br>>><br >>><br>>><br>>><br>>>----- Original Message ----<br>> ;>From: "Drake, John E" <<a ymailto="mailto:John.E.Drake2@boeing.com" hre f="mailto:John.E.Drake2@boeing.com">John.E.Drake2@boeing.com</a>><br>>> ;To: Igor Bryskin > <<a ymailto="mailto:i_bryskin@yahoo.com" href="mailto:i_bryskin@yahoo.com ">i_bryskin@yahoo.com</a>>; Yakov Rekhter <br>>><<a ymailto="mailto :yakov@juniper.net" href="mailto:yakov@juniper.net">yakov@juniper.net</a>>; Lou Berger <<a ymailto="mailto:lberger@labn.net" href="mailto:lberger@labn.n et">lberger@labn.net</a>><br>>>Cc: Yakov Rekhter <<a ymailto="mailt o:yakov@juniper.net" href="mailto:yakov@juniper.net">yakov@juniper.net</a>>; Adrian Farrel <br>>><<a ymailto="mailto:adrian@olddog.co.uk" href="ma ilto:adrian@olddog.co.uk">adrian@olddog.co.uk</a>>; <a ymailto="mailto:ccamp @ops.ietf.org" href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a>; <a ymai lto="mailto:softwires@ietf.org" href="mailto:softwires@ietf.org">softwires@ietf .org</a><br>>>Sent: Friday, August 29, 2008 2:31:36 PM<br>>>Subject : RE: [Softwires] BGP TE attr last call by softwires WG (2nd > <br>>>question)<br>>><br>>>So you are proposing an OSPF ro ute reflector? At what point does the <br>>>silliness stop?<br>> ><br>>>>-----Original Message-----<br>>>>From: Igor Bryski n [mailto:<a ymailto="mailto:i_bryskin@yahoo.com" href="mailto:i_bryskin@yahoo. com">i_bryskin@yahoo.com</a>]<br>>>>Sent: Friday, August 29, 2008 11:2 9 AM<br>>>>To: Drake, John E; Yakov Rekhter; Lou Berger<br>>>> ;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:ccamp@ops.ietf.org" href= "mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a>; <br>>>><a ymailto= "mailto:softwires@ietf.org" href="mailto:softwires@ietf.org">softwires@ietf.org </a><br>>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd<br>>>>question)<br>>>><br>>>>Hi John,<br>&g t;>><br>>>>No, not really. When you add a PE you configure > local<br>>>interfaces, local<br>>>>VPN port mappings, stuff l ike that. While doing this you will also <br>>>>configure an IPinIP tu nnel to one of your spoke Ps and enable L1VPN <br>>>>OSPF instance on the tunnel.<br>>>>Once you did that the local VPN information will be flooded<br>>>accross the<br>>>>overlay, likewise, the new PE wil l get all the necessary information <br>>>>from other PEs.<br>>> ><br>>>>Cheers,<br>>>>Igor<br>>>><br>>>> <br>>>>----- Original Message ----<br>>>>From: "Drake, John E " <<a ymailto="mailto:John.E.Drake2@boeing.com" href="mailto:John.E.Drake2@b oeing.com">John.E.Drake2@boeing.com</a>><br>>>>To: Igor Bryskin < ;<a ymailto="mailto:i_bryskin@yahoo.com" href="mailto:i_bryskin@yahoo.com">i_br yskin@yahoo.com</a>>; Yakov Rekhter <br>>>><<a ymailto="mailto:y akov@juniper.net" > href="mailto:yakov@juniper.net">yakov@juniper.net</a>>; Lou Berger <<a ymailto="mailto:lberger@labn.net" href="mailto:lberger@labn.net">lberger@labn. net</a>><br>>>>Cc: Yakov Rekhter <<a ymailto="mailto:yakov@junip er.net" href="mailto:yakov@juniper.net">yakov@juniper.net</a>>; Adrian Farre l <br>>>><<a ymailto="mailto:adrian@olddog.co.uk" href="mailto:adri an@olddog.co.uk">adrian@olddog.co.uk</a>>; <a ymailto="mailto:ccamp@ops.ietf .org" href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a>; <a ymailto="mail to:softwires@ietf.org" href="mailto:softwires@ietf.org">softwires@ietf.org</a>< br>>>>Sent: Friday, August 29, 2008 11:20:16 AM<br>>>>Subject : RE: [Softwires] BGP TE attr last call by softwires WG (2nd<br>>>>que stion)<br>>>><br>>>>Igor,<br>>>><br>>>>Does n't this defeat auto-discovery? I.e., how is a new PE <br>>added to a <br>>>>given > L1VPN?<br>>>><br>>>>Thanks,<br>>>><br>>>> ;John<br>>>><br>>>>>-----Original Message-----<br>>> >>From: Igor Bryskin [mailto:<a ymailto="mailto:i_bryskin@yahoo.com" href ="mailto:i_bryskin@yahoo.com">i_bryskin@yahoo.com</a>]<br>>>>>Sent: Friday, August 29, 2008 5:51 AM<br>>>>>To: Yakov Rekhter; Lou Berg er<br>>>>>Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:ccam p@ops.ietf.org" href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a>; <br>&g t;>>><a ymailto="mailto:softwires@ietf.org" href="mailto:softwires@iet f.org">softwires@ietf.org</a><br>>>>>Subject: Re: [Softwires] BGP T E attr last call by softwires WG (2nd<br>>>>>question)<br>>>& gt;><br>>>>>Yakov,<br>>>>><br>>>>>You sa id:<br>>>>><br>>>>><br>>>>>... And while on the subject of > scaling, please keep in mind<br>>>that BGP<br>>>>>only sto res L1VPN routes on PEs that have sites of that VPN<br>>>connected<br>> ;>>>to them, and on an RR if used, but *not* on any of the P <br>>r outers. In <br>>>>>contrast, rfc5252 (OSPF for L1VPN<br>>>> ;>autodiscovery) results in storing *all VPN TE information <br>>for all the<br>>>>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based <br>>>>>approach scales better than OSPF-based approach. <br>>>>><br>>>>>Yakov.<br>>>>><br>>>& gt;>This is not true in case of multi-instance OSPF: one can build an <br>&g t;>>>overlay interconnecting PEs via one or small number of Ps<br>> >>using IPinIP<br>>>>>tunnels and run in this overlay an inst ance of OSPF specifically <br>>>>>designated for distribution of L1 VPN information. In > this<br>>>>case the OSPF<br>>>>>solution won't scale an y worse than the BGP approach. Note. <br>>>>that rfc252<br>>>> ;>never said that the instance of OSPF used for flooding of the L1VPN <br>&g t;>>>information must be the same instance that is used for the<br>> ;>>distribution<br>>>>>of IP-related LSAs.<br>>>>> ;<br>>>>>Regards,<br>>>>>Igor<br>>>>><br>&g t;>>><br>>>>><br>>>>><br>>>><br>>& gt;><br>>>><br>>>><br>>><br>>><br>>><br> ><br>><br>><br>><br><br></div></div></div><br> > > </body></html> > --0-1141253910-1220449648=:97601--
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- RE: [Softwires] BGP TE attr last call by softwire… Drake, John E
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- RE: [Softwires] BGP TE attr last call by softwire… Drake, John E
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- RE: [Softwires] BGP TE attr last call by softwire… Drake, John E
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- RE: [Softwires] BGP TE attr last call by softwire… Drake, John E
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- Re: [Softwires] BGP TE attr last call by softwire… Yakov Rekhter
- RE: [Softwires] BGP TE attr last call by softwire… Drake, John E
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- RE: [Softwires] BGP TE attr last call by softwire… Drake, John E
- Re: [Softwires] BGP TE attr last call by softwire… Yakov Rekhter
- RE: [Softwires] BGP TE attr last call by softwire… Tony Li
- Re: [Softwires] BGP TE attr last call by softwire… Lou Berger
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- RE: [Softwires] BGP TE attr last call by softwire… Tony Li
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- Re: [Softwires] BGP TE attr last call by softwire… Lou Berger
- Re: [Softwires] BGP TE attr last call by softwire… Adrian Farrel
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin