[bess] Document shepherd review of draft-ietf-bess-evpn-fast-df-recovery-05

["Bocci, Matthew (Nokia - GB)" <[e-mail]>]

Authors

As is customary, please find below my document shepherd review of this draft.

The comments are mainly of an editorial nature or suggest improvements to aid readability.

Please treat these comments (prepended with MB>) as you would any other working group last call comments.

Best regards

Matthew

===

          Fast Recovery for EVPN Designated Forwarder Election
                draft-ietf-bess-evpn-fast-df-recovery-05

Abstract

   Ethernet Virtual Private Network (EVPN) solution provides Designated

MB> /Ethernet/The Ethernet

   Forwarder election procedures for multihomed Ethernet Segments.
   These procedures have been enhanced further by applying Highest
   Random Weight (HRW) Algorithm for Designated Forwarded election in
   order to avoid unnecessary DF status changes upon a failure.  This
   draft improves these procedures by providing a fast Designated

MB> /draft/document

   Forwarder (DF) election upon recovery of the failed link or node
   associated with the multihomed Ethernet Segment.  The solution is
   independent of number of EVIs associated with that Ethernet Segment

MB> /of number/of the number

   and it is performed via a simple signaling between the recovered PE
   and each of the other PEs in the multihoming group.

[...]

1.  Introduction

   Ethernet Virtual Private Network (EVPN) solution [RFC7432] is

MB> /Ethernet/The Ethernet

   becoming pervasive in data center (DC) applications for Network
   Virtualization Overlay (NVO) and DC interconnect (DCI) services, and
   in service provider (SP) applications for next generation virtual
   private LAN services.



[...]

   The EVPN specification [RFC7432] describes DF election procedures for

MB> I think you just need to say [RFC7432] describes...



   multihomed Ethernet Segments.  These procedures are enhanced further
   in [RFC8584] by applying Highest Random Weight Algorithm for DF
   election in order to avoid DF status change unnecessarily upon a link
   or node failure associated with the multihomed Ethernet Segment.

MB> I found the above hard to parse. Maybe replace it with:
"These procedures are enhanced further
   in [RFC8584] by applying Highest Random Weight Algorithm for DF
   election in order to avoid unnecessary DF status changes upon a link
   or node failure associated with the multihomed Ethernet Segment."

   [...]

1.1.  Terminology

   Provider Edge (PE):  A device that sits in the boundary of Provider
      and Customer networks and performs encap/decap of data from L2 to
      L3 and vice-versa.

MB> Not sure you need to define PE as it is a well known term, but in any case I think
Your definition differs from ones I could find I previous RFCs. Maybe you can just delete it.

   Designated Forwarder (DF):  A PE that is currently forwarding
      (encapsulating/decapsulating) traffic for a given VLAN in and out
      of a site.

2.  Challenges with Existing Solution

   In EVPN technology, multiple PE devices have the ability to encap and
   decap data belonging to the same VLAN.  In certain situations, this
   may cause L2 duplicates and even loops if there is a momentary
   overlap of forwarding roles between two or more PE devices, leading
   to broadcast storms.

   EVPN [RFC7432] currently uses timer based synchronization among PE
   devices in redundancy group that can result in duplications (and even
   loops) because of multiple DFs if the timer is too short or
   blackholing if the timer is too long.

   Using split-horizon filtering (Section 8.3 of [RFC7432]) can prevent
   loops (but not duplicates), however if there are overlapping DFs in

MB> I suggest you split the sentence to make it more readable:
"...(but not duplicates). However, if there are..."


   two different sites at the same time for the same VLAN, the site
   identifier will be different upon re-entry of the packet and hence
   the split-horizon check will fail, leading to L2 loops.

[...]


   However, upon PE insertion or port bring-up (recovery event), HRW

MB> Do you mean "...or port bring-up following a recovery event,"?

   also cannot help as a transfer of DF role to the newly inserted
   device/port must occur while the old DF is still active.

                                     +---------+
                  +-------------+    |         |
                  |             |    |         |
                / |    PE1      |----|         |   +-------------+
               /  |             |    |  MPLS/  |   |             |---CE3
              /   +-------------+    |  VxLAN/ |   |     PE3     |
         CE1 -                       |  Cloud  |   |             |
              \   +-------------+    |         |---|             |
               \  |             |    |         |   +-------------+
                \ |     PE2     |----|         |
                  |             |    |         |
                  +-------------+    |         |
                                     +---------+


                  Figure 1: CE1 multihomed to PE1 and PE2.

   In the Figure 1, when PE2 is inserted or booted up, PE1 will transfer

