RFC 7882

Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases 💖

okay so this RFC is all about S-BFD, a streamlined version of BFD that skips a ton of the negotiation so sessions come up way faster 🦋 It's an Informational doc from the IETF, published July 2016 (RFC 7882, ISSN 2070-1721). The authors are S. Aldrin from Google, Inc., C. Pignataro and N. Kumar from Cisco, and G. Mirsky from Ericsson. The header doesn't list any RFCs this one obsoletes or updates, so it stands on its own 🌸

Abstract ✨

okay bestie, the abstract is the TL;DR: this doc lays out the use cases for S-BFD and the requirements that protocol mechanisms need so forwarding failures are easier to detect 🔍

these use cases are the reason S-BFD exists. It's a simplified way of using BFD where most of the negotiation is gone, so a BFD session gets established much faster 🚀 The big perks are quick provisioning and better control and flexibility for the network nodes that start path monitoring 💅

Status of This Memo 🎀

reminder: this is not a standards track spec. It's published for information only 📚

this doc is a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is eligible for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious about that 🧐

for the latest status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7882 🔗

Copyright Notice 🌈

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stood on the publication date. Please actually read them, because they spell out your rights and restrictions for this document 📜 Code components pulled out of this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💜

Table of Contents 🧚

1. Introduction ....................................................3
   1.1. Terminology ................................................3
   2. Introduction to Seamless BFD ....................................4
   3. Use Cases .......................................................5
      3.1. Unidirectional Forwarding Path Validation ..................5
      3.2. Validation of the Forwarding Path prior to
           Switching Traffic ..........................................6
      3.3. Centralized Traffic Engineering ............................7
      3.4. BFD in Centralized Segment Routing .........................8
      3.5. Efficient BFD Operation under Resource Constraints .........8
      3.6. BFD for Anycast Addresses ..................................8
      3.7. BFD Fault Isolation ........................................9
      3.8. Multiple BFD Sessions to the Same Target Node ..............9
      3.9. An MPLS BFD Session per ECMP Path .........................10
   4. Detailed Requirements for Seamless BFD .........................11
   5. Security Considerations ........................................12
   6. References .....................................................12
      6.1. Normative References ......................................12
      6.2. Informative References ....................................13
   Acknowledgements ..................................................15
   Contributors ......................................................15
   Authors' Addresses ................................................15

1. Introduction ✨

okay so BFD, defined in [RFC5880], is a lightweight protocol for detecting forwarding failures 🛡️ A bunch of protocols, apps, and clients depend on it for failure detection. It's simple and light, but some use cases need sessions to set up faster and need quicker continuity checks on data-forwarding paths 🏃‍♀️ This doc identifies those use cases and the requirements that come with them, so that enhancements and extensions can turn into a Seamless BFD (S-BFD) protocol 🦋

BFD is a simple, lightweight "Hello" protocol for finding data-plane failures ✨ Once forwarding paths get dynamically provisioned at a large scale, setting up a BFD session for every single path is a mess. It's operationally complicated and also causes annoying delays when sessions get set up or torn down 😭 So the existing session establishment mechanism has to be beefed up to shrink the time it takes for a session to come up and validate the forwarding path 💪

this doc goes through specific use cases and their requirements to make BFD and other supporting protocols better 💅 The main goal is to kill the time delay (the "seam") between when a network node wants to run a continuity test and when it finishes that test 🎯 That's why the mechanism is called "Seamless BFD" (S-BFD) 🌸

the requirements here could cover a bunch of use cases, but listing every possible requirement is outside this doc's scope 🙈 Solutions for these use cases, plus protocol-specific enhancements and proposals, are also out of scope. Protocol definitions that support these use cases live in [RFC7880] and [RFC7881] 📖

1.1. Terminology 🧠

you're expected to already know the BFD [RFC5880], IP [RFC791] [RFC2460], MPLS [RFC3031], and Segment Routing [SR-ARCH] terms and protocol constructs 🤓

