[bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-00 and/or draft-ietf-bess-evpn-inter-subnet-forwarding

<wang.yubao2@zte.com.cn> Wed, 03 July 2019 01:28 UTC

Return-Path: <wang.yubao2@zte.com.cn>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BB7111200F6 for <bess@ietfa.amsl.com>; Tue, 2 Jul 2019 18:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Xl1mOXRSiyb2 for <bess@ietfa.amsl.com>; Tue, 2 Jul 2019 18:28:10 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E561200DE for <bess@ietf.org>; Tue, 2 Jul 2019 18:28:09 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown []) by Forcepoint Email with ESMTPS id F3442531F51A3759A74C; Wed, 3 Jul 2019 09:28:06 +0800 (CST)
Received: from njxapp03.zte.com.cn ([]) by mse-fl1.zte.com.cn with SMTP id x631PYhb060984; Wed, 3 Jul 2019 09:25:34 +0800 (GMT-8) (envelope-from wang.yubao2@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Wed, 3 Jul 2019 09:25:34 +0800 (CST)
Date: Wed, 3 Jul 2019 09:25:34 +0800 (CST)
X-Zmail-TransId: 2afb5d1c040eab20ad00
X-Mailer: Zmail v1.0
Message-ID: <201907030925342754178@zte.com.cn>
Mime-Version: 1.0
From: <wang.yubao2@zte.com.cn>
To: <sajassi@cisco.com>, <jorge.rabadan@nokia.com>, <jdrake@juniper.net>
Cc: <bess@ietf.org>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn x631PYhb060984
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/hgEQCVgRNrB72t8nyXpgrFWnrDE>
Subject: [bess] =?utf-8?q?Comments_on_draft-sajassi-bess-evpn-ip-aliasing?= =?utf-8?q?-00_and/or_draft-ietf-bess-evpn-inter-subnet-forwarding?=
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2019 01:28:13 -0000

Hi Ali and everyone,

I reviewed the [EVPN IP Aliasing] draft and found that it conflicts with draft-ietf-bess-evpn-inter-subnet-forwarding-05 in MPLS encapsulation.


draft-sajassi-bess-evpn-ip-aliasing-00 section 2.1 Constructing Ethernet A-D per EVPN Instance Route

... ...

   * The L3 EAD/EVI SHOULD carry one or more IP VRF Route-Target (RT)       


   * The L3 EAD/EVI SHOULD carry the RMAC Extended Community attribute.    

   * The MPLS Label usage should be as described in RFC 7432. 

... ..



draft-ietf-bess-evpn-inter-subnet-forwarding-05 section 3.2.3 Data Plane - Ingress PE

 ... ...

   If the tunnel type is that of MPLS or IP-only NVO tunnel, then TS's

   IP packet is sent over the tunnel without any Ethernet header.

   However, if the tunnel type is that of Ethernet NVO tunnel, then an

   Ethernet header needs to be added to the TS's IP packet. The source

   MAC address of this inner Ethernet header is set to the ingress PE's

   router MAC address and the destination MAC address of this inner

   Ethernet header is set to the egress PE's router MAC address. The

   MPLS VPN label or VNI fields are set accordingly and the packet is

   forwarded to the egress PE. 

 ... ...


In the first draft the L3 EAD/EVI Route for symmetric IRB uses a L2 MPLS Label, 

so the PE expects to receive a EVPN data packet with an overlay ethernet header as per RFC7432.

But unfortunatly, in the second draft, the inter-subnet forwarding procedures for symmetric IRB 

will always send the EVPN data packet without the overlay ethernet header. 

So I think these two drafts conflicts with each other, and one of them should be updated.

and I propose that the [EVPN IP Aliasing] draft should use a L3 MPLS Label in the L3 EAD/EVI route.

How do you think about it?

Best Regards