[bess] [Shepherding AD review] Pre-IETF Last-Call review of draft-ietf-bess-evpn-virtual-eth-segment-15

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

Hi Authors,

The review includes several questions and observations that arose during a thorough examination of the document.

Please find my review notes below. Before proceeding further requesting an IETF Last-Call and consequently with the IESG, I would appreciate it if you could consider my observations. These primarily aim to improve grammar and clarify certain formal procedures.

I look forward to receiving your revised document.

# Gunter Van de Velde, RTG AD, comments for draft-ietf-bess-evpn-virtual-eth-segment-15

#GENERIC COMMENTS
#================
##EVPN supports SRv6 as dataplane, however SRv6 or IPv6 is not mentioned once in this document. Maybe it should be explicit mentioned that this document is MPLS focussed and explicit exclude SRv6 from its scope?

##Is the necessary IPR pre-November 2009? (i was looking at dates involved for this document)

If not certain, you can use pre5378Trust200902 clause according: 
https://datatracker.ietf.org/doc/html/rfc7749#appendix-A.2.1.4

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

18	   Etheret VPN (EVPN) and Provider Backbone EVPN (PBB-EVPN) introduce a
19	   family of solutions for Ethernet services over MPLS/IP network with
20	   many advanced features including multi-homing capabilities.  These
21	   solutions introduce Single-Active and All-Active redundancy modes for
22	   an Ethernet Segment (ES), itself defined as a set of physical links
23	   between the multi-homed device/network and a set of PE devices that
24	   they are connected to.  This document extends the Ethernet Segment
25	   concept so that an ES can be associated to a set of Ethernet Virtual
26	   Circuits (EVCs e.g., VLANs) or other objects such as MPLS Label
27	   Switch Paths (LSPs) or Pseudowires (PWs).  Such an ES is referred to
28	   as Virtual Ethernet Segments (vES).  This draft describes the
29	   requirements and the extensions needed to support vES in EVPN and
30	   PBB-EVPN.

[minor]
I saw few typos and odd grammatical constructs. I tried to clean this up with following rewrite proposal:

"Ethernet VPN (EVPN) and Provider Backbone EVPN (PBB-EVPN) introduce a comprehensive suite of solutions for delivering Ethernet services over MPLS/IP networks. These solutions offer advanced features, including multi-homing capabilities. Specifically, they support Single-Active and All-Active redundancy modes for an Ethernet Segment (ES), which is defined as a collection of physical links connecting a multi-homed device or network to a set of Provider Edge (PE) devices.

This document extends the concept of an Ethernet Segment by allowing an ES to be associated with a set of Ethernet Virtual Circuits (EVCs, such as VLANs) or other entities, including MPLS Label Switched Paths (LSPs) or Pseudowires (PWs). This extended concept is referred to as Virtual Ethernet Segments (vES). This draft outlines the requirements and necessary extensions to support vES in both EVPN and PBB-EVPN, in alignment with the foundational principles established in RFC 7432.
"

[major]
What about SRv6 dataplane? should it be explicit mentioned that this is excluded?

114	   An Ethernet Segment, as defined in [RFC7432], represents a set of
115	   Ethernet links connecting customer site to one or more PE.  This
116	   document extends the Ethernet Segment concept so that an ES can be
117	   associated to a set of Ethernet Virtual Circuits (EVCs e.g., VLANs)
118	   or other objects such as MPLS Label Switch Paths (LSPs) or
119	   Pseudowires (PWs).  Such an ES is referred to as Virtual Ethernet
120	   Segments (vES).  This draft describes the requirements and the
121	   extensions needed to support vES in EVPN and PBB-EVPN.

[minor]
A brief proposed readability rewrite of the section
"As defined in [RFC 7432], an Ethernet Segment (ES) represents a collection of Ethernet links that connect a customer site to one or more PE devices. This document extends the concept of an Ethernet Segment by allowing an ES to be associated with a set of Ethernet Virtual Circuits (EVCs, such as VLANs), or other entities including MPLS Label Switched Paths (LSPs) and Pseudowires (PWs). This extended concept is referred to as Virtual Ethernet Segments (vES). This draft delineates the requirements and extensions necessary to support vES in both EVPN and PBB-EVPN.
"

