Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 2 May 2003 09:57:08 -0400

On Tue, 29 Apr 2003 08:02:01 -0400, Mike Duckett (Dotnet) <[email-masked]> wrote: 

>To determine which approach is better, we need to have a generally accepted
>problem definition (a.k.a., requirements). With a robust set of present
>and forward looking requirements, we can make better decisions. Which draft
>represents a consensus relative to L2VPN (PWS[Frame Relay, .,.,*],VPLS)
>requirements? Is draft-augustyn-ppvpn-l2vpn-requirements-00.txt
>representative of the problem space?
>
>I am personally interested in a solution (where the solution has a minimal
>number of unique protocols) that not only addresses VPLS but also supports
>many AC types (e.g,. Frame Relay) and robust capabilities
>signalling/negotiation. IOW, a solution optimized for VPLS that is not
>suited for point to point is not desirable. 

I think this is an important point and one that is insufficiently recognized. Many (all) service providers will offer VPWS and VPLS services as two variations of the same service class (i.e. ethernet services). Both will run over the same network and they will be managed with the same management systems. 

Eric and Ali have given several arguments why even for VPLS, signaling is essentially a point-to-point action for which LDP is best suited. IMO, nobody has given good counter arguments. Instead, there seems to be an almost dogmatic insistence that BGP can do the job as well and that BGP is good because it can be used for auto-discovery and because it is used in IP VPNs. 

Personally, I think that a common approach for VPLS, VPWS and other L2 VPN incarnations is more important than commonality with IP VPNs. Therefore, I am strongly in favor of LDP for VPLS signaling. I think BGP is the wrong way to go. 

Peter 

>Step one should be gaining
>agreement on requirements. Should we move to accept a single or small
>number of requirements documents? Did I miss this event? 
>
>
>----- Original Message -----
>From: <[email-masked]>
>To: <[email-masked]>
>Cc: <[email-masked]>
>Sent: Tuesday, April 29, 2003 4:53 AM
>Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt
>
>
>Hi Eric
>
>As I understand it a requirement would be to have a full mesh of LDP
>sessions between the PEs in the participating AS domains. This means
>configuration of each PE when for example a new site is added to an
>already existing VPN. If BGP is used this is not necessary as RRs can be
>used, minimizing the configuration to the new PE and the RR.
>But perhaps there exist a solution similar to this for LDP as well? It
>seems appealing to reuse the 2547bis structure we have also for VPLS if
>it's possible.
>
>My point is that further investigation of the two different solutions
>before rejecting one or the other would be good
>
>/Andreas
>
>-----Original Message-----
>From: Eric Rosen [mailto:[email-masked]]
>Sent: den 28 april 2003 16:29
>To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 >Cc: [email-masked]
>Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt
>
>
>
>Andreas> I would also like to know how inter-AS with the LDP
>Andreas> approach in lasserre-vkompella is to be solved.
>
>Could you say what the issue is that you think needs to be solved?

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 02 May 2003 17:04:56 +0200

> Eric and Ali have given several arguments why even for VPLS, signaling is
> essentially a point-to-point action for which LDP is best suited. 
> IMO, nobody has given good counter arguments. 

So for the benefit of those watching this list without blind believe
that VPLS must be based on point to point pseudowires and that there are
few more technologies other then LDP can some one come up with a real
design arguments that VPLS should really be used over p2p pipes with
full replication for broadcast & multicast at the ingress to SP core ?

Are all providers educating their customers that VPLS service based on
p2p PWs are not really ethernet, but a bunch of p2p pipes with all of
the conseqences behind this especially for decent rate multicast traffic
?

This entire argument for BGP versus LDP is completely unnecessary since
if you provide VPLS without locking yourself into the p2p PWs in the
core non of them is required. Further no signalling is required all
together :-). One idea of much more effcient VPLS is presented here:
draft-sajassi-mvpls-00.txt

Are providers really keen on getting into all of those LDP/BGP
configurations just to provide Metro VPLS service ? 

On the other hand when you are about to go Inter-AS with VPLS does this
sound efficient to replicate each multicast packets or streams N times
at their src PE (when N = the number of remote PEs for a given VPLS
instance) and then ship it through in parallel over most likely decent
distances ? 

Just to save some list bandwith ... 

* I am not claiming that draft-sajassi-mvpls-00.txt is the best solution
possible but for sure this is a start into a valid direction

* I am not subscribing to claims that since VPWS runs over p2p PWs VPLS
also should do so as they are members of the same family etc ...

* If one says back that IP muticast is not a scalable technology it
would be much better to specify precisely the claim. Notice that for
services like Multicast L3VPNs or MVPLS number of multicast states in
the core is very limited to the number of PEs and completely unrelated
to any thing on the SP customer side.

R.

> "Busschbach, Peter B (Peter)" wrote:
>