Re: [bess] Routing Directorate Review for draft-ietf-bess-evpn-vpws-10

["Acee Lindem (acee)" <[e-mail]>]

Hi Sami, 
This version satisfies all my comments.
Thanks,
Acee


On 3/12/17, 2:36 PM, "BESS on behalf of Acee Lindem (acee)"
<[e-mail] on behalf of [e-mail]> wrote:

>Hi Sami, 
>
>I think this version reads much better. I still have a couple comments and
>questions. 
>
>  1. Why is receiving an extended community with both the P and B flags
>set treated as a withdrawal, while it is ignored for the case when both
>the P and B flags are clear?
>  2. A related question is if a route with both the P and B flags clear is
>ignored, won’t this break DF election described on the bottom of page 8?
>It says “the rest of the PEs in the same ES should single both the P and B
>Flags clear.” 
>  3. Also, during DF election, is it implementation specific which backup
>is chosen if multiple PEs advertise the B Flag set in their respective
>extended communities? Why isn’t it the last one similar to the primary PE
>selection? 
>  4. Both VID and VLAN ID are used in the document. I didn’t research this
>but from the context it appears these are synonymous. If VID is used, I’d
>also add it to the “Terminology” in 1.1.
>
>  A few more Nits:
>*** draft-ietf-bess-evpn-vpws-11.txt.orig	2017-03-12 13:56:46.000000000
>-0400
>--- draft-ietf-bess-evpn-vpws-11.txt	2017-03-12 14:34:06.000000000 -0400
>***************
>*** 153,163 ****
>     instance. As with the Ethernet Tag in standard EVPN, the VPWS service
>     instance identifier has uniqueness within an EVPN instance.
>  
>!    For EVPN routes, the Ethernet Tag ID are set to zero for Port-based,
>!    VLAN-based, and VLAN-bundle interface mode and it is set to non-zero
>!    Ethernet tag ID for VLAN-aware bundle mode. Conversely, for EVPN-
>     VPWS, the Ethernet tag ID in the Ethernet A-D route MUST be set to a
>!    non-zero value for all four  service interface types.
>  
>     In terms of route advertisement and MPLS label lookup behavior, EVPN-
>     VPWS resembles the VLAN-aware bundle mode of [RFC7432] such that when
>--- 153,163 ----
>     instance. As with the Ethernet Tag in standard EVPN, the VPWS service
>     instance identifier has uniqueness within an EVPN instance.
>  
>!    For EVPN routes, the Ethernet Tag IDs are set to zero for Port-based,
>!    VLAN-based, and VLAN-bundle interface mode and set to non-zero
>!    Ethernet Tag IDs for VLAN-aware bundle mode. Conversely, for EVPN-
>     VPWS, the Ethernet tag ID in the Ethernet A-D route MUST be set to a
>!    non-zero value for all four service interface types.
>  
>     In terms of route advertisement and MPLS label lookup behavior, EVPN-
>     VPWS resembles the VLAN-aware bundle mode of [RFC7432] such that when
>***************
>*** 181,188 ****
>     Ethernet frames are transported as is and the tags are not altered.
>  
>     The MPLS label value in the Ethernet A-D route can be set to the
>!    VXLAN Network Identifier (VNI) for VxLAN encap, and this VNI may have
>!    a global scope or local scope per PE and may also be made equal to
>     the VPWS service instance identifier set in the Ethernet A-D route.
>  
>     The Ethernet Segment identifier encoded in the Ethernet A-D per-EVI
>--- 181,188 ----
>     Ethernet frames are transported as is and the tags are not altered.
>  
>     The MPLS label value in the Ethernet A-D route can be set to the
>!    VXLAN Network Identifier (VNI) for VXLAN encap, and this VNI may have
>!    a global scope or local scope per PE and may also be equal to
>     the VPWS service instance identifier set in the Ethernet A-D route.
>  
>     The Ethernet Segment identifier encoded in the Ethernet A-D per-EVI
>***************
>*** 312,321 ****
>  
>  2.3 VLAN-Aware Bundle Service Interface
>  
>!    Contrary to EVPN, in EVPN-VPWS this service interface maps to VLAN-
>     based service interface (defined in section 2.1) and thus this
>     service interface is not used in EVPN-VPWS.  In other words, if one
>!    tries to define data-plane and control plane behavior for this
>     service interface, one would realize that it is the same as that of
>     VLAN-based service.
>  
>--- 312,321 ----
>  
>  2.3 VLAN-Aware Bundle Service Interface
>  
>!    Contrary to EVPN, in EVPN-VPWS this service interface maps to a VLAN-
>     based service interface (defined in section 2.1) and thus this
>     service interface is not used in EVPN-VPWS.  In other words, if one
>!    tries to define data plane and control plane behavior for this
>     service interface, one would realize that it is the same as that of
>     VLAN-based service.
>  
>***************
>*** 326,332 ****
>     signal VPWS services. The Ethernet Segment Identifier field is set to
>     the customer ES and the Ethernet Tag ID 32-bit field MUST be set to
>     the VPWS service instance identifier value. The VPWS service instance
>!    identifier value MAY be set to a 24-bit value, when 24-bit value is
>     used, it MUST be right aligned. For both EPL and EVPL services using
>     a given VPWS service instance, the pair of PEs instantiating that
>     VPWS service instance will each advertise a per-EVI Ethernet A-D
>--- 326,332 ----
>     signal VPWS services. The Ethernet Segment Identifier field is set to
>     the customer ES and the Ethernet Tag ID 32-bit field MUST be set to
>     the VPWS service instance identifier value. The VPWS service instance
>!    identifier value MAY be set to a 24-bit value and when a 24-bit value
>is
>     used, it MUST be right aligned. For both EPL and EVPL services using
>     a given VPWS service instance, the pair of PEs instantiating that
>     VPWS service instance will each advertise a per-EVI Ethernet A-D
>***************
>*** 354,361 ****
>  
>  3.1 EVPN Layer 2 attributes extended community
>  
>!    This draft proposes a new extended community [RFC4360], to be
>!    included with the per-EVI Ethernet A-D route. This attribute is
>     mandatory if multihoming is enabled.
>  
>          +------------------------------------+
>--- 354,361 ----
>  
>  3.1 EVPN Layer 2 attributes extended community
>  
>!    This document defines an extended community [RFC4360], to be
>!    included with per-EVI Ethernet A-D routes. This attribute is
>     mandatory if multihoming is enabled.
>  
>          +------------------------------------+
>***************
>*** 423,429 ****
>  
>     In a multihoming all-active scenario, there is no DF election, and
>     all the PEs in the ES that are active and ready to forward traffic
>!    to/from the CE will set the P Flag. A remote PE will do per-flow load
>     balancing to the PEs that set the P Flag for the same Ethernet Tag
>     and ESI. The B Flag in control flags SHOULD NOT be set in the
>     multihoming all-active scenario and MUST be ignored by receiving
>--- 423,429 ----
>  
>     In a multihoming all-active scenario, there is no DF election, and
>     all the PEs in the ES that are active and ready to forward traffic
>!    to/from the CE will set the P Flag. A remote PE will do per-flow
>load-
>     balancing to the PEs that set the P Flag for the same Ethernet Tag
>     and ESI. The B Flag in control flags SHOULD NOT be set in the
>     multihoming all-active scenario and MUST be ignored by receiving
>***************
>*** 493,499 ****
>  
>     All PEs and ASBRs are enabled for the EVPN SAFI and exchange per-EVI
>     Ethernet A-D routes, one route per VPWS service instance.  For inter-
>!    AS option B, the ASBRs re-advertise these routes with NEXT_HOP
>     attribute set to their IP addresses as per [RFC4271]. The link
>     between the CE and the PE is either a C-tagged or S-tagged interface,
>     as described in [802.1Q], that can carry a single VLAN tag or two
>--- 493,499 ----
>  
>     All PEs and ASBRs are enabled for the EVPN SAFI and exchange per-EVI
>     Ethernet A-D routes, one route per VPWS service instance.  For inter-
>!    AS option B, the ASBRs re-advertise these routes with the NEXT_HOP
>     attribute set to their IP addresses as per [RFC4271]. The link
>     between the CE and the PE is either a C-tagged or S-tagged interface,
>     as described in [802.1Q], that can carry a single VLAN tag or two
>***************
>*** 570,576 ****
>     Finally, EVPN may employ data plane egress link protection mechanisms
>     not available in VPWS. This can be done by the primary PE (on local
>     AC down) using the label advertised in the per-EVI Ethernet A-D route
>!    by the backup PE to encapsulate the traffic and direct it to backup
>     PE.
>  
>  6 Failure Scenarios
>--- 570,576 ----
>     Finally, EVPN may employ data plane egress link protection mechanisms
>     not available in VPWS. This can be done by the primary PE (on local
>     AC down) using the label advertised in the per-EVI Ethernet A-D route
>!    by the backup PE to encapsulate the traffic and direct it to the
>backup
>     PE.
>  
>  6 Failure Scenarios
>***************
>*** 592,600 ****
>     For a faster convergence in multi-homed scenarios with either Single-
>     Active Redundancy or All-active redundancy, a mass withdraw technique
>     is used. A PE previously advertising a per-ES Ethernet A-D route, can
>!    withdraw this route signaling to the remote PEs to switch all the
>     VPWS service instances associated with this multi-homed ES to the
>!    backup PE
>  
>  7 Acknowledgements
>  
>--- 592,600 ----
>     For a faster convergence in multi-homed scenarios with either Single-
>     Active Redundancy or All-active redundancy, a mass withdraw technique
>     is used. A PE previously advertising a per-ES Ethernet A-D route, can
>!    withdraw this route by signaling to the remote PEs to switch all the
>     VPWS service instances associated with this multi-homed ES to the
>!    backup PE.
>  
>  7 Acknowledgements
>
>
>  
>
>Thanks,
>Acee
>
>
>
>
>On 3/9/17, 9:50 PM, "Sami Boutros" <[e-mail]> wrote:
>
>>Hi Acee,
>>
>>Please find attached the -11 version, I addressed most of your edits
>>below.
>>
>>Thanks,
>>
>>Sami
>>
>>
>>
>>On 3/3/17, 8:30 AM, "Acee Lindem (acee)" <[e-mail]> wrote:
>>
>>>Hello,
>>>
>>>
>>>
>>>I have been selected as the Routing Directorate reviewer for this draft.
>>>
>>>The Routing Directorate seeks to review all routing or routing-related
>>>
>>>drafts as they pass through IETF last call and IESG review, and
>>>sometimes
>>>
>>>on special request. The purpose of the review is to provide assistance
>>>to
>>>
>>>the Routing ADs. For more information about the Routing Directorate,
>>>
>>>please see 
>>>​https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org
>>>_
>>>area_rtg_trac_wiki_RtgDir&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdp
>>>t
>>>a08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=RtGVdqFdzyGNI_Ni98jxVOpGqfSYH56HwthHx
>>>0
>>>XO0pM&s=FAOrj337iGZ6aDIJ5PY-gGX_qKD3IMgp7EkT94Kuiew&e=
>>>
>>>
>>>
>>>Although these comments are primarily for the use of the Routing ADs, it
>>>
>>>would be helpful if you could consider them along with any other IETF
>>>Last
>>>
>>>Call comments that you receive, and strive to resolve them through
>>>
>>>discussion or by updating the draft.
>>>
>>>
>>>
>>>Document: draft-ietf-bess-evpn-vpws-10.txt
>>>
>>>
>>>
>>>Reviewer: Acee Lindem
>>>
>>>Review Date: 3/3/2017
>>>
>>>IETF LC End Date: 3/10/2017
>>>
>>>Intended Status: Standards Track
>>>
>>>
>>>
>>>Summary:
>>>
>>>
>>>
>>>    I have some minor concerns about this document that I think should
>>>be
>>>
>>>resolved before publication.
>>>
>>>
>>>
>>>Comments:
>>>
>>>
>>>
>>>    The document is technically correct and comprehensive as evidenced
>>>by
>>>
>>>successful implementation by multiple vendors. However, the document
>>>could
>>>
>>>be much more readable with fewer run-on sentenses and some editorial
>>>
>>>corrections. Editorial corrections are suggested in the nits.
>>>
>>>
>>>
>>>Major Issues:
>>>
>>>
>>>
>>>    No major issues were found.
>>>
>>>
>>>
>>>Minor Issues:
>>>
>>>
>>>
>>>    1. There are many compound sentences that don't need to be.
>>>
>>>       Please consider rewording these for readability. I have
>>>
>>>       made suggestions in below. Hopefully, you’ll agree with most
>>>
>>>       of these.
>>>
>>>    2. Consistent capitalization of acronyms, e.g., VLAN, P2P, and
>>>
>>>       VXLAN.
>>>
>>>    3. Consistent hyphenization, e.g., "cross-connect". Use "Per-ES" and
>>>
>>>       "Per-EVI" when describing AD routes.
>>>
>>>    4. On page 6, why is the P and B clear error treated differently
>>>
>>>       from the  P and set error?
>>>
>>>    5. On Page 9, why isn't the last received B Flag set used as the
>>>
>>>       Backup PE similar to the behavior for the Primary PE?
>>>
>>>    6. On Page 9, it is truly unfortunate that the Inter-AS options
>>>
>>>       for EVPN weren't explicitly discussed in RFC 7432.
>>>
>>>
>>>
>>>Nits:
>>>
>>>
>>>
>>>Here are some suggested edits to improve the consistency and
>>>
>>>readability of the document.
>>>
>>>
>>>
>>>*** draft-ietf-bess-evpn-vpws-10.txt.orig       2017-03-02
>>>
>>>20:41:20.000000000 -0500
>>>
>>>--- draft-ietf-bess-evpn-vpws-10.txt            2017-03-03
>>>
>>>11:20:32.000000000 -0500
>>>
>>>***************
>>>
>>>*** 118,167 ****
>>>
>>>  
>>>
>>>     This document describes how EVPN can be used to support Virtual
>>>
>>>     Private Wire Service (VPWS) in MPLS/IP networks. The use of EVPN
>>>
>>>!    mechanisms for VPWS (EVPN-VPWS) brings the benefits of EVPN to p2p
>>>
>>>     services. These benefits include single-active redundancy as well
>>>as
>>>
>>>     all-active redundancy with flow-based load-balancing. Furthermore,
>>>
>>>!    the use of EVPN for VPWS eliminates the need for traditional way of
>>>
>>>!    PW signaling for p2p Ethernet services, as described in section 4.
>>>
>>>  
>>>
>>>!    [RFC7432] has the ability to forward customer traffic to/from a
>>>given
>>>
>>>     customer Attachment Circuit (AC), without any MAC lookup. This
>>>
>>>!    capability is ideal in providing p2p services (aka VPWS services).
>>>
>>>!    [MEF] defines Ethernet Virtual Private Line (EVPL) service as p2p
>>>
>>>!    service between a pair of ACs (designated by VLANs) and Ethernet
>>>
>>>     Private Line (EPL) service, in which all traffic flows are between
>>>a
>>>
>>>     single pair of ports, that in EVPN terminology would mean a single
>>>
>>>     pair of Ethernet Segments ES(es). EVPL can be considered as a VPWS
>>>
>>>     with only two ACs. In delivering an EVPL service, the traffic
>>>
>>>!    forwarding capability of EVPN based on the exchange of a pair of
>>>
>>>!    Ethernet Auto-discovery (A-D) routes is used; whereas, for more
>>>
>>>     general VPWS as per [RFC4664], traffic forwarding capability of
>>>EVPN
>>>
>>>!    based on the exchange of a group of Ethernet AD routes (one
>>>Ethernet
>>>
>>>!    AD route per AC/ES) is used. In a VPWS service,  the traffic from
>>>an
>>>
>>>     originating Ethernet Segment can be forwarded only to a single
>>>
>>>     destination Ethernet Segment; hence, no MAC lookup is needed and
>>>the
>>>
>>>     MPLS label associated with the per EVPN instance (EVI) Ethernet A-D
>>>
>>>     route can be used in forwarding user traffic to the destination AC.
>>>
>>>  
>>>
>>>     For both EPL and EVPL services, a specific VPWS service instance is
>>>
>>>!    identified by a pair of per EVI Ethernet A-D routes which together
>>>
>>>     identify the VPWS service instance endpoints and the VPWS service
>>>
>>>     instance. In the control plane the VPWS service instance is
>>>
>>>     identified using the VPWS service instance identifiers advertised
>>>by
>>>
>>>!    each PE and in the data plane the value of the MPLS label
>>>advertised
>>>
>>>     by one PE is used by the other PE to send traffic for that VPWS
>>>
>>>     service instance. As with the Ethernet Tag in standard EVPN, the
>>>VPWS
>>>
>>>     service instance identifier has uniqueness within an EVPN instance.
>>>
>>>  
>>>
>>>!    Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero
>>>for
>>>
>>>!    Port-based, vlan-based, and vlan-bundle interface mode and it is
>>>set
>>>
>>>!    to non-zero Ethernet tag ID for vlan-aware bundle mode, in
>>>EVPN-VPWS,
>>>
>>>!    for all the four interface modes, Ethernet tag ID in the Ethernet
>>>A-D
>>>
>>>!    route MUST be set to a non-zero value in all the service interface
>>>
>>>     types.
>>>
>>>  
>>>
>>>     In terms of route advertisement and MPLS label lookup behavior,
>>>EVPN-
>>>
>>>!    VPWS resembles the vlan-aware bundle mode of [RFC7432] such that
>>>when
>>>
>>>   
>>>
>>>  
>>>
>>>  
>>>
>>>--- 118,167 ----
>>>
>>>  
>>>
>>>     This document describes how EVPN can be used to support Virtual
>>>
>>>     Private Wire Service (VPWS) in MPLS/IP networks. The use of EVPN
>>>
>>>!    mechanisms for VPWS (EVPN-VPWS) brings the benefits of EVPN to P2P
>>>
>>>     services. These benefits include single-active redundancy as well
>>>as
>>>
>>>     all-active redundancy with flow-based load-balancing. Furthermore,
>>>
>>>!    the use of EVPN for VPWS eliminates the need for the traditional
>>>way
>>>
>>>of
>>>
>>>!    PW signaling for P2P Ethernet services, as described in section 4.
>>>
>>>  
>>>
>>>!    [RFC7432] provides the ability to forward customer traffic to/from
>>>a
>>>
>>>given
>>>
>>>     customer Attachment Circuit (AC), without any MAC lookup. This
>>>
>>>!    capability is ideal in providing P2P services (aka, VPWS services).
>>>
>>>!    [MEF] defines Ethernet Virtual Private Line (EVPL) service as a P2P
>>>
>>>!    service between a pair of ACs (designated by VLANs) as an Ethernet
>>>
>>>     Private Line (EPL) service, in which all traffic flows are between
>>>a
>>>
>>>     single pair of ports, that in EVPN terminology would mean a single
>>>
>>>     pair of Ethernet Segments ES(es). EVPL can be considered as a VPWS
>>>
>>>     with only two ACs. In delivering an EVPL service, the traffic
>>>
>>>!    forwarding capability of EVPN is based on the exchange of a pair of
>>>
>>>!    Ethernet Auto-discovery (A-D) routes; whereas, for more
>>>
>>>     general VPWS as per [RFC4664], traffic forwarding capability of
>>>EVPN
>>>
>>>!    is based on the exchange of a group of Ethernet AD routes (one
>>>
>>>Ethernet
>>>
>>>!    AD route per AC/ES). In a VPWS service,  the traffic from an
>>>
>>>     originating Ethernet Segment can be forwarded only to a single
>>>
>>>     destination Ethernet Segment; hence, no MAC lookup is needed and
>>>the
>>>
>>>     MPLS label associated with the per EVPN instance (EVI) Ethernet A-D
>>>
>>>     route can be used in forwarding user traffic to the destination AC.
>>>
>>>  
>>>
>>>     For both EPL and EVPL services, a specific VPWS service instance is
>>>
>>>!    identified by a pair of per-EVI Ethernet A-D routes which together
>>>
>>>     identify the VPWS service instance endpoints and the VPWS service
>>>
>>>     instance. In the control plane the VPWS service instance is
>>>
>>>     identified using the VPWS service instance identifiers advertised
>>>by
>>>
>>>!    each PE. In the data plane the value of the MPLS label advertised
>>>
>>>     by one PE is used by the other PE to send traffic for that VPWS
>>>
>>>     service instance. As with the Ethernet Tag in standard EVPN, the
>>>VPWS
>>>
>>>     service instance identifier has uniqueness within an EVPN instance.
>>>
>>>  
>>>
>>>!    For EVPN routes, the Ethernet Tag IDs are set to zero for
>>>
>>>!    Port-based, VLAN-based, and VLAN-bundle interface mode and it is
>>>set
>>>
>>>!    to a non-zero Ethernet Tag ID for VLAN-aware bundle mode.
>>>Conversely,
>>>
>>>!    for EVPN-VPWS, the Ethernet Tag ID in the Ethernet A-D
>>>
>>>!    route MUST be set to a non-zero value in all four service interface
>>>
>>>     types.
>>>
>>>  
>>>
>>>     In terms of route advertisement and MPLS label lookup behavior,
>>>EVPN-
>>>
>>>!    VPWS resembles the VLAN-aware bundle mode of [RFC7432] such that
>>>when
>>>
>>>   
>>>
>>>  
>>>
>>>  
>>>
>>>***************
>>>
>>>*** 170,199 ****
>>>
>>>  INTERNET DRAFT            VPWS support in EVPN         February 28,
>>>2017
>>>
>>>  
>>>
>>>  
>>>
>>>!    a PE advertises per EVI Ethernet A-D route, the VPWS service
>>>instance
>>>
>>>!    serves as a 32-bit normalized Ethernet tag ID. The value of the
>>>MPLS
>>>
>>>     label in this route represents both the EVI and the VPWS service
>>>
>>>     instance, so that upon receiving an MPLS encapsulated packet, the
>>>
>>>!    disposition PE can identify the egress AC from the lookup of the
>>>MPLS
>>>
>>>!    label alone and perform any required tag translation. For EVPL
>>>
>>>     service, the Ethernet frames transported over an MPLS/IP network
>>>
>>>!    SHOULD remain tagged with the originating Vlan-ID (VID) and any VID
>>>
>>>     translation MUST be performed at the disposition PE. For EPL
>>>service,
>>>
>>>     the Ethernet frames are transported as is and the tags are not
>>>
>>>     altered.
>>>
>>>  
>>>
>>>     The MPLS label value in the Ethernet A-D route can be set to the
>>>
>>>!    VXLAN Network Identifier (VNI) for VxLAN encap, and this VNI may
>>>have
>>>
>>>     a global scope or local scope per PE and may also be made equal to
>>>
>>>     the VPWS service instance identifier set in the Ethernet A-D route.
>>>
>>>  
>>>
>>>!    The Ethernet Segment identifier encoded in the Ethernet A-D per EVI
>>>
>>>!    route is not used to identify the service, however it can be used
>>>for
>>>
>>>     flow-based load-balancing and mass withdraw functions as per
>>>
>>>!    [RFC7432] baseline.
>>>
>>>  
>>>
>>>!    As with standard EVPN, the Ethernet A-D per ES route is used for
>>>fast
>>>
>>>!    convergence upon link or node failure and the Ethernet Segment
>>>route
>>>
>>>     is used for auto-discovery of the PEs attached to a given
>>>multi-homed
>>>
>>>     CE and to synchronize state between them.
>>>
>>>  
>>>
>>>--- 170,199 ----
>>>
>>>  INTERNET DRAFT            VPWS support in EVPN         February 28,
>>>2017
>>>
>>>  
>>>
>>>  
>>>
>>>!    a PE advertises a per-EVI Ethernet A-D route, the VPWS service
>>>
>>>instance
>>>
>>>!    serves as a 32-bit normalized Ethernet Tag ID. The value of the
>>>MPLS
>>>
>>>     label in this route represents both the EVI and the VPWS service
>>>
>>>     instance, so that upon receiving an MPLS encapsulated packet, the
>>>
>>>!    disposition PE can identify the egress AC from the MPLS
>>>
>>>!    label and subsequently perform any required tag translation. For
>>>EVPL
>>>
>>>     service, the Ethernet frames transported over an MPLS/IP network
>>>
>>>!    SHOULD remain tagged with the originating VLAN-ID (VID) and any VID
>>>
>>>     translation MUST be performed at the disposition PE. For EPL
>>>service,
>>>
>>>     the Ethernet frames are transported as is and the tags are not
>>>
>>>     altered.
>>>
>>>  
>>>
>>>     The MPLS label value in the Ethernet A-D route can be set to the
>>>
>>>!    VXLAN Network Identifier (VNI) for VXLAN encap, and this VNI may
>>>have
>>>
>>>     a global scope or local scope per PE and may also be made equal to
>>>
>>>     the VPWS service instance identifier set in the Ethernet A-D route.
>>>
>>>  
>>>
>>>!    The Ethernet Segment identifier encoded in the Ethernet A-D per-EVI
>>>
>>>!    route is not used to identify the service. However, it can be used
>>>for
>>>
>>>     flow-based load-balancing and mass withdraw functions as per
>>>
>>>!    the [RFC7432] baseline.
>>>
>>>  
>>>
>>>!    As with standard EVPN, the Ethernet A-D per-ES route is used for
>>>fast
>>>
>>>!    convergence upon link or node failure. The Ethernet Segment route
>>>
>>>     is used for auto-discovery of the PEs attached to a given
>>>multi-homed
>>>
>>>     CE and to synchronize state between them.
>>>
>>>  
>>>
>>>***************
>>>
>>>*** 271,279 ****
>>>
>>>     to only a single VLAN on a specific interface.  Therefore, there is
>>>a
>>>
>>>     one-to-one mapping between a VID on this interface and the VPWS
>>>
>>>     service instance identifier. The PE provides the cross-connect
>>>
>>>!    functionality between MPLS LSP identified by the VPWS service
>>>
>>>     instance identifier and a specific <port,VLAN>. If the VLAN is
>>>
>>>!    represented by different VIDs on different PEs and different ES(es)
>>>
>>>   
>>>
>>>  
>>>
>>>  
>>>
>>>--- 271,279 ----
>>>
>>>     to only a single VLAN on a specific interface.  Therefore, there is
>>>a
>>>
>>>     one-to-one mapping between a VID on this interface and the VPWS
>>>
>>>     service instance identifier. The PE provides the cross-connect
>>>
>>>!    functionality between an MPLS LSP identified by the VPWS service
>>>
>>>     instance identifier and a specific <port,VLAN>. If the VLAN is
>>>
>>>!    represented by different VIDs on different PEs and different
>>>ES(es),
>>>
>>>   
>>>
>>>  
>>>
>>>  
>>>
>>>***************
>>>
>>>*** 293,304 ****
>>>
>>>  
>>>
>>>     With this service interface, a VPWS service instance identifier
>>>
>>>     corresponds to multiple VLANs on a specific interface. The PE
>>>
>>>!    provides the cross-connect functionality between MPLS label
>>>
>>>     identified by the VPWS service instance identifier and a group of
>>>
>>>     VLANs on a specific interface. For this service interface, each
>>>VLAN
>>>
>>>     is presented by a single VID which means no VLAN translation is
>>>
>>>     allowed. The receiving PE, can direct the traffic based on EVPN
>>>label
>>>
>>>!    alone to a specific port. The transmitting PE can cross connect
>>>
>>>     traffic from a group of VLANs on a specific port to the MPLS label.
>>>
>>>     The MPLS-encapsulated frames MUST remain tagged with the
>>>originating
>>>
>>>     VID.   
>>>
>>>--- 293,304 ----
>>>
>>>  
>>>
>>>     With this service interface, a VPWS service instance identifier
>>>
>>>     corresponds to multiple VLANs on a specific interface. The PE
>>>
>>>!    provides the cross-connect functionality between the MPLS label
>>>
>>>     identified by the VPWS service instance identifier and a group of
>>>
>>>     VLANs on a specific interface. For this service interface, each
>>>VLAN
>>>
>>>     is presented by a single VID which means no VLAN translation is
>>>
>>>     allowed. The receiving PE, can direct the traffic based on EVPN
>>>label
>>>
>>>!    alone to a specific port. The transmitting PE can cross-connect
>>>
>>>     traffic from a group of VLANs on a specific port to the MPLS label.
>>>
>>>     The MPLS-encapsulated frames MUST remain tagged with the
>>>originating
>>>
>>>     VID.   
>>>
>>>***************
>>>
>>>*** 316,335 ****
>>>
>>>     based service interface (defined in section 2.1) and thus this
>>>
>>>     service interface is not used in EVPN-VPWS.  In other words, if one
>>>
>>>     tries to define data-plane and control plane behavior for this
>>>
>>>!    service interface, he would realize that it is the same as that of
>>>
>>>     VLAN-based service.
>>>
>>>  
>>>
>>>  3. BGP Extensions
>>>
>>>  
>>>
>>>  
>>>
>>>!    This document specifies the use of the per EVI Ethernet A-D route
>>>to
>>>
>>>     signal VPWS services. The Ethernet Segment Identifier field is set
>>>to
>>>
>>>     the customer ES and the Ethernet Tag ID 32-bit field MUST be set to
>>>
>>>!    the VPWS service instance identifier value, the VPWS service
>>>instance
>>>
>>>     identifier value MAY be set to a 24-bit value, when 24-bit value is
>>>
>>>!    used, it MUST be right aligned. For both EPL and EVPL services, for
>>>a
>>>
>>>!    given VPWS service instance the pair of PEs instantiating that VPWS
>>>
>>>!    service instance will each advertise a per EVI Ethernet A-D route
>>>
>>>   
>>>
>>>  
>>>
>>>  
>>>
>>>--- 316,335 ----
>>>
>>>     based service interface (defined in section 2.1) and thus this
>>>
>>>     service interface is not used in EVPN-VPWS.  In other words, if one
>>>
>>>     tries to define data-plane and control plane behavior for this
>>>
>>>!    service interface, one would realize that it is the same as that of
>>>
>>>     VLAN-based service.
>>>
>>>  
>>>
>>>  3. BGP Extensions
>>>
>>>  
>>>
>>>  
>>>
>>>!    This document specifies the use of the per-EVI Ethernet A-D route
>>>to
>>>
>>>     signal VPWS services. The Ethernet Segment Identifier field is set
>>>to
>>>
>>>     the customer ES and the Ethernet Tag ID 32-bit field MUST be set to
>>>
>>>!    the VPWS service instance identifier value. The VPWS service
>>>instance
>>>
>>>     identifier value MAY be set to a 24-bit value, when 24-bit value is
>>>
>>>!    used, it MUST be right aligned. For both EPL and EVPL services
>>>using
>>>
>>>!    a given VPWS service instance, the pair of PEs instantiating that
>>>VPWS
>>>
>>>!    service instance will each advertise a per-EVI Ethernet A-D route
>>>
>>>   
>>>
>>>  
>>>
>>>  
>>>
>>>***************
>>>
>>>*** 340,350 ****
>>>
>>>  
>>>
>>>     with its VPWS service instance identifier and will each be
>>>configured
>>>
>>>     with the other PE's VPWS service instance identifier. When each PE
>>>
>>>!    has received the other PE's per EVI Ethernet A-D route the VPWS
>>>
>>>     service instance is instantiated. It should be noted that the same
>>>
>>>     VPWS service instance identifier may be configured on both PEs.
>>>
>>>  
>>>
>>>!    The Route-Target (RT) extended community with which the per EVI
>>>
>>>     Ethernet A-D route is tagged identifies the EVPN instance in which
>>>
>>>     the VPWS service instance is configured. It is the operator's
>>>choice
>>>
>>>     as to how many and which VPWS service instances are configured in a
>>>
>>>--- 340,350 ----
>>>
>>>  
>>>
>>>     with its VPWS service instance identifier and will each be
>>>configured
>>>
>>>     with the other PE's VPWS service instance identifier. When each PE
>>>
>>>!    has received the other PE's per-EVI Ethernet A-D route, the VPWS
>>>
>>>     service instance is instantiated. It should be noted that the same
>>>
>>>     VPWS service instance identifier may be configured on both PEs.
>>>
>>>  
>>>
>>>!    The Route-Target (RT) extended community with which the per-EVI
>>>
>>>     Ethernet A-D route is tagged identifies the EVPN instance in which
>>>
>>>     the VPWS service instance is configured. It is the operator's
>>>choice
>>>
>>>     as to how many and which VPWS service instances are configured in a
>>>
>>>***************
>>>
>>>*** 355,361 ****
>>>
>>>  3.1 EVPN Layer 2 attributes extended community
>>>
>>>  
>>>
>>>     This draft proposes a new extended community [RFC4360], to be
>>>
>>>!    included with the per EVI Ethernet A-D route. This attribute is
>>>
>>>     mandatory if multihoming is enabled.
>>>
>>>  
>>>
>>>          +------------------------------------+
>>>
>>>--- 355,361 ----
>>>
>>>  3.1 EVPN Layer 2 attributes extended community
>>>
>>>  
>>>
>>>     This draft proposes a new extended community [RFC4360], to be
>>>
>>>!    included with the per-EVI Ethernet A-D route. This attribute is
>>>
>>>     mandatory if multihoming is enabled.
>>>
>>>  
>>>
>>>          +------------------------------------+
>>>
>>>***************
>>>
>>>*** 404,447 ****
>>>
>>>  
>>>
>>>  
>>>
>>>     L2 MTU (Maximum Transmission Unit) is a 2-octet value indicating
>>>the
>>>
>>>!    MTU in bytes.
>>>
>>>  
>>>
>>>!    A received L2 MTU=0 means no MTU checking against local MTU is
>>>
>>>     needed. A received non-zero MTU MUST be checked against local MTU
>>>and
>>>
>>>     if there is a mismatch, the local PE MUST NOT add the remote PE as
>>>
>>>     the EVPN destination for the corresponding VPWS service instance.
>>>
>>>  
>>>
>>>     The usage of the Per ES Ethernet A-D route is unchanged from its
>>>
>>>!    usage in [RFC7432], i.e. the "Single-Active" bit in the flags of
>>>the
>>>
>>>     ESI Label extended community will indicate if single-active or all-
>>>
>>>     active redundancy is used for this ES.
>>>
>>>  
>>>
>>>     In multihoming scenarios, both B and P flags MUST NOT be both set.
>>>A
>>>
>>>     PE that receives an update with both B and P flags set MUST treat
>>>the
>>>
>>>     route as a withdrawal. If the PE receives a route with both B and P
>>>
>>>!    unset, it MUST discard the received route from the sender PE.
>>>
>>>  
>>>
>>>     In a multihoming all-active scenario, there is no DF election, and
>>>
>>>     all the PEs in the ES that are active and ready to forward traffic
>>>
>>>!    to/from the CE will set the P Flag to 1. A remote PE will do
>>>per-flow
>>>
>>>!    load balancing to the PEs that send P=1 for the same Ethernet Tag
>>>and
>>>
>>>!    ESI. B Flag in control flags SHOULD NOT be set in the multihoming
>>>
>>>     all-active scenario and MUST be ignored by receiving PE(s) if set.
>>>
>>>  
>>>
>>>!    In multihoming single-active scenario, for a given VPWS service
>>>
>>>!    instance, in steady state, as result of DF election, the Primary
>>>
>>>!    elected PE for the VPWS service instance should signal P=1,B=0, the
>>>
>>>!    Backup elected PE should signal P=0,B=1, and the rest of the PEs in
>>>
>>>!    the same ES should signal P=0,B=0. When the primary PE/ES fails, 
>>>the
>>>
>>>     primary PE will withdraw the associated Ethernet A-D routes for the
>>>
>>>!    VPWS service instance from the remote PE, the remote PEs should 
>>>then
>>>
>>>     send traffic associated with the VPWS instance to the backup PE. DF
>>>
>>>     re-election will happen between the PE(s) in the same ES, and there
>>>
>>>!    will be a new elected primary PE and new elected backup PE that 
>>>will
>>>
>>>!    signal the P and B Flags as described. A remote PE SHOULD receive
>>>P=1
>>>
>>>!    from only one Primary PE and a B=1 from only one Backup PE. However
>>>
>>>!    during transient situations, a remote PE receiving P=1 from more
>>>than
>>>
>>>!    one PE will select the last advertising PE as the primary PE when
>>>
>>>   
>>>
>>>  
>>>
>>>  
>>>
>>>--- 404,448 ----
>>>
>>>  
>>>
>>>  
>>>
>>>     L2 MTU (Maximum Transmission Unit) is a 2-octet value indicating 
>>>the
>>>
>>>!    MTU in octets.
>>>
>>>  
>>>
>>>!    A received L2 MTU of zero indicates no MTU checking against the
>>>local
>>>
>>>MTU is
>>>
>>>     needed. A received non-zero MTU MUST be checked against local MTU 
>>>and
>>>
>>>     if there is a mismatch, the local PE MUST NOT add the remote PE as
>>>
>>>     the EVPN destination for the corresponding VPWS service instance.
>>>
>>>  
>>>
>>>     The usage of the Per ES Ethernet A-D route is unchanged from its
>>>
>>>!    usage in [RFC7432], i.e., the "Single-Active" bit in the flags of 
>>>the
>>>
>>>     ESI Label extended community will indicate if single-active or all-
>>>
>>>     active redundancy is used for this ES.
>>>
>>>  
>>>
>>>     In multihoming scenarios, both B and P flags MUST NOT be both set. 
>>>A
>>>
>>>     PE that receives an update with both B and P flags set MUST treat 
>>>the
>>>
>>>     route as a withdrawal. If the PE receives a route with both B and P
>>>
>>>!    clear, it MUST discard the received route from the sender PE.
>>>
>>>  
>>>
>>>     In a multihoming all-active scenario, there is no DF election, and
>>>
>>>     all the PEs in the ES that are active and ready to forward traffic
>>>
>>>!    to/from the CE will set the P Flag. A remote PE will do per-flow
>>>
>>>!    load balancing to the PEs that set the P Flag for the same Ethernet
>>>
>>>Tag and
>>>
>>>!    ESI. The B Flag in control flags SHOULD NOT be set in the 
>>>multihoming
>>>
>>>     all-active scenario and MUST be ignored by receiving PE(s) if set.
>>>
>>>  
>>>
>>>!    In multihoming single-active scenario for a given VPWS service
>>>
>>>!    instance, the DF election should result in the Primary-elected PE
>>>
>>>!    the VPWS service instance advertising the P Flag set and the B Flag
>>>
>>>!    clear, the Backup-elected PE should advertise the P Flag clear and
>>>
>>>!    the B Flag set, and the rest of the PEs in the same ES should 
>>>signal
>>>
>>>!    both the P and B flags clear. When the primary PE/ES fails, the
>>>
>>>     primary PE will withdraw the associated Ethernet A-D routes for the
>>>
>>>!    VPWS service instance from the remote PE and the remote PEs should
>>>
>>>then
>>>
>>>     send traffic associated with the VPWS instance to the backup PE. DF
>>>
>>>     re-election will happen between the PE(s) in the same ES, and there
>>>
>>>!    will be a newly elected primary PE and newly elected backup PE that
>>>
>>>will
>>>
>>>!    signal the P and B Flags as described. A remote PE SHOULD receive 
>>>the
>>>
>>>P
>>>
>>>!    Flag set from only one Primary PE and the B Flag set from only one
>>>
>>>Backup 
>>>
>>>!    PE. However, during transient situations, a remote PE receiving a P
>>>
>>>Flag 
>>>
>>>!    set from more than one PE will select the last advertising PE as 
>>>the
>>>
>>>primary PE when
>>>
>>>   
>>>
>>>  
>>>
>>>  
>>>
>>>***************
>>>
>>>*** 450,461 ****
>>>
>>>  INTERNET DRAFT            VPWS support in EVPN         February 28, 
>>>2017
>>>
>>>  
>>>
>>>  
>>>
>>>!    forwarding traffic. A remote PE receiving B=1 from more than one PE
>>>
>>>!    will select only one backup PE. A remote PE MUST receive P=1 from 
>>>at
>>>
>>>     least one PE before forwarding traffic.
>>>
>>>  
>>>
>>>     If a network uses entropy labels per [RFC6790] then the C Flag MUST
>>>
>>>!    NOT be set to 1 and control word MUST NOT be used when sending 
>>>EVPN-
>>>
>>>     encapsulated packets over a P2P LSP.
>>>
>>>  
>>>
>>>  
>>>
>>>--- 451,462 ----
>>>
>>>  INTERNET DRAFT            VPWS support in EVPN         February 28, 
>>>2017
>>>
>>>  
>>>
>>>  
>>>
>>>!    forwarding traffic. A remote PE receiving a B Flag set from more 
>>>than
>>>
>>>one PE
>>>
>>>!    will select only one backup PE. A remote PE MUST receive P Flag set
>>>
>>>from at
>>>
>>>     least one PE before forwarding traffic.
>>>
>>>  
>>>
>>>     If a network uses entropy labels per [RFC6790] then the C Flag MUST
>>>
>>>!    NOT be set and the control word MUST NOT be used when sending EVPN-
>>>
>>>     encapsulated packets over a P2P LSP.
>>>
>>>  
>>>
>>>  
>>>
>>>***************
>>>
>>>*** 488,494 ****
>>>
>>>     established between PE3, PE4, ASBR2 and ASBR4. eBGP sessions are
>>>
>>>     established among ASBR1, ASBR2, ASBR3, and ASBR4.
>>>
>>>  
>>>
>>>!    All PEs and ASBRs are enabled for the EVPN SAFI and exchange per 
>>>EVI
>>>
>>>     Ethernet A-D routes, one route per VPWS service instance.  For 
>>>inter-
>>>
>>>     AS option B, the ASBRs re-advertise these routes with NEXT_HOP
>>>
>>>     attribute set to their IP addresses as per [RFC4271]. The link
>>>
>>>--- 489,495 ----
>>>
>>>     established between PE3, PE4, ASBR2 and ASBR4. eBGP sessions are
>>>
>>>     established among ASBR1, ASBR2, ASBR3, and ASBR4.
>>>
>>>  
>>>
>>>!    All PEs and ASBRs are enabled for the EVPN SAFI and exchange 
>>>per-EVI
>>>
>>>     Ethernet A-D routes, one route per VPWS service instance.  For 
>>>inter-
>>>
>>>     AS option B, the ASBRs re-advertise these routes with NEXT_HOP
>>>
>>>     attribute set to their IP addresses as per [RFC4271]. The link
>>>
>>>***************
>>>
>>>*** 510,520 ****
>>>
>>>     label will identify the VPWS service instance and if translation is
>>>
>>>     needed, it should be done by the Ethernet interface for each 
>>>service.
>>>
>>>  
>>>
>>>!    For single-homed CE, in an advertised per EVI Ethernet A-D route 
>>>the
>>>
>>>     ESI field is set to 0 and the Ethernet Tag ID is set to the VPWS
>>>
>>>     service instance identifier that identifies the EVPL or EPL 
>>>service.
>>>
>>>  
>>>
>>>!    For a multi-homed CE, in an advertised per EVI Ethernet A-D route 
>>>the
>>>
>>>     ESI field is set to the CE's ESI and the Ethernet Tag ID is set to
>>>
>>>     the VPWS service instance identifier, which MUST have the same 
>>>value
>>>
>>>     on all PEs attached to that ES. This allows an ingress PE in a
>>>
>>>--- 511,521 ----
>>>
>>>     label will identify the VPWS service instance and if translation is
>>>
>>>     needed, it should be done by the Ethernet interface for each 
>>>service.
>>>
>>>  
>>>
>>>!    For single-homed CE, in an advertised per-EVI Ethernet A-D route 
>>>the
>>>
>>>     ESI field is set to 0 and the Ethernet Tag ID is set to the VPWS
>>>
>>>     service instance identifier that identifies the EVPL or EPL 
>>>service.
>>>
>>>  
>>>
>>>!    For a multi-homed CE, in an advertised per-EVI Ethernet A-D route 
>>>the
>>>
>>>     ESI field is set to the CE's ESI and the Ethernet Tag ID is set to
>>>
>>>     the VPWS service instance identifier, which MUST have the same 
>>>value
>>>
>>>     on all PEs attached to that ES. This allows an ingress PE in a
>>>
>>>***************
>>>
>>>*** 523,535 ****
>>>
>>>     traffic follows the transport paths, which may be asymmetric.
>>>
>>>  
>>>
>>>     The VPWS service instance identifier encoded in the Ethernet Tag ID
>>>
>>>!    in an advertised per EVI Ethernet A-D route MUST either be unique
>>>
>>>     across all ASs, or an ASBR needs to perform a translation when the
>>>
>>>!    per EVI Ethernet A-D route is re-advertised by the ASBR from one AS
>>>
>>>     to the other AS.
>>>
>>>  
>>>
>>>!    Per ES Ethernet A-D route can be used for mass withdraw to withdraw
>>>
>>>!    all per EVI Ethernet A-D routes associated with the multi-home site
>>>
>>>     on a given PE.
>>>
>>>  
>>>
>>>  
>>>
>>>--- 524,536 ----
>>>
>>>     traffic follows the transport paths, which may be asymmetric.
>>>
>>>  
>>>
>>>     The VPWS service instance identifier encoded in the Ethernet Tag ID
>>>
>>>!    advertised in a per-EVI Ethernet A-D route MUST either be unique
>>>
>>>     across all ASs, or an ASBR needs to perform a translation when the
>>>
>>>!    per-EVI Ethernet A-D route is re-advertised by the ASBR from one AS
>>>
>>>     to the other AS.
>>>
>>>  
>>>
>>>!    A per-ES Ethernet A-D route can be used for mass withdraw to 
>>>withdraw
>>>
>>>!    all per-EVI Ethernet A-D routes associated with the multi-homed 
>>>site
>>>
>>>     on a given PE.
>>>
>>>  
>>>
>>>  
>>>
>>>***************
>>>
>>>*** 540,551 ****
>>>
>>>     signaling is done via LDP and service endpoint discovery is either
>>>
>>>     through manual provisioning or through BGP.
>>>
>>>  
>>>
>>>!    In existing implementation of VPWS using pseudowires(PWs), 
>>>redundancy
>>>
>>>     is limited to single-active mode, while with EVPN implementation of
>>>
>>>     VPWS both single-active and all-active redundancy modes can be
>>>
>>>     supported.
>>>
>>>  
>>>
>>>!    In existing implementation with PWs, backup PWs are not used to 
>>>carry
>>>
>>>     traffic, while with EVPN, traffic can be load-balanced among
>>>
>>>     different PEs multi-homed to a single CE.
>>>
>>>  
>>>
>>>--- 541,552 ----
>>>
>>>     signaling is done via LDP and service endpoint discovery is either
>>>
>>>     through manual provisioning or through BGP.
>>>
>>>  
>>>
>>>!    In existing implementations of VPWS using pseudowires(PWs), 
>>>redundancy
>>>
>>>     is limited to single-active mode, while with EVPN implementation of
>>>
>>>     VPWS both single-active and all-active redundancy modes can be
>>>
>>>     supported.
>>>
>>>  
>>>
>>>!    In existing implementations with PWs, backup PWs are not used to 
>>>carry
>>>
>>>     traffic, while with EVPN, traffic can be load-balanced among
>>>
>>>     different PEs multi-homed to a single CE.
>>>
>>>  
>>>
>>>***************
>>>
>>>*** 566,572 ****
>>>
>>>  
>>>
>>>     Finally, EVPN may employ data plane egress link protection 
>>>mechanisms
>>>
>>>     not available in VPWS. This can be done by the primary PE (on local
>>>
>>>!    AC down) using the label advertised in the per EVI Ethernet A-D 
>>>route
>>>
>>>     by the backup PE to encapsulate the traffic and direct it to backup
>>>
>>>     PE.
>>>
>>>  
>>>
>>>--- 567,573 ----
>>>
>>>  
>>>
>>>     Finally, EVPN may employ data plane egress link protection 
>>>mechanisms
>>>
>>>     not available in VPWS. This can be done by the primary PE (on local
>>>
>>>!    AC down) using the label advertised in the per-EVI Ethernet A-D 
>>>route
>>>
>>>     by the backup PE to encapsulate the traffic and direct it to backup
>>>
>>>     PE.
>>>
>>>  
>>>
>>>***************
>>>
>>>*** 582,594 ****
>>>
>>>     Unlike [RFC7432],  EVPN-VPWS uses Ethernet A-D route advertisements
>>>
>>>     for single-homed Ethernet Segments. Therefore, upon a link/port
>>>
>>>     failure of this single-homed Ethernet Segment, the PE MUST withdraw
>>>
>>>!    the associated per EVI Ethernet A-D routes.
>>>
>>>  
>>>
>>>  6.2 Multi-Homed CEs
>>>
>>>  
>>>
>>>     For a faster convergence in multi-homed scenarios with either 
>>>Single-
>>>
>>>!    Active Redundancy or All-active redundancy, mass withdraw technique
>>>
>>>!    is used. A PE previously advertising a per ES Ethernet A-D route, 
>>>can
>>>
>>>     withdraw this route signaling to the remote PEs to switch all the
>>>
>>>     VPWS service instances associated with this multi-homed ES to the
>>>
>>>     backup PE
>>>
>>>--- 583,595 ----
>>>
>>>     Unlike [RFC7432],  EVPN-VPWS uses Ethernet A-D route advertisements
>>>
>>>     for single-homed Ethernet Segments. Therefore, upon a link/port
>>>
>>>     failure of this single-homed Ethernet Segment, the PE MUST withdraw
>>>
>>>!    the associated per-EVI Ethernet A-D routes.
>>>
>>>  
>>>
>>>  6.2 Multi-Homed CEs
>>>
>>>  
>>>
>>>     For a faster convergence in multi-homed scenarios with either 
>>>Single-
>>>
>>>!    Active Redundancy or All-active redundancy, a mass withdraw 
>>>technique
>>>
>>>!    is used. A PE previously advertising a per-ES Ethernet A-D route, 
>>>can
>>>
>>>     withdraw this route signaling to the remote PEs to switch all the
>>>
>>>     VPWS service instances associated with this multi-homed ES to the
>>>
>>>     backup PE
>>>
>>>***************
>>>
>>>*** 630,636 ****
>>>
>>>  
>>>
>>>       P      Advertising PE is the Primary PE.
>>>
>>>       B      Advertising PE is the Backup PE.
>>>
>>>!      C      Control word [RFC4448] MUST be present
>>>
>>>  
>>>
>>>  10 References
>>>
>>>  
>>>
>>>--- 631,637 ----
>>>
>>>  
>>>
>>>       P      Advertising PE is the Primary PE.
>>>
>>>       B      Advertising PE is the Backup PE.
>>>
>>>!      C      Control word [RFC4448] MUST be present.
>>>
>>>  
>>>
>>>  10 References
>>>
>>>
>>>
>>>
>>>
>>>Thanks,
>>>
>>>Acee
>>>
>>>
>>>
>
>_______________________________________________
>BESS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/bess