Subject: Re: Re: Who do VLAN translation in LDP-VPLS? PE-rs or MTU-s?

From: Du Wenhua <[email-masked]>
Date: Fri, 19 Mar 2004 15:02:42 +0800

Hi,Ali Sajassi,

Thanks for your comments. Please see my comments bellow.

>-----Original Message-----
>From: Ali Sajassi <[email-masked]>
>Sent: 09:16:00,2004-03-18
>To: duwh <[email-masked]>
>Subject: Re: Who do VLAN translation in LDP-VPLS? PE-rs or MTU-s?

>At 04:29 PM 3/18/2004 +0800, Du Wenhua wrote:
>>Hi,all，
>>
>>  11.  Hierarchical VPLS model using Ethernet Access Network of 
>> <draft-ietf-l2vpn-vpls-ldp-01.txt> say
>>
>> >   If customer VLANs need to be treated as service delimiter (e.g.,
>> >   customer UNI port is a multiplexed port), then the MTU-s needs to
>> >   have the additional capability of translating a customer VLAN (C-
>> >   VLAN) to a P-VLAN in order to resolve overlapping VLAN-ids used by
>> >   different customers. Therefore, the MTU-s device in this model can be
>> >   considered as a typical bridge with this additional UNI capability.
>>
>>     In my option, it is not a good idea to let the MTU-s device to do 
>> VLAN translation. There are 3 reason:
>>    1)As we known, MTU-s are low cost devices,  are made by the standard 
>> commercial chips. These chips has no VLAN translation function.
>
>And I am talking about low-cost bridges based on IEEE 802.1ad that can 
>perform this functionality. Take a look at IEEE 802.1ad rev. D2.
true. 
But how many bridge chips support 802.1ad d2 do you think? I have checked more 10 kind of 
commercial chips, but only one support VLAN translation.
 
>
>>    2) On the another side, many MTU-s(a.k.a ethernet switch) have been 
>> installed in the carrier network already. It is very difficult to upgrade 
>> these ethernet switch to support VLAN translation.
>
>Many deployed Bridges/MTU-s in carrier networks can support predecessor 
>version of 802.1ad standard (QinQ) that have similar capabilities. You 
>cannot eat your cake and have it too.
QinQ is not VLAN translation.
>If you want to use
>a) Ethernet access network and
>b) allow muxed UNI port and
>c) don't restrict customer VLAN assignment,
>then MTU-s need to support VLAN translation (e.g., based on 802.1ad). But 
PE-rs can do VLAN translation. MTU-s need not to do VLAN translation.
>if you want to restrict customer VLAN assignment or use PW between your 
>u-PE and n-PE, then you don't need this feature.
>
>>    3)[PWE3-ETHERNET]<draft-ietf-pwe3-ethernet-encap-05.txt> defines the 
>> VLAN translation function for PW. <LSP-VPLS> say VPLS supports such PW 
>> defined by [PWE3-ETHERNET]. So I think PE-rs support VLAN translation also.
>
>But for that you need MPLS access network and your u-PE needs to support 
>MPLS PW (e.g., your MTU-s becomes PE-r) and this is different from section 
I think you might have misunderstood what I mean.
u-PE(MTU-s) is typical bridge, just carry  PDU over C-VLAN. 
n-PE(PE-rs) do C-VLAN tranlation when the PDU come into an VC(a.k.a PW).
[PWE3-ETHERNET] defines the VLAN translation function for VC(PW).
>11.2 whose title is "H-VPLS model using Ethernet Access Network". Besides, 
>if you use MPLS PW between u-PE and n-PE, then you wouldn't need VLAN 
>traslation to begin with since each customer VLAN gets mapped to a 
>different PW.
>
>
>>     In summary, I suggest to move the VLAN translation function from the 
>> MTU-s to PE-rs. PE-rs are more powerful and more expensive. PE-rs is more 
>> easy to do VLAN translation, which is defened in 
>> <draft-ietf-pwe3-ethernet-encap-05.txt>.
>>     MTU-s is just a typical bridge, no additional UNI capability, no VLAN 
>> translation.
>
>I think you might have misunderstood the scenario for H-VPLS with Ethernet 
>access network. Hope the above explanation helps in clarifying it.
>
>-Ali
>
>
>
>>　　　　　　　　Yours
>>
>>　　　　　　　　Du Wenhua
>>     　　　　　　　　　　2004-03-18
= = = = = = = = = = = = = = = = = = = =

---

From: Ali Sajassi <[email-masked]>
Date: Fri, 19 Mar 2004 12:48:26 -0800

>Thanks for your comments. Please see my comments bellow.

You're welcome. Please refer to my comments inline.

> >>Hi,all£¬

But the ones that have it, can do it with low-cost Ethernet switches :-)

>QinQ is not VLAN translation.

I was trying to point out that the platforms based on QinQ implementation 
may also do VLAN translation. However, 802.1ad is more than just QinQ and 
VLAN translation.

>[PWE3-ETHERNET] defines the VLAN translation function for VC(PW).

I think you are talking about a scenario in which the MTU-s (the bridge) is 
directly connected to the PE-rs without any Ethernet network in between 
(even a single bridge).  If that's the case, then yes you don't need to 
have VLAN translation at the MTU-S since each pair of port+vlan at the 
PE-rs is considered as an AC that can be associated with a given VSI. 
However, I was talking about the more general case of "Ethernet access 
network" in which MTU-S is connected via one or more provider bridges to 
the PE-rs. And in such general scenario, the VLAN translation must be done 
at the MTU-s since each provider VLAN represent a VPLS instance.

-Ali

> >>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Yours
> >>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua
> >>     ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2004-03-18

---

From: Ali Sajassi <[email-masked]>
Date: Fri, 19 Mar 2004 13:29:31 -0800

>I think you are talking about a scenario in which the MTU-s (the bridge) 
>is directly connected to the PE-rs without any Ethernet network in between 

I think I need to further clarify what I said earlier to ensure that there 
is no ambiguity. In the above paragraph, I said that if the MTU-S is 
directly connected to PE-rs, then you don't need to have VLAN translation 
at the MTU-s; however, to be more precise, I should have said that if there 
is no VLAN ambiguity within MTU-S, then there is no need for VLAN 
translation and the PE-rs can resolve the VLAN ambiguity between different 
MTU-s. However, for scenario where different ports of a MTU-s is connected 
to different customers (and different customers use different VLAN 
assignments to represent different services, then VLAN translation is still 
needed in the MTU-s even though it can be directly connected to PE-rs or 
else traffic from one customer can leak to another because of local 
switching property of MTU-s. Another way of doing this is to use 
encapsulate all the the VLANs from a given customer with a provider VLAN 
tag and use double-tag lookup at the PE-rs. This method was explained in 
detail in draft-sajassi-ppvpn-vpls-architectures. However, VLAN translation 
is more general and covers more cases and thus it is the only method 
mentioned in vpls-ldp draft.

-Ali