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

["Rabadan, Jorge (Nokia - US)" <[e-mail]>]

Sami, 

About this one:

“  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?

I agree both should be treated as a withdrawal, I will change the text.”


[JORGE] Sami, please correct this:

“If the PE receives a route with both B and P
   clear, it MUST treat the route as a withdrawal from the sender PE.”

As you have in the following paragraph, flags P=B=0 is perfectly valid:

“In multihoming single-active scenario for a given VPWS service
   instance, the DF election should result in the Primary-elected PE for
   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 P and B Flags clear.****”


Let me know if I’m missing something please. Don’t want to hold the progress, but this is important.
Thank you.
Jorge



On 3/12/17, 8:24 PM, "Sami Boutros" <[e-mail]> wrote:

    Hi Acee,
    
    Please find attached document with all comments addresses, if all good will 
    Submit before the cut-off tomorrow.
    
    Please see comments inline.
    On 3/12/17, 11:36 AM, "Acee Lindem (acee)" <[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?
    
    I agree both should be treated as a withdrawal, I will change the text.
    
    >  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.”
    
    The DF election is between the PE(s) attached to the ES and has nothing to do 
    With the remote PE receiving the routes from the PE(s) attached to the ES.
    The remote PE expect to receive one route with P Flag set and another route 
    With with B flag set from another PE, all other routes received from other PE(s) 
    Attached to the same ES are not needed, and hence can be treated as withdrawal
    Of previous routes from those Pe(s). 
    
    > 
    >  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?
    
    The DF election MUST always result in one Backup and One primary, however 
    During transit more than one route with P or B Flags can be received.
    
    >Why isn’t it the last one similar to the primary PE
    >selection?
    
    Ok, to be consistent, will change the text to have the remote PE select the 
    last advertising backup PE.
    
    > 
    >  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.
    
    Ok.
    >
    >  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,
    
    Sami
    >