[bess] Re: [Shepherding AD review] review of draft-ietf-bess-evpn-mh-pa-10

["Gunter van de Velde (Nokia)" <[e-mail]>]

[as contributor - wearing no hats]

To simplify chapter "4.3 HRW Algorithm" for readers of this draft and procedures would the following proposed revised explanation text help to explain HRW and the changes imposed by draft-ietf-bess-evpn-mh-pa-10. I also expanded the paragraph on "Detailed Definitions". I think i kept the original content while simplifying the understanding while reading the document. Hope it helps and contributes:

HRW Algorithm Basics:
* Highest Random Weight (HRW): This algorithm is used to determine which Provider Edge (PE) device in a redundancy group should be the Designated Forwarder (DF) for an Ethernet Segment (ES).
* Weight Calculation: The algorithm calculates a weight for each PE based on its IP address and the Ethernet Segment Identifier (ESI).
* Selection Process: The PE with the highest weight is selected as the DF. In case of a tie, the PE with the numerically smallest IP address is chosen.

Original HRW Operation (Per RFC 8584):
* Computation: A 32-bit Cyclic Redundancy Check (CRC) is computed over the concatenation of the Ethernet Tag and ESI.
* Granularity: The algorithm originally operates at the granularity of <ES, VLAN>, meaning the DF is selected based on a combination of the Ethernet Segment and VLAN.

Modified HRW Behavior for Port-Active Redundancy:
* Omission of Ethernet Tag: For Port-Active redundancy mode, the Ethernet Tag is omitted from the CRC computation.
* Granularity Change: All references to <V, Es> (VLAN and Ethernet Segment) are replaced by <Es> (Ethernet Segment only). This means the DF election is based solely on the Ethernet Segment, not the VLAN.

Steps of the Modified HRW Algorithm:
1) DF Selection (DF(Es)): The PE with the highest weight (Weight(Es, Si)) is selected as the DF for the Ethernet Segment (Es). In case of a tie, the PE with the numerically smallest IP address is chosen.
2) BDF Selection (BDF(Es)): The Backup Designated Forwarder (BDF) is the PE with the next highest weight after the DF. In case of a tie, the PE with the numerically smallest IP address is chosen.

Detailed Definitions:
* Si is the IP address of PE i
* Es is the ESI
* Weight is a function of V, Si, and Es
* N is the number of Pes in the Redundancy Group 
* 0 <= i < N-1
* j is the running index from 0 to N-1
* i and k are selected values.
* DF(V) denote the DF and BDF(V) denote the BDF for the Ethernet Tag V
* DF(Es): The PE with IP address Si (index i) for which Weight(Es, Si) is the highest.
* BDF(Es): The PE with address Sk for which the computed weight is the next highest after the DF.

Example Scenario:
* Redundancy Group: Suppose you have a redundancy group with 3 PEs.
* Weights: The weights are calculated based on the IP addresses and ESIs.
* DF Election: The PE with the highest weight becomes the DF, ensuring efficient load distribution and redundancy management.

In summary, the HRW algorithm is used to determine which PE should act as the DF for an Ethernet Segment by calculating weights based on IP addresses and ESIs. The modified behavior for Port-Active redundancy omits the Ethernet Tag from these calculations, focusing solely on the Ethernet Segment.


G/

-----Original Message-----
From: Gunter van de Velde (Nokia) <gunter.van_de_velde=[e-mail]> 
Sent: Friday, July 12, 2024 6:29 PM
To: [e-mail]
Cc: 'BESS' <[e-mail]>
Subject: [bess] [Shepherding AD review] review of draft-ietf-bess-evpn-mh-pa-10

# Gunter Van de Velde, RTG AD, comments for draft-ietf-bess-evpn-mh-pa-10

Please find here a shepherding AD review of draft-ietf-bess-evpn-mh-pa-10

I've begun reviewing this document before we consider the IETF Last Call process. Once we address these points we can move forward with the document through the IESG chain.

A big thank you to Ketan Talaulikar for his RTG-DIR review on the -07 version, and Paul Kyzivat for the GENART review on the -09 version.

In my review, I've noted some final observations while going through the document. For better readability, I've suggested some paragraph edits.

You can find my review notes below.

#GENERIC COMMENTS
#================
## The document is not too long and details a useful technology and is provided by implementors code. Thank you for the great work.

