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

[Sami Boutros <[e-mail]>]

Hi Jorge,

Isn’t the end result is to clear any previous state that the receiving PE learned from the PE that’s advertising now P=B=0?

I think having a PE send P=B=0 to be ignored by the receiving PE is not a good logic to start with, One can argue why send something that will be ignored anyway?

I’m not sure I get what you mean by wrongly withdraw the route? we have to remove any previously learned state from the PE advertising P=B=0, so we can’t keep any previous routes, given that the new route with P=B=0 will implicitly withdraw the previous route, so why not say that the P=B=0 route should be treated as withdraw?

Given the above, I am in favor of leaving the text as is.

Thanks,

Sami

On 3/13/17, 8:24 AM, "Rabadan, Jorge (Nokia - US)" <[e-mail]> wrote:

>Hi Acee and Sami,
>
>Thank you both for explaining, I think I now understand your point.
>I thought the sentence had more to do with error handling at application level, hence my point that P=B=0 was a legitimate combination. 
>
>I think the three of us agree that receiving an update with P=B=0 is an indication of relinquishing the DF or BDF role by the sender PE, when it previously sent different flags. However I think it would be clearer if we differentiate both cases:
>
>Update with P=B=1 -> invalid combination, treat as withdraw
>Update with P=B=0 -> valid combination, clears previous DF/BDF indication from the sender PE
>
>Otherwise we give the impression that P=B=0 is invalid and implementations may wrongly withdraw the route, even at BGP level.
>
>Thank you.
>Jorge 
>
>
>On 3/13/17, 3:46 PM, "Sami Boutros" <[e-mail]> wrote:
>
>    Hi Jorge,
>    
>    The issue I see with ignoring the routes with P and B Flags clear is the following:
>    
>    What if a PE advertised P or B Flag set then decide to send P and B Flags clear, what should we do in that case?
>    
>    Ignore the P and B Flags clear route and keep the old P or B Flag set route, wouldn’t that be incorrect?
>    
>    Thanks,
>    
>    Sami
>    
>    
>    On 3/13/17, 6:04 AM, "Rabadan, Jorge (Nokia - US)" <[e-mail]> wrote:
>    
>    >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
>    >    >
>    >    
>    >
>    
>