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

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Wed, 23 July 2014 05:23 UTC

Return-Path: <sajassi@cisco.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 A05A41B28F4 for <l2vpn@ietfa.amsl.com>; Tue, 22 Jul 2014 22:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 FyrNqBBFvMvc for <l2vpn@ietfa.amsl.com>; Tue, 22 Jul 2014 22:23:42 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7FB71B28E6 for <l2vpn@ietf.org>; Tue, 22 Jul 2014 22:23:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7554; q=dns/txt; s=iport; t=1406093023; x=1407302623; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=XAGF46pDEl9RRAFMnUPqp/1tEY3DSWRXIiV0c24WwLE=; b=E6obcix5qUoAklwjfzXVj62Z2keSLUi4frQGytSlleE+F01gk7H1joQq 1P2ppzCyvd4HPwanE0dYWDJxUGXQmDf/dNV/J/plkR5vjcWPNbtij644N c3R2lHYiJgn3auXQqRXjPFdfoUSc5Ng1WNjzxBHNs8IfA9QmPFl5Jr9pw k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEFAJFFz1OtJA2M/2dsb2JhbABZgkcjJIEpBM8pAYELFnaEAwECBHkSAQgRAwECKDkUCQgCBAENBRuIJwG/KhePOhEHhEYFmyaUNINGbIFF
X-IronPort-AV: E=Sophos; i="5.01,715,1400025600"; d="scan'208,217"; a="63214481"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP; 23 Jul 2014 05:23:42 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6N5NeEr016981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 05:23:40 GMT
Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 00:23:40 -0500
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Haoweiguo <haoweiguo@huawei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
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/qJutMowA
Date: Wed, 23 Jul 2014 05:23:39 +0000
Message-ID: <CFF4BB85.E32A2%sajassi@cisco.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:
user-agent: Microsoft-MacOutlook/14.3.4.130416
x-originating-ip: [10.21.70.24]
Content-Type: multipart/alternative; boundary="_000_CFF4BB85E32A2sajassiciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Gd9BwMmCGVpDJfNUFKf98FTuZLA
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: Wed, 23 Jul 2014 05:23:43 -0000

Hi Weiguo,

As discussed in person, there is a considerable overlap between this draft and what already exist in evpn-overlay and dci-evpn-overlay. Locally-significant VNID is covered in the former and the globally-significant VNID is covered in the latter draft. If additional clarification is need, we welcome your contribution in that.

Cheers,
Ali



From: Haoweiguo <haoweiguo@huawei.com<mailto:haoweiguo@huawei.com>>
Date: Monday, July 21, 2014 10:58 PM
To: "l2vpn@ietf.org<mailto:l2vpn@ietf.org>" <l2vpn@ietf.org<mailto:l2vpn@ietf.org>>, Cisco Employee <sajassi@cisco.com<mailto:sajassi@cisco.com>>
Cc: Frank xu <frank.xu@huawei.com<mailto:frank.xu@huawei.com>>, Zhuangshunwan <zhuangshunwan@huawei.com<mailto:zhuangshunwan@huawei.com>>, Vic Liu <liuzhiheng@chinamobile.com<mailto:liuzhiheng@chinamobile.com>>
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