125	   Some Service Providers (SPs) want to extend the concept of the
126	   physical links in an ES to Ethernet Virtual Circuits (EVCs) where
127	   many of such EVCs (e.g., VLANs) can be aggregated on a single
128	   physical External Network-to-Network Interface (ENNI).  An ES that
129	   consists of a set of EVCs instead of physical links is referred to as
130	   a virtual ES (vES).  Figure-1 depicts two PE devices (PE1 and PE2)
131	   each with an ENNI that aggregates several EVCs.  Some of the EVCs on
132	   a given ENNI can be associated with vESes.  For example, the multi-
133	   homed vES in Figure-1 consists of EVC4 on ENNI1 and EVC5 on ENNI2.

[minor]
What about the following:
"Some Service Providers (SPs) seek to extend the concept of physical links in an ES to encompass Ethernet Virtual Circuits (EVCs), wherein multiple EVCs (such as VLANs) can be aggregated onto a single physical External Network-to-Network Interface (ENNI). An ES composed of a set of EVCs rather than physical links is referred to as a virtual ES (vES). Figure 1 illustrates two PE devices (PE1 and PE2), each with an ENNI aggregating several EVCs. Some of these EVCs on a given ENNI can be associated with vESes. For instance, the multi-homed vES depicted in Figure 1 consists of EVC4 on ENNI1 and EVC5 on ENNI2.
"

180	   associated with tens or hundreds of All-Active vESes.  Specific
181	   numbers (hundreds, thousands, etc.) being used through this document
182	   are used to describe the relation of various elements between them at
183	   time of writing.


[minor]
The tone used for the numerical quantities can be made more clear

"The specific figures (hundreds, thousands, etc.) used throughout this document reflect the relative quantities of various elements as understood at the time of writing.
"
220	   In some cases, Service Providers use MPLS Aggregation Networks that
221	   belong to separate administrative entities or third parties to get
222	   access to their own IP/MPLS Core network infrastructure.  This is the
223	   case illustrated in Figure 2.

[minor]
I found that this section does not read very smooth. What about the following writeup?

"In certain scenarios, Service Providers utilize MPLS Aggregation Networks that are managed by separate administrative entities or third-party organizations to gain access to their own IP/MPLS core network infrastructure. This situation is depicted in Figure 2."

225	   In such scenarios, a virtual ES (vES) is defined as a set of
226	   individual PWs if they cannot be aggregated.  If the aggregation of
227	   PWs is possible, the vES can be associated to a group of PWs that
228	   share the same unidirectional LSP pair (by LSP pair we mean the
229	   ingress and egress LSPs between the same endpoints).

[minor]
I am not a fan of using the word 'we' in formal procedural documents. What about the following rewrite:

"In such scenarios, a virtual ES (vES) is defined as a set of individual PWs when aggregation is not feasible. If aggregation is possible, the vES can be associated with a group of PWs that share the same unidirectional LSP pair, where the LSP pair consists of the ingress and egress LSPs between the same endpoints.
"

251	   For MPLS/IP access networks where a vES represents a set of LSP pairs
252	   or a set of PWs, this document extends Single-Active multi-homing
253	   procedures of [RFC7432] and [RFC7623] to vES.  The vES extension to
254	   All-Active multi-homing is outside of the scope of this document for
255	   MPLS/IP access networks.

[minor]
Fixing typos in this section:

"For MPLS/IP access networks where a virtual vES represents a set of LSP pairs or a set of PWs, this document extends the Single-Active multi-homing procedures defined in [RFC 7432] and [RFC 7623] to accommodate vES. The extension of vES to support All-Active multi-homing in MPLS/IP access networks is beyond the scope of this document.
"

257	   This draft defines the concept of a vES and additional extensions
258	   needed to support a vES in [RFC7432] and [RFC7623].  Section 3 lists
259	   the set of requirements for a vES.  Section 4 describes extensions
260	   for a vES that are applicable to EVPN solutions including [RFC7432]
261	   and [RFC7209].  Furthermore, these extensions meet the requirements
262	   described in Section 3.  Section 4 gives solution overview and
263	   Section 5 describes failure handling, recovery, scalability, and fast
264	   convergence of [RFC7432] and [RFC7623] for vESes.

