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