## not too many directorate reviews have been performed just yet. for a clean early review sheet, would it be possible for Ketan to update the RTGDIR review as something else as "has issues"? in the archive i found that all open items Ketan identified were resolved https://mailarchive.ietf.org/arch/msg/bess/o_QKeUOBaT7YQCCqhDf2V6qRD1A/.

## In section4. there were few times i lost track of the story flow. It was not trivial trying to process the used nomenclature and associated formal processes. Would it be possible to improve make the procedures documents less dense or maybe focus upon the normative changes that this draft proposes?

## majority of the comments are style changes to aim to improve readability of the flow and paragraphs. I hope the suggestions help the authors to further fine tune the text within the draft

## Once the draft is further updated, I'll process it one more time before processing it in along the IETF document queues 


#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

20	   group of independent nodes.  The purpose of multi-chassis LAG is to
21	   provide a solution to achieve higher network availability while
22	   providing different modes of sharing/balancing of traffic.  RFC7432
23	   defines EVPN-based MC-LAG with Single-active and All-active
24	   multi-homing redundancy modes.  This document expands on existing
25	   redundancy mechanisms supported by EVPN and introduces a new Port-
26	   Active redundancy mode.

[minor]
Proposed idnit re-edit for being more clear and explicit in abstract and document objective. I was not sure what the difference intended was for the sharing vs balancing is. Please give this a look and correct where you find useful

"
The objective of multi-chassis LAG is to enhance network availability while offering various modes for traffic sharing and balancing. RFC7432 defines EVPN-based MC-LAG with Single-active and All-active multi-homing redundancy modes. This document builds on the existing redundancy mechanisms supported by EVPN and introduces a new Port-Active redundancy mode.
"

88	   EVPN [RFC7432] defines the All-Active and Single-Active redundancy
89	   modes.  All-Active redundancy provides per-flow load-balancing for
90	   multi-homing, and Single-active redundancy provides service carving
91	   where only one of the PEs in a redundancy relationship is active per
92	   service.

94	   While these two multi-homing scenarios are most widely utilized in
95	   data center and service provider access networks, there are scenarios
96	   where an active/standby multi-homing at the interface level is useful
97	   and required.  The main consideration for this new mode of
98	   load-balancing is the determinism of traffic forwarding through a
99	   specific interface rather than statistical per-flow load-balancing
100	   across multiple PEs providing multi-homing.  The determinism provided
101	   by active/standby multi-homing at the interface level is also
102	   required for certain QoS features to work.  While using this mode,
103	   customers also expect fast convergence during failure and recovery.

105	   This document defines the Port-Active redundancy mode as a new type
106	   of multi-homing in EVPN and describes how this new mode operates and
107	   is to be supported via EVPN.

[minor] 
proposed readability rewrite to to help the document flow

"
EVPN [RFC7432] defines the All-Active and Single-Active redundancy modes. All-Active redundancy provides per-flow load-balancing for multi-homing, while Single-Active redundancy ensures service carving where only one of the PEs in a redundancy relationship is active per service.

Although these two multi-homing scenarios are widely utilized in data center and service provider access networks, there are cases where active/standby multi-homing at the interface level is beneficial and necessary. The primary consideration for this new mode of load-balancing is the determinism of traffic forwarding through a specific interface, rather than statistical per-flow load-balancing across multiple PEs providing multi-homing. This determinism is essential for certain QoS features to function correctly. Additionally, this mode ensures fast convergence during failure and recovery, which is expected by customers.

This document defines the Port-Active redundancy mode as a new type of multi-homing in EVPN and details how this mode operates and is supported via EVPN.
"

119	   When a CE is multi-homed to a set of PE nodes using the
120	   [IEEE.802.1AX_2014] Link Aggregation Control Protocol (LACP), the PEs
121	   must act as if they were a single LACP speaker for the Ethernet links
122	   to form and operate as a Link Aggregation Group (LAG).  To achieve
123	   this, the PEs connected to the same multi-homed CE must synchronize
124	   LACP configuration and operational data between them.  Interchassis
125	   Communication Protocol (ICCP) [RFC7275] has historically been used to
126	   achieve this.  EVPN in [RFC7432] describes the case where a CE is
127	   multihomed to multiple PE nodes, using a LAG as a means to greatly
128	   simplify the procedure.  The simplification, however, comes with a
129	   few assumptions:

