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

Haoweiguo <haoweiguo@huawei.com> Tue, 22 July 2014 12:53 UTC

Return-Path: <haoweiguo@huawei.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 48C861A0B10 for <l2vpn@ietfa.amsl.com>; Tue, 22 Jul 2014 05:53:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.749
X-Spam-Level: *
X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 GrYaDQipZ7a5 for <l2vpn@ietfa.amsl.com>; Tue, 22 Jul 2014 05:53:34 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93511A0652 for <l2vpn@ietf.org>; Tue, 22 Jul 2014 05:53:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHM25321; Tue, 22 Jul 2014 12:53:31 +0000 (GMT)
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Jul 2014 13:53:29 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 22 Jul 2014 20:53:18 +0800
From: Haoweiguo <haoweiguo@huawei.com>
To: "UTTARO, JAMES" <ju1738@att.com>, "'l2vpn@ietf.org'" <l2vpn@ietf.org>, "'sajassi@cisco.com'" <sajassi@cisco.com>
Subject: 答复: 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/qJusCIVQgAABFeY=
Date: Tue, 22 Jul 2014 12:53:17 +0000
Message-ID: <DD5FC8DE455C3348B94340C0AB5517334F7E6313@nkgeml501-mbs.china.huawei.com>
References: <DD5FC8DE455C3348B94340C0AB5517334F7E6255@nkgeml501-mbs.china.huawei.com>, <B17A6910EEDD1F45980687268941550F06D53249@MISOUT7MSGUSRCD.ITServices.sbc.com>
In-Reply-To: <B17A6910EEDD1F45980687268941550F06D53249@MISOUT7MSGUSRCD.ITServices.sbc.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.131.9]
Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F7E6313nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/WII7hUENYBJRiiO6z-BHCkJ-gdU
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:53:36 -0000

Yes, it is for scalability. NVO3 network and EVPN network can be inter-connected through option-A or option-B method. Option-A is back-to-back connection method, sub-interfaces associated with each MAC-VRF are created to connect two ASBRs. If there are huge number of tenants and end systems in data center,  it will impose big burden on ASBRs.

In option-B solution, only VN ID and MPLS VPN Label switching is needed on ASBR, no need to create huge number of sub-interfaces and MAC-VRFs.

EVPN base protocol provides homogenous network inter-as option-B connection method, for heterogeneous network, new technical points should be introduced, this draft describes inter-as option-B for heterogeneous network interconnection.

weiguo

________________________________
发件人: UTTARO, JAMES [ju1738@att.com]
发送时间: 2014年7月22日 20:36
收件人: Haoweiguo; 'l2vpn@ietf.org'; 'sajassi@cisco.com'
抄送: 'Vic Liu'; Frank xu
主题: RE: About inter-as option-B solution between NVO3 network and EVPN network

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