RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
"Drake, John E" <John.E.Drake2@boeing.com> Tue, 02 September 2008 18:38 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 6D7283A6927 for <ietfarch-ccamp-archive@core3.amsl.com>; Tue, 2 Sep 2008 11:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.452
X-Spam-Level:
X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=-3.157, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1]
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 WCiQdNAevRFl for <ietfarch-ccamp-archive@core3.amsl.com>; Tue, 2 Sep 2008 11:38:53 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B46E3A6A16 for <ccamp-archive@ietf.org>; Tue, 2 Sep 2008 11:38:53 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1Kaadz-0003HU-Hw for ccamp-data@psg.com; Tue, 02 Sep 2008 18:30:23 +0000
Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <John.E.Drake2@boeing.com>) id 1Kaadr-0003GR-4M for ccamp@ops.ietf.org; Tue, 02 Sep 2008 18:30:18 +0000
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m82IOSWI028034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Sep 2008 11:24:34 -0700 (PDT)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m82IOSfX022841; Tue, 2 Sep 2008 11:24:28 -0700 (PDT)
Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m82IORA6022821; Tue, 2 Sep 2008 11:24:28 -0700 (PDT)
Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Sep 2008 11:24:28 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Date: Tue, 02 Sep 2008 11:24:26 -0700
Message-ID: <51661468CBD1354294533DA79E85955A010A08A1@XCH-SW-5V2.sw.nos.boeing.com>
In-Reply-To: <163244.22737.qm@web36801.mail.mud.yahoo.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Thread-Index: AckKCt8sop060WOeRs67j10vgmblWQDHcZGw
References: <163244.22737.qm@web36801.mail.mud.yahoo.com>
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
X-OriginalArrivalTime: 02 Sep 2008 18:24:28.0053 (UTC) FILETIME=[2281EC50:01C90D29]
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>
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 >>> >>> >>> >>> >> >> >> >> > > >
- 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