[minor]
What about the following slight re-edit to enhance story flow

"
When a CE device is multi-homed to a set of PE nodes using the [IEEE.802.1AX_2014] Link Aggregation Control Protocol (LACP), the PEs must function as a single LACP entity for the Ethernet links to form and operate as a Link Aggregation Group (LAG). To achieve this, the PEs connected to the same multi-homed CE must synchronize LACP configuration and operational data among them. Historically, the Interchassis Communication Protocol (ICCP) [RFC7275] has been used for this synchronization.

EVPN, as described in [RFC7432], covers the scenario where a CE is multi-homed to multiple PE nodes, using a LAG to simplify the procedure significantly. This simplification, however, comes with certain assumptions:
"

135	   *  identical LACP parameters MUST be configured on peering PEs such
136	      as system id, port priority, and port key.

[minor]
potential readability re-edit keeping original intent

"
Identical LACP parameters MUST be configured on peering PEs, including system ID, port priority, and port key.
"

138	   This document relies on proper LAG operation as in [RFC7432].
139	   Discrepancies from the list above are out of the scope of this
140	   document, as are LAG misconfiguration and miswiring detection across
141	   peering PEs.

[minor]
What about the following re-edit proposal:

"
This document presumes proper LAG operation as specified in [RFC7432]. Issues such as deviations from the aforementioned assumptions, LAG misconfiguration, and miswiring detection across peering PEs are considered outside the scope of this document.
"

163	   Figure 1 shows a MC-LAG multi-homing topology where PE1 and PE2 are
164	   part of the same redundancy group providing multi-homing to CE1 via
165	   interfaces I1 and I2.  Interfaces I1 and I2 are members of a LAG
166	   running LACP.  The core, shown as IP or MPLS enabled, provides a wide
167	   range of L2 and L3 services.  MC-LAG multi-homing functionality is
168	   decoupled from those services in the core and it focuses on providing
169	   multi-homing to the CE.  In Port-Active redundancy mode, only one of
170	   the two interfaces I1 or I2 would be in forwarding and the other
171	   interface will be in standby.  This also implies that all services on
172	   the active interface are in active mode and all services on the
173	   standby interface operate in standby mode.

[minor]
proposed styling rewrite:

"
Figure 1 illustrates an MC-LAG multi-homing topology where PE1 and PE2 are part of the same redundancy group, providing multi-homing to CE1 via interfaces I1 and I2. Interfaces I1 and I2 are members of a LAG running LACP. The core network, depicted as IP or MPLS enabled, offers a wide range of Layer 2 (L2) and Layer 3 (L3) services. The MC-LAG multi-homing functionality is decoupled from these core services, focusing solely on providing multi-homing to the CE.

In Port-Active redundancy mode, only one of the two interfaces, I1 or I2, MUST be in forwarding mode while the other interface MUST be in standby mode. Consequently, all services on the active interface MUST operate in active mode, and all services on the standby interface MUST operate in standby mode.
"

177	3.1.  Overall Advantages

179	   The use of Port-Active redundancy brings the following benefits to
180	   EVPN networks:
181
182	   a.  Open standards-based active/standby redundancy at the interface
183	       level which eliminates the need to run ICCP and LDP (e.g., they
184	       may be running VXLAN or SRv6 in the network).
185
186	   b.  Agnostic of underlay technology (MPLS, VXLAN, SRv6) and
187	       associated services (L2, L3, Bridging, E-LINE, etc).
188
189	   c.  Provides a way to enable deterministic QoS over MC-LAG attachment
190	       circuits.
191
192	   d.  Fully compliant with [RFC7432], does not require any new protocol
193	       enhancement to existing EVPN RFCs.
194
195	   e.  Can leverage various Designated Forwarder (DF) election
196	       algorithms e.g. modulo, HRW, etc.
197
198	   f.  Replaces legacy MC-LAG ICCP-based solution, and offers the
199	       following additional benefits:
200
201	       *  Efficiently supports 1+N redundancy mode (with EVPN using BGP
202	          RR) whereas ICCP requires a full mesh of LDP sessions among
203	          PEs in the redundancy group.
204
205	       *  Fast convergence with mass-withdraw is possible with EVPN, no
206	          equivalent in ICCP.

[minor]
proposed styling rewrite. Would item 'e' use some references to modulo (rfc7432), HRW and enhanced DF election (rfc8584). 

