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)" <jorge.raba...@nokia.com> 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" <sbout...@vmware.com> 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)" > <jorge.raba...@nokia.com> 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" <sbout...@vmware.com> 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)" <a...@cisco.com> 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 > > > > > > > > > _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
