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

<!DOCTYPE html> <html data-bs-theme="auto" lang="en" prefix="og: http://ogp.me/ns# article: http://ogp.me/ns/article#"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <title> draft-ietf-bess-evpn-fast-df-recovery-12 - Fast Recovery for EVPN Designated Forwarder Election </title> <meta name="viewport" content="width=device-width, initial-scale=1"> <link href="https://static.ietf.org/fonts/inter/import.css" rel="stylesheet"> <link href="https://static.ietf.org/fonts/noto-sans-mono/import.css" rel="stylesheet"> <link rel="stylesheet" href="https://static.ietf.org/dt/12.28.2/ietf/css/ietf.css"> <link rel="stylesheet" href="https://static.ietf.org/dt/12.28.2/ietf/css/select2.css"> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/theme.js"></script> <style> .inline { display: inline; } </style> <meta property="og:title" content="Fast Recovery for EVPN Designated Forwarder Election"> <meta property="og:url" content="https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/"> <link rel="canonical" href="https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/"> <meta property="og:site_name" content="IETF Datatracker"> <meta property="og:description" content="The Ethernet Virtual Private Network (EVPN) solution in RFC 7432 provides Designated Forwarder (DF) election procedures for multihomed Ethernet Segments. These procedures have been enhanced further by applying the Highest Random Weight (HRW) algorithm for Designated Forwarder election 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 RFC 8584 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 in BGP between the recovered node and each of the other nodes in the multihoming group."> <meta property="og:type" content="article"> <meta property="og:image" content="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-card.png"> <meta property="og:image:alt" content="Logo of the IETF"> <meta property="article:section" content="IETF - Internet Engineering Task Force"> <meta property="og:image:type" content="image/png"> <meta property="og:image:width" content="1200"> <meta property="og:image:height" content="630"> <meta name="twitter:card" content="summary_large_image"> <meta property="article:author" content="Patrice Brissette"> <meta property="article:author" content="Ali Sajassi"> <meta property="article:author" content="Luc Andr茅 Burdet"> <meta property="article:author" content="John Drake"> <meta property="article:author" content="Jorge Rabadan"> <link rel="alternate" type="application/atom+xml" title="Document changes" href="/feed/document-changes/draft-ietf-bess-evpn-fast-df-recovery/"> <meta name="description" content="Fast Recovery for EVPN Designated Forwarder Election "> <script type="module" crossorigin="" src="https://static.ietf.org/dt/12.28.2/assets/embedded-e653257c.js"></script> <link href="https://static.ietf.org/dt/12.28.2/assets/create-pinia-singleton-091c62b7.js" type="text/javascript" crossorigin="anonymous" rel="modulepreload" as="script" /> <link href="https://static.ietf.org/dt/12.28.2/assets/Scrollbar-7de50899.js" type="text/javascript" crossorigin="anonymous" rel="modulepreload" as="script" /> <link rel="apple-touch-icon" sizes="180x180" href="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-180.png"> <link rel="icon" sizes="32x32" href="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-32.png"> <link rel="icon" sizes="16x16" href="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-16.png"> <link rel="manifest" href="/site.webmanifest"> <link rel="mask-icon" href="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-mask.svg" color="#ffffff"> <meta name="msapplication-TileColor" content="#ffffff"> <meta name="theme-color" content="#ffffff"> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/ietf.js"></script> </head> <body class="navbar-offset position-relative" data-group-menu-data-url="/group/groupmenu.json"> <noscript><iframe class="status" title="Site status" src="/status/latest"></iframe></noscript> <div class="vue-embed" data-component="Status"></div> <a class="visually-hidden visually-hidden-focusable" href="#content">Skip to main content</a> <nav class="navbar navbar-expand-lg fixed-top bg-secondary-subtle"> <div class="container-fluid"> <a class="navbar-brand" href="/"> <img alt="IETF Logo" class="d-lm-none me-2" src="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-white.svg" > <img alt="IETF Logo" class="d-dm-none me-2" src="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor.svg" > Datatracker </a> <div class="collapse navbar-collapse" id="navbar-collapse"> <ul class="nav navbar-nav flex-nowrap"> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> Groups </a> <ul class="dropdown-menu mt-n1"> <li class="dropdown-header">By area/parent</li> <li class="dropend group-menu group-parent-2010"> <a class="dropdown-item dropdown-toggle " href="/wg/#ART"> Apps & Realtime </a> </li> <li class="dropend group-menu group-parent-1008"> <a class="dropdown-item dropdown-toggle " href="/wg/#GEN"> General </a> </li> <li class="dropend group-menu group-parent-1052"> <a class="dropdown-item dropdown-toggle " href="/wg/#INT"> Internet </a> </li> <li class="dropend group-menu group-parent-1193"> <a class="dropdown-item dropdown-toggle " href="/wg/#OPS"> Ops & Management </a> </li> <li class="dropend group-menu group-parent-1249"> <a class="dropdown-item dropdown-toggle " href="/wg/#RTG"> Routing </a> </li> <li class="dropend group-menu group-parent-1260"> <a class="dropdown-item dropdown-toggle " href="/wg/#SEC"> Security </a> </li> <li class="dropend group-menu group-parent-2412"> <a class="dropdown-item dropdown-toggle " href="/wg/#WIT"> Web and Internet Transport </a> </li> <li class="dropend group-menu group-parent-7"> <a class="dropdown-item dropdown-toggle " href="/program/"> IAB </a> </li> <li class="dropend group-menu group-parent-3"> <a class="dropdown-item dropdown-toggle " href="/rg/"> IRTF </a> </li> <li class="dropend group-menu group-parent-2309"> <a class="dropdown-item dropdown-toggle " href="/adm/"> IETF LLC </a> </li> <li class="dropend group-menu group-parent-1876"> <a class="dropdown-item dropdown-toggle " href="/rfcedtyp/"> RFC Editor </a> </li> <li class="dropend"> <a class="dropdown-item dropdown-toggle " href="/group/"> Other </a> <ul class="dropdown-menu ms-n1"> <li> <a class="dropdown-item " href="/ag/">Active AGs</a> </li> <li> <a class="dropdown-item " href="/area/">Active Areas</a> </li> <li> <a class="dropdown-item " href="/dir/">Active Directorates</a> </li> <li> <a class="dropdown-item " href="/iabworkshop/">Active IAB Workshops</a> </li> <li> <a class="dropdown-item " href="/program/">Active Programs</a> </li> <li> <a class="dropdown-item " href="/rag/">Active RAGs</a> </li> <li> <a class="dropdown-item " href="/team/">Active Teams</a> </li> </ul> </li> <li><hr class="dropdown-divider"></li> <li class="dropdown-header">New work</li> <li> <a class="dropdown-item " href="/group/chartering/"> Chartering groups </a> </li> <li> <a class="dropdown-item " href="/wg/bofs/"> BOFs </a> </li> <li> <a class="dropdown-item " href="/doc/bof-requests"> BOF Requests </a> </li> <li><hr class="dropdown-divider"></li> <li class="dropdown-header">Other groups</li> <li> <a class="dropdown-item " href="/group/concluded/"> Concluded groups </a> </li> <li> <a class="dropdown-item " href="/list/nonwg"> Non-WG lists </a> </li> </ul> </li> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> Documents </a> <ul class="dropdown-menu mt-n1"> <li> <a class="dropdown-item " href="/doc/search"> Search </a> </li> <li> <a class="dropdown-item " href="/doc/recent"> Recent I-Ds </a> </li> <li> <a class="dropdown-item " href="/submit/"> I-D submission </a> </li> <li> <a class="dropdown-item " href="/doc/ad"> IESG dashboard </a> </li> <li><hr class="dropdown-divider"> </li> <li class="dropdown-header"> RFC streams </li> <li> <a class="dropdown-item " href="/stream/iab/"> IAB </a> </li> <li> <a class="dropdown-item " href="/stream/irtf/"> IRTF </a> </li> <li> <a class="dropdown-item " href="/stream/ise/"> ISE </a> </li> <li> <a class="dropdown-item " href="/stream/editorial/"> Editorial </a> </li> <li><hr class="dropdown-divider"> </li> <li class="dropdown-header"> Subseries </li> <li> <a class="dropdown-item " href="/doc/std"> STD </a> <a class="dropdown-item " href="/doc/bcp"> BCP </a> <a class="dropdown-item " href="/doc/fyi"> FYI </a> </li> </ul> </li> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> Meetings </a> <ul class="dropdown-menu mt-n1"> <li> <a class="dropdown-item " href="/meeting/agenda"> Agenda </a> </li> <li> <a class="dropdown-item " href="/meeting/materials"> Materials </a> </li> <li> <a class="dropdown-item " href="/meeting/floor-plan"> Floor plan </a> </li> <li> <a class="dropdown-item " href="https://www.ietf.org/how/meetings/register/"> Registration </a> </li> <li> <a class="dropdown-item " href="/meeting/important-dates/"> Important dates </a> </li> <li> <a class="dropdown-item " href="/secr/sreq/"> Request a session </a> </li> <li> <a class="dropdown-item " href="/meeting/requests"> Session requests </a> </li> <li><hr class="dropdown-divider"> </li> <li class="dropdown-header"> Upcoming meetings </li> <li> <a class="dropdown-item " href="/meeting/upcoming"> Upcoming meetings </a> </li> <li><hr class="dropdown-divider"> </li> <li class="dropdown-header"> Past meetings </li> <li> <a class="dropdown-item " href="/meeting/past"> Past meetings </a> </li> <li> <a class="dropdown-item " href="https://www.ietf.org/how/meetings/past/"> Meeting proceedings </a> </li> </ul> </li> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> Other </a> <ul class="dropdown-menu mt-n1"> <li> <a class="dropdown-item " href="/ipr/"> IPR disclosures </a> </li> <li> <a class="dropdown-item " href="/liaison/"> Liaison statements </a> </li> <li> <a class="dropdown-item " href="/iesg/agenda/"> IESG agenda </a> </li> <li> <a class="dropdown-item " href="/nomcom/"> NomComs </a> </li> <li> <a class="dropdown-item " href="/doc/downref"> Downref registry </a> </li> <li> <a class="dropdown-item " href="/stats/"> Statistics </a> <ul class="dropdown-menu mt-n1"> <li> <a class="dropdown-item " href="/stats/document/"> I-Ds/RFCs </a> </li> <li> <a class="dropdown-item " href="/stats/meeting/"> Meetings </a> </li> </ul> </li> <li> <a class="dropdown-item " href="/api/"> API Help </a> </li> <li> <a class="dropdown-item " href="/release/"> Release notes </a> </li> <li> <a class="dropdown-item " target="_blank" href="https://status.ietf.org"> System status </a> </li> <li><hr class="dropdown-divider"> </li> <li> <a class="dropdown-item text-danger " target="_blank" href="https://github.com/ietf-tools/datatracker/issues/new/choose"> <i class="bi bi-bug"> </i> Report a bug </a> </li> </ul> </li> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> User </a> <ul class="dropdown-menu mt-n1 "> <li> <a class="dropdown-item " rel="nofollow" href="/accounts/login/?next=/doc/draft-ietf-bess-evpn-fast-df-recovery/"> Sign in </a> </li> <li> <a class="dropdown-item " rel="nofollow" href="/accounts/reset/"> Password reset </a> </li> <li> <a class="dropdown-item " href="/accounts/settings/" rel="nofollow"> Preferences </a> </li> <li> <a class="dropdown-item " href="/accounts/create/"> New account </a> </li> </ul></li> </ul> </div> <div class="d-flex align-items-center"> <a class="nav-link text-danger d-none d-xl-inline me-xl-4" target="_blank" href="https://github.com/ietf-tools/datatracker/issues/new/choose"> Report a bug <i class="bi bi-bug"></i> </a> <a class="btn me-1 btn-warning d-none d-sm-block" rel="nofollow" href="/accounts/login/?next=/doc/draft-ietf-bess-evpn-fast-df-recovery/"> Sign in </a> <label class="d-none d-md-block" aria-label="Document search"> <input class="form-control select2-field search-select" id="navbar-doc-search" data-select2-ajax-url="/doc/select2search/document/all/" type="text" data-placeholder="Document search"> </label> </div> <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbar-collapse" aria-controls="navbar-collapse" aria-expanded="false" aria-label="Toggle navigation"> <i class="navbar-toggler-icon"></i> </button> </div> </nav> <main class="pt-3 container-fluid" id="main"> <div class="row"> <div class="col mx-lg-3 ietf-auto-nav" id="content"> <noscript> <div class="alert alert-danger alert-ignore my-3"> <b>Javascript disabled?</b> Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality. </div> </noscript> <h1> Fast Recovery for EVPN Designated Forwarder Election <br> <small class="text-body-secondary">draft-ietf-bess-evpn-fast-df-recovery-12</small> </h1> <ul class="nav nav-tabs my-3"> <li class="nav-item"> <a class="nav-link active" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/"> Status </a> </li> <li class="nav-item"> <a class="nav-link " href="/doc/draft-ietf-bess-evpn-fast-df-recovery/ballot/"> IESG evaluation record </a> </li> <li class="nav-item"> <a class="nav-link " href="/doc/draft-ietf-bess-evpn-fast-df-recovery/writeup/"> IESG writeups </a> </li> <li class="nav-item"> <a class="nav-link " href="/doc/draft-ietf-bess-evpn-fast-df-recovery/email/"> Email expansions </a> </li> <li class="nav-item"> <a class="nav-link " href="/doc/draft-ietf-bess-evpn-fast-df-recovery/history/"> History </a> </li> </ul> <label class="my-1 fw-bold">Versions:</label> <nav class="mb-3"> <ul class="revision-list pagination pagination-sm text-center flex-wrap"> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/00/" > 00 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/01/" rel="nofollow"> 01 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/02/" rel="nofollow"> 02 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/03/" rel="nofollow"> 03 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/04/" rel="nofollow"> 04 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/05/" rel="nofollow"> 05 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/06/" rel="nofollow"> 06 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/07/" rel="nofollow"> 07 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/08/" rel="nofollow"> 08 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/09/" rel="nofollow"> 09 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/10/" rel="nofollow"> 10 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/11/" rel="nofollow"> 11 </a> </li> <li class="page-item active"> <a class="page-link" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/12/" > 12 </a> </li> </ul> </nav> <div id="doc-timeline"></div> <table class="table table-sm table-borderless"> <tbody class="meta align-top border-top"> <tr> <th scope="row">Document</th> <th scope="row">Type</th> <td class="edit"></td> <td> <span class="text-success">Active Internet-Draft</span> (<a href="/wg/bess/about/">bess WG</a>) </td> </tr> <tr> <td></td> <th scope="row">Authors</th> <td class="edit"> </td> <td> <span ><a title="Datatracker profile of Patrice Brissette" href="/person/pbrisset@cisco.com" >Patrice Brissette</a> <a href="mailto:pbrisset%40cisco.com" aria-label="Compose email to pbrisset@cisco.com" title="Compose email to pbrisset@cisco.com"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Ali Sajassi" href="/person/sajassi@gmail.com" >Ali Sajassi</a> <a href="mailto:sajassi%40gmail.com" aria-label="Compose email to sajassi@gmail.com" title="Compose email to sajassi@gmail.com"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Luc Andr茅 Burdet" href="/person/laburdet.ietf@gmail.com" >Luc Andr茅 Burdet</a> <a href="mailto:laburdet.ietf%40gmail.com" aria-label="Compose email to laburdet.ietf@gmail.com" title="Compose email to laburdet.ietf@gmail.com"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of John Drake" href="/person/jdrake@juniper.net" >John Drake</a> <a href="mailto:jdrake%40juniper.net" aria-label="Compose email to jdrake@juniper.net" title="Compose email to jdrake@juniper.net"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Jorge Rabadan" href="/person/jorge.rabadan@nokia.com" >Jorge Rabadan</a> <a href="mailto:jorge.rabadan%40nokia.com" aria-label="Compose email to jorge.rabadan@nokia.com" title="Compose email to jorge.rabadan@nokia.com"> <i class="bi bi-envelope"></i></a></span> </td> </tr> <tr> <td></td> <th scope="row">Last updated</th> <td class="edit"></td> <td> 2024-11-20 </td> </tr> <tr> <td></td> <th scope="row">Replaces</th> <td class="edit"> </td> <td> <a href="/doc/draft-sajassi-bess-evpn-fast-df-recovery/" title="Fast Recovery for EVPN DF Election">draft-sajassi-bess-evpn-fast-df-recovery</a> </td> </tr> <tr> <td></td> <th scope="row"> RFC stream </th> <td class="edit"> </td> <td > Internet Engineering Task Force (IETF) </td> </tr> <tr> <td></td> <th scope="row"> Intended RFC status </th> <td class="edit"> </td> <td> Proposed Standard </td> </tr> <tr> <td></td> <th scope="row"> Formats </th> <td class="edit"> </td> <td> <div class="buttonlist"> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.ietf.org/archive/id/draft-ietf-bess-evpn-fast-df-recovery-12.txt"> <i class="bi bi-file-text"></i> txt </a> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.ietf.org/archive/id/draft-ietf-bess-evpn-fast-df-recovery-12.html"> <i class="bi bi-file-code"></i> html </a> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.ietf.org/archive/id/draft-ietf-bess-evpn-fast-df-recovery-12.xml"> <i class="bi bi-file-code"></i> xml </a> <a class="btn btn-primary btn-sm" href="/doc/html/draft-ietf-bess-evpn-fast-df-recovery-12"> <i class="bi bi-file-code"></i> htmlized </a> <a class="btn btn-primary btn-sm" target="_blank" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/12/bibtex/"> <i class="bi bi-file-ruled"></i> bibtex </a> <a class="btn btn-primary btn-sm" target="_blank" href="/doc/bibxml3/draft-ietf-bess-evpn-fast-df-recovery-12.xml"> <i class="bi bi-file-code"></i> bibxml </a> </div> </td> </tr> <tr> <td></td> <th scope="row"> Reviews </th> <td class="edit"> </td> <td> <div class="review-assignment-summary"> <a href="/doc/review-ietf-bess-evpn-fast-df-recovery-10-opsdir-lc-chown-2024-08-21/"> OPSDIR Last Call review (of -10) by Tim Chown</a> <span class="badge rounded-pill text-bg-warning text-wrap"> <i class="bi bi-exclamation-lg"></i> Has issues </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-bess-evpn-fast-df-recovery-09-intdir-telechat-thaler-2024-08-13/"> INTDIR Telechat review (of -09) by Dave Thaler</a> <span class="badge rounded-pill text-bg-success text-wrap"> <i class="bi bi-"></i> Ready w/nits </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-bess-evpn-fast-df-recovery-09-iotdir-telechat-eckert-2024-08-14/"> IOTDIR Telechat review (of -09) by Toerless Eckert</a> <span class="badge rounded-pill text-bg-warning text-wrap"> <i class="bi bi-exclamation-lg"></i> On the right track </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-bess-evpn-fast-df-recovery-09-rtgdir-telechat-robles-2024-08-19/"> RTGDIR Telechat review (of -09) by Ines Robles</a> <span class="badge rounded-pill text-bg-danger text-wrap"> <i class="bi bi-x-lg"></i> Not ready </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-bess-evpn-fast-df-recovery-09-genart-lc-davies-2024-08-12/"> GENART Last Call review (of -09) by Elwyn Davies</a> <span class="badge rounded-pill text-bg-danger text-wrap"> <i class="bi bi-x-lg"></i> Not ready </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-bess-evpn-fast-df-recovery-07-rtgdir-early-farrel-2023-05-27/"> RTGDIR Early review (of -07) by Adrian Farrel</a> <span class="badge rounded-pill text-bg-warning text-wrap"> <i class="bi bi-exclamation-lg"></i> Has issues </span> </div> </td> </tr> <tr> <td> </td> <th scope="row"> Additional resources </th> <td class="edit"> </td> <td> <a href="https://mailarchive.ietf.org/arch/browse/bess/?q=draft-ietf-bess-evpn-fast-df-recovery"> Mailing list discussion </a> </td> </tr> </tbody> <tbody class="meta border-top"> <tr> <th scope="row"> Stream </th> <th scope="row"> <a href="/doc/help/state/draft-stream-ietf/"> WG state </a> </th> <td class="edit"> </td> <td> <span class=""> Submitted to IESG for Publication </span> </td> </tr> <tr> <td></td> <th scope="row"> Document shepherd </th> <td class="edit"> </td> <td> <span ><a title="Datatracker profile of Matthew Bocci" href="/person/matthew.bocci@nokia.com" >Matthew Bocci</a> <a href="mailto:matthew.bocci%40nokia.com" aria-label="Compose email to matthew.bocci@nokia.com" title="Compose email to matthew.bocci@nokia.com"> <i class="bi bi-envelope"></i></a></span> </td> </tr> <tr> <td></td> <th scope="row"> Shepherd write-up </th> <td class="edit"> </td> <td> <a class="btn btn-primary btn-sm" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/shepherdwriteup/"> Show </a> <span class="badge rounded-pill text-bg-secondary">Last changed 2023-11-29</span> </td> </tr> </tbody> <tbody class="meta border-top"> <tr> <th scope="row"> IESG </th> <th scope="row"> <a href="/doc/help/state/draft-iesg/"> IESG state </a> </th> <td class="edit"> </td> <td> <span class=""> RFC Ed Queue </span> </td> </tr> <tr> <td></td> <th scope="row"> Action Holders </th> <td class="edit"> </td> <td> <div> <span class="text-body-secondary"> (None) </span> </div> </td> </tr> <tr> <td></td> <th scope="row"> Consensus boilerplate </th> <td class="edit"> </td> <td> <span class="text-success" title="Whether the document is the result of a community consensus process as defined in RFC 5741"> Yes </span> </td> </tr> <tr> <td></td> <th scope="row"> Telechat date </th> <td class="edit"> </td> <td> <span class="text-body-secondary"> (None) </span> </td> </tr> <tr> <td></td> <th scope="row"> Responsible AD </th> <td class="edit"> </td> <td> <span ><a title="Datatracker profile of Gunter Van de Velde" href="/person/gunter@vandevelde.cc" >Gunter Van de Velde</a> <a href="mailto:gunter%40vandevelde.cc" aria-label="Compose email to gunter@vandevelde.cc" title="Compose email to gunter@vandevelde.cc"> <i class="bi bi-envelope"></i></a></span> </td> </tr> <tr> <td></td> <th scope="row"> Send notices to </th> <td class="edit"> </td> <td> <a href="mailto:matthew.bocci@nokia.com">matthew.bocci@nokia.com</a> </td> </tr> </tbody> <tbody class="meta border-top"> <tr> <th scope="row"> IANA </th> <th scope="row"> <a href="/doc/help/state/draft-iana-review/"> IANA review state </a> </th> <td class="edit"> </td> <td class="text-danger"> Version Changed - Review Needed </td> </tr> <tr> <th scope="row"> </th> <th scope="row"> <a href="/doc/help/state/draft-iana-action/"> IANA action state </a> </th> <td class="edit"> </td> <td> In Progress </td> </tr> </tbody> <tbody class="meta border-top"> <tr> <th scope="row"> RFC Editor </th> <th scope="row"> <a href="/doc/help/state/draft-rfceditor/"> RFC Editor state </a> </th> <td class="edit"> </td> <td> EDIT </td> </tr> <tr> <td></td> <th scope="row"> Details </th> <td class="edit"> </td> <td> <div> <a href="https://www.rfc-editor.org/queue2.html#draft-ietf-bess-evpn-fast-df-recovery"> Publication queue entry </a> </div> </td> </tr> </tbody> </table> <div class="buttonlist"> <a class="btn btn-primary btn-sm" href="mailto:draft-ietf-bess-evpn-fast-df-recovery@ietf.org?subject=Mail%20regarding%20draft-ietf-bess-evpn-fast-df-recovery"> <i class="bi bi-envelope"> </i> Email authors </a> <a class="btn btn-primary btn-sm" href="mailto:bess@ietf.org?subject=Mail%20regarding%20draft-ietf-bess-evpn-fast-df-recovery"> <i class="bi bi-envelope"> </i> Email WG </a> <a class="btn btn-primary btn-sm" href="/ipr/search/?submit=draft&id=draft-ietf-bess-evpn-fast-df-recovery" rel="nofollow"> <i class="bi bi-lightning"> </i> IPR </a> <a class="btn btn-primary btn-sm" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/references/" rel="nofollow"> <i class="bi bi-arrow-left"> </i> References </a> <a class="btn btn-primary btn-sm" href="/doc/draft-ietf-bess-evpn-fast-df-recovery/referencedby/" rel="nofollow"> <i class="bi bi-arrow-right"> </i> Referenced by </a> <a class="btn btn-primary btn-sm" href="https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-evpn-fast-df-recovery-12.txt" rel="nofollow" target="_blank"> <i class="bi bi-exclamation"> </i> Nits </a> <a class="btn btn-primary btn-sm" href="https://mailarchive.ietf.org/arch/search/?q=%22draft-ietf-bess-evpn-fast-df-recovery%22" rel="nofollow" target="_blank"> <i class="bi bi-search"> </i> Search email archive </a> </div> <div class="card mt-5"> <div class="card-header"> draft-ietf-bess-evpn-fast-df-recovery-12 </div> <div class="card-body"> <pre>BESS Working Group P. Brissette Internet-Draft A. Sajassi Updates: 8584 (if approved) LA. Burdet, Ed. Intended status: Standards Track Cisco Expires: 24 May 2025 J. Drake Independent J. Rabadan Nokia 20 November 2024 Fast Recovery for EVPN Designated Forwarder Election draft-ietf-bess-evpn-fast-df-recovery-12 <span>Abstract</span> The Ethernet Virtual Private Network (EVPN) solution in RFC 7432 provides Designated Forwarder (DF) election procedures for multihomed Ethernet Segments. These procedures have been enhanced further by applying the Highest Random Weight (HRW) algorithm for Designated Forwarder election 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 RFC 8584 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 in BGP between the recovered node and each of the other nodes in the multihoming group. <span>Status of This Memo</span> This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 May 2025. <span>Brissette, et al. Expires 24 May 2025 [Page 1]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> <span>Copyright Notice</span> Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. <span>Table of Contents</span> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Challenges with Existing Mechanism . . . . . . . . . . . 4 1.4. Design Principles for a Solution . . . . . . . . . . . . 5 2. DF Election Synchronization Solution . . . . . . . . . . . . 6 2.1. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Timestamp Verification . . . . . . . . . . . . . . . . . 9 2.3. Updates to RFC8584 . . . . . . . . . . . . . . . . . . . 9 3. Synchronization Scenarios . . . . . . . . . . . . . . . . . . 10 3.1. Concurrent Recoveries . . . . . . . . . . . . . . . . . . 12 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The Ethernet Virtual Private Network (EVPN) solution [RFC7432] is widely used 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. <span>Brissette, et al. Expires 24 May 2025 [Page 2]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> [RFC7432] describes Designated Forwarder (DF) election procedures for multihomed Ethernet Segments. These procedures are enhanced further in [RFC8584] by applying the 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. This document makes further improvements to the DF election procedures in [RFC8584] by providing an option for a fast DF election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. This DF election is achieved independent of the number of EVPN Instances (EVIs) associated with that Ethernet Segment and it is performed via straightforward signaling in BGP between the recovered node and each of the other nodes in the multihomed Ethernet Segment redundancy group. This document updates the DF Election Finite State Machine (FSM) described in Section 2.1 of [RFC8584], by optionally introducing delays between some events, as further detailed in Section 2.3. The solution is based on a simple one-way signaling mechanism. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology PE: Provider Edge device. Designated Forwarder (DF): A PE that is currently forwarding (encapsulating/decapsulating) traffic for a given VLAN in and out of a site. NDF: Non-Designated Forwarder, a PE that is currently blocking traffic (see DF above). EVI: An EVPN instance spanning the Provider Edge (PE) devices participating in that EVPN. HRW: Highest Random Weight algorithm, [HRW98] Service carving: DF Election is also referred to as "service carving" in [RFC7432] SCT: Service Carving Time, defined in this document, the time at <span>Brissette, et al. Expires 24 May 2025 [Page 3]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> which all nodes participating in an Ethernet Segment perform DF Election. 1.3. Challenges with Existing Mechanism In EVPN technology, multiple Provider Edge (PE) devices encapsulate and decapsulate data belonging to the same VLAN. Under certain conditions, this may cause duplicated Ethernet packets and potential loops if there is a momentary overlap in forwarding roles between two or more PE devices, potentially also leading to broadcast storms of frames forwarded back into the VLAN. EVPN [RFC7432] currently specifies timer-based synchronization among PE devices within an Ethernet Segment redundancy group. This approach can lead to duplications and potential loops due to multiple Designated Forwarders (DFs) if the timer interval is too short, or to packet drops if the timer interval is too long. Split-horizon filtering, as described in Section 8.3 of [RFC7432], can prevent loops but does not address duplicates. However, if there are overlapping Designated Forwarders of two different sites simultaneously for the same VLAN, the site identifier will differ when the packet re-enters the Ethernet Segment. Consequently, the split-horizon check will fail, resulting in layer-2 loops. The updated DF procedures outlined in [RFC8584] use the well-known Highest Random Weight (HRW) algorithm to prevent the reshuffling of VLANs among PE devices within the Ethernet Segment redundancy group during failure or recovery events. This approach minimizes the impact on VLANs not assigned to the failed or recovered ports and eliminates the occurrence of loops or duplicates during such events. However, upon PE insertion or a port being newly added to a multihomed Ethernet Segment, HRW cannot help either as a transfer of DF role to the new port must occur while the old DF is still active. <span>Brissette, et al. Expires 24 May 2025 [Page 4]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> +---------+ +-------------+ | | | | | | / | PE1 |----| | +-------------+ / | | | MPLS/ | | |---CE3 / +-------------+ | VxLAN/ | | PE3 | CE1 - | Cloud | | | \ +-------------+ | |---| | \ | | | | +-------------+ \ | PE2 |----| | | | | | +-------------+ | | +---------+ Figure 1: CE1 multihomed to PE1 and PE2. In Figure 1, when PE2 is inserted in the Ethernet Segment or its CE1-facing interface recovered, PE1 will transfer the DF role of some VLANs to PE2 to achieve load balancing. However, because there is no handshake mechanism between PE1 and PE2, overlapping of DF roles for a given VLAN is possible which leads to duplication of traffic as well as layer-2 loops. Current EVPN specifications [RFC7432] and [RFC8584] rely on a timer- 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 1.4. Design Principles for a Solution The clock-synchronization solution for fast DF recovery presented in this document follows several design principles and offers multiple advantages, namely: * Complex handshake signaling mechanisms and state machines are avoided in favor of a simple uni-directional signaling approach. * The fast DF recovery solution maintains backwards compatibility (see Section 4) by ensuring that PEs reject any unrecognized new BGP EVPN Extended Community. * Existing DF Election algorithms remain supported. <span>Brissette, et al. Expires 24 May 2025 [Page 5]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> * The fast DF recovery solution is independent of any BGP delays in propagation of Ethernet Segment routes (Route Type 4) * The fast DF recovery solution is agnostic of the actual time synchronization mechanism used; however, an NTP-based representation of time is used for EVPN signaling. The solution in this document relies on nodes in the topology, more specifically the peering nodes of each Ethernet-Segment, to be clock- synchronized and advertise Time Synchronization capability. When this is not the case, or clocks are badly desynchronized, network convergence and DF Election is no worse than [RFC7432] due to the timestamp range checking (Section 2.2). 2. DF Election Synchronization Solution The fast DF recovery solution relies on the concept of common clock alignment between partner PEs participating in a common Ethernet Segment, i.e., PE1 and PE2 in Figure 1. The main idea is to have all peering PEs of that Ethernet Segment perform DF election and apply the result at the same previously-announced time. The DF Election procedure, as described in [RFC7432] and as optionally signaled in [RFC8584], is applied. All PEs attached to a given Ethernet Segment are clock-synchronized using a networking protocol for clock synchronization (e.g., NTP, PTP). Whenever possible, recovery activities for failed PEs SHOULD NOT be initiated until after the underlying clock synchronization protocol has converged to benefit from this document's fast DF recovery procedures. When a new PE is inserted in an Ethernet Segment or a failed PE of the Ethernet Segment recovers, that PE communicates to peering partners the current time plus the value of the timer for partner discovery from step 2 in Section 8.5 of [RFC7432]. This constitutes an "end time" or "absolute time" as seen from the local PE. That absolute time is called the "Service Carving Time" (SCT). A new BGP EVPN Extended Community, the Service Carving Time is advertised along with the Ethernet Segment Route Type 4 (RT-4) and communicates the Service Carving Time to other partners to ensure an orderly transfer of forwarding duties. Upon receipt of the new BGP EVPN Extended Community, partner PEs can determine the service carving time of the newly inserted PE. To eliminate any potential for duplicate traffic or loops, the concept of skew is introduced: a small time offset to ensure a controlled and orderly transition when multiple Provider Edge (PE) devices are involved. The previously inserted PE(s) must perform service carving first for NDF to DF transitions. The receiving PEs subtract this <span>Brissette, et al. Expires 24 May 2025 [Page 6]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> skew (default = 10ms) to the Service Carving Time and apply NDF to DF transitions first. This is followed shortly by the NDF to DF transitions on both PEs, after the skew delay. On the recovering PE, all services are already in NDF state and no skew for DF to NDF transitions is required. This document proposes a default skew value of 10ms to allow completion of programming the DF to NDF transitions, but implementations may make the skew larger (or configurable) taking into consideration scale, hardware capabilities and clock accuracy. To summarize, all peering PEs perform service carving almost simultaneously at the time announced by the newly added/recovered PE. The newly inserted PE initiates the SCT, and triggers service carving immediately on its local timer expiry. The previously inserted PE(s) receiving Ethernet Segment route (RT-4) with an SCT BGP extended community, perform service carving shortly before Service Carving Time for DF to NDF transitions, and at Service Carving Time for NDF to DF transitions. 2.1. BGP Encoding A BGP extended community, with Type 0x06 and Sub-Type 0x0F, is defined to communicate the Service Carving Time for each Ethernet Segment: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x06 | Sub-Type(0x0F)| Timestamp Seconds ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Timestamp Seconds | Timestamp Fractional Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Service Carving Time The timestamp exchanged uses the NTP prime epoch of January 1, 1900 [RFC5905] and an adapted form of the 64-bit NTP Timestamp Format. The 64-bit NTP Timestamp Format consists of a 32-bit part for Seconds and a 32-bit part for Fraction, which are encoded in the Service Carving Time as follows: * Timestamp Seconds: 32-bit NTP seconds are encoded in this field. * Timestamp Fractional Seconds: the high order 16 bits of the NTP 'Fraction' field are encoded in this field. <span>Brissette, et al. Expires 24 May 2025 [Page 7]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> When rebuilding a 64-bit NTP Timestamp Format using the values from a received SCT BGP extended community, the lower order 16 bits of the Fractional field are set to 0. The use of a 16-bit fractional seconds value yields adequate precision of 15 microseconds (2^-16 s). This document introduces a new flag called Time Synchronization indicated by "T" in the DF Election Capabilities registry defined in [RFC8584] for use in DF Election Extended Community. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x06 | Sub-Type(0x06)| RSV | DF Alg | Bitmap ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Bitmap | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: DF Election Extended Community Figure 3: DF Election Extended Community 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |A| |T| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: DF Election Capabilities Figure 4: DF Election Capabilities * Bit 3: Time Synchronization (corresponds to Bit 27 of the DF Election Extended Community). When set to 1, it indicates the desire to use Time Synchronization capability with the rest of the PEs in the Ethernet Segment. This capability is utilized in conjunction with the agreed-upon DF Election Type. For instance, if all the PE devices in the Ethernet Segment indicate the desire to use the Time Synchronization capability and request the DF Election Type to be Highest Random Weight (HRW), then the HRW algorithm is used in conjunction with this capability. A PE which does not support the procedures set out in this document, or receives a route from another PE in which the capability is not set, MUST NOT delay Designated Forwarder election as this could lead to duplicate traffic in some instances (overlapping Designated Forwarders). <span>Brissette, et al. Expires 24 May 2025 [Page 8]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> 2.2. Timestamp Verification The NTP Era value is not exchanged and participating PEs may consider the timestamps to be in the same Era as their local value. A DF Election operation occurring exactly at the next Era transition will be sometime on February 7, 2036. Implementors and operators may address credible cases of rollover ambiguity (adjacent Eras n and n+1), as well as the security issue of unreasonably large or unreasonably small NTP timestamps, in the following manner. The procedures in this document address implicitly what occurs with receiving a SCT value in the past. This would be a naturally occurring event with a large BGP propagation delay: the receiving PE treats the DF Election at the peer as having occurred already and proceeds without starting any timer to further delay service carving, effectively falling back on [RFC7432] behavior. A PE which receives a SCT value smaller than its current time, MUST discard the Service Carving Time and SHALL treat the DF Election at the peer as having occurred already. The more problematic scenario is the PE in Era n+1 which receives a Service Carving Time advertised by the PE still in Era n, with a very large SCT value. To address this Era rollover as well as the large values attack vector, implementations MUST validate the received SCT against an upper-bound. It is left to implementations to decide what constitutes an "unreasonably large" SCT value. A recommended approach, however, is to compare the received offset to the local peering timer value. In practice, peering timer values are configured uniformly across Ethernet-Segment peers and may be treated as an upper-bound on the offset of received SCT values. A PE which receives an SCT representing an offset larger than the local peering timer MUST discard the Service Carving Time and SHALL treat the DF Election at the peer as having occurred already, as above. 2.3. Updates to RFC8584 This document introduces an additional delay to the events and transitions defined for the default DF election algorithm FSM in Section 2.1 of [RFC8584] without changing the FSM state or event definitions themselves. Upon receiving a RCVD_ES message, the peering PE's Finite State Machine (FSM) transitions from the DF_DONE (indicating the DF election process was complete) state to the DF_CALC (indicating that a new DF calculation is needed) state. Due to the Service Carving Time (SCT) included in the Ethernet-Segment update, the completion of the DF_CALC state and the subsequent transition back to the DF_DONE <span>Brissette, et al. Expires 24 May 2025 [Page 9]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> state are delayed. This delay ensures proper synchronization and prevents conflicts. Consequently, the accompanying forwarding updates to the Designated Forwarder (DF) and Non-Designated Forwarder (NDF) states are also deferred. Item 9. in Section 2.1 of [RFC8584], the list "Corresponding actions when transitions are performed or states are entered/exited" is changed as follows: 9. DF_CALC on CALCULATED: Mark the election result for the VLAN or VLAN Bundle. 9.1 If an SCT timestamp is present during the RCVD_ES event of Action 11, wait until the time indicated by the SCT minus skew before proceeding to step 9.3. 9.2 If an SCT timestamp is present during the RCVD_ES event of Action 11, wait until the time indicated by the SCT before proceeding to step 9.4. 9.3 Assume the role of NDF for the local PE concerning the VLAN or VLAN Bundle, and transition to the DF_DONE state. 9.4 Assume the role of DF for the local PE concerning the VLAN or VLAN Bundle, and transition to the DF_DONE state. This revised approach ensures proper timing and synchronization in the DF election process, avoiding conflicts and ensuring accurate forwarding updates. 3. Synchronization Scenarios Consider Figure 1 as an example, where initially PE2 has failed and PE1 has taken over. This scenario illustrates the problem with the DF-Election mechanism described in Section 8.5 of [RFC7432], specifically in the context of the timer value configured for all PEs on the Ethernet Segment. Procedure based on Section 8.5 of [RFC7432] with the default 3-second timer in step 2: 1. Initial state: PE1 is in a steady-state and PE2 is recovering. 2. Recovery: PE2 recovers at an absolute time of t=99. 3. Advertisement: PE2 advertises RT-4, sent at t=100, to partner PE1. <span>Brissette, et al. Expires 24 May 2025 [Page 10]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> 4. Timer Start: PE2 starts a 3-second timer to allow the reception of RT-4 from other PE nodes. 5. Immediate carving: PE1 performs service carving immediately upon RT-4 reception, i.e., t=100 plus some BGP propagation delay. 6. Delayed Carving: PE2 performs service carving at time t=103. [RFC7432] favors traffic drops over duplicate traffic. With the above procedure, traffic drops will occur as part of each PE recovery sequence since PE1 transitions some VLANs to Non-Designated Forwarder (NDF) immediately upon RT-4 reception. The timer value (default = 3 seconds) directly affects the duration of the packet drops. A shorter (or zero) timer may result in duplicate traffic or traffic loops. Procedure based on the Service Carving Time (SCT) approach: 1. Initial state: PE1 is in a steady state, and PE2 is recovering. 2. Recovery: PE2 recovers at an absolute time of t=99. 3. Timer Start: PE2 starts at t=100 a 3-second timer to allow the reception of RT-4 from other PE nodes. 4. Advertisement: PE2 advertises RT-4, sent at t=100, with a target SCT value of t=103 to partner PE1. 5. Service Carving Timer: PE1 starts the service carving timer, with the remaining time until t=103. 6. Simultaneous Carving: Both PE1 and PE2 carve at an absolute time of t=103. To maintain the preference for minimal loss over duplicate traffic, PE1 SHOULD carve slightly before PE2 (with skew). The recovering PE2 performs both DF to NDF and NDF to DF transitions per VLAN at the timer's expiry. The original PE1, which received the SCT, applies the following: * DF to NDF Transition(s): at t=SCT minus skew, where both PEs are NDF for the skew duration. * NDF to DF Transition(s): at t=SCT. This split-behavior ensures a smooth DF role transition with minimal loss. <span>Brissette, et al. Expires 24 May 2025 [Page 11]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> Using the SCT approach, the negative effect of the timer to allow the reception of Ethernet Segment RT-4 from other PE nodes is mitigated. Furthermore, the BGP transmission delay (from PE2 to PE1) of the ES RT-4 becomes a non-issue. The SCT approach shortens the 3-second timer window to the order of milliseconds. The peering timer is a configurable value where 3 seconds represents the default. Configuring a timer value of 0, or so small as to expire during propagation of the BGP routes, is outside the scope of this document. In reality, the use of the SCT approach presented in this document encourages the use of larger peering timer values to overcome any sort of BGP route propagation delays. 3.1. Concurrent Recoveries In the eventuality 2 or more PEs in a peering Ethernet Segment group are recovering concurrently or roughly the same time, each will advertise a Service Carving Time. This SCT value would correspond to what each recovering PE considers the "end time" for DF Election. A similar situation arises in sequentially recovering PEs, when a second PE recovers approximately at the time of the first PE's advertised SCT expiry, and with its own new SCT-2 outside of the initial SCT window. In the case of multiple concurrent DF elections, each initiated by one of the recovering PEs, the SCTs must be ordered chronologically. All PEs SHALL execute only a single DF Election at the service carving time corresponding to the largest (latest) received timestamp value. This DF Election will lead peering PEs into a single co- ordinated DF Election update. Example: 1. Initial State: PE1 is in a steady state, with services elected at PE1. 2. Recovery of PE2: PE2 recovers at time t=100 and advertises RT-4 with a target SCT value of t=103 to its partners (PE1). 3. Timer Initiation by PE2: PE2 starts a 3-second timer to allow the reception of RT-4 from other PE nodes. 4. Timer Initiation by PE1: PE1 starts the service carving timer, with the remaining time until t=103. 5. Recovery of PE3: PE3 recovers at time t=102 and advertises RT-4 with a target SCT value of t=105 to its partners (PE1, PE2). <span>Brissette, et al. Expires 24 May 2025 [Page 12]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> 6. Timer Initiation by PE3: PE3 starts a 3-second timer to allow the reception of RT-4 from other PE nodes. 7. Timer Update by PE2: PE2 cancels the running timer and starts the service carving timer with the remaining time until t=105. 8. Timer Update by PE1: PE1 updates its service carving timer, with the remaining time until t=105. 9. Service Carving: PE1, PE2, and PE3 perform service carving at the absolute time of t=105. In the eventuality a PE in an Ethernet Segment group recovers during the discovery window specified in Section 8.5 of [RFC7432], and does not support or advertise the T-bit, then all PEs in the current peering sequence SHALL immediately revert to the default [RFC7432] behavior. 4. Backwards Compatibility For the DF election procedures to achieve global convergence and unanimity within a redundancy group, it is essential that all participating PEs agree on the DF election algorithm to be employed. However, it is possible that some PEs may continue to use the existing modulo-based DF election algorithm from [RFC7432] and not utilize the new Service Carving Time (SCT) BGP extended community. PEs that operate using the baseline DF election mechanism will simply discard the new SCT BGP extended community as unrecognized. A PE can indicate its willingness to support clock-synchronized carving by signaling the new 'T' DF Election Capability and including the new SCT BGP extended community along with the Ethernet Segment Route Type 4. If one or more PEs attached to the Ethernet Segment do not signal T=1, then all PEs in the Ethernet Segment SHALL revert to the timer-based approach as specified in [RFC7432]. This reversion is particularly crucial in preventing VLAN shuffling when more than two PEs are involved. In the event a new or extra RT-4 is received without the new 'T' DF Election Capability in the midst of an ongoing DF Election sequence, all SCT-based delays are cancelled and the DF Election immediately applied as specified in [RFC7432], as if no SCT had been previously exchanged. <span>Brissette, et al. Expires 24 May 2025 [Page 13]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> 5. Security Considerations The mechanisms in this document use the EVPN control plane as defined in [RFC7432]. Security considerations described in [RFC7432] are equally applicable. For the new SCT Extended Community, attack vectors may be setting the value to zero, to a value in the past or to large times in the future. Handling of this attack vector is addressed in Section 2.2 alongside NTP Era rollover ambiguity. This document uses MPLS and IP-based tunnel technologies to support data plane transport. Security considerations described in [RFC7432] and in [RFC8365] are equally applicable. 6. IANA Considerations IANA maintains the "EVPN Extended Community Sub-Types" registry set up by [RFC7153], where the following assignment has been made: Sub-Type Value Name Reference -------------- ------------------------- ------------- 0x0F Service Carving Time This document 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 ---- ---------------- ------------- 3 Time Synchronization This document 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>. <span>Brissette, et al. Expires 24 May 2025 [Page 14]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, <https://www.rfc-editor.org/info/rfc7153>. [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, March 2018, <https://www.rfc-editor.org/info/rfc8365>. [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet VPN Designated Forwarder Election Extensibility", RFC 8584, DOI 10.17487/RFC8584, April 2019, <https://www.rfc-editor.org/info/rfc8584>. 7.2. Informative References [HRW98] Thaler, D. and C. Ravishankar, "Using Name-Based Mappings to Increase Hit Rates", 1998, <https://www.microsoft.com/en-us/research/wp-content/ uploads/2017/02/HRW98.pdf>. <span>Appendix A. Contributors</span> In addition to the authors listed on the front page, the following co-authors have also contributed substantially to this document: Gaurav Badoni Cisco Email: gbadoni@cisco.com Dhananjaya Rao Cisco Email: dhrao@cisco.com <span>Brissette, et al. Expires 24 May 2025 [Page 15]</span> <span>Internet-Draft Fast Recovery for EVPN DF-Election November 2024</span> <span>Appendix B. Acknowledgements</span> Authors would like to acknowledge helpful comments and contributions of Satya Mohanty and Bharath Vasudevan. Also thank you to Anoop Ghanwani and Gunter van de Velde for their thorough review with valuable comments and corrections. <span>Authors' Addresses</span> Patrice Brissette Cisco Email: pbrisset@cisco.com Ali Sajassi Cisco Email: sajassi@cisco.com Luc Andre Burdet (editor) Cisco Email: lburdet@cisco.com John Drake Independent Email: je_drake@yahoo.com Jorge Rabadan Nokia Email: jorge.rabadan@nokia.com <span>Brissette, et al. Expires 24 May 2025 [Page 16]</span> </pre> </div> </div> </div> </div> </main> <footer class="col-md-12 col-sm-12 border-top mt-5 py-5 bg-light-subtle text-center position-sticky"> <a href="https://www.ietf.org/" class="p-3">IETF</a> <a href="https://www.ietf.org/iesg/" class="p-3">IESG</a> <a href="https://www.iab.org/" class="p-3">IAB</a> <a href="https://www.irtf.org/" class="p-3">IRTF</a> <a href="https://www.ietf.org/llc/" class="p-3 text-nowrap">IETF LLC</a> <a href="https://trustee.ietf.org/" class="p-3 text-nowrap">IETF Trust</a> <a href="https://www.rfc-editor.org/" class="p-3 text-nowrap">RFC Editor</a> <a href="https://www.iana.org/" class="p-3">IANA</a> <a href="https://www.ietf.org/privacy-statement/" class="p-3 text-nowrap">Privacy Statement</a> <div class="small text-body-secondary py-3"> <a class="mx-2" href="/release/about">About IETF Datatracker</a> <span class="mx-2"> <a href="https://github.com/ietf-tools/datatracker/releases/tag/12.28.2"> Version 12.28.2 (release - 7ecf23e) </a> </span> <a class="mx-2" href="https://status.ietf.org" target="_blank">System Status</a> <span class="mx-2 text-danger"> <i class="bi bi-bug"></i> Report a bug: <a class="text-reset" target="_blank" href="https://github.com/ietf-tools/datatracker/issues/new/choose">GitHub</a> <a class="text-reset" href="mailto:tools-help@ietf.org">Email</a> </span> </div> </footer> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/d3.js"> </script> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/document_timeline.js"> </script> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/select2.js"></script> <script> $('#navbar-doc-search').on('select2:select', function (e) { window.location.href = e.params.data.url; }); </script> <script type="text/javascript"> var _paq = window._paq || []; _paq.push(['disableCookies']); _paq.push(['trackPageView']); _paq.push(['enableLinkTracking']); (function() { var u="//analytics.ietf.org/"; _paq.push(['setTrackerUrl', u+'matomo.php']); _paq.push(['setSiteId', 7]); var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0]; g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s); })(); </script> <noscript><p><img src="//analytics.ietf.org/piwik.php?idsite=7" style="border:0;" alt="" /></p></noscript> <script>(function(){function c(){var b=a.contentDocument||a.contentWindow.document;if(b){var d=b.createElement('script');d.innerHTML="window.__CF$cv$params={r:'8e9362b3c99cce35',t:'MTczMjcyMzc5Ny4wMDAwMDA='};var a=document.createElement('script');a.nonce='';a.src='/cdn-cgi/challenge-platform/scripts/jsd/main.js';document.getElementsByTagName('head')[0].appendChild(a);";b.getElementsByTagName('head')[0].appendChild(d)}}if(document.body){var a=document.createElement('iframe');a.height=1;a.width=1;a.style.position='absolute';a.style.top=0;a.style.left=0;a.style.border='none';a.style.visibility='hidden';document.body.appendChild(a);if('loading'!==document.readyState)c();else if(window.addEventListener)document.addEventListener('DOMContentLoaded',c);else{var e=document.onreadystatechange||function(){};document.onreadystatechange=function(b){e(b);'loading'!==document.readyState&&(document.onreadystatechange=e,c())}}}})();</script></body> </html>

CINXE.COM

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