The claim at point 'f' (***with EVPN using BGP RR***) about using RR setup is not well documented and could use few words on the achieved benefit for people less skilled with BGP RR benefits. 

"
3.1. Overall Advantages
The use of Port-Active redundancy in EVPN networks provides the following benefits:

a. Port-Active redundancy offers open standards-based active/standby redundancy at the interface level, eliminating the need for ICCP and LDP (e.g., VXLAN or SRv6 may be used in the network).

b. This mode is agnostic of the underlying technology (MPLS, VXLAN, SRv6) and associated services (L2, L3, Bridging, E-LINE, etc.).

c. It enables deterministic QoS over MC-LAG attachment circuits.

d. Port-Active redundancy is fully compliant with [RFC7432] and does not require any new protocol enhancements to existing EVPN RFCs.

e. It can leverage various Designated Forwarder (DF) election algorithms, such as modulo, HRW, etc.

f. Port-Active redundancy replaces legacy MC-LAG ICCP-based solutions and offers the following additional benefits:

Efficient support for 1+N redundancy mode (with EVPN using BGP RR), whereas ICCP requires a full mesh of LDP sessions among PEs in the redundancy group.

Fast convergence with mass-withdraw is possible with EVPN, which has no equivalent in ICCP.
"

208	3.2.  Port-Active Redundancy Procedures

210	   The following steps describe the proposed procedure with EVPN LAG to
211	   support Port-Active redundancy mode:
212
213	   a.  The Ethernet-Segment Identifier (ESI) MUST be assigned per access
214	       interface as described in [RFC7432], which may be auto-derived or
215	       manually assigned.  The access interface MAY be a Layer-2 or
216	       Layer-3 interface.  The use of ESI over a Layer-3 interface is
217	       newly described in this document.
218
219	   b.  Ethernet-Segment (ES) MUST be configured in Port-Active
220	       redundancy mode on peering PEs for specific access interface.
221
222	   c.  When ESI is configured on a Layer-3 interface, the Ethernet-
223	       Segment (ES) route (Route Type-4) may be the only route exchanged
224	       by PEs in the redundancy group.
225
226	   d.  PEs in the redundancy group leverage the DF election defined in
227	       [RFC8584] to determine which PE keeps the port in active mode and
228	       which one(s) keep it in standby mode.  While the DF election
229	       defined in [RFC8584] is per [ES, Ethernet Tag] granularity, the
230	       DF election is done per [ES] in Port-Active redundancy mode.  The
231	       details of this algorithm are described in Section 4.
232
233	   e.  DF router MUST keep corresponding access interface in up and
234	       forwarding active state for that Ethernet-Segment
235
236	   f.  Non-DF routers SHOULD implement a bidirectional blocking scheme
237	       for all traffic comparable to [RFC7432] Single-Active blocking
238	       scheme, albeit across all VLANs.
239
240	       *  Non-DF routers MAY bring and keep peering access interface
241	          attached to it in an operational down state.
242
243	       *  If the interface is running LACP protocol, then the non-DF PE
244	          MAY also set the LACP state to OOS (Out of Sync) as opposed to
245	          an interface down state.  This allows for better convergence
246	          on standby to active transition.
247
248	   g.  The primary/backup bits of EVPN Layer 2 Attributes Extended
249	       Community [RFC8214] SHOULD be used to achieve better convergence
250	       as decribed in section Section 5.1.

[minor]
styling rewrite with some comments:

Point 'a': It is unclear why the comment "This document introduces the use of ESI over a Layer-3 interface." is only mentioned here. It seems out of place at this location. Is this what in the abstract is referenced as 'introduces a new Port-Active redundancy mode'

Point 'f': add more explicit section reference to the blocking scheme in rfc7432

"
The following steps outline the proposed procedure for supporting Port-Active redundancy mode with EVPN LAG:

a. The Ethernet-Segment Identifier (ESI) MUST be assigned per access interface as described in [RFC7432]. The ESI can be auto-derived or manually assigned. The access interface MAY be a Layer-2 or Layer-3 interface. This document introduces the use of ESI over a Layer-3 interface.

b. The Ethernet-Segment (ES) MUST be configured in Port-Active redundancy mode on peering PEs for the specified access interface.

c. When ESI is configured on a Layer-3 interface, the Ethernet-Segment (ES) route (Route Type-4) MAY be the only route exchanged by PEs in the redundancy group.