[minor]
fixing typo's

"This draft defines the concept of a vES and outlines the additional extensions necessary to support a vES in accordance with [RFC 7432] and [RFC 7623]. Section 3 enumerates the set of requirements for a vES. Section 4 details the extensions for a vES applicable to EVPN solutions, including those specified in [RFC 7432] and [RFC 7209]. These extensions are designed to meet the requirements outlined in Section 3. Section 4 also provides an overview of the solution, while Section 5 addresses failure handling, recovery, scalability, and fast convergence of [RFC 7432] and [RFC 7623] for vESes.
"

320	3.1.  Single-Homed and Multi-Homed vES
322	   A PE needs to support the following types of vESes:
324	   (R1a) A PE MUST handle single-homed vESes on a single physical port
325	   (e.g., single ENNI)
327	   (R1b) A PE MUST handle a mix of Single-Homed vESes and Single-Active
328	   multi-homed vESes simultaneously on a single physical port (e.g.,
329	   single ENNI).  Single-Active multi-homed vESes will be simply
330	   referred to as Single-Active vESes through the rest of this document.
332	   (R1c) A PE MAY handle All-Active multi-homed vESes on a single
333	   physical port.  All-Active multi-homed vESes will be simply referred
334	   to as All-Active vESes through the rest of this document.
336	   (R1d) A PE MAY handle a mix of All-Active vESes along with other
337	   types of vESes on a single physical port.
339	   (R1e) A Multi-Homed vES (Single-Active or All-Active) can be spread
340	   across two or more ENNIs, on any two or more PEs.

[minor] i believe we should use more strong MUST/MAY support' language here to make the requirement more clear. COnsider the following:

"A PE device MUST support the following types of virtual Ethernet Segments (vES):

(R1a) The PE MUST support single-homed vESes on a single physical port, such as a single ENNI.

(R1b) The PE MUST support a combination of single-homed vESes and Single-Active multi-homed vESes simultaneously on a single physical port, such as a single ENNI. Throughout this document, Single-Active multi-homed vESes will be referred to as Single-Active vESes.

(R1c) The PE MAY support All-Active multi-homed vESes on a single physical port. Throughout this document, All-Active multi-homed vESes will be referred to as All-Active vESes.

(R1d) The PE MAY support a combination of All-Active vESes along with other types of vESes on a single physical port.

(R1e) A Multi-Homed vES, whether Single-Active or All-Active, can span across two or more ENNIs on any two or more PEs.
"

350	   (R3a) A PE that supports vES function, MUST support local switching
351	   among different vESes belonging to the same service instance (or
352	   customer) on a single physical port.  For example, in Figure 1, PE1
353	   must support local switching between CE11 and CE12 (both belonging to
354	   customer A) that are mapped to two Single-homed vESes on ENNI1.  In
355	   case of Single-Active vESes, the local switching is performed among
356	   active EVCs belonging to the same service instance on the same ENNI.

[major]
I am not sure why the word 'customer' is mentioned here. I do understand that multiple vESes i a service instance is often associated with a single customer, but is that an absolute protocol requirement? does the association with customer add value in this paragraph?

Slight rephrasing of the paragraph:
"(R3a) A PE device that supports the vES function MUST support local switching among different vESes associated with the same service instance on a single physical port. For instance, in Figure 1, PE1 must support local switching between CE11 and CE12, which are mapped to two single-homed vESes on ENNI1. In the case of Single-Active vESes, the local switching is performed among active EVCs associated with the same service instance on the same ENNI.
"

