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

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Wed, 26 September 2012 05:55 UTC

Return-Path: <sajassi@cisco.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 D87F621F8826 for <l2vpn@ietfa.amsl.com>; Tue, 25 Sep 2012 22:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 89xaVG-01PnF for <l2vpn@ietfa.amsl.com>; Tue, 25 Sep 2012 22:55:16 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1B23E21F87BD for <l2vpn@ietf.org>; Tue, 25 Sep 2012 22:55:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29469; q=dns/txt; s=iport; t=1348638916; x=1349848516; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=wbBzvxqu5VDRxocabkH/apHd9zWh5wx8T/r5HMyVSUg=; b=G4jgFTLN+42n1zWuGczGUfrvvbHeR6J/TV9LDwkveOvpzXk3gCGAMgFn jf3BZm9BU9woizt/aFclqZukeVVd+a46iRSKAvafzcIdQk+DmC2Jg76IW 3o2OwcsT5wnNFnQIzt85kZ4/hYvSludDqyta6/DV00ROq2JFwWuQi7GKv E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkEFAE+YYlCtJXG//2dsb2JhbABFgksjqyGIagGIZYEIgiABAQEDARIBGjoQAgUHBgEIEQMBAQEhAQYoERQJCAIEAQ0FCRIHh1EDCQYBCplRlj0NiVSKOGKGCQOUEYFVgRWKCYMhgWmCZ4FjNA
X-IronPort-AV: E=Sophos; i="4.80,488,1344211200"; d="scan'208,217"; a="125372461"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 26 Sep 2012 05:55:15 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8Q5tF6H017653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Sep 2012 05:55:15 GMT
Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Wed, 26 Sep 2012 00:55:14 -0500
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Jiangyuanlong <jiangyuanlong@huawei.com>, Giles Heron <giles.heron@gmail.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: AQHNm6t/BSBgWtJE/UGEFPctAcjr7g==
Date: Wed, 26 Sep 2012 05:55:14 +0000
Message-ID: <CC87E369.1AF4D%sajassi@cisco.com>
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E157@szxeml546-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.1.120420
x-originating-ip: [10.21.91.100]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19210.004
x-tm-as-result: No--53.554200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_CC87E3691AF4Dsajassiciscocom_"
MIME-Version: 1.0
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: Wed, 26 Sep 2012 05:55:18 -0000

Hi Yuanlong,

MPLS forwarding is one of the forwarding mode in E-VPN that cannot be compromised. I would highly suggest that you read E-VPN drat again before making any suggestions. The reasons that I gave you previously regarding why the use of vlan-tag doesn't make sense for E-VPN still holds and if needed I can go over the E-VPN solution the next time we meet. But I won't be able to provide a tutorial over the email. As I mentioned before the E-VPN forwarding plane already supports E-TREE without any changes to the forwarding behavior. And changing the E-VPN forwarding behavior to do something that it already supports, doesn't make any sense. But you have heard that from multiple people already.

Cheers,
Ali

From: Jiangyuanlong <jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>>
Date: Monday, September 24, 2012 11:43 PM
To: Cisco Employee <sajassi@cisco.com<mailto:sajassi@cisco.com>>, Giles Heron <giles.heron@gmail.com<mailto:giles.heron@gmail.com>>
Cc: "l2vpn@ietf.org<mailto:l2vpn@ietf.org>" <l2vpn@ietf.org<mailto:l2vpn@ietf.org>>
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt


Hi Ali,



I am not sure whether "pure MPLS forwarding at the egress PE” is something we are pursuing or something true enough, but it seems to me the forwarding of EVPN is not so different from VPLS/VPWS in the description of EVPN document:

"

   Per EVI label assignment requires the least number of E-VPN labels,

   but requires a MAC lookup in addition to an MPLS lookup on an egress

   PE for forwarding. On the other hand, a unique label per <ESI,

   Ethernet Tag> or a unique label per MAC allows an egress PE to

   forward a packet that it receives from another PE, to the connected

   CE, after looking up only the MPLS labels without having to perform a

   MAC lookup. This includes the capability to perform appropriate VLAN

   ID translation on egress to the CE.

"

That is, if label per EVI is allocated, forwarding is based on MAC lookup (like VPLS), otherwise, if label per Ethernet segment or per MAC is allocated, the forwarding is like in VPWS, and VLAN translation is allowed further. Why an extra VLAN translation operation breaks?



For the 2nd question, I could not find SH label in the etree-evpn draft, were you referring to ESI MPLS label?



Thanks,

Yuanlong





-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, September 25, 2012 7:42 AM
To: Jiangyuanlong; Giles Heron
Cc: l2vpn@ietf.org<mailto:l2vpn@ietf.org>
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt





Jiangyuanlong,





Your proposal of applying vlan-tags (as done for VPLS) to E-VPN solution

is broken and doesn't work properly for E-VPN for the following reasons:



1) It breaks MPLS forwarding for egress PE - E-VPN allows for pure MPLS

forwarding at the egress PE



2) Even in scenarios where MAC lookup is used on egress PE, it creates

unnecessary overhead that is absolutely NOT needed. E-VPN multicast

packets already carries SH label (which as describe in etree-evpn draft)

is also used for root/leaf indication.





EVPN is the next gen solution which doesn't have the limitation of

existing vpls solution. It is extreemly flexible as it allows for pure

MPLS forwarding to a given AC without any MAC lookup (in either

direction). It allows for asymmetric MAC lookup operation (lookup in the

ingress PE but no lookup on the egress PE). Or it allows for lookup in

both directions. We don't want to contamiate such solution with the kludge

that we used for VPLS.



Cheers,

Ali







On 9/21/12 7:31 PM, "Jiangyuanlong" <jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>> wrote:



>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<mailto: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> [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-etree-2vlan-00

>>.txt

>> Status:

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

>> Htmlized:

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

>>

>