d. PEs in the redundancy group leverage the DF election defined in [RFC8584] to determine which PE keeps the port in active mode and which one(s) keep it in standby mode. Although the DF election defined in [RFC8584] is per [ES, Ethernet Tag] granularity, the DF election is performed per [ES] in Port-Active redundancy mode. The details of this algorithm are described in Section 4.

e. The DF router MUST keep the corresponding access interface in an up and forwarding active state for that Ethernet-Segment.

f. Non-DF routers SHOULD implement a bidirectional blocking scheme for all traffic comparable to the Single-Active blocking scheme described in [RFC7432], albeit across all VLANs.

* Non-DF routers MAY bring and keep the peering access interface attached to them in an operational down state.

* If the interface is running the LACP protocol, the non-DF PE MAY set the LACP state to OOS (Out of Sync) instead of setting the interface to a down state. This approach allows for better convergence during the transition from standby to active mode.

g. The primary/backup bits of the EVPN Layer 2 Attributes Extended Community [RFC8214] SHOULD be used to achieve better convergence, as described in Section 5.1.
"

254	   The ES routes, running in Port-Active redundancy mode, are advertised
255	   with the new Port Mode Load-Balancing capability bit in the DF
256	   Election Extended Community defined in [RFC8584].  Moreover, the ES
257	   associated with the port leverages the existing procedure of Single-
258	   Active, and signals Single-Active Multihomed site redundancy mode
259	   along with Ethernet-AD per-ES route (Section 7.5 of [RFC7432]).
260	   Finally the ESI label-based split-horizon procedures in Section 8.3
261	   of [RFC7432] should be used to avoid transient echo'ed packets when
262	   Layer-2 circuits are involved.

264	   The various algorithms for DF Election are discussed in Sections 4.2
265	   to 4.5 for completeness even though the choice of algorithm in this
266	   solution doesn't affect complexity or performance as in other
267	   redundancy modes.

[minor]
styling rewrite. Modified one 'should' into SHOULD at the end of the below first paragraph.

"
The ES routes operating in Port-Active redundancy mode are advertised with the new Port Mode Load-Balancing capability bit in the DF Election Extended Community as defined in [RFC8584]. Additionally, the ES associated with the port utilizes the existing Single-Active procedure and signals the Single-Active Multihomed site redundancy mode along with the Ethernet-AD per-ES route (refer to Section 7.5 of [RFC7432]). The ESI label-based split-horizon procedures specified in Section 8.3 of [RFC7432] SHOULD be employed to prevent transient echo packets when Layer-2 circuits are involved.

Various algorithms for DF Election are detailed in Sections 4.2 to 4.5 for comprehensive understanding, although the choice of algorithm in this solution does not significantly impact complexity or performance compared to other redundancy modes.
"

292	   Bit 5:    Port Mode Designated Forwarder Election (P bit hereafter),
293	             determines that the DF Election algorithm should be
294	             modified to consider the port ES only and not the Ethernet
295	             Tags.

[minor]
proposed styling rewrite. Is this a 'must' be modified or the suggested 'should' be modified. What if an implementation does not modify and another one does modify, Would that cause issues?


"
Bit 5: Port Mode Designated Forwarder Election (referred to as the P bit hereafter). This bit determines that the DF Election algorithm should be modified to consider the port ES only and not the Ethernet Tags.
"

297	4.2.  Modulo-based Algorithm
298
299	   The default DF Election algorithm, or modulus-based algorithm as in
300	   [RFC7432] and updated by [RFC8584], is used here, at the granularity
301	   of ES only.  Given that ES-Import Route Target extended community may
302	   be auto-derived and directly inherits its auto-derived value from ESI
303	   bytes 1-6, many operators differentiate ESI primarily within these
304	   bytes.  As a result, bytes 3-6 are used to determine the designated
305	   forwarder using Modulo-based DF assignment, achieving good entropy
306	   during Modulo calculation across ESIs:
307	   Assuming a redundancy group of N PE nodes, the PE with ordinal i is
308	   the DF for an <ES> when (Es mod N) = i, where Es represents bytes 3-6
309	   of that ESI.

[minor]
styling rewrite from readability perspective keeping original intent

