Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)

Igor Bryskin <i_bryskin@yahoo.com> Fri, 29 August 2008 19:20 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 23DC23A68A7 for <ietfarch-ccamp-archive@core3.amsl.com>; Fri, 29 Aug 2008 12:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.339
X-Spam-Level:
X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 odxiFjHNvw7x for <ietfarch-ccamp-archive@core3.amsl.com>; Fri, 29 Aug 2008 12:20:20 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9FE383A685D for <ccamp-archive@ietf.org>; Fri, 29 Aug 2008 12:20:19 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KZ9MR-000PgX-9H for ccamp-data@psg.com; Fri, 29 Aug 2008 19:10:19 +0000
Received: from [209.191.85.52] (helo=web36801.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from <i_bryskin@yahoo.com>) id 1KZ9MM-000Pfs-V8 for ccamp@ops.ietf.org; Fri, 29 Aug 2008 19:10:17 +0000
Received: (qmail 23651 invoked by uid 60001); 29 Aug 2008 19:10:14 -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=KnHwlhV8pszx+SUdQ5aXmXUymbEkh5cIW+gV0/QTPfmp9+fke1I6I47W3vLHMqqWW9s4IcXFyh2KDYxIYwuXqTKBnCz+5iBrxnPdY9OakRsB61em/fm4qdbAE80UbmuXkT5bxSZS986pCC6iwvoPkgjnQiI0T7Vm85hIM1kL/I4=;
X-YMail-OSG: u.Mrk5cVM1k1ZPNxTfCfE6iikhlk4Dizzh8phmKP4VvgjuwWhUkOtuMClqVuLpkuqQAj0Ag_8eHrtWQYme9vLAbBOVfqM7jfgYIM.lzM3GmQCcV3U3MAB4DnlHFSy0GHjwHGQnRPR6jT2ZpIlHk-
Received: from [67.102.145.11] by web36801.mail.mud.yahoo.com via HTTP; Fri, 29 Aug 2008 12:10:13 PDT
X-Mailer: YahooMailRC/1042.48 YahooMailWebService/0.7.218.2
Date: Fri, 29 Aug 2008 12:10:13 -0700
From: Igor Bryskin <i_bryskin@yahoo.com>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
To: "Drake, John E" <John.E.Drake2@boeing.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
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-575769772-1220037013=:22737"
Message-ID: <163244.22737.qm@web36801.mail.mud.yahoo.com>
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>

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
>>
>>
>>
>>
>
>
>
>