Subject: Re: Re: draft-lasserre-vkompella-ppvpn-vpls as working groupdraft

From: Du Wenhua <[email-masked]>
Date: Thu, 17 Apr 2003 10:09:28 +0800

Hi, Ali Sajassi
   Thanks for your comments again. But your comments is out of the scope of my topic.
   I'm talking about: one P-VLAN or many P-LAN? Many P-VLAN is better.
   Your comments is: one VPLS instance or many VPLS instance? Many VPLS instance is better.
   The two topic has nothing to do with each other. They do not conflict with each other.                      

　　　　　　　　Du Wenhua
　　　　　　　　[email-masked]
　　　　　　　　　　2003-04-17

At 14:24:00 2003-04-16, Ali Sajassi wrote:
>>> >No, there is still confusion and your confusion may be about VPLS instance
>> >First, are these two customers part of the same VPLS instance or not ? If
>> >they are then they are using the same FIB and they need to coordinate their
>> >MAC addresses with each other in order not to have overlapping MAC
>> >addresses (refer to sec. 8.1.1).
>> >Because both customers are part of the
>> >same VPLS instance, then they will be identified by the same P-VLAN.
>>Yes, I'm talking about two customers belong to the same VPLS instance.
>>True, the two customers can be identified by the same P-VLAN.
>>But how to distinguish the two customers in PE-rs???  Your answer is 
>>-customer MAC-.
>>I do agree with you that customer MAC is unique in the VPLS intstance. But 
>>it is
>>a bad way to run ACL based on -customer MAC-, and it is a better way to 
>>run ACL based one
>>different P-VLANs. Pls see my explain above for why it is a bad way.
>>
>>In the other side, would you tell me why we can  not  use different 
>>P-VLANs for different
>>customers in the same VPLS instance? Is this hard to implement? Is this 
>>break any rules
>>in the draft-ietf-ppvpn-l2-framework-03.txt?
>
>The reason you cannot combine two customers in the same VPLS instance or at 
>least is not recommended is because you only have a single MAC address 
Once more, your answer is out of the scope of the my topic.
I'm talking about: one P-VLAN or many P-LAN?
Your comment is: one VPLS instance or many VPLS instance? 

>domain and broadcast domain per VPLS instance which means the same FIB 
>table is shared by VLANs from both customer (VLANs from both customers 
>point to the same FIB table) as well as the same broadcast domain is used 
>for both (customers see each other MAC addresses). Then, how do you 
>coordinate the MAC addressed across different customers. It is tough enough 
>to coordinate within a single customer for unqualified learning. If the MAC 
>addresses are not coordinated (both within the domain of a single customer 
>as well as across them), then their traffic gets blackholed !!!! 
What is the issue with MAC coordinated? I'm sorry I don't known what you mean.
Please a example of the issue.
>How do you address that ? 
or are you going to restrict their MAC address sapce ? And 
>how do you enforce how much of that FIB to be used by one customer versus 
>the other ?
This has nothing to do with P-VLAN. It has something to do with number of VPLS
instances. 
> Or how do you block one customer traffic from reaching the 
>other one ?
By P-VLAN.
> Because of these issues, sharing a VPLS instance is not viable.
Once more, your answer is out of the scope of the my topic.
I'm talking about: one P-VLAN or many P-LAN?
Your comment is: one VPLS instance or many VPLS instance? 
>Also I am definitely not recommending to use MAC ACL for such 
>cases. The recommendation is that each customer has (at least) its own VPLS 
>instance so that the SP can properly enforce the SLA and proper delivery of 
>customer frames.
Once more, your answer is out of the scope of the my topic.
(1)My topic: it is better to use many P-VLANs than one P-VLAN when all customer 
share one VPLS instance.
(2)Your answer: it is better to use many VPLS instances rather than one VPLS instance.
I think (1) and (2) is two different topic. They do not conflict with each other.  

**********************************************************************
I beleive many P-VLAN have no issue. Let us look into the draft again.

(1)Between PE-rs and PE-r, we use VC label.
(2)Between PE-rs and MTU-s, we can use VC label.
(3)Between PE-rs and MTU-s, we can also use P-VLAN tag.

As list above, to PE-rs a P-VLAN tag is just have the same function as a VC lable. 
The different is P-VLAN tag is 12bit and the VC label is 20bit.
Now we can use different VC label for different customer, so we can use different 
P-VLAN tag for different customer. Just replace a VC label with a P-VLAN tag.

