Subject: RE: Eric Rosen's comments on Hybrid VPLS

From: Shahram Davari <[email-masked]>
Date: Wed, 2 Apr 2003 11:37:46 -0800

Vach,

How come CE-based L3VPN is in PPVPN scope but this draft is not?

-Shahram

>-----Original Message-----
>From: Vach Kompella [mailto:[email-masked]]
>Sent: Wednesday, April 02, 2003 2:21 PM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: RE: Eric Rosen's comments on Hybrid VPLS
>
>
>Cheng-Yin,
>
>Just because the CE sees it as a VPLS, it doesn't become a 
>VPLS (from the
>provider's point of view).  It still looks like a VPWS which 
>the customer turns
>into a VPLS by putting bridges with split horizon, etc.
>
>The basic point is that the customer needs a VPWS service from 
>the provider, so
>from a ppvpn perspective, what you presented is that a 
>customer can turn a ppvpn
>VPWS into a customer-based VPLS.
>
>That's a customer deployment/use scenario.
>
>-Vach
>
>> -----Original Message-----
>> From: Cheng-Yin Lee [mailto:[email-masked]]
>> Sent: Wednesday, April 02, 2003 11:06 AM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: Re: Eric Rosen's comments on Hybrid VPLS
>>
>>
>> Eric,
>>
>> Eric Rosen wrote:
>> > Cheng-Yin> Norm Finn commented  it is a VPWS and I  
>clarified this along the
>> > Cheng-Yin> same lines and during the discussion in IETF-56 
>PPVPN. May I know
>> > Cheng-Yin> which part of the above clarification is still 
>not clear?
>> >
>> > I don't believe any clarification was ever made; the same 
>claims were merely
>> > repeated.
>> Ok, I see the problem now, you've deleted/or ignored the 
>clarification
>> ;-). I have repasted it below.
>>
>> "It is not simply VPWS. A provider may offer a VPLS service when the
>> provider manages the CLEs.
>> A provider may use p2p PW to build a VPLS service for customers, as
>> discussed in IETF-56 PPVPN WG meeting. In this case, the CE 
>sees a VPLS
>> service. "
>>
>> Perhaps you can say what is not clear in the above.
>> If the CE sees a VPLS service, why is this not a VPLS service?
>>
>> thanks
>> Cheng-Yin
>>
>>
>>
>
>
>
>

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 2 Apr 2003 12:40:40 -0800

Did I say it is not in scope?  All I said is that the CEs are using a ppvpn
based VPWS in a particular way.

But, on a different note:
Perhaps you don't remember the position of my hand when the call for whether a
ce-based l3vpn was in the ppvpn scope was made.  I haven't changed my position,
regardless of whether the consensus is that it is in scope.

Which is not to say that CE-based VPNs are not important, particularly if they
make demands of a provider provisioned VPN that are specific to the CE-based
model.

As far as I can see, the fact that the CEs are using a VPWS (from the provider's
perspective) to create a CE-based VPLS.

In response to Cheng-Yin's clarification, what you have done is identify how,
given a VPLS capable node (CLE), and a set of VPLS-challenged routers (PEs), you
can build a distributed VPLS, where the PEs only do VPWS, and the CLEs do the
VPLS bit of learning, split horizon, etc.  As a result you don't need to do DTLS
or GVPLS style decoupling.

I still maintain that this is an application of VPLS and VPWS, not something
new.

-Vach

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Wednesday, April 02, 2003 11:38 AM
> To: [email-masked]'; [email-masked]; [email-masked]

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Wed, 02 Apr 2003 17:20:07 -0500

Vach,

> perspective) to create a CE-based VPLS.
As described now, a CE sees a VPLS service not a VPWS in the case where
the service subscribed is VPLS. 
As I mentioned before, a provider may provide or a customer may
subscribe to a VPWS instead (in that case a CE sees a VPWS. The
migration approach may be a VPWS as outlined in Section 2.2)

> given a VPLS capable node (CLE), 
CLEs as defined in the draft are not lasseurre-vkompella VPLS capable
node.

> and a set of VPLS-challenged routers (PEs), you
> VPLS bit of learning, split horizon, etc.
The draft as described now -  CLEs process customer's STP, the draft is
currently not in favour of split horizon, some reasons are given in the
draft, issues with inconsistent view of routing when a VC/PW is down.
Other reasons include some providers concerns with the full-meshed
requirements. Even if only a few hubs are used, every site must be
full-meshed. Some people are questioning why a full-meshed (plus
protections VCs) must be setup when some sites only need connectivity to
a one or two hub sites.

Regards,
Cheng-Yin

---

From: Eric Rosen <[email-masked]>
Date: Wed, 02 Apr 2003 18:53:23 -0500

Shahram> How come CE-based L3VPN is in PPVPN scope but this draft is not? 

The basic issues in CE-based PPVPN (whether L2 or L3) are (a) the methods by
which the CEs in  a common VPN may discover each other,  and (b) the methods
by which the SP provisions and monitors the CEs.  These issues are in scope.
These issues  are already being addressed.   I don't think  these issues are
any different  if the CEs are  bridges than if they  are routers.  Certainly
the draft  in question  does not exhibit  any L2VPN-specific issues  in this
area.  

In CE-based  L3VPN, the CEs  appear as routers  to the other devices  at the
site, and  to CEs at  other sites.  How  the CEs perform routing,  with each
other, and with other devices at  the customer sites, is not within the WG's
scope. 

In CE-based  L2VPN, the CEs  appear as bridges  to the other devices  at the
site, and  to CEs at other sites.   How the CEs perform  bridging, with each
other, and with other devices at  the customer sites, is not within the WG's
scope.  

So the part of the draft that discusses how to create a bridged network over
a set of p2p links is out of scope.