358	3.3.  EVC Service Types
360	   A physical port (e.g., ENNI) of a PE can aggregate many EVCs each of
361	   which is associated with a vES.  Furthermore, an EVC may carry one or
362	   more VLANs.  Typically, an EVC carries a single VLAN and thus it is
363	   associated with a single broadcast domain.  However, there is no
364	   restriction preventing an EVC from carrying more than one VLAN.
366	   (R4a) An EVC can be associated with a single broadcast domain - e.g.,
367	   VLAN-based service or VLAN bundle service.
369	   (R4b) An EVC MAY be associated with several broadcast domains - e.g.,
370	   VLAN-aware bundle service.
372	   In the same way, a PE can aggregate many LSPs and PWs.  In the case
373	   of individual PWs per vES, typically a PW is associated with a single
374	   broadcast domain, but there is no restriction preventing the PW from
375	   carrying more than one VLAN if the PW is of type Raw mode.
377	   (R4c) A PW can be associated with a single broadcast domain - e.g.,
378	   VLAN-based service or VLAN bundle service.
380	   (R4d) An PW MAY be associated with several broadcast domains - e.g.,
381	   VLAN-aware bundle service.

[minor]
Slight readability rewrite:

"A physical port, such as an ENNI of a PE device, can aggregate numerous EVCs, each associated with a vES. An EVC may carry one or more VLANs. Typically, an EVC carries a single VLAN and is therefore associated with a single broadcast domain. However, there are no restrictions preventing an EVC from carrying multiple VLANs.

(R4a) An EVC can be associated with a single broadcast domain, such as in a VLAN-based service or a VLAN bundle service.

(R4b) An EVC MAY be associated with several broadcast domains, such as in a VLAN-aware bundle service.

Similarly, a PE can aggregate multiple LSPs and PWs. In the case of individual PWs per vES, typically, a PW is associated with a single broadcast domain, although there are no restrictions preventing a PW from carrying multiple VLANs if the PW is configured in Raw mode.

(R4c) A PW can be associated with a single broadcast domain, such as in a VLAN-based service or a VLAN bundle service.

(R4d) A PW MAY be associated with several broadcast domains, such as in a VLAN-aware bundle service.
"

383	3.4.  Designated Forwarder (DF) Election

385	   Section 8.5 of [RFC7432] describes the default procedure for DF
386	   election in EVPN which is also used in [RFC7623] and [RFC8214].
387	   [RFC8584] describes the additional procedures for DF election in
388	   EVPN.  These DF election procedures is performed at the granularity
389	   of (ESI, Ethernet Tag).  In case of a vES, the same EVPN default
390	   procedure for DF election also applies; however, at the granularity
391	   of (vESI, Ethernet Tag); where vESI is the virtual Ethernet Segment
392	   Identifier and the Ethernet Tag field is represented by and I-SID in
393	   PBB-EVPN and by a VLAN ID (VID) in EVPN.  As in [RFC7432], this
394	   default procedure for DF election at the granularity of (vESI,
395	   Ethernet Tag) is also referred to as "service carving".  With service
396	   carving, it is desirable to evenly partition the DFs for different
397	   vESes among different PEs, thus evenly distributing the traffic among
398	   different PEs.  The following list the requirements apply to DF
399	   election of vESes for (PBB-)EVPN.

[minor]
Fixing typos in this textblob

"Section 8.5 of [RFC 7432] outlines the default procedure for DF election in EVPN, which is also applied in [RFC 7623] and [RFC 8214]. [RFC 8584] elaborates on additional procedures for DF election in EVPN. These DF election procedures are performed at the granularity of (ESI, Ethernet Tag). In the context of a vES, the same EVPN default procedure for DF election is applicable, but at the granularity of (vESI, Ethernet Tag). In this context, the Ethernet Tag is represented by an I-SID in PBB-EVPN and by a VLAN ID (VID) in EVPN.

As described in [RFC 7432], this default procedure for DF election at the granularity of (vESI, Ethernet Tag) is also known as "service carving." The goal of service carving is to evenly distribute the DFs for different vESes among various PEs, thereby ensuring an even distribution of traffic across the PEs. The following requirements are applicable to the DF election of vESes for (PBB-)EVPN:
"

409	3.5.  OAM

411	   To detect the failure of an individual EVC and perform DF election
412	   for its associated vES as the result of this failure, each EVC should
413	   be monitored independently.

415	   (R6a) Each EVC SHOULD be monitored for its health independently.

