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

"UTTARO, JAMES" <ju1738@att.com> Mon, 24 September 2012 14:32 UTC

Return-Path: <ju1738@att.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 6619421F87A9 for <l2vpn@ietfa.amsl.com>; Mon, 24 Sep 2012 07:32:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level:
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 LrPsktmS43dw for <l2vpn@ietfa.amsl.com>; Mon, 24 Sep 2012 07:32:51 -0700 (PDT)
Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 229A221F8787 for <l2vpn@ietf.org>; Mon, 24 Sep 2012 07:32:51 -0700 (PDT)
Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 31f60605.2aaadd421940.260449.00-562.716320.nbfkord-smmo08.seg.att.com (envelope-from <ju1738@att.com>); Mon, 24 Sep 2012 14:32:51 +0000 (UTC)
X-MXL-Hash: 50606f136dbc4849-b82706e7c86553cd9882404db95908469b8374c8
Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id efe60605.0.260138.00-334.715393.nbfkord-smmo08.seg.att.com (envelope-from <ju1738@att.com>); Mon, 24 Sep 2012 14:32:31 +0000 (UTC)
X-MXL-Hash: 50606eff4a9ae5ad-1c88c4b7ee8c882339081445ad3575408779f0d9
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8OEWTwq017324; Mon, 24 Sep 2012 10:32:30 -0400
Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8OEWM7N017264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Sep 2012 10:32:24 -0400
Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by sflint01.pst.cso.att.com (RSA Interceptor); Mon, 24 Sep 2012 10:32:08 -0400
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0318.001; Mon, 24 Sep 2012 10:32:08 -0400
From: "UTTARO, JAMES" <ju1738@att.com>
To: 'Aldrin Isaac' <aldrin.isaac@GMAIL.COM>, Jiangyuanlong <jiangyuanlong@huawei.com>
Subject: RE: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
Thread-Topic: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
Thread-Index: AQHNmY5PXxacLEvPy023O8araW2PqZeYxY1AgABkUYCAAGW8IA==
Date: Mon, 24 Sep 2012 14:32:07 +0000
Message-ID: <B17A6910EEDD1F45980687268941550FB8A6A2@MISOUT7MSGUSR9I.ITServices.sbc.com>
References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@szxeml546-mbs.china.huawei.com> <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DCCD@szxeml546-mbs.china.huawei.com> <F9336571731ADE42A5397FC831CEAA020BA7CA63@ILPTWPVEXMB03.ecitele.com> <CAOA2mbzOpAkV006TAjuykVsEoP8hz67YnWpm0=v2FxVkwWNK_g@mail.gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE31@szxeml546-mbs.china.huawei.com> <CAOA2mbzejgQ_UnFn+J1e7H+o+dUA6f6sXV9tjdp=3f_RLWQNZA@mail.gmail.com>
In-Reply-To: <CAOA2mbzejgQ_UnFn+J1e7H+o+dUA6f6sXV9tjdp=3f_RLWQNZA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.91.76.182]
Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB8A6A2MISOUT7MSGUSR9IIT_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <ju1738@att.com>
X-SOURCE-IP: [144.160.20.145]
X-AnalysisOut: [v=1.0 c=1 a=g8Qva45Ca7EA:10 a=J2Vbl3tn3xcA:10 a=ofMgfj31e3]
X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=48]
X-AnalysisOut: [vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=ZGL3M7cMNNvo5dJb82IA:9 a=C]
X-AnalysisOut: [juIK1q_8ugA:10 a=lZB815dzVvQA:10 a=MSl-tDqOz04A:10 a=VoFdV]
X-AnalysisOut: [tO4Zh8pUFhG:21 a=z6OVhWwbMu7veibq:21 a=yMhMjlubAAAA:8 a=SS]
X-AnalysisOut: [mOFEACAAAA:8 a=OE8dijOsa_V_ASBdUsAA:9 a=gKO2Hq4RSVkA:10 a=]
X-AnalysisOut: [UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsn]
X-AnalysisOut: [liwV7b4A:10 a=UBzO5rIaD1cl0UIF:21 a=jYhiiormMYBrbmZx:21]
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, Ali Sajassi <sajassi@cisco.com>, Himanshu Shah <hshah@force10networks.com>
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 14:32:54 -0000

+1

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Aldrin Isaac
Sent: Monday, September 24, 2012 12:28 AM
To: Jiangyuanlong
Cc: l2vpn@ietf.org; Ali Sajassi; Himanshu Shah
Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Hi Yuanlong,

I'm not clear as to why different forwarding contexts for root and leaf is less than good -- can you elaborate?  Also I'm not clear as to why you see that ETREE using EVPN is any different from other topologies that can be created with EVPN.  EVPN's ability to create any topology is fundamental to it.  In IPVPN we commonly create hub-and-spoke VPN with hubs and spokes in different VRF. In some cases we even overlap one or more hub-and-spoke RT pairs with one or more mesh RT.  EVPN was purposefully designed to bring this flexibility to Ethernet.

Best regards -- aldrin


On Sunday, September 23, 2012, Jiangyuanlong wrote:
Hi Aldrin,

I agree with you that using different labels for root/leaf AC can work, but not sure using 2 forwarding contexts (EVI) is a good thing - that means forwarding plane for E-Tree will be very different from other services in E-VPN.

Regards,
Yuanlong

From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com<javascript:_e(%7b%7d,%20'cvml',%20'aldrin.isaac@gmail.com');>]
Sent: Sunday, September 23, 2012 9:21 PM
To: Alexander Vainshtein
Cc: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi; l2vpn@ietf.org<javascript:_e(%7b%7d,%20'cvml',%20'l2vpn@ietf.org');>
Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt



With EVPN, leaf AC should have different context and associated label from root AC.  A leaf AC forwarding context (say EVI) on an ingress PE would not import the RT for other leaf AC and hence not have forwarding vectors to any leaf AC.  The packet would have nowhere to go and hence be dropped on ingress.  In the case of BUM ingress replication, the leaf AC forwarding context on the ingress PE would not have imported the Inclusive Tag route of egress leaf AC and hence have no vectors to local replication context IDs of other leaf AC .  In the case of BUM tree, the leaf EVI would not have imported the Inclusive Tag route of other leaf EVI and hence not form a tree to other leaf EVI.




On Sunday, September 23, 2012, Alexander Vainshtein wrote:

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> [mailto:l2vpn-bounces@ietf.org] On Behalf

> Of Jiangyuanlong

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

> To: Giles Heron

> Cc: l2vpn@ietf.org<mailto: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<mailto:l2vpn@ietf.org>