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

Jiangyuanlong <jiangyuanlong@huawei.com> Mon, 24 September 2012 11:39 UTC

Return-Path: <jiangyuanlong@huawei.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CB921F85AC for <l2vpn@ietfa.amsl.com>; Mon, 24 Sep 2012 04:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYmmvz0G6vmK for <l2vpn@ietfa.amsl.com>; Mon, 24 Sep 2012 04:39:16 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4D85721F851A for <l2vpn@ietf.org>; Mon, 24 Sep 2012 04:39:15 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKZ40216; Mon, 24 Sep 2012 11:39:14 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 12:38:27 +0100
Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 12:38:47 +0100
Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.97]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Mon, 24 Sep 2012 19:38:39 +0800
From: Jiangyuanlong <jiangyuanlong@huawei.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Giles Heron <giles.heron@gmail.com>, Ali Sajassi <sajassi@cisco.com>
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
Thread-Index: Ac2aLGAdAR1X+eyYskOHru3ESKxPQQAF4Pbg
Date: Mon, 24 Sep 2012 11:38:39 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF11@szxeml546-mbs.china.huawei.com>
References: <F9336571731ADE42A5397FC831CEAA020BA7FDAC@ILPTWPVEXMB03.ecitele.com>
In-Reply-To: <F9336571731ADE42A5397FC831CEAA020BA7FDAC@ILPTWPVEXMB03.ecitele.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.77.95]
Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF11szxeml546mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Sep 2012 11:39:23 -0000

Hi Sasha,



Just snips of it:

[[[Sasha]]] You do not really have to negotiate usage of the Leaf  flag in the CW. At most you have to negotiate usage of the CW, which is well defined (including the latest standard for changes in the preferred CW usage:-). And you would locally configure your VPLS instance to be an E-Tree on and hence setting the Leaf flag on Tx to peers and respecting the value of this flag received from your peers. A regular VPLS instance (equivalent to Root only) would never set this flag on Tx and ignore it on Rx - so you would have complete backward compatibility at no cost.

[JY] Yes, you are right that only CW negotiation is needed. Though I am not sure if a PE has no capability of CW support, how can this approach be backward compatible?



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.



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.



Thanks,

Yuanlong



From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Monday, September 24, 2012 4:13 PM
To: Jiangyuanlong; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Yuanlong hi!
Lots of thanks for a prompt response.
Please see some responses in line below.

Regards,
     Sasha

From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]
Sent: Monday, September 24, 2012 9:44 AM
To: Alexander Vainshtein; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Hi Sasha,

You are aiming 2 birds with a single stone;)
But please see my comments in line.

Thanks,
Yuanlong

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


Yuanlong.

Lots of thanks for a prompt response and clarification.



I have always considered the CW-based proposal for E-tree as the simplest (and, by implication, the most clean) approach:

- No need to distribute the types of ACs a given PE supports (and to re-distribute it when the set of ACs is changed). It is a purely local matter

- No OAM issues

[JY] it seems neither issue is with 2VLAN, right?



- No need to allocate special VLAN tags to mark Leaf and Root- originated traffic and to propagate these allocations - hence no problem with preservation of  C-VLANs if/when it is needed (or VLAN manipulation) etc.

[JY] It may be commensurate with the negotiation of E-Tree bit in the control word (if using CW), but save the work of redesigning a new forwarding plane;) BTW, not sure what is the problem with preservation of C-VLAN, can you give some more hints?

[[[Sasha]]] You do not really have to negotiate usage of the Leaf  flag in the CW. At most you have to negotiate usage of the CW, which is well defined (including the latest standard for changes in the preferred CW usage:-). And you would locally configure your VPLS instance to be an E-Tree on and hence setting the Leaf flag on Tx to peers and respecting the value of this flag received from your peers. A regular VPLS instance (equivalent to Root only) would never set this flag on Tx and ignore it on Rx - so you would have complete backward compatibility at no cost.



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.

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





Unfortunately the WG has decided to drop this approach - presumably, because it mandated the use of CW in the Ethernet PW encapsulation which is not supported by some implementations.



So now we have a good chance to end with two different solutions (one for E-VPN and one for regular VPLS), and, most probably, with some additional mechanism for their interworking...



But is probably spilled milk now.



Regards.

Sasha.

________________________________
From: Jiangyuanlong [jiangyuanlong@huawei.com]
Sent: Monday, September 24, 2012 4:22 AM
To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
Sasha,

