Skip to main content

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

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-evpn-fast-df-recovery@ietf.org, gunter@vandevelde.cc, matthew.bocci@nokia.com, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Fast Recovery for EVPN Designated Forwarder Election' to Proposed Standard (draft-ietf-bess-evpn-fast-df-recovery-12.txt)

The IESG has approved the following document:
- 'Fast Recovery for EVPN Designated Forwarder Election'
  (draft-ietf-bess-evpn-fast-df-recovery-12.txt) as Proposed Standard

This document is the product of the BGP Enabled ServiceS Working Group.

The IESG contact persons are Gunter Van de Velde, Jim Guichard and John
Scudder.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/


Ballot Text

Technical Summary

   The Ethernet Virtual Private Network (EVPN) solution provides
   Designated Forwarder (DF) election procedures for multihomed Ethernet
   Segments.  These procedures have been enhanced further by applying
   Highest Random Weight (HRW) algorithm for Designated Forwarder
   election in order to avoid unnecessary DF status changes upon a
   failure.  This document improves these procedures by providing a fast
   Designated Forwarder election upon recovery of the failed link or
   node associated with the multihomed Ethernet Segment.  This document
   updates Section 2.1 of [RFC8584] by optionally introducing delays
   between some of the events therein.

   The solution is independent of the number of EVPN Instances (EVIs)
   associated with that Ethernet Segment and it is performed via a
   simple signaling between the recovered node and each of the other
   nodes in the multihoming group.

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

None indicated.

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

BESS has a policy of requiring at least one implementation for standards track
protocol drafts before proceeding. There is at least one known implementation
which has been declared on the BESS list during an implementation poll.

Personnel

   The Document Shepherd for this document is Matthew Bocci. The
   Responsible Area Director is Gunter Van de Velde.

IANA Note

   IANA maintains the "EVPN Extended Community Sub-Types" registry set
   up by [RFC7153].  IANA is requested to confirm the First Come First
   Served assignment as follows:

      Sub-Type Value   Name                        Reference       Date
      --------------   -------------------------   -------------   ----
            0x0F       Service Carving Timestamp   This document   TBD

   IANA should replace the field TBD with the date of publication of this
   document as an RFC.

   IANA maintains the "DF Election Capabilities" registry set up by
   [RFC8584].  IANA is requested to make the following assignment from
   this registry:

       Bit         Name                         Reference        Date
       ----        ----------------             -------------    ----
       3           Time Synchronization         This document    TBD

   IANA should replace the field TBD with the date of publicaton of this
   document as an RFC.

RFC Editor Note