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

["Ali Sajassi (sajassi)" <[e-mail]>]


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=[e-mail]>
Date: Friday, June 7, 2024 at 9:08 AM
To: 'BESS' <[e-mail]>
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 -- [e-mail]
To unsubscribe send an email to [e-mail]