In other words, P-VLAN tag == VC label of spoke pseudowire,  as follow
(1)Thus, the spoke pseudowire from the PE-r is treated as a virtual 
port and the PE-rs device will switch traffic between the spoke pseudowire, 
hub pseudowires, and  access ports once it has learned the MAC addresses. 
(2)Thus, the P-VLAN from the MTU is treated as a virtual 
port and the PE-rs device will switch traffic between the PVLANs, 
hub pseudowires, and  access ports once it has learned the MAC addresses. 

There is no issue in (1), so there is no issue in (2).

follow words are copied from the draft:
    10.1.1.2.  PE-rs Operation 
    
   The PE-rs device is a device that supports all the bridging 
   functions for VPLS service and supports the routing and MPLS 
   encapsulation, i.e. it supports all the functions described in 
   [VPLS]. 
    
   The operation of PE-rs is independent of the type of device at the 
   other end of the spoke pseudowire.  Thus, the spoke pseudowire from 
   the PE-r is treated as a virtual port and the PE-rs device will 
   switch traffic between the spoke pseudowire, hub pseudowires, and 
   access ports once it has learned the MAC addresses. 

>
>> >Second, regarding the rate limiting and traffic policing. Policing and
>> >shaping functionality should be done as close to the edge as possible
>> >(before congestion point) and they are done at the MTU-s (not PE-rs) and
>> >they are performed on a per AC basis (AC can be either customer port for
>> >unqualified learning and customer VLAN for qualified learning). Some of
>> >these stuff is described in MEF white paper and you may want to take a look
>> >at it. So for a given customer that has multiple sites connected to the
>> >same MTU-s, the QoS (rate limiting, shaping, policing) is performed on per
>> >customer site (e.g., per AC) basis.
>>
>>Rate-limit is just only  an example, there are many other value-add 
>>services which
>>need to apply in PE-rs based on per customer. If you think that MTU  can 
>>do all the
>>value-add services and the PE-rs do not need to apply any value-add
>>services based on per customer, I have nothing to say.
>
>PE-rs can offer whatever value-add service that you have in mind on a per 
>customer basis by having one VPLS instance per customer. What benefits can 
>you get by sharing the same VPLS instance by multiple customers which 
>violates the principle of isolation and privacy between customers.
Once more, your answer is out of the scope of the my topic.
I'm talking about: one P-VLAN or many P-LAN?
Your comment is: one VPLS instance or many VPLS instance? 
>-Ali

---

From: Ali Sajassi <[email-masked]>
Date: Wed, 16 Apr 2003 20:35:56 -0700

>    The two topic has nothing to do with each other. They do not conflict 

They do if you try to understand the relationship between VPLS instance, 
MAC address domain, and broadcast domain. It seems like you still haven't 
grasped what a VPLS instance really means. In IEEE language, MAC address 
domain correspond to the filtering database (e.g., IVL versus SVL mode) and 
broadcast domain correspond to the filtering action (e.g., GVRP). In IEEE, 
you can have either SVL or IVL mode in parallel with running GVRP - e.g., a 
group of VLANs can share the same filtering database (SVL mode) and still 
have different broadcast groups per VLAN. To simplify thing for VPLS and to 
avoid running GVRP over the core, we have decided long time ago to have one 
broadcast domain per filtering database (per MAC address domain). In VPLS, 
the broadcast domain is identified by a group of PWs and MAC address domain 
by filtering database (e.g. one filtering database per MAC address domain).

Now, if you understand these fundamentals, then you understand the rest of 
the comments that I made.

>Your comment is: one VPLS instance or many VPLS instance?

Think about in term of MAC address domain and broadcast domain. When you 
talk about two customers sharing one VPLS instance. Based on our definition 
of VPLS instance, it means both of them use the same MAC address domain and 
broadcast domain.

>Please a example of the issue.

Please refer to Annex B of 802.1Q standards. It gives a good description of 
why you have to use IVL mode when you have duplicate MAC addresses - e.g., 
why you have to use different filtering databases - e.g., if you don't, 
then MAC address entries get over-written and traffic goes to wrong places.

>I think (1) and (2) is two different topic. They do not conflict with each 

I hope by now, it is clear why we cannot map two P-VLANs into the same VPLS 
instance. If not, then I give up :-)

A single VC label correspond to a single PW; whereas, a group of PWs 
correspond to a single LAN - that's why we sometimes refer to it as V-LAN 
emulation. You can refer to the L2-framework draft and it explain it some 
more. PW is different than VLAN !!!

I hope by now, the whole thing is clear and this will be my last email on 
this thread.

Cheers,
Ali