Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Yakov Rekhter <yakov@juniper.net> Wed, 03 September 2008 14:08 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 D60933A6891 for <ietfarch-ccamp-archive@core3.amsl.com>; Wed, 3 Sep 2008 07:08:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-2.966, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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, RCVD_IN_DNSWL_MED=-4, 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 M6JLNhj+5J6X for <ietfarch-ccamp-archive@core3.amsl.com>; Wed, 3 Sep 2008 07:08:53 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C27863A6403 for <ccamp-archive@ietf.org>; Wed, 3 Sep 2008 07:08:52 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1Kasth-000ABM-Us for ccamp-data@psg.com; Wed, 03 Sep 2008 13:59:49 +0000
Received: from [64.18.2.165] (helo=exprod7og106.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <yakov@juniper.net>) id 1KastX-000AA5-8E for ccamp@ops.ietf.org; Wed, 03 Sep 2008 13:59:43 +0000
Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Wed, 03 Sep 2008 06:58:01 PDT
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 06:58:01 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 06:58:01 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 06:55:51 -0700
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m83Dtnu87842; Wed, 3 Sep 2008 06:55:49 -0700 (PDT) (envelope-from yakov@juniper.net)
Message-Id: <200809031355.m83Dtnu87842@magenta.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
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
In-reply-to: <986393.97601.qm@web36802.mail.mud.yahoo.com>
References: <986393.97601.qm@web36802.mail.mud.yahoo.com>
X-MH-In-Reply-To: Igor Bryskin <i_bryskin@yahoo.com> message dated "Wed, 03 Sep 2008 06:47:28 -0700."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <50339.1220450149.1@juniper.net>
Date: Wed, 03 Sep 2008 06:55:49 -0700
From: Yakov Rekhter <yakov@juniper.net>
X-OriginalArrivalTime: 03 Sep 2008 13:55:51.0365 (UTC) FILETIME=[C6A03F50:01C90DCC]
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>
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 :-) Yakov. > > > > > ----- 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