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

[Sami Boutros <[e-mail]>]

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=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=RtGVdqFdzyGNI_Ni98jxVOpGqfSYH56HwthHx0XO0pM&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
>
>
>