IETF Logo Mail Archive

RE: About inter-as option-B solution between NVO3 network and EVPN network

"UTTARO, JAMES" <ju1738@att.com> Tue, 22 July 2014 12:40 UTC

Return-Path: <ju1738@att.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506661A0B0F for <l2vpn@ietfa.amsl.com>; Tue, 22 Jul 2014 05:40:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7l54G6W9bGn for <l2vpn@ietfa.amsl.com>; Tue, 22 Jul 2014 05:40:25 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574FC1A0B13 for <l2vpn@ietf.org>; Tue, 22 Jul 2014 05:40:04 -0700 (PDT)
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 4ab5ec35.2b690c8b3940.4102866.00-2421.11442275.nbfkord-smmo05.seg.att.com (envelope-from <ju1738@att.com>); Tue, 22 Jul 2014 12:40:04 +0000 (UTC)
X-MXL-Hash: 53ce5ba4641cf780-d62c8817308f150e363f48aaf1d299adf740f2c0
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id aea5ec35.0.4101197.00-2240.11437484.nbfkord-smmo05.seg.att.com (envelope-from <ju1738@att.com>); Tue, 22 Jul 2014 12:37:00 +0000 (UTC)
X-MXL-Hash: 53ce5aec27958fc1-483c9f574a003f01801e5917ac16fa6cc31a309b
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6MCav5q005392; Tue, 22 Jul 2014 08:36:58 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6MCagl0005207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2014 08:36:47 -0400
Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 22 Jul 2014 12:36:26 GMT
Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.29]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 08:36:26 -0400
From: "UTTARO, JAMES" <ju1738@att.com>
To: 'Haoweiguo' <haoweiguo@huawei.com>, "'l2vpn@ietf.org'" <l2vpn@ietf.org>, "'sajassi@cisco.com'" <sajassi@cisco.com>
Subject: RE: About inter-as option-B solution between NVO3 network and EVPN network
Thread-Topic: About inter-as option-B solution between NVO3 network and EVPN network
Thread-Index: AQHPpVi3EZreusKv3UCYUjOuvcu/qJusCIVQ
Date: Tue, 22 Jul 2014 12:36:26 +0000
Message-ID: <B17A6910EEDD1F45980687268941550F06D53249@MISOUT7MSGUSRCD.ITServices.sbc.com>
References: <DD5FC8DE455C3348B94340C0AB5517334F7E6255@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <DD5FC8DE455C3348B94340C0AB5517334F7E6255@nkgeml501-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.101.35]
Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F06D53249MISOUT7MSGUSRCD_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=YYkKEXtf c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=IVec6rvzyLMA:10 a=ofMgfj31e3cA:10 a=WSY2yPJkZp0A:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA]
X-AnalysisOut: [AAA:8 a=AUd_NHdVAAAA:8 a=rmX2rSMOcY9gcJmx6lsA:9 a=CjuIK1q_]
X-AnalysisOut: [8ugA:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a=yMhMjlubAAAA]
X-AnalysisOut: [:8 a=SSmOFEACAAAA:8 a=VAhy_TdBy8ZAR8odLUYA:9 a=gKO2Hq4RSVk]
X-AnalysisOut: [A:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10]
X-AnalysisOut: [ a=B30_pNtOU0k2EQyn:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: <ju1738@att.com>
X-SOURCE-IP: [144.160.229.24]
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Rvh0a5_siCLJlKb35dL2s3B54WE
Cc: 'Vic Liu' <liuzhiheng@chinamobile.com>, 'Frank xu' <frank.xu@huawei.com>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Layer 2 Virtual Private Networks <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: Tue, 22 Jul 2014 12:40:30 -0000

Not sure I understand what is the problem being solved by this draft?? Is it scalability??

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Haoweiguo
Sent: Monday, July 21, 2014 10:59 PM
To: l2vpn@ietf.org; sajassi@cisco.com
Cc: Vic Liu; Frank xu
Subject: About inter-as option-B solution between NVO3 network and EVPN network


Hi Ali,

I think the inter-as option-B solution in our draft is different from current EVPN inter-as solution. The procedures are described as follows:



Assuming ASBR in NVO3 network is called ASBR-d, ASBR in EVPN network is called ASBR-w.



Control plane process:

1. From DC to WAN side:

MPLS VPN Label is allocated on ASBR-d per ESI per VN, the usage of the VN has no change from traditional NVO3 network,the VN has global significance; For single-homed scenario, it is allocated per NVE per VN. Incoming forwarding table is generated on ASBR-d. ASBR-d advertises the MAC/IP advertisement route with new allocated MPLS VPN Label to peer ASBR-w.



2.From WAN to DC side:

VN ID is allocated per MPLS VPN Label, the VN ID has local significance on ASBR-d.  Outgoing forwarding table is generated on ASBR-d. ASBR-d advertises the MAC/IP advertisement route with new VN ID to local NVE.



Data plane process:

1.From DC to WAN side:

When a NVE receives traffic from local TS, the NVE performs MAC lookup in local VN, then it sends the traffic to ASBR-d using NVO3 encapsulation, VN ID is the new allocated VN ID on ASBR-d, It can only have local significance on ASBR-d. ASBR-d performs NVO3 decapsulation, switch VN ID to MPLS VPN Label, then performs MPLS encapsulation and sends to peer ASBR-w.



2. From WAN to DC side:

When ASBR-d receives traffic from peer ASBR-w, ASBR-d switches MPLS VPN Label to local NVE+ VN ID and sends it to local NVE using NVO3 encapsulation. The VN ID in the NVO3 header has global significance on all NVEs.



In option-B solution, only VN ID and MPLS VPN Label switching is supported on ASBR-d, ASBR-d doesn't need to perform MAC look up, ASBR-d has more scalability.

Thanks

weiguo

v2.23.0 | Report a Bug | By Email