RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

[Alexander Vainshtein <[e-mail]>]

Yuanlong,

Lots of thanks for a prompt response.



I did not perform complete analysis of all the interworking MPLS vs. Ethernet network) cases for E-Tree.

My gut feeling is that it can be always reduced to the trivial case of two ACs between a VPLS PE and its adjacent Ethernet network PE (which is a CE from the VPLS point of view), these ACs being represented either as two VLANs on the same port or by two C-VLANs in the QinQ case (with the same S-VLAN). I am aware3 of some VPLS implementations that can treat any given pair of VLAN tags (for QinQ) as a separate AC, not sure how common this functionality is. The Ethernet side may be more problematic. E.g., it is not quite clear to me what are the expectations of the Ethernet edge device in your example of QinQ  for H-VPLS in order to support E-Tree; nor am I sure that IEEE has a ready answer for that.



Do I miss something?

Regards,
     Sasha

From: Jiangyuanlong [mailto:[e-mail]]
Sent: Monday, September 24, 2012 2:37 PM
To: Alexander Vainshtein; Giles Heron; Ali Sajassi
Cc: [e-mail]
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt


Hi Sasha,



Just snips of it:



As for the new forwarding plane: IMHO you need some modifications in the forwarding plane to mark Leaf-originated traffic on Tx and to block Leaf-to-Leaf traffic regardless of how you identify it. I do not see how you can avoid it taking into account that E-Tree forwarding behavior is different from a plain old Layer 2 switch.

[JY] Consider the access may well be an Ethernet network, 2VLAN should be supported there or in the bridge module, thus there is no need to introduce new forwarding paradigms in the VSI.

For the same reason, if CW solution is adopted, except the new modifications in VSI, 2VLAN may still be needed on the bridge module side.

[[Sasha]] I see it a bit differently: if your access is Ethernet, you need two ACs between your PE and its adjacent access device, one for Root and one for Leaf. No need to involve the bridge module of the PE into access behavior, especially if you want to run xSTP in your access network IMO.

[JY] The group have discussed quite a lot in the last few months around the scenarios of E-Tree and I don't think it is that simple (except in a pure MPLS network of course). BTW, Appendix of draft-ietf-l2vpn-vpls-pe-etree-00 have a brief discussion on the support of them. Just as an example, how can H-VPLS with QinQ spoke be supported? How can E-NNI be supported?



Regarding preservation of C-VLANs - would you not need to push the Root/Leaf VLAN tag on top of the C-tag you are going to preserve? This may result in backward compatibility issues when you have Root-only PEs that now have to be aware of these additional VLAN tags (push them on Tx and pop them on Rx).

[JY] That is not the case. You can have a look at Section 5.3.2 of draft-ietf-l2vpn-vpls-pe-etree-00, it says raw PW should be used, thus no root or leaf VLAN tag is needed on the PW.

[[Sasha]] I am not sure I understand, will look up the draft and respond.



Thanks,

Yuanlong



This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.