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

From: Du Wenhua <[email-masked]>
Date: Thu, 17 Apr 2003 00:19:52 +0800

Hi, Ali Sajassi

	See my comment bellow.

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

At 16:40:00 2003-04-15, Ali Sajassi wrote:
>>>
>> >1) Unqualified learning: all traffic from a given customer is tagged by
>> >P-VLAN, so if a customer is connected to a given access network through 10
>> >different ACs (and through several different MTU-s), then all those ACs
>> >will be tagged by the same P-VLAN. The P-VLAN as mentioned before
>> >corresponds to a single VPLS instance. Thus, all C-VLANs for a that
>> >customer share the same MAC address domain and broadcast domain.
>> >
>> >2) Qualified learning: each C-VLAN is represented by a P-VLAN. Thus a given
>> >C-VLAN (e.g., VLAN-10) over different ACs maps into a unique P-VLAN (e.g.,
>> >VLAN-100) and that P-VLAN corresponds to a single VPLS instance.
>> >
>> >Therefore, in both cases, a single P-VLAN correspond to a single VPLS
>> >instance and vise versa - e.g., one-to-one mapping.
>> >
>>
>>No. You misunderstand my point. I'm not talking about learning, I'm 
>>talking about value-add service, such as rate-limited, access list control.
>>For learning,I agree with you, one P-VLAN to one VPLS-instance is enough. 
>>But for value-add service, it is not enough, require many P-VLANs to one 
>>VPLS-instance.
>
>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.

>-Ali

---

From: Ali Sajassi <[email-masked]>
Date: Wed, 16 Apr 2003 10:11:53 -0700

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

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

---

From: Du Wenhua <[email-masked]>
Date: Fri, 18 Apr 2003 00:50:38 +0800

Hi, Ali Sajassi
    Thank for your comments.
	I agree with you that it is better to end the thread now. So I don't write 
comments in line, just give a summarization.
(1)My topic: It is better to use many P-VLANs than one P-VLAN  in one VPLS 
intance mode(a.k.a Unqualified learning). 
(2)Your comment: It is better to use many VPLS instances(a.k.a Qualified learning) 
than one VPLS instance(a.k.a Qualified learning) in VPLS.
(3)Another guy say: It is better to use L3 VPN than VPLS in PPVPN.

All of above maybe true. Their relationship  is as follow tree:
 
PPVPN---+-----L3 VPN
        |
        |
        +-----VPLS---+-----Qualified learning
                     |
                     |
                     +----Unqualified learning--+----One P-VLAN
                                                |
                                                |
                                                +----Many P-VLANs   

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

At 20:35:00 2003-04-16, Ali Sajassi wrote:
>>At 10:09 AM 4/17/2003 +0800, Du Wenhua wrote:
>>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.
>
>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.
>
>> >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?
>
>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.
>
>
>
>> >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.
>
>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.
>
>
>> >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 hope by now, it is clear why we cannot map two P-VLANs into the same VPLS 
>instance. If not, then I give up :-)
>
>
>>**********************************************************************
>>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.
>
>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
>
>
>>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.
>>
>> >
>> >>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
>>
>>
>>