>From Ali's I-D draft-sajassi-l2vpn-evpn-etree-00, it seems two ESI MPLS labels per Ethernet segment are used for E-Tree. So one is used for root traffic and another is used for leaf traffic, just like in the 2PW approach.
But it has the same problem as 2PW IMHO and OAM will be a challenge.
Besides, manipulation of those labels and import/export of their associated RT attributes may not be easy.

Thanks,
Yuanlong

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Sunday, September 23, 2012 4:25 PM
To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt


Yuanlong, Giles, Himanshu, Ali and all,

I have probably missed something important (not being present at the latest IETF meeting).

But I think something is wrong with the statement "there was no benefit in the E-VPN case in using an additional tag (such as a VLAN)".



IMHO and FWIW the real E-Tree problem is the situation when there are two (or more) PEs with both Root and Leaf ACs.

When one of such PEs receives a VPLS packet from another such PE, it must somehow identify the source AC of the Ethernet frame in this packet, and, in the case of it being a leaf AC, prevent its forwarding to the local Leaf AC(s) while allowing forwarding to local Root AC(s). This equally applies to regular VPLS and E-VPN, e.g., in the case when the contained Ethernet frame is a broadcast one (so that no learning is associated with it). And I strongly doubt this can be achieved without some "tags" in the encapsulation.



My 2c,

     Sasha



> -----Original Message-----

> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf

> Of Jiangyuanlong

> Sent: Saturday, September 22, 2012 5:32 AM

> To: Giles Heron

> Cc: l2vpn@ietf.org

> Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

>

> Hi Giles,

>

> Perhaps the gauge of the consensus in the minutes was not so clear for me:

> "         Giles - are we agreed we want to get to one solution for VPLS and E-

> VPN.

>           Not many people.  But even fewer who want multiple.  Checked to see

> if

>           people want one solution only for E-VPN and VPLS - only a couple of

> hands."

> Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus to

> decide which way to take.

>

> Thanks,

> Yuanlong

>

> -----Original Message-----

> From: Giles Heron [mailto:giles.heron@gmail.com]

> Sent: Friday, September 21, 2012 9:09 PM

> To: Jiangyuanlong

> Cc: l2vpn@ietf.org

> Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

>

> Thanks Yuanlong,

>

> however I must say that your memory of the IETF 84 L2VPN meeting differs

> from mine (and from what is noted in the minutes).  Whilst Himanshu said

> that it was better to have the same solution for VPLS and E-VPN, Ali stated

> that there was no benefit in the E-VPN case in using an additional tag (such as

> a VLAN).  No consensus was reached in the meeting.

>

> Giles

>

> On 21 Sep 2012, at 10:16, Jiangyuanlong <jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>>

> wrote:

>

> > Hi all,

> >

> > During the 84th IETF meeting, the group discussed the issue of E-Tree in E-

> VPN, and it was shown that a single solution was more preferred than two

> different approaches for VPLS and E-VPN.

> > This I-D probes how the 2VLAN approach can be used to support E-Tree in

> E-VPN and it seems not a big issue.

> > Any comments from you are greatly appreciated.

> >

> > Best regards,

> > Yuanlong

> >

> > -----Original Message-----

> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]

> > Sent: Friday, September 21, 2012 4:55 PM

> > To: Jiangyuanlong

> > Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

> >

> >

> > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

> > has been successfully submitted by Yuanlong Jiang and posted to the

> > IETF repository.

> >

> > Filename:     draft-jiang-l2vpn-evpn-etree-2vlan

> > Revision:      00

> > Title:                               E-Tree Support with 2VLAN in E-VPN

> > Creation date:            2012-09-21

> > WG ID:                           Individual Submission

> > Number of pages: 6

> > URL:             http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-<http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00.txt>

> etree-2vlan-00.txt<http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00.txt>

> > Status:          http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-<http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan>

> 2vlan<http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan>

> > Htmlized:        http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-<http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00>

> 2vlan-00<http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00>

> >

> >

> > Abstract:

> >   This document discusses how the Dual-VLAN approach as described in

> >   [Etree-vlan] can be used to support the transport of E-Tree service

> >   in E-VPN. Thus a single convergent solution is possible for both VPLS

> >   and E-VPN.

> >

> >

> >

> >

> > The IETF Secretariat

> >



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.

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.

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.