Subject: Re: Ali Sajassi's comments on Hybrid VPLS

From: "Cheng-Yin Lee" <[email-masked]>
Date: Wed, 02 Apr 2003 11:30:34 -0500

Ali,
(6) is the issue you raised in the PPVPN meeting.

> 6) STP : if provider's access network is Ethernet (e.g., .1q or QinQ) and 
> these access networks (metro regions) are connected via an MPLS or IP core, 
> then my point was that STP is not suitable for putting everything on one 
> giant flat network and it would create administrative issues.
I think you have misunderstood Hybrid VPLS on this aspect. Customers'
STP is processed by CLEs - PEs, Ps, L2PEs do not process, participate or
even snoop
Customers' BPDUs, there are transparent to PEs, L2PEs, Ps. MAC address
learning and STP are restricted to a customer VPLS only. 

I don't understand your point about one giant flat network.
A customer (CEs) may run STP even when using PE-based VPLS, are you
saying the customer should not run STP then? 

I would agree that building one giant flat network as in VPLS/VLAN
instance switching (and bridging) in the network (i.e. PE/P based VPLS)
is not scalable. I do not know how one can aggregate [VPLS instance, MAC
address] in that case. Even if the MAC addressing is changed to be
aggregatable (reinventing what's already existing), how can one
aggregate [VPLS instance, MAC address].

> 1) Need to get the terminologies straight out: the draft talks about an 
> Attachment Circuit as demarcation point between provider's CLE and PE as 
> well as demarcation point between customer's CE and provider's PE. AC as 
> defined in L2VPN framework, refers to demarcation between customer's CE and 
> provider's PE and if you go by this, then the service that is provided by 
> the PEs is basically just VPWS and nothing more !! and there is no reason 
> to mix this up with VPLS service  
Please refer to my response to Eric Rosen's comments on VPWS and VPLS
service in Hybrid VPLS.
I clarified these services in the discussion at IETF-56 PPVPN WG as
well.

> - please refer to L2VPN framework draft.
If you acknowledge CLEs exist, perhaps a better suggestion is to update
the L2VPN framework draft.

> 2) With CLEs in the mix, then there are two cases: a) a CLE cannot use 
> VLANs as virtual interfaces and b) a CLE has a magical ability to use VLANs 
> as virtual interfacs. Case (a) is clearly not scalable since one would need 
> as many interfaces on a CE/CLE as number of customer sites - so if a 
> customer has 100 sites, then you need 100 interfaces on the CLEs for that 
> customer alone !!! 
As the draft says, Section 2.2 is a migration step (but this can be used
for many end-customers today in the interim) and the draft describes
bridging over virtual ports for the longer term.

> Case (b) uses VLAN tags not only as service delimiter 
> but also as virtual ports in a CLE and the main premise of this draft is 
> based on this. This concept is nothing new and was first introduced by 
> Kompella in his VPLS draft. But as soon as you introduce such concept, you 
> cannot use typical bridges and you need to develop modified bridges for 
> such functionality which would defeat the purpose of low-cost CLE. If 
> someone wants to develop a modified bridge for using VLAN tags as virtual 
> circuits/ports, then he can as easily develop modified bridge using PWs 
> (either MPLS or L2TPv3) as VCs and this becomes the good old draft-lasserre.
A bridging expert commented that it would be trivial to specify bridging
over different VLAN Ids. I see that as a positive comment. 
You may want to reevaluate your assertion that it is as easy to develop
modified bridge using PWs on CLEs.

It would be beneficial to review the issues and requirements with
full-meshed VCs and reverse split horizon forwarding for VPLS in
general. The issues with this are similar to using OSPF NBMA mode, which
a well-respected routing person said should be avoided like the plaque.

> 3) Interworking between disparate Attachment Circuits has already been 
> covered by two drafts. draft-shah-ppvpn-arp-mediation talks about 
> interworking for IP end points and draft-sajassi-l2vpn-interworking talks 
> about more general case of interworking and covers interworking for VPLS as 
> well. I didn't see anything new that has not been already covered by these 
> two drafts.
> 
> 4) Furthermore, ARP-mediation is a PtP mechanism and for multi-point 
> service, IPLS which is based somewhat on ARP-mdediation was introduced. So 
> lets not re-invent the wheel and lets not re-describe IPLS mechanism in 
> here again.
I don't think they are the same. Hybrid VPLS describes a specific
service which allows a CE router with a FR interface to peer on the same
broadcast network as CE routers with Ethernet access.