"
The default DF Election algorithm, or modulo-based algorithm, as described in [RFC7432] and updated by [RFC8584], is applied here at the granularity of ES only. Given that the ES-Import Route Target extended community may be auto-derived and directly inherits its auto-derived value from ESI bytes 1-6, many operators differentiate ESIs primarily within these bytes. Consequently, bytes 3-6 are utilized to determine the designated forwarder using the modulo-based DF assignment, achieving good entropy during modulo calculation across ESIs.

Assuming a redundancy group of N PE nodes, the PE with ordinal i is designated as the DF for an <ES> when (Es mod N) = i, where Es represents bytes 3-6 of that ESI.
"

311	4.3.  HRW Algorithm
312
313	   Highest Random Weight (HRW) algorithm defined in [RFC8584] MAY also
314	   be used and signaled, and modified to operate at the granularity of
315	   <ES> rather than per <ES, VLAN>.
316
317	   Section 3.2 of [RFC8584] describes computing a 32-bit CRC over the
318	   concatenation of Ethernet Tag and ESI.  For Port-Active redundancy
319	   mode, the Ethernet Tag is simply omitted from the CRC computation and
320	   all references to (V, Es) are replaced by (Es), as repeated and
321	   summarised below.
322
323	   DF(Es) denotes the DF and BDF(Es) denote the BDF for the Ethernet
324	   Segment Es; Si is the IP address of PE i; and Weight is a function of
325	   Si, and Es.
326
327	   1.  DF(Es) = Si| Weight(Es, Si) >= Weight(Es, Sj), for all j.  In the
328	       case of a tie, choose the PE whose IP address is numerically the
329	       least.  Note that 0 <= i,j < number of PEs in the redundancy
330	       group.
331
332	   2.  BDF(Es) = Sk| Weight(Es, Si) >= Weight(Es, Sk), and Weight(Es,
333	       Sk) >= Weight(Es, Sj).  In the case of a tie, choose the PE whose
334	       IP address is numerically the least.
335

[major]
In the text i see ES, Es, V, Sk, VLAN, Si etc... it makes it not so easy to digest and understand this text. There should be somewhere an explanation what is exactly intended with all of these. The secret sauce is most likely in the referenced RFCs, but having a quick summary in this document would not hurt if its only a naming convention. Similar items can be observed earlier in the document, where it confused also. 

[minor] 
HRW has been used earlier in the document and was not expended upon. Maybe expand and reference with first usage consquently with the other abbreviations. BDF abbreviation is never explained.

[major]
The formal procedure outlined in this section does not look so trivial, even though it was/is implied. If the focus would be on the difference this draft introduces compared to the previous behaviour, would the story then be simpler? 

proposed styling re-write. It needs some extra TLC to make it easier to process the intent and newly introduced procedure:

"
The Highest Random Weight (HRW) algorithm, as defined in [RFC8584], MAY be utilized and signaled, and is modified to operate at the granularity of <ES> rather than per <ES, VLAN>.

Section 3.2 of [RFC8584] outlines the process of computing a 32-bit CRC over the concatenation of the Ethernet Tag and ESI. For Port-Active redundancy mode, the Ethernet Tag is omitted from the CRC computation, and all references to (V, Es) are replaced by (Es). The modified procedure is summarized below.

In this context, DF(Es) denotes the Designated Forwarder and BDF(Es) denotes the Backup Designated Forwarder for the Ethernet Segment Es. Si is the IP address of PE i, and Weight is a function of Si and Es.

1. DF(Es): The DF is determined by the following rule:

* DF(Es) = Si | Weight(Es, Si) >= Weight(Es, Sj) for all j.
* In the case of a tie, the PE with the numerically smallest IP address is chosen.
* Note: 0 <= i,j < number of PEs in the redundancy group.

2. BDF(Es): The BDF is determined by the following rule:

* BDF(Es) = Sk | Weight(Es, Si) >= Weight(Es, Sk) and Weight(Es, Sk) >= Weight(Es, Sj).
* In the case of a tie, the PE with the numerically smallest IP address is chosen.
"

345	4.4.  Preference-based DF Election

347	   When the new capability 'Port Mode' is signaled, the preference-based
348	   DF Election algirithm in [I-D.ietf-bess-evpn-pref-df] is modified to
349	   consider the port only and not any associated Ethernet Tags.
350	   Furthermore, the Port Mode capability MUST be compatible with the
351	   'Don't Preempt' bit.  When an interface recovers, a peering PE
352	   signaling D bit will enable non-revertive behavior at the port level.

[major]
What does it mean that the capability MUST be compatible? This sounds as an expectation and not a protocol formal process? WHat does in the compatibility embody exacty?

354	4.5.  AC-Influenced DF Election

356	   The AC-DF bit defined in [RFC8584] MUST be set to 0 when advertising
357	   Port Mode Designated Forwarder Election capability (P=1).  When an AC
358	   (sub-interface) goes down, it does not influence the DF Election.
359	   The peer's Ethernet A-D per EVI is ignored in all Port Mode
360	   DF Election algorithms.

362	   Upon receiving the AC-DF bit set (A=1) from a remote PE, it MUST be
363	   ignored when performing Port Mode DF Election.

[major]
Should the text say that "The peer's Ethernet A-D per EVI MUST be ignored in all Port Mode DF Election algorithms." to lign with the next paragraph of the text?

365	5.  Convergence considerations
366
367	   To improve the convergence, upon failure and recovery, when the Port-
368	   Active redundancy mode is used, some advanced synchronization between
369	   peering PEs may be required.  Port-Active is challenging in the sense
370	   that the "standby" port may be in a down state.  It takes some time
371	   to bring a "standby" port to an up state and settle the network.  For
372	   IRB and L3 services, ARP / ND cache may be synchronized.  Moreover,
373	   associated VRF tables may also be synchronized.  For L2 services, MAC
374	   table synchronization may be considered.

376	   Finally, for members of a LAG running LACP the ability to set the
377	   "standby" port in "out-of-sync" state a.k.a "warm-standby" can be
378	   leveraged.

[major]
The section seems to have some formal procedures described while the title indicates considerations. Should this be renamed to "Convergence Considerations and Procedures"?

[minor]
IS there a reference to confirm the below claim "can be utilized to improve convergence times."?

Proposed style rewrite:

"
To enhance convergence during failure and recovery when Port-Active redundancy mode is employed, advanced synchronization between peering PEs may be necessary. The Port-Active mode poses a challenge since the "standby" port may be in a down state. Transitioning a "standby" port to an up state and stabilizing the network requires time. For Integrated Routing and Bridging (IRB) and Layer 3 services, synchronizing ARP / ND caches is recommended. Additionally, associated VRF tables may need to be synchronized. For Layer 2 services, synchronization of MAC tables may be considered.

Moreover, for members of a LAG running LACP, the ability to set the "standby" port to an "out-of-sync" state, also known as "warm-standby," can be utilized to improve convergence times.
"

380	5.1.  Primary / Backup per Ethernet-Segment
381
382	   The EVPN Layer 2 Attributes Extended Community ("L2-Attr") defined in
383	   [RFC8214] SHOULD be advertised in the Ethernet A-D per ES route for
384	   fast convergence.
385
386	   Only the P and B bits of the Control Flags field in the L2-Attr
387	   Extended Community are relevant to this document, and only in the
388	   context of Ethernet A-D per ES routes:
389
390	   *  When advertised, the L2-Attr Extended Community SHALL have only P
391	      or B bits in the Control Flags field set, and all other bits and
392	      fields MUST be zero.
393
394	   *  A remote PE receiving the optional L2-Attr Extended Community in
395	      Ethernet A-D per ES routes SHALL consider only P and B bits and
396	      ignore other values.
397
398	   For L2-Attr Extended Community sent and received in Ethernet A-D
399	   per EVI routes used in [RFC8214], [RFC7432] and
400	   [I-D.ietf-bess-evpn-vpws-fxc]:
401
402	   *  P and B bits received SHOULD be considered overridden by "parent"
403	      bits when advertised in the Ethernet A-D per ES.
404
405	   *  Other fields and bits of the extended community are used according
406	      to the procedures of those documents

[minor]
Proposed styling rewrite

"
The EVPN Layer 2 Attributes Extended Community ("L2-Attr") defined in [RFC8214] SHOULD be advertised in the Ethernet A-D per ES route to enable fast convergence.

Only the P and B bits of the Control Flags field in the L2-Attr Extended Community are relevant to this document, specifically in the context of Ethernet A-D per ES routes:

* When advertised, the L2-Attr Extended Community SHALL have only the P or B bits set in the Control Flags field, and all other bits and fields MUST be zero.

* A remote PE receiving the optional L2-Attr Extended Community in Ethernet A-D per ES routes SHALL consider only the P and B bits and ignore other values.

For L2-Attr Extended Community sent and received in Ethernet A-D per EVI routes used in [RFC8214], [RFC7432], and [I-D.ietf-bess-evpn-vpws-fxc]:

* P and B bits received SHOULD be considered overridden by "parent" bits when advertised in the Ethernet A-D per ES.

* Other fields and bits of the extended community are used according to the procedures outlined in the referenced documents.

By adhering to these procedures, the network ensures proper handling of the L2-Attr Extended Community to maintain robust and efficient convergence across Ethernet segments.
"

408	5.2.  Backward Compatibility
409
410	   Implementations that comply with [RFC7432] or [RFC8214] only (i.e.,
411	   implementations that predate this specification) will not advertise
412	   the EVPN Layer 2 Attributes Extended Community in Ethernet A-D per ES
413	   routes.  That means that all remote PEs in the ES will not receive P
414	   and B bit per ES and will continue to receive and honour the P and B
415	   bits received in Ethernet A-D per EVI route(s).  Similarly, an
416	   implementation that complies with [RFC7432] or [RFC8214] only and
417	   that receives an L2-Attr Extended Community in Ethernet A-D per ES
418	   routes will ignore it and continue to use the default path resolution
419	   algorithm:
420
421	   *  The remote ESI Label Extended Community ([RFC7432]) signals
422	      Single-Active (Section 4)
423
424	   *  the remote MAC and/or Ethernet A-D per EVI routes are unchanged,
425	      and since the L2-Attr Extended Community in Ethernet A-D per ES
426	      route is ignored, the P and B bits in the L2-Attr Extended
427	      Community in Ethernet A-D per EVI routes are used.

[minor]
Proposed styling rewrite

"
A prevalent deployment scenario involves providing L2 or L3 services on PE devices that offer multi-homing capabilities. The services may include any L2 EVPN solutions such as EVPN VPWS or standard EVPN as defined in [RFC7432]. Additionally, L3 services may be provided within a VPN context, as specified in [RFC4364], or within a global routing context. When a PE provides first-hop routing, EVPN IRB may also be deployed on the PEs. The mechanism outlined in this document applies to PEs providing L2 and/or L3 services where active/standby redundancy at the interface level is required.

An alternative solution to the one described in this document is Multi-Chassis Link Aggregation Group (MC-LAG) with ICCP active-standby redundancy, as detailed in [RFC7275]. However, ICCP requires LDP to be enabled as a transport for ICCP messages. There are numerous scenarios where LDP is not necessary, such as deployments utilizing VXLAN or SRv6. The solution described in this document using EVPN does not mandate the use of LDP or ICCP and remains independent of the underlay encapsulation.
"

456	8.  Security Considerations

458	   The same Security Considerations described in [RFC7432] and [RFC8584]
459	   are valid for this document.

461	   By introducing a new capability, a new requirement for unanimity (or
462	   lack thereof) between PEs is added.  Without consensus on the new
463	   DF Election procedures and Port Mode, the DF Election algorithm falls
464	   back to the default DF Election as provided in [RFC8584] and
465	   [RFC7432].  This behavior could be exploited by an attacker that
466	   manages to modify the configuration of one PE in the ES so that the
467	   DF Election algorithm and capabilities in all the PEs in the ES fall
468	   back to the default DF Election.  If that is the case, the PEs will
469	   be exposed to the same unfair load balancing, service disruption, and
470	   possibly black-holing or duplicate traffic mentioned in those
471	   documents and their security sections.

[minor]
Styling rewrite

"
The Security Considerations described in [RFC7432] and [RFC8584] are applicable to this document.

Introducing a new capability necessitates unanimity among PEs. Without consensus on the new DF Election procedures and Port Mode, the DF Election algorithm defaults to the procedures outlined in [RFC8584] and [RFC7432]. This fallback behavior could be exploited by an attacker who modifies the configuration of one PE within the Ethernet Segment (ES). Such manipulation could force all PEs in the ES to revert to the default DF Election algorithm and capabilities. In this scenario, the PEs may be subject to unfair load balancing, service disruption, and potential issues such as black-holing or duplicate traffic, as mentioned in the security sections of those documents.
"

_______________________________________________
BESS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]