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

From: Du Wenhua <[email-masked]>
Date: Thu, 17 Apr 2003 03:05:03 +0800

Hi, Ali Sajassi
       Thanks. Pls see my comments in line
				 
　　　　　　　　Du Wenhua
　　　　　　　　[email-masked]
　　　　　　　　　　2003-04-17

At 10:11:00 2003-04-16, Ali Sajassi wrote:
>>> >For unqualified learning, customer's VLANs are transparent to the SP. And
>> >as the matter of fact there is single MAC address domain and broadcast
>> >domain for all the VLAN of that customer. So what that means is the
>> >customer's MAC addresses need to be unique across all the VLANs or else
>> >unqualified learning would not work for that customer. So, given that all
>> >MAC addresses of a given customer are unique, then you can run ACL based on
>> >customer's MAC for that P-VLAN. If multi SLAs are needed for unqualified
>> >learning, then you simply copy the CoS bits of the inner tag to he outer
>> >tag and perform QoS on the P-VLAN tag.
>> >
>> >The situation for qualified learning, should be clear since there is no
>> >outer-tag and P-VLAN is just a mapping of the C-VLAN.
>> >
>> >If this is yet not clear to you, please clearly state the issue with an
>> >example.
>> >
>>Ok, I give an example.
>>Two customers A and B are connected a MTU via different physcal ports,
>>the MTU is connected to a PE-rs via one physical port.The PE-rs aplly
>>rate-limit of 5Mbps to customer A, and apply rate-limit of 10Mbps to 
>>customer B.
>>How can the PE-rs distinguish the two customer?
>>(1)Your answer is run ACL on  customer's MAC.
>>But, Customer MAC is untrusted, because the provider do not know  customer 
>>MAC,
>>and the MAC will change frequently so need to change ACL frequently.
>>So,it is difficult  to use ACL based on customer MAC.
>>(2)My unswer is to run ACL based on P-VLAN, customer A and customer B have 
>>different P-VLAN.
>>P-VLAN is trusted, P-VLAN would not change frequently, provider known 
>>P-VLAN. It is better  than
>>run ACL based on customer MAC.
>
>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?

>However, if each customer has its own VPLS instance, then they have their 
>own FIB (and MAC address space) and each will be identified by its own 
>VPLS-instance id and P-VLAN id.
No, I'm not talking about this. I'm talking about two customers belong to the same VPLS instance.

>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.
>
>-Ali

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.

---

From: Ali Sajassi <[email-masked]>
Date: Wed, 16 Apr 2003 14:24:07 -0700

>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 
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 !!!! 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 ? Or how do you block one customer traffic from reaching the 
other one ? Because of these issues, sharing a VPLS instance is not 
viable.  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.

>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.

-Ali