the key words in this doc are as follows, and they're to be read as described in [RFC2119]:

"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL"

2. Introduction to Seamless BFD 🌷

so BFD, as defined in [RFC5880], needs two network nodes to swap locally allocated discriminators 🔁 Those discriminators let each side tell who's sending and who's receiving BFD packets for a given session. After that, BFD does proactive continuity monitoring of the forwarding path between the two 👀 A few specs cover BFD's different deployment uses:

• [RFC5881] defines BFD over IPv4 and IPv6 for single IP hops.
• [RFC5883] defines BFD over multi-hop paths.
• [RFC5884] defines BFD for MPLS Label Switched Paths (LSPs).
• [RFC5885] defines BFD for MPLS Pseudowires (PWs).

right now BFD is best at checking that two endpoints can reach each other, or that an existing connection is still up and alive 🤝 But for BFD to initially confirm that a connection is valid and really links the expected endpoints, each endpoint has to get the discriminators tied to that connection before it starts BFD sessions 📬 Those discriminators are what verify the connection is up and valid. Right now, how discriminators get exchanged and how the initial BFD packets get demultiplexed both depend on the application 😤

if the endpoints of a potential BFD session already know this info, the initial handshake (including the discriminator exchange) isn't needed, and the endpoints can start BFD messaging seamlessly ✨ A key goal of the S-BFD use cases is to skip exchanging those initial packets before the session can be established, so it reaches the established state faster. Put simply, the initial discriminator exchange is an unnecessary extra step in these cases and can be avoided 🙅‍♀️

in a given scenario, some entity (like an operator or a centralized controller) figures out which network entities might need BFD sessions 🧩 In traditional BFD, each of those entities picks a BFD Discriminator for every session it takes part in (see Section 6.3 of [RFC5880]). But S-BFD is all about operational simplification 💖 So for S-BFD, each network entity gets one or more BFD Discriminators, and those entities can reuse one discriminator value across multiple sessions. That means a node might only have one or a few discriminators assigned to it 🌈 These entities create an S-BFD listener session instance that listens for incoming BFD Control packets 👂

here's the cool part: once the mappings between network entities and their BFD Discriminators are known to other nodes in the same administrative domain, a network entity can send a BFD Control packet to a target's assigned discriminator in the Your Discriminator field without having received any BFD packets from that target first 🤯 When the target node gets that BFD Control packet, it sends a response BFD Control packet back to the sender 📨

3. Use Cases 🦋

so per the BFD protocol [RFC5880], BFD sessions get set up with a handshake before the forwarding path is validated 🤝 This section covers use cases where that existing mechanism can't meet the requirements 🙃 Some of these use cases also really need expedited BFD session establishment, while still keeping the forwarding failure detection benefits of the existing BFD mechanisms 💅 Both of these high-level goals lead to the S-BFD use cases in this document, which is what we're getting into next 🫶

3.1. Unidirectional Forwarding Path Validation

okay bestie, so sometimes you only need to check the path in ONE direction between two nodes 🦋 like when a static route uses BFD to check that the next-hop IP router is reachable. the static route goes from one network entity to another, so the only path that needs validating is that one-way path. checking the way back, from the target to the originating entity, is NOT needed here 🙅‍♀️ and yeah, lots of LSPs act this way too, super common in Segment Routing and LDP-based MPLS networks ✨ the last example is a unidirectional tunnel using BFD to check that the egress node is reachable 🌸

and the operational side is so real 😭 with traditional BFD, the target entity AND the initiator both have to be provisioned, even though the reverse-path check isn't required. but with unidirectional BFD there's no provisioning on the target at all, only on the source 💅

