RFC 9722
Fast Recovery for EVPN Designated Forwarder Election
📖 RFC 9722: Fast Recovery for EVPN Designated Forwarder Election ✨
Okay bestie, let's get into it 🎀 This one is an Internet Standards Track doc (so it's the real deal, not a brainstorm 💅) from the IETF, published May 2025. It is Updates: RFC 8584, which means it tweaks some of 8584's DF election stuff, and it doesn't obsolete anything 🦋
Authors: P. Brissette, A. Sajassi, LA. Burdet (Ed.) from Cisco, J. Drake (Independent), and J. Rabadan from Nokia 🌸
ISSN: 2070-1721 🧚
Abstract ✨
Okay so the EVPN solution in RFC 7432 has Designated Forwarder (DF) election procedures for multihomed Ethernet Segments 💜 Those got an upgrade in RFC 8584, which uses the Highest Random Weight (HRW) algorithm so DF status doesn't flip around for no reason when something fails 🙌 This doc is the next level: it gives you a fast DF election when the failed link or node comes back up, which is so iconic 👑
It's an update to RFC 8584 that optionally adds delays between some of its events. The whole thing works no matter how many EVPN Instances (EVIs) are on that Ethernet Segment, and it's done with simple signaling in BGP between the recovered node and every other node in the multihoming group 💅
Status of This Memo ✨
This is an Internet Standards Track document 🎀
It's a product of the Internet Engineering Task Force (IETF), so it represents IETF community consensus. It went through public review and got approved by the Internet Engineering Steering Group (IESG). More on Internet Standards is in Section 2 of RFC 7841 🌈
Want the current status, errata, or a way to send feedback? Head to https://www.rfc-editor.org/info/rfc9722 💖
Copyright Notice ✨
Copyright (c) 2025 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) as they stand on the publication date. Read them carefully, because they spell out your rights and restrictions for this doc 🙈 Code Components pulled out of this document have to include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes 💅
Table of Contents 🦋
- 1. Introduction
- 1.1. Requirements Language
- 1.2. Terminology
- 1.3. Challenges with Existing Mechanism
- 1.4. Design Principles for a Solution
- 2. DF Election Synchronization Solution
- 2.1. BGP Encoding
- 2.2. Timestamp Verification
- 2.3. Updates to RFC 8584
- 3. Synchronization Scenarios
- 3.1. Concurrent Recoveries
- 4. Backwards Compatibility
- 5. Security Considerations
- 6. IANA Considerations
- 7. References
- 7.1. Normative References
- 7.2. Informative References
- Acknowledgements
- Contributors
- Authors' Addresses
1. Introduction 🌸
The EVPN solution in [RFC7432] is hugely popular in data center (DC) land for Network Virtualization Overlay (NVO) and Data Center Interconnect (DCI) services 💖 Service providers use it too, for next-gen virtual private LAN services 🧚
[RFC7432] spells out the DF election procedures for multihomed Ethernet Segments 🎀 Then [RFC8584] levels them up by using the HRW algorithm for DF election, so there are fewer unnecessary DF status changes when a link or node fails 🦋
This doc makes more improvements to the DF election procedures in [RFC8584] by offering a fast DF election when the failed link or node on that multihomed Ethernet Segment recovers 🚀 The election works regardless of how many EVIs are on that Ethernet Segment, and it's done with straightforward BGP signaling between the recovered node and every other node in the multihomed Ethernet Segment redundancy group 💅
This doc updates the DF Election Finite State Machine (FSM) from Section 2.1 of [RFC8584] by optionally adding delays between some events. Details are 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
- DF: Designated Forwarder. 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: EVPN Instance. It spans the PE devices participating in that EVPN.
- HRW: Highest Random Weight algorithm [HRW98]
- Service carving: This refers to DF election, as defined in [RFC7432].
- SCT: Service Carving Time. Defined in this document as the time at which all nodes participating in an Ethernet Segment perform DF Election.
1.3. Challenges with Existing Mechanism 😭
In EVPN, multiple PE devices encapsulate and decapsulate data from the same VLAN. Under certain conditions this can cause duplicated Ethernet packets and loops if two or more PE devices have a momentary overlap in forwarding roles. It could even lead to broadcast storms of frames getting forwarded back into the VLAN 💀
[RFC7432] currently uses timer-based synchronization among PE devices in an Ethernet Segment redundancy group. That can cause duplicates and loops because of multiple DFs if the timer interval is too short, or packet drops if it's too long 🙈
Split-horizon filtering, from Section 8.3 of [RFC7432], can prevent loops but doesn't handle duplicates. Also, if two different sites have overlapping DFs for the same VLAN at the same time, the site identifier will be different when the packet re-enters the Ethernet Segment. So the split-horizon check fails and you get Layer 2 loops 😱
The updated DF procedures in [RFC8584] use the well-known HRW algorithm to stop VLANs from getting reshuffled among PE devices in the Ethernet Segment redundancy group during failure or recovery events. This keeps the impact small on VLANs not tied to the failed or recovered ports, and it stops loops and duplicates during those events 🦋
Still, when a PE is inserted or a port is newly added to a multihomed Ethernet Segment, HRW can't help. The DF role has to move to the new port while the old DF is still active 🥺
+---------+
+-------------+ | |
| | | |
/ | PE1 |----| | +-------------+
/ | | | MPLS/ | | |---CE3
/ +-------------+ | VxLAN/ | | PE3 |
CE1 - | Cloud | | |
\ +-------------+ | |---| |
\ | | | | +-------------+
\ | PE2 |----| |
| | | |
+-------------+ | |
+---------+
Figure 1: CE1 Multihomed to PE1 and PE2In Figure 1, when PE2 gets inserted into the Ethernet Segment or its CE1-facing interface recovers, PE1 moves the DF role for some VLANs over to PE2 to balance the load. But since PE1 and PE2 have no handshake mechanism, the DF roles for a given VLAN can overlap. That causes duplicated traffic and Layer 2 loops 🌀
The current EVPN specs ([RFC7432] and [RFC8584]) rely on a timer-based approach for handing the DF role to the newly inserted device, and that can cause these problems:
- Loops and duplicates, if the timer value is too short 😵
- Prolonged traffic loss, if the timer value is too long 😢
1.4. Design Principles for a Solution 🌟
The clock-synchronization solution for fast DF recovery in this document follows several design principles and comes with a bunch of advantages 👑 Here they are:
- Complex handshake signaling mechanisms and state machines are avoided in favor of a simple unidirectional signaling approach 💅
- The fast DF recovery solution keeps backwards compatibility (see Section 4) by making sure PEs reject any unrecognized new BGP EVPN Extended Community 🛡️
- Existing DF Election algorithms are still supported 🙌
- The fast DF recovery solution doesn't depend on any BGP delays in propagating Ethernet Segment routes (Route Type 4) 🚀
- The fast DF recovery solution doesn't care which time synchronization mechanism you use. But an NTP-based representation of time is used for EVPN signaling ⏰
The solution here relies on nodes in the topology (specifically the peering nodes of each Ethernet Segment) to be clock-synchronized and to advertise the Time Synchronization capability. If that's not the case, or the clocks are badly desynchronized, then network convergence and DF Election are no worse than what [RFC7432] describes, thanks to the timestamp range checking in Section 2.2 🫧
Part 1 of 3 is done, bestie 🎀 Part 2 is coming with Section 2 and onward 💖
2. DF Election Synchronization Solution ✨
okay bestie, so the fast DF recovery solution runs on common clock alignment between partner PEs that share an Ethernet Segment 🫶 think PE1 and PE2 in Figure 1. The main vibe is that every peering PE on that Ethernet Segment runs DF election and applies the result at the same previously announced time ⏰
The DF Election procedure from [RFC7432] gets applied, and it can also be signaled the optional way from [RFC8584] 💅 All the PEs attached to a given Ethernet Segment get clock-synchronized with a networking clock sync protocol, like NTP or Precision Time Protocol (PTP) 🕰️ Whenever possible, recovery for failed PEs SHOULD NOT be kicked off until the underlying clock sync protocol has converged, so you get the fast DF recovery perks from this doc 🙈
Here's the flow: when a new PE gets inserted into an Ethernet Segment, or a failed PE of that segment comes back, it tells its peering partners the current time plus the partner discovery timer from step 2 in Section 8.5 of [RFC7432]. That's an "end time" or "absolute time" from the local PE's point of view, and it's called the Service Carving Time (SCT) 🎀
A brand new BGP EVPN Extended Community, the Service Carving Time, rides along with the Ethernet Segment Route Type 4 (RT-4). It tells the other partners the SCT so everyone hands off forwarding duties in an orderly way 🦋
When partner PEs get that new Extended Community, they can figure out the SCT of the newly inserted PE. To kill any chance of duplicate traffic or loops, there's this idea of skew, a small time offset that keeps transitions controlled and orderly when a bunch of PE devices are involved 🌈 The previously inserted PE(s) must perform service carving first for NDF to DF transitions. The receiving PEs subtract this skew (default = 10 ms) from the Service Carving Time and apply NDF to DF transitions first. The NDF to DF transitions on both PEs follow shortly after, once the skew delay has passed. On the recovering PE, all services are already in NDF state, so no skew is needed for DF to NDF transitions 💜
This document proposes a default skew of 10 ms, which gives enough room to finish programming the DF to NDF transitions. Implementations may make the skew larger (or configurable), depending on scale, hardware capabilities, and clock accuracy ✨
So to sum it up: all the peering PEs do service carving almost at the same time, at the moment the newly added or recovered PE announced. The new PE starts the SCT and triggers service carving as soon as its local timer expires 🔥 The previously inserted PE(s) that receive the Ethernet Segment route (RT-4) with an SCT BGP extended community do service carving shortly before the SCT for DF to NDF transitions, and right at the SCT 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 SCT 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 Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Service Carving TimeThe timestamp exchanged uses the NTP prime epoch of 0 h 1 January 1900 UTC [RFC5905] and an adapted form of the 64-bit NTP timestamp format 🕰️
The 64-bit NTP timestamp format is a 32-bit unsigned seconds field plus a 32-bit fraction field. Here's how they get encoded into the Service Carving Time:
Timestamp Seconds: 32-bit NTP seconds are encoded in this field.Timestamp Fraction: The high-order 16 bits of the NTP "Fraction" field are encoded in this field.
When you rebuild a 64-bit NTP timestamp from the values in a received SCT BGP extended community, the lower-order 16 bits of the NTP "Fraction" field get set to 0. A 16-bit fractional seconds value gives you adequate precision of 15 microseconds (2^-16 s) 🎯
The DF Election Extended Community used in this document is formatted like this:
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 3: DF Election Extended Community (RFC 8584)The Bitmap field (2 octets) encodes "capabilities" [RFC8584], and this document introduces a brand new Time Synchronization capability, marked with "T" 💖
1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |A| |T| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Bitmap Field in the DF Election Extended Community- Bit 3: Time Synchronization (corresponds to Bit 27 of the DF Election Extended Community). When set to 1, it means the PE wants to use the Time Synchronization capability with the rest of the PEs in the Ethernet Segment 🌸
This capability gets used together with the agreed-upon DF Election Type. For example, if all the PE devices in the Ethernet Segment want the Time Synchronization capability and ask for the DF Election Type to be HRW, then the HRW algorithm gets used along with this capability 🧁
A PE that does not support the procedures set out in this document, or that receives a route from another PE in which the capability is not set, MUST NOT delay DF election. Delaying could lead to duplicate traffic in some instances (overlapping DFs), so don't be that PE 🚫
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 happening exactly at the next Era transition will be some time 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 implicitly handle receiving an SCT value in the past. This is a naturally occurring event with a large BGP propagation delay. The receiving PE treats the DF Election at the peer as already having occurred and proceeds without starting any timer to further delay service carving, which basically falls back on the behavior specified in [RFC7432] 🔙 A PE that receives an 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 that receives an SCT 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's left to implementations to decide what counts as an "unreasonably large" SCT value. A recommended approach, though, is to compare the received offset to the local peering timer value. In practice, peering timer values are configured uniformly across Ethernet Segment peers, so they may be treated as an upper bound on the offset of received SCT values 📏 A PE that receives an SCT representing an offset larger than the local peering timer MUST discard the SCT and SHALL treat the DF Election at the peer as having already occurred, same as above 🙅♀️
2.3. Updates to RFC 8584
This document adds an additional delay to the events and transitions defined for the default DF election algorithm FSM in Section 2.1 of [RFC8584]. It does this without changing the FSM state or event definitions themselves 🧠
When a peering PE receives an RCVD_ES message, its FSM transitions from the DF_DONE state (meaning the DF election process was complete) to the DF_CALC state (meaning a new DF calculation is needed). Because of the SCT included in the Ethernet Segment update, the completion of the DF_CALC state and the transition back to the DF_DONE state get delayed. This delay keeps everything synchronized and prevents conflicts. As a result, the accompanying forwarding updates to the DF and NDF states get deferred too ⏳
Item 9 in Section 2.1 of [RFC8584], in 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 no Service Carving Time is present during the RCVD_ES
| event of Action 11, proceed to step 9.4
|
| 9.2 If a Service Carving Time 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.3 Assume the role of NDF for the local PE concerning the
| VLAN or VLAN bundle. Wait the remaining skew time before
| proceeding to step 9.4.
|
| 9.4 Assume the election result's role (DF or NDF) for the
| local PE concerning the VLAN or VLAN bundle and
| transition to the DF_DONE state.This revised approach keeps the timing and synchronization in the DF election process on track, avoiding conflicts and making sure the forwarding updates are accurate 🎀
Okay bestie, I'm going to be honest, this part is wild. We're hitting the timing stuff that makes the whole thing click 🕰️💖 Let's go!
3. Synchronization Scenarios ✨
Okay so picture Figure 1 🎀: PE2 has failed and PE1 has taken over the whole vibe 👑. This is the scenario that shows the problem with the DF Election mechanism from Section 8.5 of [RFC7432] 💅, specifically when you look at the timer value that's set for every PE on the Ethernet Segment ⏱️.
The old-school procedure is based on Section 8.5 of [RFC7432], with the default 3-second timer in step 2 🍓.
- Initial state: PE1 is in a steady-state and PE2 is recovering 🌸.
- Recovery: PE2 recovers at an absolute time of t=99 ✨.
- Advertisement: PE2 advertises RT-4, sent at t=100, to its partner (PE1) 📣.
- Timer Start: PE2 starts a 3-second timer so it can catch the RT-4 from the other PE nodes 👀.
- Immediate carving: PE1 performs service carving immediately upon RT-4 reception, i.e., t=100 plus some BGP propagation delay 😭.
- Delayed Carving: PE2 performs service carving at time t=103 💀.
Here's the tea 🫖: [RFC7432] favors traffic drops over duplicate traffic. With that procedure, traffic drops happen during every PE recovery sequence, because PE1 flips some VLANs to an NDF right away when it gets RT-4 🙈. The timer value (default = 3 seconds) directly decides how long those packet drops last. A shorter timer (or a zero one) might cause duplicate traffic or traffic loops 🌀. Not me getting a loop just because the timer got too small 💅.
The SCT approach goes like this 🦋:
- Initial state: PE1 is in a steady state, and PE2 is recovering 🌸.
- Recovery: PE2 recovers at an absolute time of t=99 ✨.
- Timer Start: PE2 starts at t=100 a 3-second timer so it can catch the RT-4 from the other PE nodes ⏱️.
- Advertisement: PE2 advertises RT-4, sent at t=100, with a target SCT value of t=103 to its partner (PE1) 📣.
- Service Carving Timer: PE1 starts the service carving timer, with the remaining time until t=103 ⏳.
- Simultaneous Carving: Both PE1 and PE2 carve at an absolute time of t=103 🎯.
To keep the preference for minimal loss over duplicate traffic, PE1 SHOULD carve slightly before PE2 (with skew) 🫶. The recovering PE2 does both DF-to-NDF and NDF-to-DF transitions per VLAN when the timer expires. The original PE1, which got 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 gives a smooth DF role transition with minimal loss, and it's giving perfection 🧚.
The SCT approach takes care of the annoying problem of needing a timer to discover the Ethernet Segment (ES) RT-4 from other PE nodes 😤. On top of that, the BGP transmission delay (from PE2 to PE1) of the ES RT-4 becomes a non-issue 🙌. The SCT approach shrinks that 3-second timer window down to milliseconds, iykyk ⚡.
The peering timer is configurable, and 3 seconds is the default ⏲️. Configuring a timer of 0, or one so small that it expires while the BGP routes are still propagating, is outside the scope of this document 🚫. Honestly, the SCT approach actually encourages larger peering timer values so any BGP route propagation delays get covered 🌈.
3.1. Concurrent Recoveries 🌀
Sometimes two or more PEs in a peering Ethernet Segment group recover at the same time, or roughly the same time 👯. Each one advertises an SCT 📣. That SCT value is what each recovering PE thinks the "end time" for DF Election should be 🏁. A similar thing happens with sequentially recovering PEs, when a second PE recovers around the time the first PE's advertised SCT expires and has its own new SCT-2 outside of the initial SCT window 😳.
When there are multiple concurrent DF elections, each started by one of the recovering PEs, the SCTs MUST be ordered chronologically. Hmm wait, let me be careful here, bestie: the original says these SHALL be ordered, so the word is SHALL. All PEs SHALL execute only a single DF Election at the service carving time that matches the largest (latest) received timestamp value 🕐. This one DF Election pulls the peering PEs into a single coordinated DF Election update 🤝.
Example:
- Initial State: PE1 is in a steady state, with services elected at PE1 🏠.
- Recovery of PE2: PE2 recovers at time t=100 and advertises RT-4 with a target SCT value of t=103 to its partner (PE1) 📣.
- Timer Initiation by PE2: PE2 starts a 3-second timer so it can catch the RT-4 from the other PE nodes ⏱️.
- Timer Initiation by PE1: PE1 starts the service carving timer, with the remaining time until t=103 ⏳.
- 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) 🎉.
- Timer Initiation by PE3: PE3 starts a 3-second timer so it can catch the RT-4 from the other PE nodes ⏱️.
- Timer Update by PE2: PE2 cancels the running timer and starts the service carving timer with the remaining time until t=105 🔄.
- Timer Update by PE1: PE1 updates its service carving timer, with the remaining time until t=105 🔄.
- Service Carving: PE1, PE2, and PE3 perform service carving at the absolute time of t=105 🎯.
Now, if a PE in an Ethernet Segment group recovers during the discovery window from Section 8.5 of [RFC7432] and doesn't support or advertise the T-bit, then all PEs in the current peering sequence SHALL immediately go back to the default behavior described in [RFC7432] 🔙. Bestie, that's the safety net 🧯.
4. Backwards Compatibility 🤝
For the DF election procedures to reach global convergence and unanimity inside a redundancy group, it is essential that all participating PEs agree on the DF election algorithm they use 💯. But some PEs may keep using the existing modulo-based DF election algorithm from [RFC7432] and not use the new SCT BGP extended community 🫠. PEs running the baseline DF election mechanism will simply discard the new SCT BGP extended community as unrecognized 🗑️. Totally fine, no drama 🌷.
A PE can say it's willing 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 fall back to the timer-based approach specified in [RFC7432] ⏪. This reversion is super crucial for preventing VLAN shuffling when more than two PEs are involved 🚫🔀.
If a new or extra RT-4 shows up without the new "T" DF Election Capability in the middle of an ongoing DF Election sequence, all SCT-based delays get canceled, and the DF Election is applied immediately as specified in [RFC7432], as if no SCT had been exchanged before 🛑. Main character energy for the default behavior 👑.
5. Security Considerations 🔐
Okay, security time, and I'm not playing 😤. The mechanisms in this document use the EVPN control plane as defined in [RFC7432]. The security considerations described in [RFC7432] are equally applicable 🛡️.
For the new SCT Extended Community, the attack vectors may be setting the value to zero, to a value in the past, or to large times in the future 🚨. How this attack vector is handled is covered in Section 2.2, alongside NTP Era rollover ambiguity 🕰️. Literally the scariest timestamp drama 💀.
This document uses MPLS- and IP-based tunnel technologies to support data plane transport. The security considerations described in [RFC7432] and [RFC8365] are equally applicable 🔒.
6. IANA Considerations 📋
IANA has made the following assignment in the "EVPN Extended Community Sub-Types" registry set up by [RFC7153] 🗂️:
+================+======================+===========+
| Sub-Type Value | Name | Reference |
+================+======================+===========+
| 0x0F | Service Carving Time | RFC 9722 |
+----------------+----------------------+-----------+
Table 1IANA has made the following assignment in the "DF Election Capabilities" registry set up by [RFC8584] 🏷️:
+=====+======================+===========+
| Bit | Name | Reference |
+=====+======================+===========+
| 3 | Time Synchronization | RFC 9722 |
+-----+----------------------+-----------+
Table 27. 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>.
[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", IEEE/ACM Transactions on Networking, vol. 6, no. 1, February 1998, <https://www.microsoft.com/en-us/research/wp- content/uploads/2017/02/HRW98.pdf>.
Acknowledgements 🫶
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 💖.
Contributors 🌟
In addition to the authors listed on the front page, the following coauthors have also contributed substantially to this document:
Gaurav Badoni
Cisco
Email: gbadoni@cisco.com
Dhananjaya Rao
Cisco
Email: dhrao@cisco.comAuthors' Addresses 📮
Patrice Brissette
Cisco
Email: pbrisset@cisco.com
Ali Sajassi
Cisco
Email: sajassi@cisco.com
Luc André Burdet (editor)
Cisco
Email: lburdet@cisco.com
John Drake
Independent
Email: je_drake@yahoo.com
Jorge Rabadan
Nokia
Email: jorge.rabadan@nokia.com📦 where this page comes from
- ietf: rfc9722 2025-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms