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

["Luc Andre Burdet (lburdet)" <[e-mail]>]

FYI if HRW is unclear perhaps the following draft is the right place to clarify :
https://datatracker.ietf.org/doc/html/draft-ietf-bess-weighted-hrw-00

Regards,
Luc André

Luc André Burdet  |  [e-mail]<mailto:[e-mail]>  |  Tel: [phone]


From: Luc Andre Burdet (lburdet) <[e-mail]>
Date: Wednesday, October 16, 2024 at 11:27
To: Wen, Bin <[e-mail]>, Gunter van de Velde (Nokia) <[e-mail]>, Gunter van de Velde (Nokia) <gunter.van_de_velde=[e-mail]>, [e-mail] <[e-mail]>
Cc: 'BESS' <[e-mail]>
Subject: Re: [Shepherding AD review] review of draft-ietf-bess-evpn-mh-pa-10
Gunter, Wen,

The point of the HRW section in the Port-Active draft is not to clarify HRW.  If there is confusion or perceived complexity, this needs to be done as an update, errata, or other clarifying change to RFC8485.
Port-active assumes familiarity with RFC8485 – all the port-active draft does is state: Run the *same* algorithm as RFC8584 substituting (V, Es) with (Es).

I will post a -11 version of Port-Active based on the feedbacks below and others received but I don’t see a need to expand too much on HRW – especially not more than RFC8485 does itself: does that mean P-A updates RFC8485? What if the description introduces an error or ambiguity while trying to help?
If RFC8485 is unclear, BESS needs to be informed that is unclear and act upon that feedback as a WG.

Regards,
Luc André

Luc André Burdet  |  [e-mail]<mailto:[e-mail]>  |  Tel: [phone]


From: Wen, Bin <[e-mail]>
Date: Monday, July 15, 2024 at 10:44
To: Gunter van de Velde (Nokia) <[e-mail]>, Gunter van de Velde (Nokia) <gunter.van_de_velde=[e-mail]>, [e-mail] <[e-mail]>
Cc: 'BESS' <[e-mail]>
Subject: Re: [Shepherding AD review] review of draft-ietf-bess-evpn-mh-pa-10
I think we should probably clarify for the BDF selection, j is not equal to i.


On 7/15/24, 3:55 AM, "Gunter van de Velde (Nokia)" <[e-mail] <mailto:[e-mail]>> wrote:


[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] <mailto:[e-mail]>>
Sent: Friday, July 12, 2024 6:29 PM
To: [e-mail] <mailto:[e-mail]>
Cc: 'BESS' <[e-mail] <mailto:[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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/bess/o_QKeUOBaT7YQCCqhDf2V6qRD1A/__;!!CQl3mcHX2A!ENVHg-18R0Sz0MRVHVnBzuV0qw3Tpr7I1MjkfRC3eGrZcBdD2sFfAdT9mjqq1LowM38tBeT10bof2gckJZ0jqwuaZDU$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/o_QKeUOBaT7YQCCqhDf2V6qRD1A/__;!!CQl3mcHX2A!ENVHg-18R0Sz0MRVHVnBzuV0qw3Tpr7I1MjkfRC3eGrZcBdD2sFfAdT9mjqq1LowM38tBeT10bof2gckJZ0jqwuaZDU$> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/bess/o_QKeUOBaT7YQCCqhDf2V6qRD1A/__;!!CQl3mcHX2A!ENVHg-18R0Sz0MRVHVnBzuV0qw3Tpr7I1MjkfRC3eGrZcBdD2sFfAdT9mjqq1LowM38tBeT10bof2gckJZ0jqwuaZDU$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/o_QKeUOBaT7YQCCqhDf2V6qRD1A/__;!!CQl3mcHX2A!ENVHg-18R0Sz0MRVHVnBzuV0qw3Tpr7I1MjkfRC3eGrZcBdD2sFfAdT9mjqq1LowM38tBeT10bof2gckJZ0jqwuaZDU$>> .


## 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] <mailto:[e-mail]>
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>