417	   (R6b) A single EVC failure (among many aggregated on a single
418	   physical port/ENNI) MUST trigger DF election for its associated vES.

[minor]
gramatical rewrite proposal:

"To detect the failure of an individual EVC and subsequently perform DF election for its associated vES as a result of this failure, each EVC should be monitored independently.

(R6a) Each EVC SHOULD be independently monitored for its operational health.

(R6b) A failure in a single EVC, among many aggregated on a single physical port or ENNI, MUST trigger a DF election for its associated vES.
"

469	   For the EVPN solution, everything basically remains the same except
470	   for the handling of physical port failure where many vESes can be
471	   impacted.  Sections 5.1 and 5.3 below describe the handling of
472	   physical port/link failure for EVPN.  In a typical multi-homed
473	   operation, MAC addresses are learned behind a vES and are advertised
474	   with the ESI corresponding to the vES (i.e., vESI).  EVPN aliasing
475	   and mass-withdraw operations are performed with respect to vES
476	   identifier: the Ethernet A-D routes for these operations are
477	   advertised with vESI instead of ESI.

[minor]
textual readability rewrite:
"In the EVPN solution, the overall procedures remain consistent, with the primary difference being the handling of physical port failures that can affect multiple vESes. Sections 5.1 and 5.3 describe the procedures for managing physical port or link failures in the context of EVPN. In a typical multi-homed setup, MAC addresses learned behind a vES are advertised using the ESI associated with the vES, referred to as the vESI. EVPN aliasing and mass-withdraw operations are conducted with respect to the vES identifier. Specifically, the Ethernet Auto-Discovery (A-D) routes for these operations are advertised using the vESI instead of the ESI.
"

575	   The difference between coloring mechanism for EVPN and PBB-EVPN is
576	   that for EVPN, the extended community is advertised with the Ethernet
577	   A-D per ES route whereas for PBB-EVPN, the extended community may be
578	   advertised with the B-MAC route.

[minor]
Is there with PBB-EVPN any other means to advertise the color as with the proposed B-MAC route? if not, then maybe s/may/is/ in the phrase?

580	   The following sections describe Grouping Ethernet A-D per ES and
581	   Grouping B-MAC, will become crucial for port failure handling as seen
582	   in Section 5.3, Section 5.4, and Section 5.5 below.

[minor]
this was reading confusing for me. Was this text intended to say:

"The subsequent sections detailing Grouping of Ethernet Auto-Discovery (A-D) per ES and Grouping of B-MAC addresses will be essential for addressing port failure handling, as discussed in Sections 5.3, 5.4, and 5.5.
"
606	   The ESI label extended community (Section 7.5 of [RFC7432]) is not
607	   relevant to Grouping Ethernet A-D per ES route.  The label value is
608	   not used for encapsulating BUM (Broadcast, Unknown-unicast,
609	   Multicast) packets for any split-horizon function.  The ESI label
610	   extended community SHOULD NOT be added to Grouping Ethernet A-D per
611	   ES route and SHOULD be ignored on receiving PE.

[minor]
Why is SHOULD NOT be used? Would it not be better to say MUST NOT be added and MUST be ignored. The implemenation seems broken if it would be added or if it would be processed

613	   This Grouping Ethernet A-D per ES route is advertised with a list of
614	   Route Targets corresponding to the impacted service instances.  If
615	   the number of attached Route Targets exceeds the limit than can fit
616	   into a single route, then a set of Grouping Ethernet A-D per ES
617	   routes are advertised.

[minor]
This paragraph was reading a odd, and i propose a small rewrite:

"The Grouping Ethernet Auto-Discovery (A-D) per ES route is advertised with a list of Route Targets corresponding to the affected service instances. If the number of associated Route Targets exceeds the capacity of a single route, multiple Grouping Ethernet A-D per ES routes are advertised accordingly.
"

621	   For PBB-EVPN, especially where there are large number of service
622	   instances (i.e., I-SIDs) associated with each EVC the PE MAY color
623	   each vES B-MAC route with an attribute representing their association
624	   to a physical port (e.g.  ENNI).

[minor]
fixing some gramatical issues, hoping that the original intent of the text was kept correct.