IPLS (version 01), Section 10 says:
  "In addition to (i) an Ethernet port and (ii) combination of 
   Ethernet port and a VLAN ID, an Attachment Circuit to IPLS may also 
   be (iii) an ATM or FR VC carrying encapsulated ***bridged Ethernet***
   frames or (iv) the combination of an ATM or FR VC and a VLAN ID. 
    
   The ATM/FR VC is just used as a way to transport Ethernet frames 
   between a customer site and the PE. "

In Router Peering in Hybrid VPLS, the ATM/FR VC transports IP packets
between a customer site and the PE. This is not the same as Router
Peering in Hybrid VPLS. 

For the case where the FR CEs are bridges, Hybrid VPLS leverages
bridging on CEs & CLEs, so PEs need not do bridging (not by distributing
MAC info in the control plane). 
In contrast, IPLS says (Section 11):

   However, unlike VPLS, IPLS is restricted to IP traffic only. By 
   restricting the scope of the service to the predominant type of 
   traffic in today's environment, IPLS eliminates the need for service 
   provider edge routers to implement some bridging functions such as 
   MAC address learning in the data path (by, instead, ***distributing
MAC 
   information in the control plane***)."

> 5) Discovery deals with the discovery of members of a VPN and there are 
> already few proposal on the table (e.g., BGP-based, directory-based such as 
> Radius, and MPLS-based). Mapping VLAN-tags to PWs is not related to 
> auto-discovery and such mapping in more general sense (ACs to PWs) has 
> already been described in details in L2VPN framework.
I think the intention of Marco Carugi's solution template (which is used
in the Hybrid VPLS draft)is to allow L2VPN "vertical" solutions to refer
to other documents which can be used for
different L2VPN solutions. 
Discovery of tunnel endpoints in this proposal is meant to reduce
provisioning steps at PEs but is not mandatory (a provider may choose to
use a NMS). 

regards
Cheng-Yin

> 
> 
> Regards,
> Ali
> 
> At 01:35 AM 3/20/2003 -0500, Cheng-Yin Lee wrote:
> >Ali,
> >I am trying to understand your comments at PPVPN WG meeting this
> >afternoon about Spanning Tree and Hybrid VPLS. Could you elaborate pls?
> >
> >Thanks,
> >Cheng-Yin
> 
> 
>

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 03 Apr 2003 15:19:46 -0800

>learning and STP are restricted to a customer VPLS only.

I was not talking about customer's BPDUs but instead about provider's BPDUs 
(I hoped this was clear from my reference to provider's access network).

>saying the customer should not run STP then?

No, the point which I was making is that the provider's network consists of 
a number of Metro Ethernet (ME) Networks connected over an MPLS/IP 
backbone. Each ME network can be either MPLS, IP or QinQ. It is O.K. to run 
STP within a ME network but running it across all ME networks is something 
else and can create administrative nightmare the least. I would be very 
interested to hear from any operator who is considering such topology.

>I clarified these services in the discussion at IETF-56 PPVPN WG as

With respect to terminology, still you should try to use the correct 
terminology - e.g. AC means demarcation between CE and PE (and not the 
interface between u-pe and n-pe). Based on framework document, your CLE is 
u-PE and your PE is then n-PE.

>the L2VPN framework draft.

you can still use the same terminology as u-PE and n-PE, in your case you 
have a different distribution of functionality between u-PE and n-PE (e.g., 
u-PE doing all the bridging functionality and n-PE doing all the PW 
functionality).

>bridging over virtual ports for the longer term.

I hope this point is clear to everyone that the initial step is a non-starter.

>modified bridge using PWs on CLEs.

I would love to hear how the existing Ethernet switches can be "easily" 
modified to do this !!! Everything is easy at the 10,000 ft level :-)
And once this is done, then the difference between this approach and using 
actual PW is just encapsulation - again at the 10,000 ft level :-)

>a well-respected routing person said should be avoided like the plaque.

And that's why for a year and half there are all these drafts on 
distributed-PE and hierarchical-PE to address this N^^2 scalability issue - 
there is a difference between full-mesh among edge devices and full-mesh 
among core devices !!

>broadcast network as CE routers with Ethernet access.

There are easier way of taking care of this type of situations (e.g., ACs 
with routed encap) - please refer to draft-sajassi-l2vpn-interworking.

>provisioning steps at PEs but is not mandatory (a provider may choose to

That's fine. But still the mapping of VLANs to PWs is not part of 
auto-discovery :-)

Cheers,
Ali