so here's how it goes: a BFD session can be set up in just one direction 🎀 when the target gets the packet, it recognizes it as BFD in an application-specific way (for example, by destination UDP port number) 🧚 then the BFD module processes it using the Your Discriminator value as context, and the target sends a response back to the originator. no bidirectional session needed, so the two-way handshake to swap discriminators isn't needed either 💀 and the target doesn't need to know the source's My Discriminator value. iconic 👑

so the big requirements for this use case are: BFD has to let a session get set up from the source entity to the target entity WITHOUT needing a session (and its state) for the reverse direction 💖 and the BFD response from the target back to the sender can take ANY path, in-band or out-of-band 🌈 the BFD module on the target, once it gets a BFD packet, starts processing it based on the discriminator it received. so the source can set up a unidirectional BFD session with no bidirectional handshake and no discriminator exchange for session setup. main character energy ✨

3.2. Validation of the Forwarding Path prior to Switching Traffic

okay so in this use case, BFD checks reachability BEFORE any traffic gets sent over a path/LSP 🌸 but there's a catch 🙈 traffic can't use the path/LSP until BFD has validated reachability, and that could take seconds because of BFD session bring-up sequences [RFC5880], LSP Ping bootstrapping [RFC5884], etc. ngl that's a lot of waiting 😭 this use case would be better served by getting rid of the need for the initial BFD session negotiation altogether 💅

here's the thing: all it takes for BFD packets to reach a target and for the target to demultiplex them properly is for the source network entities to know which Discriminator values will be used for the session 🦋 the same goes for S-BFD, where the three-way handshake is skipped entirely during BFD session bootstrapping 🎀 but each entity still needs this info to verify that BFD messages are coming from the expected endpoints, so the handshake mechanism literally serves no purpose 💀 cutting out that unnecessary handshake means faster reachability validation for BFD-provisioned paths/LSPs ⚡

also, some MPLS technologies are going to need traffic-engineered LSPs created dynamically, maybe driven by external applications like in Software-Defined Networking (SDN) 🧚 it'll be really desirable to run BFD validation as soon as those LSPs are created, so they can be used right away 💖

so to support this, an S-BFD session gets set up with NO session negotiation and NO discriminator exchange 🫶

3.3. Centralized Traffic Engineering

okay so there's this whole SDN vibe where the intelligence that used to live in a distributed, dynamic control plane gets pulled out of the networking devices and put in a (logically) centralized place 🌈 controllers handle setting up forwarding paths for data flows, and traffic engineering is a big one 👑 that's where the path of a traffic flow is engineered based on its attributes and constraints as well as the current network state 💅

when the network's brain is centralized, keeping track of the dynamic network, all its data paths, and node reachability gets really hard 😭 one way to make sure forwarding paths are valid and working is to validate them with BFD 🦋 when traffic-engineered tunnels get created, it's operationally critical to confirm the forwarding paths work BEFORE switching traffic onto them 🫶 without distributed control-plane protocols, it may be desirable to verify ANY arbitrary forwarding path in the network 🧚 and when the network state changes, traffic has to move with minimum latency and without black-holing the data 💀

in this centralized traffic-engineering use case, it's HIGHLY desirable that traditional BFD session establishment and forwarding path validation don't turn into a bottleneck 🔥 if the controller can verify a traffic-engineered tunnel's forwarding path super fast, it can steer traffic onto that tunnel quickly and minimize bad effects on a service ✨ this matters even more as the network scales and the number of traffic-engineered tunnels grows 🌸

the time it takes to negotiate BFD sessions and establish them to identify valid paths is VERY costly when network redundancy is a critical issue 😭

3.4. BFD in Centralized Segment Routing

there's a monitoring technique for a Segment Routing network based on a centralized controller, described in [SR-MPLS] 🦋 the specific Operations, Administration, and Maintenance (OAM) requirements for Segment Routing are captured in [SR-OAM-REQS] 💖 when validating this use case, one requirement is that the BFD packet's behavior follows the monitoring specified for the segment, AND that the packet is U-turned at the expected node 🙈 that criterion is what makes sure the continuity check to the adjacent Segment Identifier works 🫶

