Re: [bess] Query about Ethernet Tag Id for TYpe-5 routes (RFC 9136)

wang.yubao2@zte.com.cn Sat, 04 December 2021 04:26 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4C13A077D for <bess@ietfa.amsl.com>; Fri, 3 Dec 2021 20:26:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 N3qJg780zUOC for <bess@ietfa.amsl.com>; Fri, 3 Dec 2021 20:26:16 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4FB3A0777 for <bess@ietf.org>; Fri, 3 Dec 2021 20:26:15 -0800 (PST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4J5c5G5WXjz7R0Gq; Sat, 4 Dec 2021 12:23:46 +0800 (CST)
Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl1.zte.com.cn with SMTP id 1B44Q7OC082650; Sat, 4 Dec 2021 12:26:07 +0800 (GMT-8) (envelope-from wang.yubao2@zte.com.cn)
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid203; Sat, 4 Dec 2021 12:26:07 +0800 (CST)
Date: Sat, 04 Dec 2021 12:26:07 +0800
X-Zmail-TransId: 2afd61aaeddf8eacff5f
X-Mailer: Zmail v1.0
Message-ID: <202112041226077422518@zte.com.cn>
Mime-Version: 1.0
From: wang.yubao2@zte.com.cn
To: jorge.rabadan@nokia.com
Cc: bess@ietf.org, vinayak.joshi@hpe.com, jdrake@juniper.net
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 1B44Q7OC082650
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 61AAED52.000 by FangMail milter!
X-FangMail-Envelope: 1638591826/4J5c5G5WXjz7R0Gq/61AAED52.000/10.30.14.238/[10.30.14.238]/mse-fl1.zte.com.cn/<wang.yubao2@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 61AAED52.000/4J5c5G5WXjz7R0Gq
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/TwsdEnoqsGFARkhmqzJFtMEl_Vw>
Subject: Re: [bess] Query about Ethernet Tag Id for TYpe-5 routes (RFC 9136)
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: Sat, 04 Dec 2021 04:26:21 -0000

Hi Jorge and Vinayak,






I don't understand this use case of RFC9136 very well either,  


because when a BD of VLAN-aware bundle EVI is used in Bump-in-the-wire use case,


I don't sure how the IP prefixes routes are recursively rosolved.


I hope to share my understandings to help to make this use case more clear.






When  an IP Prefix route is advertised in the context of a VLAN-aware BD, and the IP Prefix route would be using a non-zero Ethernet Tag ID,


The overlay index of the IP prefix route should be considered to be the <ESI, Ethernet Tag ID> or just the ESI?


In section 3 of RFC9136, I see that only the ESI is considered to be the overlay index.






Thanks,



Yubao









On Fri, 3 Dec 2021 17:03:48 +0000

"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> wrote:




> Hi again,

> 

> John pointed to me that there are some cases where a non-zero Ethernet Tag ID on the IP Prefix route may be used in RFC9136.

> 

> In the RFC9136 IP-VRF-to-IP-VRF use cases, the Ethernet Tag ID is always zero, since the IP Prefix route is advertised in the context of the IP-VRF. However it is true that RFC9136 also discusses some use-cases where the IP Prefix route is advertised in the context of a BD, in which case, if the BD belongs to a VLAN-aware bundle EVI, the IP Prefix routes would be using a non-zero Ethernet Tag ID.

> 

> I overlooked that when I replied first.

> Thanks John.

> 

> Jorge

> 

> From: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>

> Date: Thursday, December 2, 2021 at 6:00 PM

> To: Joshi, Vinayak <vinayak.joshi@hpe.com>, bess@ietf.org <bess@ietf.org>

> Subject: Re: Query about Ethernet Tag Id for TYpe-5 routes (RFC 9136)

> Hi Vinayak,

> 

> RFC9136 does not have any use case for the use of a non-zero ethernet tag id. The IP Prefix route includes the ethernet tag id as part of the key for consistency with the rest of the EVPN service routes, for future use.

> 

> Thanks.

> Jorge

> 

> From: BESS <bess-bounces@ietf.org> on behalf of Joshi, Vinayak <vinayak.joshi@hpe.com>

> Date: Thursday, December 2, 2021 at 7:33 AM

> To: bess@ietf.org <bess@ietf.org>

> Subject: [bess] Query about Ethernet Tag Id for TYpe-5 routes (RFC 9136)

> Hi all,

> 

> RFC 9136 says the following (Section 3.1)

> 

> 

> “   The RD, Ethernet Tag ID, IP prefix length, and IP prefix are part of

>    the route key used by BGP to compare routes.  The rest of the fields

>    are not part of the route key.

> 

> With VLAN Aware Bundling the Eth Tag ID acts as a distinguisher for the routes while importing into L2-VRF.

> But for L3 prefix routes what is the use case for setting the Ether Tag ID to any non-zero value?

> 

> Thanks in advance,

> Vinayak