Hi Ali, Thanks for the update When none of the formal procedures changed and only clarifications have been made, then WGLC is not required.
I started the request for a IETF LC for this draft. It will provide an opportunity to review the latest version of the document. Brgds, G/ From: Ali Sajassi (sajassi) <sajassi=40cisco....@dmarc.ietf.org> Sent: Sunday, November 3, 2024 8:40 PM To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; 'BESS' <bess@ietf.org> Subject: Re: [Shepherding AD review] Pre-IETF Last-Call review of draft-ietf-bess-evpn-virtual-eth-segment-15 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Gunter, Thanks very much for your review and combing through the document and providing helpful comments specially for both clarification and improving readability. I have incorporated all of your comments (please refer to my resolutions below for details). I have also checked in the latest version(Rev 16). Considering that vast majority of the changes (if not all the changes) since the last WGLC have been for clarification purposes and improving the readability of the document, I am wondering if we need another WGLC? The document passed WGLC and sent to the IESG for “Publication Requested” on 2021/9/27. Regards, Ali From: Gunter van de Velde (Nokia) <gunter.van_de_velde=40nokia....@dmarc.ietf.org<mailto:gunter.van_de_velde=40nokia....@dmarc.ietf.org>> Date: Friday, June 7, 2024 at 9:08 AM To: 'BESS' <bess@ietf.org<mailto:bess@ietf.org>> Subject: [bess] [Shepherding AD review] Pre-IETF Last-Call review of draft-ietf-bess-evpn-virtual-eth-segment-15 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? Ali> Done! Added couple of sentences to explicitly indicate what is included and what is excluded. ##Is the necessary IPR pre-November 2009? (i was looking at dates involved for this document) Ali> No, the individual rev00 of this document was written in 2014. 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. " Ali> Done except the very last phrase because it needs elaboration which is covered in introduction section. [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. " Ali> Done 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. " Ali> Done 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. " Ali> Done 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." Ali> Done 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. " Ali> Done 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. " Ali> Done 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. " Ali> Done 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. " Ali> Done 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? Ali> Agreed, it is better to remove it. 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. " Ali> Done 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. " Ali> Done 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: " Ali> Done 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. " Ali> Done 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. " Ali> Done 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? Ali> Thanks for catching this. I made the substitute. 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. Ali> Done. Thanks for the enhanced text! " 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 Ali> Done. 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. " Ali> Done. 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). " Ali> Done. 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. " Ali> Done. 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. " Ali> Done. _______________________________________________ BESS mailing list -- bess@ietf.org<mailto:bess@ietf.org> To unsubscribe send an email to bess-le...@ietf.org<mailto:bess-le...@ietf.org>
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