so to support this, the operational requirement is that BFD, initiated from a centralized controller, performs liveness detection for any given segment in its domain 🌈

3.5. Efficient BFD Operation under Resource Constraints

okay so whenever BFD sessions get set up, torn down, or modified (like when intervals and multipliers change), BFD needs extra packets on top of the scheduled transmissions to finish the negotiation 🎀 those are the Poll (P) bits and Final (F) bits, see Section 4.1 of [RFC5880] 🧚

now, network resources can be seriously constrained 😭 a node might need BFD to monitor a HUGE number of paths, or BFD might have to run in low-powered, traffic-sensitive networks like microwave systems, low-powered nanocells, and others 🍓 in those cases it's really desirable for BFD to slow down, speed up, stop, or resume at will, with as few extra BFD packets exchanged as possible to modify a session or set up a new one 💅

and the established BFD session parameters, like the transmission interval and receiver interval, need to be modifiable WITHOUT changing the state of the session ✨

3.6. BFD for Anycast Addresses

okay so the BFD protocol needs two endpoints hosting BFD sessions, both sending packets to each other 💜 that model doesn't really vibe with anycast address monitoring 😭 because BFD packets sent from a network node to an anycast address only reach ONE of the potentially many nodes hosting that address 🙈

this use case checks that a source node can send a packet to an anycast address AND that the target node receiving it can send a response packet back to the source 🦋 traditional BFD can't do this, since it has no way for a set of BFD agents to collectively act as one endpoint of a session 💀 the "target listener" concept in S-BFD covers exactly that 👑

to support this, the BFD sender transmits BFD packets that get received by any node hosting the anycast address they're sent to, and whichever anycast target receives the packet responds 🌸 this doesn't mean a BFD session has to be set up with every node hosting the anycast address 🫶 so target nodes that don't happen to receive any BFD packets don't need to keep any state, and the source doesn't need separate state for each target node 🧚

3.7. BFD Fault Isolation

okay so BFD for multi-hop paths [RFC5883] and BFD for MPLS LSPs [RFC5884] do end-to-end validation across multiple network nodes 🌈 BFD is designed to declare a failure after not receiving some number of consecutive packets, and that failure can be caused by a fault ANYWHERE along the path ⚡ fast failure detection means fast fault detection and fast path recovery 💖

