----- 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: Wednesday, September 3, 2008 10:01:29 AM
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Igor,
I'm sorry, but you were the one that stipulated P routers. I mentioned
the more general requirement in my last e-mail: "every PE router needs
to have connectivity to two other routers in the IGP instance".
The points being that:
1) The configuration burden is twice what you claimed it to be.
IB>> I was told on many occasions that configuration of IPinIP tunnels requires a lesser burden than configuring BGP sessions
2) Every PE router in the IGP instance has L1VPN routes that it doesn't
care about.
3) The number of L1VPN routes that a given PE router doesn't care about
is probably greater than the number of L1VPN routes it does care about.
IB>> As I answered to Yakov if this proves to be a problem you can configure multiple overlays
Thanks,
John
>-----Original Message-----
>From: Igor Bryskin [mailto:
i_bryskin@yahoo.com]
>Sent: Wednesday, September 03, 2008 6:47 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)
>
>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 IPinIP 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.
>
>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: 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>