MB> /transfer/transfer the

   DF role of some VLANs to PE2 to achieve load balancing.  However,
   because there is no handshake mechanism between PE1 and PE2,
   duplication of DF roles for a given VLAN is possible.  Duplication of
   DF roles may eventually lead to duplication of traffic as well as L2
   loops.

   Current EVPN specification [RFC7432] and [RFC8584] relies on a timer-

MB> /specification/specifications
MB> /relies/rely


   based approach for transferring the DF role to the newly inserted
   device.  This can cause the following issues:

   *  Loops/Duplicates if the timer value is too short

   *  Prolonged Traffic Blackholing if the timer value is too long

3.  DF Election Synchronization Solution

   The solution relies on the concept of common clock alignment between
   partner PEs participating to a common Ethernet Segment.  The main
   idea is to have all peering PEs of that Ethernet Segment perform DF
   election, and apply their resulting carving state, at a same well-
   known time.


MB> It would be clearer if you could identify the partner YEs on a figure e.g. Figure 1


   The DF Election procedure, as described in [RFC7432] and as
   optionally signalled in [RFC8584], is applied.  All PEs attached to a
   given Ethernet Segment are clock-synchronized; using a networking

MB> /clock-synchronized;/clock-synchronized


   protocol for clock synchronization (e.g.  NTP, PTP, etc.).  Newly
   inserted device PE or during failure recovery of a PE, that PE
   communicates the current time to peering partners plus the remaining
   peering timer time left.

MB> The first part of the above does not parse. Do you mean "When a new PE is inserted
or an existing PE device recovers,..."?


This constitutes an "end time" or "absolute
   time" as seen from local PE.  That absolute time is called "Service
   Carving Time" (SCT).

   A new BGP Extended Community is advertised along with Ethernet

MB> Maybe say it is the "Service Carving Timestamp" here.

   Segment route (RT-4) to communicate to other partners the Service
   Carving Time.

   Upon reception of that new BGP Extended Community, partner PEs know

MB> /know/can determine

   exactly its carving time.  The notion of skew is introduced to
   eliminate any potential duplicate traffic or loops.  They add a skew

MB> Who is "they". Do you mean "The receiving partner PEs"?

   (default = -10ms) to the Service Carving Time to enforce this.  The
   previously inserted PE(s) must carve first, followed shortly(skew) by
   the newly insterted PE.

   To summarize, all peering PEs carve almost simultaneously at the time
   announced by newly added/recovered PE.  The newly inserted PE
   initiates the SCT, and carves immediately on peering timer expiry.
   The previously inserted PE(s) receiving Ethernet Segment route (RT-4)
   with a SCT BGP extended community, carve shortly before Service
   Carving Time.

3.1.  Advantages

MB> This section seems out of place in a protocol spec. I suggest moving this text to the end of the
introduction.


   There are multiples advantages of using the approach.  Here is a non-
   exhaustive list:

   *  A simple uni-directional signaling is all that is needed

   *  Backwards-compatible: PEs supporting only older [RFC7432] shall
      simply discard unrecognized new "Service Carving Timestamp" BGP
      Extended Community

   *  Multiple DF Election algorithms can be supported:

      -  [RFC7432] default ordered list ordinal algorithm (Modulo),

      -  [RFC8584] highest-random weight, etc.

   *  Independent of BGP transmission delay regarding Ethernet Segment
      route (RT-4)

   *  Agnostic of the time synchronization mechanism used (e.g.  NTP,
      PTP, etc.)


[…]

3.2.  BGP Encoding

[…]


   This capability is used in conjunction with the agreed upon DF Type
   (DF Election Type).  For example if all the PEs in the Ethernet
   Segment indicated that they have Time Synchronization capability and
   they want the DF type to be HRW, then HRW algorithm is used in

S/then HRW/then the HRW

   conjunction with this capability.