but operators often have to follow up, by hand or automatically, to figure out and localize the fault that made the BFD session fail (that's fault isolation) 😭 if Equal-Cost Multipath (ECMP) is in use, other tools for isolating the fault (like traceroute) might send packets down a different path through the network 🙈 and the longer it takes from the BFD failure to when fault isolation starts, the more likely the fault won't be isolated at all, since it might get fixed by rerouting or something else in the meantime 💀 if BFD had built-in fault-isolation capability, fault isolation would kick off the moment the fault was first detected 🔥 that embedded version would work better (faults detected sooner) if its fault-isolation packets were load-balanced the same way as the BFD packets that got dropped 🫶

this use case describes S-BFD fault-isolation capabilities, using a TTL field (like the one described in Section 5.1.1 of [RFC7881]) or fields that indicate status 🦋

3.8. Multiple BFD Sessions to the Same Target Node 🎀

okay so BFD is literally SO fast at spotting failures 🏃💨 because the relevant nodes keep blasting BFD packets at the negotiated rate. If those packets stop, even for a tiny moment, BFD can declare a failure whether or not the path is actually dead 😭. On a system running BFD, certain events can cause a brief pause in packet transmission, on purpose or by accident 🙈. With distributed BFD architectures, that pause can be prevented ✨. This use case is for an S-BFD node running several BFD sessions to the same target node, with those sessions living on different system modules (like different CPU instances) 🧩. The payoff is fewer false alarms and a more stable network 💖.

To pull this off, a mapping between the multiple discriminators on a single system and the specific entity within that system is required 🎀.

3.9. An MPLS BFD Session per ECMP Path 🦋

so [RFC5884] is the one that defines running BFD as an in-band continuity check for LSPs, using MPLS Echo Request messages [RFC4379] to bootstrap the BFD session on the target (i.e., egress) node 🧚. Section 4 of [RFC5884] also describes running multiple BFD sessions per alternative of LSPs. Then [RFC7726] clarifies the procedures for both ingress and egress nodes, covering how to bootstrap, maintain, and remove multiple BFD sessions for the same <MPLS LSP, FEC> tuple ("FEC" means Forwarding Equivalence Class). Still, this approach needs MPLS LSP Ping for bootstrapping, round trips for initialization, and state kept at the receiver 🙄.

Now, with ECMP inside an MPLS LSP, it may be giving to run in-band monitoring that exercises every path of that ECMP 👑. Otherwise you get the nightmare where an in-band BFD session stays up through one path while traffic is black-holing over another path 💀. A BFD session per ECMP path of an LSP needs procedures that update [RFC5884], spelling out how to bootstrap and maintain the correct set of BFD sessions on the egress node. The problem is that traditional BFD needs constant MPLS Echo Request messages to create and delete those sessions on the egress node whenever the ECMP paths and/or the corresponding load-balance hash keys change 😩. If a BFD session over any LSP path could be instantiated, stopped, and resumed without extra bootstrapping through an MPLS Echo Request message, it would greatly simplify implementations and operations 🫶. Network devices would benefit too, since they'd have less processing to do.

To support this, multiple S-BFD sessions need to be established over different ECMP paths between the same pair of source and target nodes 🌈.

4. Detailed Requirements for Seamless BFD 📋

• REQ 1: When an S-BFD packet arrives, a target network entity (for the S-BFD session) MUST process it based on the discriminator in the BFD packet. If the S-BFD context is found, the target network entity MUST be able to send a response.
• REQ 2: The source network entity MUST be able to set up a unidirectional S-BFD session without the bidirectional handshake of discriminators for session establishment.
• REQ 3: The S-BFD session MUST be able to be established without needing to exchange discriminators during session negotiation.
• REQ 4: In a Segment Routed network, S-BFD MUST be able to do liveness detection initiated from a centralized controller for any given segment in its domain.
• REQ 5: The established S-BFD session parameters and attributes, such as transmission interval and reception interval, MUST be modifiable without changing the state of the session.
• REQ 6: An S-BFD source network entity MUST be able to send Control packets to an anycast address. Those packets are received and processed by any node hosting that anycast address. The S-BFD entity MUST be able to receive responses to S-BFD Control packets from any of these anycast nodes, without setting up a separate S-BFD session with every node hosting the anycast address.
• REQ 7: S-BFD SHOULD support fault-isolation capability, which MAY be triggered when a fault is encountered.
• REQ 8: S-BFD SHOULD be able to establish multiple sessions between the same pair of source and target nodes. This enables, but doesn't guarantee, the ability to monitor divergent paths in ECMP environments. It also provides resiliency in distributed router architectures. The mapping between BFD Discriminators and particular entities (e.g., ECMP paths, line cards) is out of scope for the S-BFD protocol.
• REQ 9: The S-BFD protocol MUST provide mechanisms for loop detection and prevention, protecting against malicious attacks trying to create packet loops.
• REQ 10: S-BFD MUST incorporate robust security protections against impersonators, malicious actors, and various active and passive attacks. The simple and accelerated establishment of an S-BFD session should not negatively affect security.

5. Security Considerations 🔐

this section is SERIOUS, bestie 🚨 read it all.

so this doc walks through the use cases for S-BFD and lists the requirements tied to them, and some of those requirements are about security 🛡️. The use cases described here don't expose a system to abuse or extra security risks ✨. BUT, since some negotiation steps are gone, a misconfiguration can send S-BFD packets to the wrong node 😱. If that receiving node runs S-BFD, the packet gets discarded because of a discriminator mismatch 🙌. If the node doesn't run S-BFD, the packet just gets naturally discarded 🍃.

The proposed new protocols, extensions, and enhancements for S-BFD that support these use cases and realize these requirements will deal with the related security considerations 💅. S-BFD should not have reduced security capabilities compared to traditional BFD 🔒.

6. References 📚

6.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,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
           (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
           <http://www.rfc-editor.org/info/rfc5880>.

[RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
           (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
           DOI 10.17487/RFC5881, June 2010,
           <http://www.rfc-editor.org/info/rfc5881>.

[RFC5883]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
           (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
           June 2010, <http://www.rfc-editor.org/info/rfc5883>.

[RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
           "Bidirectional Forwarding Detection (BFD) for MPLS Label
           Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
           June 2010, <http://www.rfc-editor.org/info/rfc5884>.

[RFC5885]  Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional
           Forwarding Detection (BFD) for the Pseudowire Virtual
           Circuit Connectivity Verification (VCCV)", RFC 5885,
           DOI 10.17487/RFC5885, June 2010,
           <http://www.rfc-editor.org/info/rfc5885>.

6.2. Informative References

[RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
           DOI 10.17487/RFC791, September 1981,
           <http://www.rfc-editor.org/info/rfc791>.

[RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
           December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
           Label Switching Architecture", RFC 3031,
           DOI 10.17487/RFC3031, January 2001,
           <http://www.rfc-editor.org/info/rfc3031>.

[RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
           Label Switched (MPLS) Data Plane Failures", RFC 4379,
           DOI 10.17487/RFC4379, February 2006,
           <http://www.rfc-editor.org/info/rfc4379>.

[RFC7726]  Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S.
           Aldrin, "Clarifying Procedures for Establishing BFD
           Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726,
           DOI 10.17487/RFC7726, January 2016,
           <http://www.rfc-editor.org/info/rfc7726>.

[RFC7880]  Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
           Pallagatti, "Seamless Bidirectional Forwarding Detection
           (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
           <http://www.rfc-editor.org/info/rfc7880>.

[RFC7881]  Pignataro, C., Ward, D., and N. Akiya, "Seamless
           Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6,
           and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016,
           <http://www.rfc-editor.org/info/rfc7881>.

[SR-ARCH]  Filsfils, C., Ed., Previdi, S., Ed., Decraene, B.,
           Litkowski, S., and R. Shakir, "Segment Routing
           Architecture", Work in Progress,
           draft-ietf-spring-segment-routing-09, July 2016.

[SR-MPLS]  Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N.
           Kumar, "A Scalable and Topology-Aware MPLS Dataplane
           Monitoring System", Work in Progress,
           draft-ietf-spring-oam-usecase-03, April 2016.

[SR-OAM-REQS]
           Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
           and S. Litkowski, "OAM Requirements for Segment Routing
           Network", Work in Progress,
           draft-ietf-spring-sr-oam-requirement-02, July 2016.

Acknowledgements 🙏

the authors want to thank Tobias Gondrom and Eric Gray for their insightful and useful comments 🥰. They also appreciate the thorough review and comments from Dale R. Worley 👏.

Contributors 🌸

the following are key contributors to this document 💜:

• Manav Bhatia, Ionos Networks
• Satoru Matsushima, Softbank
• Glenn Hayden, ATT
• Santosh P K
• Mach Chen, Huawei
• Nobo Akiya, Big Switch Networks

Authors' Addresses 💌

Sam Aldrin
Google, Inc.

Email: aldrin.ietf@gmail.com


Carlos Pignataro
Cisco Systems, Inc.

Email: cpignata@cisco.com


Greg Mirsky
Ericsson

Email: gregory.mirsky@ericsson.com


Nagendra Kumar
Cisco Systems, Inc.

Email: naikumar@cisco.com