[bess] [Shepherding AD review] Pre-IETF Last-Call review of draft-ietf-bess-evpn-mh-split-horizon-08

"Gunter van de Velde (Nokia)" <gunter.van_de_velde@nokia.com> Tue, 11 June 2024 16:33 UTC

Return-Path: <gunter.van_de_velde@nokia.com>
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 A2C00C1D61E6; Tue, 11 Jun 2024 09:33:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nokia.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tFw0O-r0qx7; Tue, 11 Jun 2024 09:33:55 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2088.outbound.protection.outlook.com [40.107.20.88]) (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 1999FC14CF1E; Tue, 11 Jun 2024 09:33:54 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bpB0xGOXgTwPvK7VavR/lr/HHbuEyYER56U37EiG76PQBikml3XKqeYJJeBtkqFno9VBpT+DkogqTMKra8p6UrRAzNapcKjVwDSQr3kWnKg2txQpoGlqPiGj4n7QlrZlthAe2ZKSelDYOmc6ZN3ZdufKs9tR2JYIUV/N8ATNItZ7NrVjG9RTM5wUcE+9snGpCXG9o6dhAmnVe5hBmeMAX13HeYPLTSTQF/XWYad/tBkL6ddGAKUs8+98U4A5WiZLcGAN9vmSNLrJDj0DoNac2grtvUGkHXX6sFwCdsV43XERZcPzSEIpQLH17xJzNYMMHBlzXCXqvr49KjDqCbhiIg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dBYi6hXjRjYfcTUoEviMiM5c1yG1GqEyZfzqigZKilU=; b=aNd2IFxlYCt5k2tTCLoLi6AXI0Eo+MyJg2MhwLepK2kdQYlV+gc/3fj7TVx/JbxrlXLkJc+CzRo4hxtlLYUhn3cdTvnm9SaAuilNB+1FHqKPS4x2o+gylMmu/S+a20EhlvDfD91zZ1HbnVBu1H0TerXRaNii2ySj7EHqqfnMsV5jANcExFTNbeiU2Dhr2z6W3tpZugbmhSDGUEkmBJK1WHqZlhnoWNJGV3GSQcuAD3shihO0hx6j/lzGIaOjuZVz8hfIGkoeaVyysvsFnWwY5WEXqw1V9ruQkbF0Loawdn4bx1wcIxs9OaB908DIYeGh8yrVGW85miFf4N+nzKjjJw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dBYi6hXjRjYfcTUoEviMiM5c1yG1GqEyZfzqigZKilU=; b=qco2zApYRdlma4o8bW1Bp3VgA6qckZ0o+L8FuJIrjWB4Zly6/ZCW5MliPurRYKgedqknT+vXDhsalx0XcKO9s8mIWqs8RiyFpBcvzMRiPtvltMRSQy9FjaRghh5mDv1GvJ6ST14IqStVOv+G//laddcfT6L8bQoUNzZehNH/wB16oo++imH2wLD1AnJMuMmOOXdzPUgzutLYab5OjJYCUKK9ELe+XZc2wM4eDsZhoYUVwcZSjbMLkDWr8sHz68siA7Ffcmwmhi14CCvHRx2QeV29un1Xg2hXPYHa5movE49xvqUGGCIrYoq/RWDQRdD2niJTVNlqm2JSeSv18vFw8Q==
Received: from AS1PR07MB8589.eurprd07.prod.outlook.com (2603:10a6:20b:470::16) by AS1PR07MB8832.eurprd07.prod.outlook.com (2603:10a6:20b:47f::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7633.34; Tue, 11 Jun 2024 16:33:51 +0000
Received: from AS1PR07MB8589.eurprd07.prod.outlook.com ([fe80::5ca6:f902:8e31:6f3e]) by AS1PR07MB8589.eurprd07.prod.outlook.com ([fe80::5ca6:f902:8e31:6f3e%3]) with mapi id 15.20.7633.036; Tue, 11 Jun 2024 16:33:50 +0000
From: "Gunter van de Velde (Nokia)" <gunter.van_de_velde@nokia.com>
To: 'BESS' <bess@ietf.org>
Thread-Topic: [Shepherding AD review] Pre-IETF Last-Call review of draft-ietf-bess-evpn-mh-split-horizon-08
Thread-Index: Adq8HMj6IWzIxN5PTdSTYPmU1l93sw==
Date: Tue, 11 Jun 2024 16:33:50 +0000
Message-ID: <AS1PR07MB85896624830690B704ACEBA9E0C72@AS1PR07MB8589.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS1PR07MB8589:EE_|AS1PR07MB8832:EE_
x-ms-office365-filtering-correlation-id: 32ba893b-37ad-44de-7c85-08dc8a3446b0
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230032|376006|366008|1800799016|38070700010;
x-microsoft-antispam-message-info: jEBQqTEJnTeReSP6iKM0NxCI64OUssyG+BeEpEhED6MaRMybdgLGQxRkeIHqCCEKqe0ojkUE8P8Ar6VohaoMBlrdmJGxbrfi9Y3EGq9JpB53wgsGb8C0cyYVV+oatdVtNTsDPjwBf7O1+gTQdFz+3vgFDBRlDAaJrMxveEqCsV1xgy0mv/nnmLDOAREqo03p8SwRP42/9hW8i3KYyscUEYpMYSO8LJ5tp7Y4qSCIzHX6wdbeAsJOkF/rHr5Y2S2cD1IOfyG5yU0tOsTV5YGqOyf+oxPI8SUwFvRxOYJZTp2V1WPqB0RbOyGoPeCW16t3uK7S6+X+6N9ye9ICSyK18O/fT7utQI6q8ID9PbxT0lH049HoHDbaRnMzmqOVuijWdfpX02GB41z1NfBCVBVDhYpomtntB6+KZ0gYqmf6utMhDPCn7DV3YPALMV+6GXMwiJ7NVAI+rbcFk0RsGM3Rb25oZU+7y9xjp9BJQ9e7ogcG+z1Tgb6kCWyuuNpHMYPdo5erzEkdkDDPHnd1Fu4eA6R/HTJQjCnr4UJHor89KuMteX5BwNh1qhfilSKw0NLW1WtGXITYmWqFf7nwTdaHLh0TZQOMfWYmdHqE4g1z1JL4QVnjKULQl/Fo/rpmuxOganfPZTGz24/nMg9Rlzzx4E+rE+7zApgTdi5x++XktcnpTI7X+xLmEt9SElpS3YacSGUjjISD5nMk9Yz9hl53O4YD/vA3OdOIl3eqwzkiens5+bsu6pP65A5XfDsVsA2VYbB88WZFwLuq1ynb72TwFvNOBS1jhbURiIFa8EluRMZwSRqSeHdj2fH48RsiHt6zm9PFft2RyqsE6CMLkYdacHxHKFNDPy/B2R6iiit7ZACEnpFlzLtB1WQAO8XFTodoHeir0HJ8MKMgkydo8hg+I1+H6Kvjq1bn+FH13ZoNcta/zHpzWFhmRvQLOKjm/GZWKQZycA/Vk/X6m0TUObPBElBucqsyMb/42ttsv66w+tEJslcb5H2bGHjpJbTEh9CjVgM9t74+bPY8+FNYzDJhhy0Xv8pu4IzVHQDx4T+rVoaVMCPfkbBzz9QcE0rvqJNFRoc8VqdriaOSowHSnXvWjostQO/39pLE06egTOnZHke5d731N1sha32h8PlwJgC+MhgxhbSPjjUmmPMj+HvwgGQ9+ohQYXhQ3silUaz2MgzkKjrdJkq+4tX6YQha62Rfm1mdclmadJWqhbx8vWJOXXjcrCOxVt7K9FGAYts3poMFA1edvM//5TXePe7KQSe8yvdRWcvvr6bYJjQKUVKn9yyoueIKlKXZwfOB/pWctya+uP48tQ09LZu+RUuznsnYVd6CnEFrdeB9FV03gECVFYH2tVNi6/D7ZpNLDMChyyg=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS1PR07MB8589.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230032)(376006)(366008)(1800799016)(38070700010);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: PdAFmQtEdmVpr8fj4jXCDDLT7qDxh37d9anzPuN2bbo7QTeSkUDiXCvIGFzi2ejfC+5fbL63D80uPQ5IElbsp1zoDb+CTrpqBZjNfvRZMvughHRJ7uVu35qib3IFBERIGl/2i9tSwIJEzwdsWYoVUZiG8du0+sRFtIM6StdiI9RDzMdlrLpOBpfKjNJa4mN8jGVn5xmkVo6WDXQudRAh4YToh205oNZFAoXgExYumZaft3KBI/IU4ZjlHRUB32zlp4qrad2uCwFOFH8+fbZ8duZe/SjXkxCOPhs3vZFhjScInW3x5rJV5NKVZFAXmO++9ST6kf8cnMIIM9zdCf+EwYp3EZio8CQTQeejqBek88U0hvzRGPjddUT7HYOtbxzFhP2lPZVQeb4GM2eEsKluTdkfB4yYir9S/LFuWNTP9wN8lKmVoS+6VLPcQ+xo4QLWjGJ13z6RfRQhL+yL/DHfateTt8XW+92YECRy4Poc7CksRHf7LUZKfkh8TujmaNqaqTGEyZbOKevjUYXHC1tHItleggQDWr5/72fW8TwPiLq3+ZvuoB32uzPwOpBgZqYUSFpoKKU9Zzxby8y5GrcM9LVc8o1aUfQMj9GeW41UwHiomUcmTNq1swz6+74NQ2Ek0rPntzBiXPHFt0eHFsdxwq9S3vX82bW5O8BGYHqWGoeLYnyjtphmllhdDYoxHD/jC3wCKyXM+HHL9B42dcsZUHMJboyRyWbSLtn7DsgMRWGiRMKJkJ+tnB631ejTN1n5W6U/v/dXNpOxqtMugrw+SCvQsVDtL9hLNn751JnxmmwFE/QGwSBSU5x1m5Ep+qf3tlo7qgop+YIhgBPUSWvuVi45waAMN8cseLlmmmKEBMD0Tkv29hnumqm/6dDp8KsrQoQd46d74SENHKgJ9nPHhXx/w31wQ38xR3UJmiHXDbg6/8V6JBZJSoXTdtCD4E/iXx1vsQf6wfZespD+Hann3RvpTDtQ4TpPQULZZ4LZ0fmSk5PC9yrTVDuc86eaI/scjmAheagomyXWd1rr2BLgF1Xo1XmZaWrwAnHo/+bjlskQYcIVAuMhxWrsoK/F/0qdI/whS4QLJPwkSCjrIUMXMmwXy2TYOXlLSlO+lh3s9GUXAz3uR9SJLRNKkysTuRqoLCrd6a8YVLNJ+XcpcCpfHDnGUerYxE/rPD+RxezNEHw09s3Q52Z2912KHH9kQzKshp4ozuktDrRN/g4PWEzoNXyPvx4RsEWVV+JFGK96qvZjPS8J4rMoMMjKoiFXPKU+nna98hkJAwsguYj0RcHVWGlOeiY4mgLDKOaG4V7u3olaTJdLMryyjNzGsehMZTXFaNQhCaL5fDbYch1YbOC2waIo1YDSG2uiof1fNlly5//RAfThdjjZVFx/SJGfJjB4mdkiLbFHyo7h/ifnQ2y3Tf0g48uEfsZcVjIHp+fcFYhOXyCpzjxtl1cLd62LEXt/kuj7ncTO/pCdT18eQNJ96kz/Y9j6+9p23RY3Ieu+YNI+zPG4h3xzFe7Gl2kM7tg1wkoH665KD9z1e/reB7BlgnEI1Yu3bYJq0oeskbt2kqPF9GjpgsdiGfl1JPhjOmZdwGus2LiHUcBXG1yY0A26dgXw71P4Z38sxWlDDPe5HkFXG1bjFvegCrhboY2BtvctEviO00w7Xw84F9edLI0p9g==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS1PR07MB8589.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 32ba893b-37ad-44de-7c85-08dc8a3446b0
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2024 16:33:50.8531 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Tt4YQAK3DZ0oQ0oMv9xA6BoCe5Rz3wQRPjeAUlSEC0JkN6kg2xajYBZAN8c90AjUjYT/YxkqgjyzWqNV8PouV3/DcRaDVfIdOa/mRhHDo9M=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS1PR07MB8832
Message-ID-Hash: G6YJ6NLLDXM3TZGNDT4VMHKDEFXF6BLW
X-Message-ID-Hash: G6YJ6NLLDXM3TZGNDT4VMHKDEFXF6BLW
X-MailFrom: gunter.van_de_velde@nokia.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "draft-ietf-bess-evpn-mh-split-horizon@ietf.org" <draft-ietf-bess-evpn-mh-split-horizon@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [bess] [Shepherding AD review] Pre-IETF Last-Call review of draft-ietf-bess-evpn-mh-split-horizon-08
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/nJiVUSXkIqhhDcdXtGomjqwnDMw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Owner: <mailto:bess-owner@ietf.org>
List-Post: <mailto:bess@ietf.org>
List-Subscribe: <mailto:bess-join@ietf.org>
List-Unsubscribe: <mailto:bess-leave@ietf.org>

# Gunter Van de Velde, RTG AD, comments for draft-ietf-bess-evpn-mh-split-horizon-08

Hi Authors, 

Many thanks to Himanshu Shah for the RTG-DIR review and Jouni Korhonen for GENART review.

Please find some review notes below. Before processing the draft further with the IESG and requesting IETF Last-Call, please have a look into these observations. I believe the document is well written. Mostly the observations are efforts to further enhance grammar/readablity and try to clarify some formal procedures.

There is some need to expand with more content on the flags field for which the IANA section requests a new 8 bit flags registery. I also wonder if the 'RFC Required' is strict enough to contol the 8 bits. I am wondering if we should not enforce IETF consensus/review to allocate any of them? When the registry policy is set to "IETF Review" we make sure that there is an IETF track document. Individual submissions are not valid for requesting a code point with "IETF Review" policy.  Also, would authors investigate if the not-yet-allocated flag bits are unused or reserved, and what the implied actions are for senders/recipients of the bits within the flags field are. And finally, where in the existing IANA registry will the new flags field registry be placed? It is not mentioned in the draft.

Thanks for all the hard work on this document. Before progressing i will be waiting for your feedback and your revised drafts.

Please find below my observations when going through draft-ietf-bess-evpn-mh-split-horizon-08

#Review Observations
#===================

16	   Ethernet Virtual Private Network (EVPN) is commonly used along with
17	   Network Virtualization Overlay (NVO) tunnels, as well as MPLS and
18	   Segment Routing tunnels.  The EVPN multi-homing procedures may be
19	   different depending on the tunnel type used in the EVPN Broadcast
20	   Domain.  In particular, there are two multi-homing Split Horizon
21	   procedures to avoid looped frames on the multi-homed CE: ESI Label
22	   based and Local Bias.  ESI Label based Split Horizon is used for
23	   MPLSoX tunnels, E.g., MPLSoUDP, whereas Local Bias is used for other
24	   tunnels, E.g., VXLAN tunnels.  The existing specifications do not
25	   allow the operator to decide which Split Horizon procedure to use for
26	   tunnel encapsulations that could support both.  Examples of tunnels
27	   that may support both procedures are MPLSoGRE, MPLSoUDP, GENEVE or
28	   SRv6.  This document updates the EVPN Multihoming procedures in
29	   RFC8365 and RFC7432 so that an operator can decide the Split Horizon
30	   procedure for a given tunnel depending on their own requirements.

Maybe a proposed readability re-edit as follows helps reders of the abstract to understand the document intent better:

"
Ethernet Virtual Private Network (EVPN) is commonly used with Network Virtualization Overlay (NVO) tunnels, as well as MPLS and Segment Routing tunnels. The multi-homing procedures in EVPN may vary based on the type of tunnel used within the EVPN Broadcast Domain. Specifically, there are two multi-homing Split Horizon procedures designed to prevent looped frames on multi-homed Customer Edge (CE) devices: the ESI Label-based procedure and the Local Bias procedure. The ESI Label-based Split Horizon is applied to MPLS-based tunnels, such as MPLSoUDP, while the Local Bias procedure is used for other tunnels, such as VXLAN.

Current specifications do not allow operators to choose which Split Horizon procedure to use for tunnel encapsulations that support both methods. Examples of tunnels that may support both procedures include MPLSoGRE, MPLSoUDP, GENEVE, and SRv6. This document updates the EVPN multi-homing procedures described in RFC 8365 and RFC 7432, enabling operators to select the appropriate Split Horizon procedure for a given tunnel based on their specific requirements.
"

85	   Ethernet Virtual Private Network (EVPN) is commonly used with the
86	   following tunnel encapsulations:
88	   *  Network Virtualization Overlay (NVO) tunnels as specified in
89	      [RFC8365]
91	   *  MPLS and Segment Routing with MPLS data plane (SR-MPLS), as
92	      specified in [RFC7432]
94	   *  Segment Routing with IPv6 data plane (SRv6), as specified in
95	      [RFC9252].

The abstract mentions: MPLSoGRE, MPLSoUDP, GENEVE or SRv6

The list here does not explicit calls these out. Can relevant references be added?
Also is an MPLS lsp considered as a tunnel in the context of this document? if yes, it maybe should be added next to referencing SRv6?

97	   The EVPN multihoming procedures may be different depending on the
98	   tunnel type used in the EVPN Broadcast Domain.  In particular, there
99	   are two multihoming Split Horizon procedures to avoid looped frames
100	   on the multihomed CE: ESI Label based and Local Bias.  ESI Label
101	   based Split Horizon is used for MPLS or MPLSoX tunnels, E.g.,
102	   MPLSoUDP [RFC7510], and its procedures described in [RFC7432].  Local
103	   Bias is used by IP tunnels, E.g., VXLAN tunnels, and it is described
104	   in [RFC8365].

>From readability perspective, the following can be used to improve the text:

"
The EVPN multihoming procedures may vary depending on the type of tunnel utilized within the EVPN Broadcast Domain. Specifically, there are two multihoming Split Horizon procedures employed to prevent looped frames on multihomed Customer Edge (CE) devices: the ESI Label-based procedure and the Local Bias procedure.

The ESI Label-based Split Horizon procedure is used for MPLS or MPLS-over-X (MPLSoX) tunnels, such as MPLS-over-UDP as specified in [RFC 7510], and its procedures are detailed in [RFC 7432]. Conversely, the Local Bias procedure is used for IP-based tunnels, such as VXLAN tunnels, and it is described in [RFC 8365].
"

112	      When EVPN is used for MPLS transport tunnels, an MPLS label
113	      enables the Split Horizon filtering capability to support All-
114	      Active multihoming.  The ingress Network Virtualization Edge (NVE)
115	      device adds a label corresponding to the source ES (an ESI label)
116	      when encapsulating the packet.  The egress NVE checks the ESI
117	      label when attempting to forward a multi-destination frame out of
118	      a local ES interface, and if the label corresponds to the same
119	      site identifier (ESI) associated with that ES interface, the
120	      packet is not forwarded.  This prevents the occurrence of
121	      forwarding loops for BUM traffic.

123	      The ESI Label Split Horizon filtering SHOULD also be used with
124	      Single-Active multihoming to avoid transient loops for in-flight
125	      packets when the egress NVE takes over as Designated Forwarder for
126	      an ES.

I am wondering if the SHOULD in the above paragraph is something this document is adding to its formal procedures? if not, then i wonder why RFC2119 language is used. In the contex above it seems to be more a suggestion then a formal procedure description. In the below roposed rewrite, i used lowercase should.

>From readability perspective, the following can be used to improve the text:

"
When EVPN is employed for MPLS transport tunnels, an MPLS label facilitates Split Horizon filtering to support All-Active multihoming. The ingress Network Virtualization Edge (NVE) device appends a label corresponding to the source Ethernet Segment Identifier (ESI label) during packet encapsulation. The egress NVE verifies the ESI label when attempting to forward a multi-destination frame through a local Ethernet Segment (ES) interface. If the ESI label matches the site identifier (ESI) associated with that ES interface, the packet is not forwarded. This mechanism effectively prevents forwarding loops for Broadcast, Unknown Unicast, and Multicast (BUM) traffic.

The ESI Label Split Horizon filtering should also be utilized with Single-Active multihoming to prevent transient loops for in-flight packets when the egress NVE assumes the role of Designated Forwarder for an ES.
"

130	      Since IP tunnels (such as VXLAN or NVGRE) do not support the ESI
131	      label (or any MPLS label at all), a different Split Horizon
132	      filtering procedure must be used for All-Active multihoming.  This
133	      mechanism is called Local Bias and relies on the tunnel source IP
134	      address to decide whether to forward BUM traffic to a local ES
135	      interface at the egress NVE.
136
137	      In a nutshell, every NVE tracks the IP address(es) associated with
138	      the other NVE(s) with which it has shared multihomed ESs.  When
139	      the egress NVE receives a BUM frame encapsulated in a IP tunnel,
140	      it examines the source IP address in the tunnel header (which
141	      identifies the ingress NVE) and filters out the frame on all local
142	      interfaces connected to ESes that are shared with the ingress NVE.
143
144	      Due to this behavior at the egress NVE, the ingress NVE's behavior
145	      is also changed to perform replication locally to all directly
146	      attached ESes (regardless of the Designated Forwarder election
147	      state) for all BUM ingress from the access ACs.  Because of this
148	      "local" replication at the ingress NVE, this approach is referred
149	      to as Local Bias.
150
151	      Local Bias cannot be used for Single-Active multihoming, since the
152	      ingress NVE brings operationally down the Attachment Circuits
153	      (ACs) for which it is non-Designated Forwarder (hence local
154	      replication to non-Designated Forwarder ACs cannot be done).  This
155	      means transient in-flight BUM packets may be looped back to the
156	      originating site by new elected Designated Forwarder egress NVEs.

>From readability perspective, the following can be used to improve the text:

"
Since IP tunnels, such as VXLAN or NVGRE, do not support the ESI label or any MPLS label, an alternative Split Horizon filtering procedure must be implemented for All-Active multihoming. This mechanism, known as Local Bias, relies on the source IP address of the tunnel to determine whether to forward Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a local Ethernet Segment (ES) interface at the egress Network Virtualization Edge (NVE).

In summary, each NVE monitors the IP address(es) of other NVEs with which it shares multihomed ESs. Upon receiving a BUM frame encapsulated in an IP tunnel, the egress NVE inspects the source IP address in the tunnel header, which identifies the ingress NVE. The egress NVE then filters out the frame on all local interfaces connected to ESs that are shared with the ingress NVE.

Due to this behavior at the egress NVE, the ingress NVE is required to perform local replication to all directly attached ESs, regardless of the Designated Forwarder election state, for all BUM traffic ingressing from the access Attachment Circuits (ACs). This local replication at the ingress NVE is the basis for the term Local Bias.

Local Bias is not suitable for Single-Active multihoming, as the ingress NVE deactivates the ACs for which it is not the Designated Forwarder. Consequently, local replication to non-Designated Forwarder ACs cannot occur, leading to the potential for transient in-flight BUM packets to be looped back to the originating site by newly elected Designated Forwarder egress NVEs.
"

158	   [RFC8365] states that Local Bias is used only for IP tunnels, and ESI
159	   Label based Split Horizon for IP-based MPLS tunnels.  However, IP-
160	   based MPLS tunnels, such as MPLSoGRE or MPLSoUDP, are also IP tunnels
161	   and can potentially support both procedures, since they can carry ESI
162	   Labels and they also use a tunnel IP header where the source IP
163	   address identifies the ingress NVE.
164
165	   Similarly, some IP tunnels that carry an identifier of the source ES
166	   in the tunnel header, may potentially follow either procedure too.
167	   Some examples are GENEVE or SRv6:

>From readability perspective, the following can be used to improve the text:

"
[RFC 8365] specifies that Local Bias is exclusively utilized for IP tunnels, while ESI Label-based Split Horizon is employed for IP-based MPLS tunnels. However, IP-based MPLS tunnels, such as MPLS over GRE (MPLSoGRE) or MPLS over UDP (MPLSoUDP), are also categorized as IP tunnels and have the potential to support both procedures. These tunnels are capable of carrying ESI labels and also utilize a tunnel IP header in which the source IP address identifies the ingress Network Virtualization Edge (NVE).

Similarly, certain IP tunnels that include an identifier for the source Ethernet Segment (ES) in the tunnel header may also potentially support either procedure. Examples of such tunnels include GENEVE and SRv6.
"

174	   *  In an SRv6 tunnel, the source IP address also identifies the
175	      ingress NVE, however, by default, and as described in [RFC9252]
176	      the ingress PE will add information in the SRv6 packet so that the
177	      egress PE can identify the source ES of the BUM packet.  That
178	      information is the ESI filtering argument (Arg.FE2) of the service
179	      Segment Identifier (SID) received on an A-D per ES route from the
180	      egress PE.

It would be good to mention that Arg.FE2 is described in RFC 9252/8986. Reference added to the below revised textblob edit:

>From readability perspective, the following can be used to improve the text:

"
In an SRv6 tunnel, the source IP address identifies the ingress NVE. By default, and as outlined in [RFC 9252], the ingress PE adds specific information to the SRv6 packet to enable the egress PE to identify the source ES of the BUM packet. This information is the ESI filtering argument (Arg.FE2) [RFC9252][RFC8986] of the service Segment Identifier (SID) received on an A-D per ES route from the egress PE.
"

182	   Table 1 shows different tunnel encapsulations and their supported and
183	   default Split Horizon method.  In the case of GENEVE, the default
184	   Split Horizon Type (SHT) depends on whether the Ethernet Option with
185	   Source ID TLV is negotiated.  In the case of SRv6, the default SHT is
186	   listed as ESI label filtering in the Table, since the behavior is
187	   equivalent to that of ESI Label filtering.  In this document, ESI
188	   Label filtering refers to the Split Horizon filtering based on the
189	   existence of a source ES identifier in the tunnel header.

>From readability perspective, the following can be used to improve the text:

"
Table 1 presents various tunnel encapsulations along with their supported and default Split Horizon methods. For GENEVE, the default Split Horizon Type (SHT) is contingent upon the negotiation of the Ethernet Option with the Source ID TLV. In the case of SRv6, the default SHT is specified as ESI Label filtering in the table, as its behavior is analogous to that of ESI Label filtering. In this document, ESI Label filtering refers to the Split Horizon filtering based on the presence of a source Ethernet Segment (ES) identifier in the tunnel header.
"

201	   Any other tunnel encapsulation (different from the encapsulations in
202	   Table 1) that can be classified into any of the four encapsulation
203	   groups above, supports Split Horizon based on the following rules:
204
205	   *  IP-based MPLS tunnels and SRv6 tunnels can support both Split
206	      Horizon filtering methods
207
208	   *  (SR-)MPLS tunnels only support ESI Label based Split Horizon
209	      filtering
210
211	   *  IP tunnels support Local Bias Split Horizon and may support ESI
212	      Label based Split Horizon, if they include a method to identify
213	      the source ESI in the header.

>From readability perspective, the following can be used to improve the text:

"
Any tunnel encapsulation not listed in Table 1 that can be categorized into one of the four encapsulation groups mentioned above will support Split Horizon filtering based on the following rules:

* IP-based MPLS tunnels and SRv6 tunnels are capable of supporting both Split Horizon filtering methods.

* (SR-)MPLS tunnels only support ESI Label-based Split Horizon filtering.

* IP tunnels support Local Bias Split Horizon filtering and may also support ESI Label-based Split Horizon filtering, provided they incorporate a mechanism to identify the source ESI in the header.
"

244	   The ESI Label method works for All-Active and Single-Active, while
245	   Local Bias only works for All-Active.  In addition, the ESI Label
246	   method works across different network domains, whereas Local Bias is
247	   limited to networks with no next hop change between the NVEs attached
248	   to the same ES.  However, some operators prefer the Local Bias
249	   method, since it simplifies the encapsulation, consumes less
250	   resources on the NVEs and the ingress NVE always forwards locally to
251	   other interfaces, reducing the delay to reach multihomed hosts.

253	   This document extends the EVPN multihoming procedures so that an
254	   operator can decide the Split Horizon procedure for a given NVO
255	   tunnel depending on their own specific requirements.  The choice of
256	   Local Bias or ESI Label Split Horizon is now allowed for tunnel
257	   encapsulations that support both methods, and it is advertised along
258	   with the EVPN A-D per ES route.  IP tunnels that do not support both
259	   methods, E.g., VXLAN or NVGRE, will keep following [RFC8365]
260	   procedures

>From readability perspective, the following can be used to improve the text:

"
The ESI Label method is applicable for both All-Active and Single-Active configurations, whereas the Local Bias method is suitable only for All-Active configurations. Moreover, the ESI Label method is effective across different network domains, while Local Bias is constrained to networks where there is no change in the next hop between the NVEs attached to the same ES. Nonetheless, some operators favor the Local Bias method due to its simplification of the encapsulation process, reduced resource consumption on NVEs, and the fact that the ingress NVE always forwards traffic locally to other interfaces, thereby decreasing the delay in reaching multihomed hosts.

This document extends the EVPN multihoming procedures to allow operators to select the preferred Split Horizon method for a given NVO tunnel according to their specific requirements. The choice between Local Bias and ESI Label Split Horizon is now permissible for tunnel encapsulations that support both methods, and this selection is advertised along with the EVPN A-D per ES route. IP tunnels that do not support both methods, such as VXLAN or NVGRE, will continue to adhere to the procedures specified in [RFC 8365].
"

295	   *  EVI and EVI-RT: EVPN Instance and EVI Route Target.  A group of
296	      NVEs attached to the same EVI will share the same EVI-RT.

Why not split out in two entries instead of one entry in the terminology list?

307	   *  MPLSoUDP: Multi-Protocol Label Switching over User Datagram
308	      Protocol, [RFC7510]

Should the terminology not be extended to MPLS-over-UDP in the description?
Same is valid for the next few entries in the list.

343	   EVPN extensions are needed so that NVEs can advertise their
344	   preference for the Split Horizon method to be used in the ES.
345	   Figure 1 shows the ESI Label extended community that is always
346	   advertised along with the EVPN A-D per ES route.  All the NVEs
347	   attached to an ES advertise an A-D per ES route for the ES, including
348	   this extended community that conveys the information for the
349	   multihoming mode (All-active or Single-Active), as well as the ESI
350	   Label to be used (if needed).

It would be helpful to specify where the ESI Label extended community is defined:
section "7.5.  ESI Label Extended Community" of RFC7432. 

>From readability perspective, the following can be used to improve the text:

"Extensions to EVPN are required to enable NVEs to advertise their preferred Split Horizon method for a given ES. Figure 1 illustrates the ESI Label extended community (RFC7432 Section7.5), which is consistently advertised alongside the EVPN A-D per ES route. All NVEs connected to an ES advertise an A-D per ES route for that ES, including the extended community, which communicates information regarding the multihoming mode (either All-Active or Single-Active) and, if necessary, specifies the ESI Label to be utilized."

363	   *  A value of 0 means that the multihomed ES is operating in All-
364	      Active mode.
365
366	   *  A value of 1 means that the multihomed ES is operating in Single-
367	      Active mode.

This is not entirely correct. section7.5 defines indeed the "Single-Active" bit, but  
is is All-Active "redundancy" mode and the Single-Active "redundancy" mode. I suggest to be formally correct and add the word "redundancy".

369	   Section 5 creates a registry for the Flags octet, where the "Single-
370	   Active" bit is the low-order bit of the RED (multihoming redundancy
371	   mode) field

It is not entirely clear that the RED field is new to a reader. We should consider
making this more explicit. Not sure if the remainder of this document provides extra context on the motivation why a new field is defined?. What about the following:

"
Section 5 establishes a registry for the Flags octet, designating the "Single-Active" bit as the low-order bit of the newly defined Redundancy (RED) field for multihoming modes.
"

375	   [RFC8365] does not add any explicit indication about the Split
376	   Horizon method in the A-D per ES route.  In this document, the
377	   [RFC8365] Split Horizon procedure is the default behavior and assumes
378	   that Local Bias is used only for IP tunnels, and ESI Label based
379	   Split Horizon for IP-based MPLS tunnels.  This document defines the
380	   two high-order bits in the Flags octet (bits 6 and 7) as the "Split
381	   Horizon Type" (SHT) field, where:

>From readability perspective, the following can be used to improve the text:

"
[RFC 8365] does not include any explicit indication regarding the Split Horizon method in the A-D per Ethernet Segment (ES) route. In this document, the Split Horizon procedure defined in [RFC 8365] is considered the default behavior, presuming that Local Bias is employed exclusively for IP tunnels, while ESI Label-based Split Horizon is used for IP-based MPLS tunnels. This document specifies that the two high-order bits in the Flags octet (bits 6 and 7) constitute the "Split Horizon Type" (SHT) field, where:
"

391	           0 0  --> Default SHT. Backwards compatible with [RFC8365]

Is it not required to mention that there is backwards compatibility with RFC7432 also?
Theflags field is defined in sectio 7.5 of RFC7432?

421	   *  An SHT value different than 00 expresses the intent to use a
422	      specific Split Horizon method, but does not reflect the actual
423	      operational SHT used by the advertising NVE, unless all the NVEs
424	      attached to the ES advertise the same SHT.

I believe that formal RFC2119 language to explain this is desired. 

439	   As an example, egress NVEs that support IP-based MPLS tunnels, E.g.,
440	   MPLSoGRE or MPLSoUDP, will advertise A-D per ES route(s) for the ES
441	   along with the BGP Encapsulation extended community [RFC9012]
442	   indicating the encapsulation (MPLSoGRE or MPLSoUDP) and MAY use the
443	   SHT = 01 or 10 to indicate the intent to use Local Bias or ESI Label,
444	   respectively.
445
446	   An egress NVE MUST NOT use an SHT value different from 00 when
447	   advertising an A-D per ES route with encapsulation VXLAN, NVGRE, MPLS
448	   or no BGP tunnel encapsulation extended community [RFC9012].  We
449	   assume that, in all these cases, there is no Split Horizon method
450	   choice, and therefore the SHT value MUST be 00.  A received route
451	   with one of the above encapsulation options and SHT value different
452	   from 00 SHOULD be treat-as-withdraw.
453
454	   An egress NVE advertising A-D per ES route(s) for an ES with
455	   encapsulation GENEVE MAY use an SHT value of 01 or 10.  A value of 01
456	   indicates the intent to use Local Bias, irrespective of the presence
457	   of an Ethernet option TLV with a non-zero Source-ID
458	   [I-D.ietf-bess-evpn-geneve].  A value of 10 indicates the intent to
459	   use ESI Label based Split Horizon.  A value of 00 indicates the
460	   default behavior in Table 1, that is, use Local Bias if no ESI-Label
461	   exists in the Ethernet option TLV or no Ethernet option TLV
462	   whatsoever.  Otherwise the ESI Label Split Horizon method is used.
463
464	   The above procedures assume a single encapsulation supported in the
465	   egress NVE.  Section 3 describes additional procedures for NVEs
466	   supporting multiple encapsulations.

How do some of the rules apply to routers not aware or not supporting SHT?

A brief rewording for readability and removing the usage of the word 'we':

"As an example, egress NVEs that support IP-based MPLS tunnels, such as MPLSoGRE or MPLSoUDP, will advertise A-D per ES routes for the ES along with the BGP Encapsulation extended community, as defined in [RFC 9012]. This extended community indicates the encapsulation type (MPLSoGRE or MPLSoUDP) and may use the SHT value of 01 or 10 to signify the intent to use Local Bias or ESI Label, respectively.

An egress NVE MUST NOT use an SHT value other than 00 when advertising an A-D per ES route with encapsulation types such as VXLAN, NVGRE, MPLS, or no BGP tunnel encapsulation extended community, as specified in [RFC 9012]. In all these cases, it is presumed that there is no choice for the Split Horizon method; therefore, the SHT value MUST be set to 00. If a route with any of the mentioned encapsulation options is received and has an SHT value different from 00, it SHOULD be treated as a withdrawal.

An egress NVE advertising A-D per ES route(s) for an ES with GENEVE encapsulation MAY use an SHT value of 01 or 10. A value of 01 indicates the intent to use Local Bias, regardless of the presence of an Ethernet option TLV with a non-zero Source-ID, as described in [I-D.ietf-bess-evpn-geneve]. A value of 10 indicates the intent to use ESI Label-based Split Horizon. A value of 00 indicates the default behavior outlined in Table 1, which is to use Local Bias if no ESI-Label is present in the Ethernet option TLV, or if there is no Ethernet option TLV. Otherwise, the ESI Label Split Horizon method is applied.

These procedures assume a single encapsulation supported in the egress NVE. Section 3 describes additional procedures for NVEs supporting multiple encapsulations."

470	   This document also updates [RFC8365] in the value that is advertised
471	   in the ESI Label field of the ESI Label extended community, as
472	   follows:

474	   *  The A-D per ES route(s) for an ES MAY have an ESI Label value of
475	      zero if the SHT value is 01.  Section 2.2 specifies the cases
476	      where the SHT can be 01.  An ESI Label value of zero avoids the
477	      allocation of Labels in the cases where they are not used (Local
478	      Bias).

480	   *  The A-D per ES route(s) for an ES MAY have an ESI Label value of
481	      zero for VXLAN or NVGRE encapsulations.

A rewording from readability perspective

"
This document also updates [RFC 8365] regarding the value that is advertised in the ESI Label field of the ESI Label extended community, as follows:

* The A-D per ES route(s) for an ES MAY have an ESI Label value of zero if the SHT value is 01. Section 2.2 specifies the scenarios where the SHT can be 01. An ESI Label value of zero eliminates the need to allocate labels in cases where they are not utilized, such as in the Local Bias method.

* The A-D per ES route(s) for an ES MAY have an ESI Label value of zero for VXLAN or NVGRE encapsulations.
"

490	   An NVE has an administrative SHT value for an ES (the one that is
491	   advertised along with the A-D per ES route) and an operational SHT
492	   value (the one that is actually used irrespective of what the NVE
493	   advertised).  The administrative SHT matches the operational SHT if
494	   all the NVEs attached to the ES have the same administrative SHT.
495
496	   This document assumes that an [RFC7432] or [RFC8365] implementation
497	   that does not support this document, ignores the value of all the
498	   Flags in the ESI Label extended community except for the Single-
499	   Active bit.  Based on this assumption, a non-upgraded NVE will ignore
500	   an SHT different from 00.  As soon as an upgraded NVE receives at
501	   least one A-D per ES route for the ES with SHT value of 00, it MUST
502	   revert its operational SHT to the default Split Horizon method, as in
503	   Table 1, and irrespective of its administrative SHT.
504
505	   As an example, consider an NVE attached to ES N that receives two A-D
506	   per ES routes for N from different NVEs, NVE1 and NVE2.  If the route
507	   from NVE1 has SHT = 00 and the one from NVE2 an SHT = 01, the NVE
508	   MUST use the default Split Horizon method in Table 1 as operational
509	   SHT, irrespective of its administrative SHT.
510
511	   All the NVEs attached to an ES with operational SHT value of 10 MUST
512	   advertise a valid non-zero ESI Label.  If the operational SHT value
513	   is 01, the ESI Label MAY be zero.  If the operational SHT value is
514	   00, the ESI Label MAY be zero only if the default encapsulation
515	   supports Local Bias only and the NVEs do not check the presence of a
516	   valid non-zero ESI Label.
517
518	   If an NVE changes its operational SHT value from 01 (Local Bias) to
519	   00 (Default SHT) as a result of a new non-upgraded NVE present in the
520	   ES, and it previously advertised a zero ESI Label, it MUST send an
521	   update with a non-zero valid ESI Label, unless all the non-upgraded
522	   NVEs in the ES support Local Bias only.  As an example, suppose NVE1
523	   and NVE2 use MPLSoUDP as encapsulation, they are attached to the same
524	   Ethernet Segment ES1 and advertise an SHT value of 01 (Local Bias)
525	   and a zero ESI label value.  Suppose NVE3 does not support this
526	   specification and joins ES1, therefore advertises an SHT of 00
527	   (default).  Upon receiving NVE3's A-D per ES route, NVE1 and NVE2
528	   MUST send an update of their A-D per ES route for ES1 with a non-zero
529	   valid ESI label value.  The assumption is that NVE3 supports only the
530	   default ESI label based Split Horizon filtering.

A rewording from readability perspective

"
A NVE maintains an administrative SHT value for an Ethernet Segment (ES), which is advertised alongside the A-D per ES route, and an operational SHT value, which is the one actually used regardless of what the NVE has advertised. The administrative SHT matches the operational SHT if all the NVEs attached to the ES have the same administrative SHT.

This document assumes that an implementation of [RFC 7432] or [RFC 8365] that does not support the specifications in this document will ignore the values of all the Flags in the ESI Label extended community, except for the Single-Active bit. Based on this assumption, a non-upgraded NVE will disregard any SHT value other than 00. If an upgraded NVE receives at least one A-D per ES route for the ES with an SHT value of 00, it MUST revert its operational SHT to the default Split Horizon method, as described in Table 1, irrespective of its administrative SHT.

For instance, consider an NVE attached to ES N that receives two A-D per ES routes for N from different NVEs, NVE1 and NVE2. If the route from NVE1 has an SHT value of 00 and the one from NVE2 has an SHT value of 01, the NVE MUST use the default Split Horizon method specified in Table 1 as its operational SHT, regardless of its administrative SHT.

All NVEs attached to an ES with an operational SHT value of 10 MUST advertise a valid, non-zero ESI Label. If the operational SHT value is 01, the ESI Label MAY be zero. If the operational SHT value is 00, the ESI Label may be zero only if the default encapsulation supports Local Bias exclusively, and the NVEs do not require the presence of a valid, non-zero ESI Label.

If an NVE changes its operational SHT value from 01 (Local Bias) to 00 (Default SHT) due to the presence of a new non-upgraded NVE in the ES, and it previously advertised a zero ESI Label, it MUST send an update with a valid, non-zero ESI Label, unless all the non-upgraded NVEs in the ES support only Local Bias. For example, consider NVE1 and NVE2 using MPLSoUDP as encapsulation, attached to the same Ethernet Segment ES1, and advertising an SHT value of 01 (Local Bias) with a zero ESI Label value. Suppose NVE3, which does not support this specification, joins ES1 and advertises an SHT value of 00 (default). Upon receiving NVE3's A-D per ES route, NVE1 and NVE2 MUST update their A-D per ES routes for ES1 to include a valid, non-zero ESI Label value. The assumption here is that NVE3 only supports the default ESI Label-based Split Horizon filtering.
"

534	   As specified by [RFC8365], an egress NVE that supports multiple data
535	   plane encapsulations (I.e., VXLAN, NVGRE, MPLS, MPLSoUDP, GENEVE)
536	   needs to indicate all the supported encapsulations using BGP
537	   Encapsulation extended communities defined in [RFC9012] with all EVPN
538	   routes.  This section clarifies the multihoming Split Horizon
539	   behavior for NVEs advertising and receiving multiple BGP
540	   Encapsulation extended communities along with the A-D per ES routes.
541	   This section uses a notation of {x,y} to indicate the encapsulations
542	   advertised in BGP Encapsulation extended communities [RFC9012], with
543	   x and y being different encapsulation values.
544
545	   It is important to remember that an NVE MAY advertise multiple A-D
546	   per ES routes for the same ES (and not only one), each route
547	   conveying a number of Route Targets (RT).  We refer to the total
548	   number of Route Targets in a given ES as RT-set for that ES.  Any of
549	   the EVIs represented in the RT-set will have its RT included in one
550	   (and only one) A-D per ES route for the ES.  When multiple A-D per ES
551	   routes are advertised for the same ES, each route MUST have a
552	   different Route Distinguisher.

This section can use a textual readability and grammar update. THe proposed rewrite removes the usage of the word 'we' as it is unclear in formla procedures who exactly is 'we'? What about the following:

"
As specified in [RFC 8365], an NVE that supports multiple data plane encapsulations (e.g., VXLAN, NVGRE, MPLS, MPLSoUDP, GENEVE) must indicate all supported encapsulations using BGP Encapsulation extended communities as defined in [RFC 9012] for all EVPN routes. This section provides clarification on the multihoming Split Horizon behavior for NVEs that advertise and receive multiple BGP Encapsulation extended communities along with the A-D per ES routes. This section uses the notation {x, y} to denote the encapsulations advertised in BGP Encapsulation extended communities, where x and y represent different encapsulation values.

It is important to note that an NVE MAY advertise multiple A-D per ES routes for the same ES, rather than a single route, with each route conveying a set of Route Targets (RT). The total set of Route Targets associated with a given ES is referred to as the RT-set for that ES. Each of the EVIs represented in the RT-set will have its RT included in one, and only one, A-D per ES route for the ES. When multiple A-D per ES routes are advertised for the same ES, each route must have a distinct Route Distinguisher.
"

568	   This document extends this behavior as follows:

570	   a.  An A-D per ES route for ES-x may be advertised with multiple
571	       encapsulations where some support a single Split Horizon method.
572	       In this case, the SHT value MUST be 00.  As an example, {VXLAN,
573	       NVGRE}, {VXLAN, GENEVE} or {MPLS, MPLSoGRE, MPLSoUDP} can be
574	       advertised in an A-D per ES route.  In all those cases SHT MUST
575	       be 00.
576
577	   b.  An A-D per ES route for ES-y may be advertised with multiple
578	       encapsulations where all of them support both Split Horizon
579	       methods.  In this case the SHT value MAY be 01 if the desired
580	       method is Local Bias, or 10 if ESI Label based.  For example,
581	       {MPLSoGRE, MPLSoUDP, GENEVE} (or a subset) may be advertised in
582	       an A-D per ES route with SHT value of 01.  The ESI Label value in
583	       this case MAY be zero.
584
585	   c.  If ES-z with RT-set composed of (RT1, RT2, RT3.. RTn) supports
586	       multiple encapsulations that require a different Split Horizon
587	       method, a different A-D per ES route (or group of routes) per
588	       Split Horizon method MUST be advertised.  For example, consider n
589	       RTs in ES-z and:
590
591	       *  the EVIs corresponding to (RT1..RTi) support VXLAN,
592	       *  the ones for (RTi+1..RTm) (with i<m) support MPLSoUDP with
593	          Local Bias,
594
595	       *  and the ones for (RTm+1..RTn) (with m<n) support GENEVE with
596	          ESI Label based Split Horizon.
597
598	       In this case, three groups of A-D per ES routes MUST be
599	       advertised for ES-z:
600
601	       *  A-D per ES route group 1, including (RT1..RTi), with
602	          encapsulation {VXLAN}, SHT = 00.  The ESI Label MAY be zero.
603
604	       *  A-D per ES route group 2, including (RTi+1..RTm), with
605	          encapsulation {MPLSoUDP}, SHT = 01.  The ESI Label MAY be
606	          zero.
607
608	       *  A-D per ES route group 3, including (RTm+1..RTn), with
609	          encapsulation {GENEVE}, SHT = 10.  The ESI Label MUST have a
610	          valid value, different from zero, and the Ethernet option
611	          [RFC8926] MUST be advertised.
612
613	   As per [RFC8365], it is the responsibility of the operator of a given
614	   EVI to ensure that all of the NVEs in that EVI support a common
615	   encapsulation.  If this condition is violated, it could result in
616	   service disruption or failure.

I did an effort to improve readability of these formal rules and hope i kept the original intent unchanged (i changed some words into uppercase RFC2119 language.. please confirm it was correctly processed):


"
This document extends the described behavior as follows:

a. An A-D per ES route for ES-x may be advertised with multiple encapsulations, some of which support a single Split Horizon method. In this case, the Split Horizon Type (SHT) value MUST be 00. For instance, encapsulations such as {VXLAN, NVGRE}, {VXLAN, GENEVE}, or {MPLS, MPLSoGRE, MPLSoUDP} can be advertised in an A-D per ES route. In all these cases, the SHT value MUST be 00.

b. An A-D per ES route for ES-y may be advertised with multiple encapsulations that all support both Split Horizon methods. In this case, the SHT value MAY be 01 if the preferred method is Local Bias, or 10 if the ESI Label-based method is desired. For example, encapsulations such as {MPLSoGRE, MPLSoUDP, GENEVE} (or a subset) MAY be advertised in an A-D per ES route with an SHT value of 01. The ESI Label value in this case MAY be zero.

c. If ES-z with an RT-set composed of (RT1, RT2, RT3... RTn) supports multiple encapsulations requiring different Split Horizon methods, a distinct A-D per ES route (or group of routes) for each Split Horizon method MUST be advertised. For example, consider an ES-z with n Route Targets (RTs) where:

* The EVIs corresponding to (RT1...RTi) support VXLAN.
* The EVIs for (RTi+1...RTm) (with i < m) support MPLSoUDP with Local Bias.
* The EVIs for (RTm+1...RTn) (with m < n) support GENEVE with ESI Label-based Split Horizon.

In this scenario, three groups of A-D per ES routes MUST be advertised for ES-z:

* A-D per ES route group 1, including (RT1...RTi), with encapsulation {VXLAN}, and an SHT value of 00. The ESI Label MAY be zero.
* A-D per ES route group 2, including (RTi+1...RTm), with encapsulation {MPLSoUDP}, and an SHT value of 01. The ESI Label MAY be zero.
* A-D per ES route group 3, including (RTm+1...RTn), with encapsulation {GENEVE}, and an SHT value of 10. The ESI Label MUST have a valid, non-zero value, and the Ethernet option as defined in [RFC 8926] MUST be advertised.

As per [RFC 8365], it is the responsibility of the operator of a given EVI to ensure that all NVEs within that EVI support a common encapsulation. Failure to meet this condition may result in service disruption or failure.
"

618	4.  Security Considerations
617
620	   The same security considerations described in [RFC7432] relevant to
621	   multihoming apply to this document.
622
623	   In addition, this document modifies the [RFC8365] procedures for
624	   Split Horizon filtering, providing the operator with a choice between
625	   Local Bias and ESI Label based filtering for the tunnels that support
626	   both methods.  A misconfiguration of the desired SHT to be used may
627	   result in a forwarding behavior that is different from the intended
628	   one.  Other than that, this document describes procedures so that all
629	   the PEs or NVEs attached to the same ES agree on a common SHT method,
630	   therefore an attacker changing the configuration of the SHT should
631	   not cause traffic disruption, only a change in the forwarding
632	   behavior.

The text here reads slightly odd. WHat about following readability rewrite:

"
The security considerations relevant to multihoming described in [RFC 7432] are applicable to this document.

Additionally, this document modifies the procedures for Split Horizon filtering as outlined in [RFC 8365], offering operators a choice between Local Bias and ESI Label-based filtering for tunnels that support both methods. Misconfiguration of the desired Split Horizon Type (SHT) could lead to forwarding behaviors that differ from the intended configuration. Apart from this risk, this document describes procedures to ensure that all Provider Edge (PE) devices or Network Virtualization Edges (NVEs) connected to the same Ethernet Segment (ES) agree on a common SHT method. Consequently, unauthorized changes to the SHT configuration by an attacker should not cause traffic disruption but may result in alterations to forwarding behavior.
"

634	5.  IANA Considerations

In which parent IANA codepoint registration does the new flags registery sit?

What is with bits 2, 3, 4, 5? reserved or unused? Please document somewhere in the document and prescribe what must happen by a sender and received of these fields.

While i could not find a specific formal IETF normative description of unused or reserved bits the difference between "unused bits" and "reserved bits" is often as follows:

* Reserved Bits: These are explicitly set aside for future use. They must be set to a specific value, usually zero, and ignored by receivers. Reserved bits ensure compatibility and extensibility for future updates or enhancements to the protocol.

* Unused Bits: These bits currently have no defined function or purpose. They are not used in the protocol's operation and are typically ignored by both senders and receivers. Unused bits provide flexibility for potential future uses without specific handling requirements in the current specification.

* Summary
Reserved Bits: Explicitly set aside for future use with specific handling instructions.
Unused Bits: Currently unassigned and ignored, providing flexibility for future definition.




636	   This document creates a registry called "EVPN ESI Label Extended
637	   Community Flags" for the 1-octet Flags field in the ESI Label
638	   Extended Community.  New registrations will be made through the "RFC
639	   Required" procedure defined in [RFC8126].  Initial registrations are
640	   made for the "Multihoming redundancy mode" field in bits 0 and 1, as
641	   follows:

643	                   +=====+=============================+
644	                   | RED | Multihoming redundancy mode |
645	                   +=====+=============================+
646	                   | 00  | All-Active mode             |
647	                   +-----+-----------------------------+
648	                   | 01  | Single-Active mode          |
649	                   +-----+-----------------------------+

651	                                  Table 2

Is there a reason the registration procedure is "RFC Required". There are only few (8) bits available and maybe there should be IETF consensus before allocating any of them. RFC Required "The RFC need not be in the IETF stream, but may be in any RFC stream (currently an RFC may be in the IETF, IRTF, IAB, or Independent Submission streams [RFC5742])." If the setting is slightly more strict "IETF Review" then the following applies:

"  With the IETF Review policy, new values are assigned only
   through RFCs in the IETF Stream -- those that have been shepherded
   through the IESG as AD-Sponsored or IETF working group documents
   [RFC2026] [RFC5378], have gone through IETF Last Call, and have been
   approved by the IESG as having IETF consensus."

The motivation for 2 bits where only 1 bit is used is unusual. Is the high-order bit of RED for future use or is is reserved (because some implementation is squatting on it?) or are they unused? There should be guidelines about what value the unuased bit is set and what recipients should/must set the value.

653	   In addition, this document requests the registration of the "Split
654	   Horizon Type" field in bits 6 and 7 of the Flags Octet of the EVPN
655	   ESI Label extended community.  This field is called "Split Horizon
656	   Type" bits and it is defined as follows:

658	                    +=====+===========================+
659	                    | SHT | Split Horizon Type value  |
660	                    +=====+===========================+
661	                    | 00  | Default SHT               |
662	                    +-----+---------------------------+
663	                    | 01  | Local Bias                |
664	                    +-----+---------------------------+
665	                    | 10  | ESI Label based filtering |
666	                    +-----+---------------------------+
667	                    | 11  | Reserved                  |
668	                    +-----+---------------------------+

670	                                  Table 3

Is the setting SHT setting 11 "Reserved" or "Unused"?