"In PBB-EVPN, particularly when there are a large number of service instances (i.e., I-SIDs) associated with each EVC, the PE device MAY assign a color attribute to each vES B-MAC route, indicating their association with a physical port (e.g., an ENNI).
"

648	   [RFC7432], [RFC7623], and [RFC8214] solutions provide protection
649	   against such failures as described in the corresponding references.
650	   In the presence of virtual Ethernet Segments (vESes) in these
651	   solutions, besides the above failure scenarios, individual EVC
652	   failure is an additional scenario to consider.  Handling vES failure
653	   scenarios implies that individual EVCs or PWs need to be monitored
654	   and upon detection of failure or restoration of services, appropriate
655	   DF election and failure recovery mechanisms are executed.

[minor]
gramatical rewrite for readability purpose and fixing grammar

"The solutions outlined in [RFC 7432], [RFC 7623], and [RFC 8214] provide protection against failures as described in these respective references. In the context of these solutions, the presence of vESes introduces an additional failure scenario beyond those already considered, specifically the failure of individual EVCs. Addressing vES failure scenarios necessitates the independent monitoring of EVCs or PWs. Upon detection of failure or service restoration, appropriate DF election and failure recovery mechanisms must be executed.
"

894	   1.  When a vES is configured, the PE SHOULD advertise the Ethernet
895	       Segment route for this vES with a color corresponding to the
896	       physical port.
898	   2.  All receiving PEs (in the redundancy group) SHOULD take note of
899	       this color and create a list of vESes for this color.
901	   3.  Recall, that the PE SHOULD also advertise a Grouping Ethernet A-D
902	       per ES (for EVPN) and a Grouping B-MAC (for PBB-EVPN)
903	       representing this color and vES grouping.
905	   4.  Upon a port failure (e.g., ENNI failure), the PE SHOULD withdraw
906	       this previously advertised Grouping Ethernet A-D per ES or
907	       Grouping B-MAC associated with the failed port.  The PE SHOULD
908	       prioritize sending these Grouping routes withdraw message over
909	       individual vES route withdrawal messages of impacted vESes.  For
910	       example, in Figure 5, when the physical port associated with
911	       ENNI3 fails on PE2, it withdraws the previously advertised
912	       Grouping Ethernet A-D per ES route.  When other multi-homing
913	       PEs(i.e., PE1 and PE3) receives this withdrawal message, they
914	       know that the vESes associated with CE1 and CE3 are impacted
915	       (because of the associated color), and thus to initiate DF
916	       election procedure for these vESes.  Furthermore, the remote PEs
917	       (i.e., PE4) upon receiving this withdrawal message, it intiates
918	       failover procedure for vESes associated with CE1, CE3, and
919	       switches over to the other PE for each vES redundancy group.

[minor]
grammatical rewrite for readability and fixing grammar. I hope i kept the original text intent:

"1) When a vES is configured, the PE SHOULD advertise the Ethernet Segment route for this vES with a color that corresponds to the associated physical port.

2) All receiving PEs within the redundancy group SHOULD record this color and compile a list of vESes associated with it.

3) Additionally, the PE SHOULD advertise a Grouping Ethernet A-D per ES for EVPN, and a Grouping B-MAC for PBB-EVPN, which corresponds to the color and vES grouping.

4) In the event of a port failure, such as an ENNI failure, the PE SHOULD withdraw the previously advertised Grouping Ethernet A-D per ES or Grouping B-MAC associated with the failed port. The PE SHOULD prioritize sending these Grouping route withdrawal messages over the withdrawal of individual vES routes affected by the failure. For instance, as depicted in Figure 5, when the physical port associated with ENNI3 fails on PE2, it withdraws the previously advertised Grouping Ethernet A-D per ES route. Upon receiving this withdrawal message, other multi-homing PEs (such as PE1 and PE3) recognize that the vESes associated with CE1 and CE3 are impacted, based on the associated color, and thus initiate the DF election procedure for these vESes. Furthermore, remote PEs (such as PE4), upon receiving this withdrawal message, initiate the failover procedure for the vESes associated with CE1 and CE3, and switch to the other PE for each vES redundancy group.
"