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

From: Igor Bryskin <[email-masked]>
Date: Fri, 29 Aug 2008 12:10:13 -0700 (PDT)

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" <[email-masked]>
To: Igor Bryskin <[email-masked]>; Yakov Rekhter <[email-masked]>; Lou Berger <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked]; [email-masked]
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:[email-masked]] 
>Sent: Friday, August 29, 2008 11:29 AM
>To: Drake, John E; Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>[email-masked]
>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" <[email-masked]>
>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
><[email-masked]>; Lou Berger <[email-masked]>
>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
><[email-masked]>; [email-masked]; [email-masked]
>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:[email-masked]]
>>Sent: Friday, August 29, 2008 5:51 AM
>>To: Yakov Rekhter; Lou Berger
>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>>[email-masked]
>>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
>>
>>
>>
>>
>
>
>
>

_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 2 Sep 2008 11:24:26 -0700

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 

>Sent: Friday, August 29, 2008 12:10 PM
>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.
>
>So you are proposing an OSPF route reflector?  At what point 
>does the silliness stop? 
>
>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.
>accross the 
>>overlay, likewise, the new PE will get all the necessary information 
>>from other PEs.
>>
>>Cheers,
>>Igor
>>
>>
>>Doesn't this defeat auto-discovery?  I.e., how is a new PE added to a 
>>given L1VPN?
>>
>>Thanks,
>>
>>John
>>