RFC 9819
Argument Signaling for BGP Services in Segment Routing over IPv6 (SRv6)
RFC 9819: Argument Signaling for BGP Services in Segment Routing over IPv6 (SRv6) 🦋
Okay bestie, here's the title block first 💖 It's a Standards Track doc from the IETF, published July 2025.
- Authors: K. Talaulikar (Cisco Systems), K. Raza (Cisco Systems), J. Rabadan (Nokia), and W. Lin (Juniper Networks) ✨
- Category: Standards Track
- ISSN: 2070-1721
- Date: July 2025
- Updates: RFC 9252 🎀 (this one is basically a glow-up for 9252)
- Obsoletes: nothing listed in the header
Abstract 🌸
RFC 9252 defines the procedures and messages for BGP overlay services over SRv6, including L3VPN, EVPN, and global Internet routing. This document updates RFC 9252 and gives more detailed specs for how SRv6 Segment Identifier advertisements get signaled and processed for BGP overlay service routes tied to SRv6 Endpoint Behaviors that take arguments 🧚
Status of This Memo 📜
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🙈
For the current status of this document, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9819 💅
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. Please read these carefully, because they describe your rights and restrictions for this document. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License ⚖️
Table of Contents 🗂️
1. Introduction
1.1. Requirements Language
2. Advertisement of SRv6 SID and Arguments
3. End.DT2M Signaling for EVPN ESI Filtering
3.1. Advertisement of Ethernet A-D per ES Route
3.2. Advertisement of Inclusive Multicast Ethernet Tag Route
3.3. Processing at Ingress PE
4. Backward Compatibility
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction ✨
Okay so SRv6 is Segment Routing running over the IPv6 data plane [RFC8402] 🦋 An SRv6 Segment Identifier (SID) [RFC8402] can be tied to one of the service-specific SRv6 Endpoint Behaviors on the advertising Provider Edge (PE) router. That covers L3VPN, global Internet routing, and Ethernet VPN (EVPN) services, as defined in [RFC8986]. These SRv6 SIDs are called SRv6 Service SIDs. [RFC9252] is the one that defines the procedures and messages for signaling BGP overlay services over SRv6, including L3VPN, EVPN, and Internet services 💖
Now for the EVPN drama 🍓 Section 4.12 of [RFC8986] brought in the End.DT2M SRv6 Endpoint Behavior, which uses an argument (aka Arg.FE2). Then [RFC9252] came along and specified how the SRv6 SID and its argument get encoded and signaled. The SID goes in the Inclusive Multicast Ethernet Tag route (EVPN Route Type 3), and the argument goes in the Ethernet A-D (Auto-Discovery) per ES route (EVPN Route Type 1). But here's the tea: during implementation and interoperability testing, people noticed that the specs in [RFC9252] aren't detailed enough. That leads to ambiguity in how to interpret and implement them 😭
So this document updates [RFC9252] with extra details and clarifications on signaling SRv6 Service SIDs tied to Endpoint Behaviors that use arguments 🫶 The main focus is End.DT2M signaling via the Ethernet A-D per ES route and the Inclusive Multicast Ethernet Tag route. But the procedures here also apply to other similar SRv6 Endpoint Behaviors with arguments that might get signaled using BGP, so it's not a one-behavior show 👑
Section 6.3 of [RFC9252] says the SRv6 Service SID used in the data plane is derived by doing a bitwise logical-OR between the SID with an argument (signaled via the Ethernet A-D per ES route) and the SID with the 'Locator + Function' components (signaled via the Inclusive Multicast Ethernet Tag route). But that approach assumes every SID advertised through those two routes has the same SID structure. That assumption isn't always true, and the procedures in this document remove that restriction, so SRv6 SID signaling gets way more flexible ✨
The descriptions and examples in this document don't use the Transposition Scheme (see Section 4 of [RFC9252]). So the Transposition Offset (TPOS-O) and Transposition Length (TPOS-L) are set to zero, and any references to MPLS label fields where the function or argument parts might be transposed are left out. The same examples could still be applied with the Transposition Scheme, though. This document doesn't change how the Transposition Scheme is used when signaling EVPN routes. Implementations are expected to follow the procedures and recommendations in [RFC9252] about the Transposition Scheme 🌈
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 🙈
2. Advertisement of SRv6 SID and Arguments 💅
Section 3.1 of [RFC8986] defines the format of an SRv6 SID as three components: Locator (LOC), Function (FUNC), and Argument (ARG) 🍓 For SRv6 SIDs tied to Endpoint Behaviors that don't support arguments, the ARG component isn't there. So all bits after the FUNC portion MUST be set to zero, and the Argument Length (AL) MUST be zero. No arg, no drama ✨
Some Endpoint Behaviors (like End.DT2M) do support arguments 🦋 As specified in Section 3.2.1 of [RFC9252], the SRv6 SID Structure Sub-Sub-TLV MUST be included when signaling an SRv6 SID that corresponds to an Endpoint Behavior supporting an argument. That way, the receiving router can check that the argument is consistent and correctly encode the ARG value inside the SRv6 SID 💖
Sometimes the SRv6 SID is signaled as a complete structure, with LOC:FUNC:ARG fully encoded inside the SID 🧚 But there are also cases where only the LOC:FUNC portion gets signaled in one advertisement, and the ARG value comes in a separate advertisement or through some other mechanism. In that case, it's the job of the SRv6 source node to append the ARG component to the LOC:FUNC portion, which builds the complete SRv6 SID (LOC:FUNC:ARG). That fully formed SID can then be used in the data plane, either as the IPv6 destination address of a packet or as a segment inside the Segment Routing Header (SRH) [RFC8754], depending on what's needed 👑
Since arguments may be optional, the SRv6 endpoint node that owns the SID MUST advertise the SRv6 SID Structure Sub-Sub-TLV along with the LOC:FUNC portion of the SRv6 SID. That's how it signals whether arguments are supported for that specific SID. A zero AL value means the node doesn't accept an argument for that SRv6 SID. A non-zero AL value, on the other hand, gives the size of the supported argument. It also comes with the Locator Block Length (LBL), Locator Node Length (LNL), and Function Length (FL) parameters, which define the offset where the node expects the ARG to be encoded. All bits beyond LBL + LNL + FL + AL MUST be set to zero 🫶
The ARG value can be advertised either by the node that owns the SRv6 SID and advertises the LOC:FUNC portion of it, or by another node or mechanism. Either way, the advertisement of the ARG value MUST specify the size of the argument, its value, and the associated SRv6 Endpoint Behavior of the SID 💜 Also, specifying how the ARG advertisement maps to the corresponding SID(s) it applies to is REQUIRED. No guessing games here 🔥
3. End.DT2M Signaling for EVPN ESI Filtering 🌸
As specified in [RFC9252], the LOC:FUNC portion of the SRv6 SID with End.DT2M behavior is signaled via the Inclusive Multicast Ethernet Tag route. Meanwhile, the Ethernet Segment Identifier (ESI) Filtering ARG (called Arg.FE2 in [RFC8986]) is signaled via the Ethernet A-D per ES route 🧚 The subsections below give a more detailed spec of the signaling and processing mechanisms compared to [RFC9252] ✨
ESI Filtering is a split-horizon mechanism used for multihoming [RFC7432] or Ethernet-Tree (E-Tree) procedures [RFC8317] 🦋 ESI Filtering is not applicable in these scenarios:
- No E-Tree leaf Broadcast, Unknown Unicast, or Multicast (BUM) traffic exists,
- No multihoming is present,
- No split-horizon mechanism is required, or
- The "Local Bias" method (as specified in [RFC8365]) is employed.
In this document, "ESI Filtering" is a general reference to the procedure the disposition Provider Edge (PE) router performs to stop BUM traffic from being forwarded to local Ethernet Segments or local leaf attachment circuits. That decision is based on whether the ESI Filtering ARG is present 💖
The signaling and processing descriptions in the following sections also apply to End.DT2M behavior flavors designed for SRv6 SID list compression [RFC9800] 🍓 In deployments that mix compressed and uncompressed SIDs, the behaviors advertised in the Ethernet A-D per ES routes and Inclusive Multicast Ethernet Tag routes MAY consist of a combination of compressed and uncompressed End.DT2M behavior flavors. The procedures in this document stay valid for those deployments, as long as the AL consistency checks between the Ethernet A-D per ES route and the Inclusive Multicast Ethernet Tag route (described in the following subsections) are satisfied 👑
3.1. Advertisement of Ethernet A-D per ES Route 💖
okay so Ethernet A-D per ES routes, as defined in [RFC7432] 🎀, are used to enable split-horizon filtering and fast convergence in multihoming scenarios 🌸. And bestie, they also help with egress filtering of BUM traffic coming from a leaf, as specified in [RFC8317] ✨. Main character energy for sure 💅
When ESI Filtering is not in use, no ESI Filtering ARG is required to be conveyed 🦋. BUT, for backward compatibility and consistency with [RFC9252] 🫶, the advertisement of this route SHOULD include the BGP Prefix-SID attribute with an SRv6 L2 Service TLV carrying an SRv6 Service SID set to ::0 in the SRv6 SID Information Sub-TLV 🧚, with the SRv6 Endpoint Behavior set to End.DT2M. Since End.DT2M supports an ARG, an SRv6 SID Structure Sub-Sub-TLV MUST be included 💜. Since no ARG value is needed here, the AL MUST be set to 0 🍓.
Here's what it looks like 👀:
BGP Prefix-SID attribute:
SRv6 L2 Service TLV:
SRv6 SID Information Sub-TLV:
SID: ::
Behavior: End.DT2M
SRv6 SID Structure Sub-Sub-TLV:
LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0Figure 1: Ethernet A-D per ES Route Without ARG for ESI Filtering 🌈
When ESI Filtering IS in use 🔥, the advertisement of this route MUST include the BGP Prefix-SID attribute with an SRv6 L2 Service TLV carrying the SRv6 Service SID that contains the ESI Filtering ARG value within the SRv6 SID Information Sub-TLV (when not using the Transposition Scheme) 👑, with the SRv6 Endpoint Behavior set to End.DT2M. End.DT2M supports an ARG, so an SRv6 SID Structure Sub-Sub-TLV MUST be included 🙈. Additionally, since a non-zero ARG value is being signaled, the AL MUST be set to the size of the ARG, and the size SHOULD be a multiple of 8 to keep things consistent across implementations and easy to operate ⭐. The SRv6 SID Structure Sub-Sub-TLV MUST set the LBL, LNL, and FL fields to values that indicate the offset where the ARG value is encoded within the 128-bit SRv6 SID 🦋.
Example time! This one is for a 16-bit argument value of 'aaaa' 💅:
BGP Prefix-SID attribute:
SRv6 L2 Service TLV:
SRv6 SID Information Sub-TLV:
SID: ::aaaa:0:0:0
Behavior: End.DT2M
SRv6 SID Structure Sub-Sub-TLV:
LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0Figure 2: Ethernet A-D per ES Route with ARG for ESI Filtering 🌸
Okay, so in the examples above, it would have been possible to set the LBL, LNL, and FL values to 0 and to encode the SRv6 SID as either ::0 or aaaa::. 🙈 But ngl, that encoding would NOT be backward compatible with [RFC9252], as explained more in Section 4 💀.
Therefore, it is REQUIRED that the LBL, LNL, and FL values be set in accordance with the SID structure for End.DT2M SRv6 Service SIDs, making sure we stay compliant with [RFC9252] 🎀✨.
3.2. Advertisement of Inclusive Multicast Ethernet Tag Route 🦋
The Inclusive Multicast Ethernet Tag route, as defined in [RFC7432] 🌸, is how multicast traffic reachability info gets advertised via Multiprotocol BGP (MP-BGP) to all the other PE routers within a given EVPN instance 💜. When using SRv6 transport, the advertisement of this route MUST include the BGP Prefix-SID attribute with an SRv6 L2 Service TLV to indicate that SRv6 is being used 🫶.
No matter whether ESI Filtering is in use, the SRv6 Service SID MUST include only the LOC:FUNC portion within the SRv6 SID Information Sub-TLV (when not using the Transposition Scheme) 🧚, with the SRv6 Endpoint Behavior set to End.DT2M. End.DT2M supports an ARG, so an SRv6 SID Structure Sub-Sub-TLV MUST be included 👑. The LBL, LNL, and FL fields MUST be set to indicate the structure of the SRv6 Service SID being advertised 🍓.
When ESI Filtering is NOT in use, no ARG is expected to be received by the router along with the advertised SRv6 Service SID 🙈. So the AL MUST be set to 0 💅.
Here's the example for this case 👀:
BGP Prefix-SID attribute:
SRv6 L2 Service TLV:
SRv6 SID Information Sub-TLV:
SID: 2001:db8:1:fbd1::
Behavior: End.DT2M
SRv6 SID Structure Sub-Sub-TLV:
LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0Figure 3: Inclusive Multicast Ethernet Tag Route Without ESI Filtering 🌈
When ESI Filtering IS in use 🔥, the router expects to receive traffic in the data path to the SRv6 Service SID it signaled, along with the ARG portion embedded in it ✨. That means the AL MUST be set to the size of the ARG supported by the advertising router for that specific SRv6 Service SID 💖. The AL value is unique per End.DT2M behavior signaled by the egress PE, so the egress PE MUST use the same AL for all local Ethernet Segments with attachment circuits within the same broadcast domain 🎀.
Here's the example with a 16-bit argument 🦋:
BGP Prefix-SID attribute:
SRv6 L2 Service TLV:
SRv6 SID Information Sub-TLV:
SID: 2001:db8:1:fbd1::
Behavior: End.DT2M
SRv6 SID Structure Sub-Sub-TLV:
LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0Figure 4: Inclusive Multicast Ethernet Tag Route with ESI Filtering 💜
Last bit for this section 🫶: when ESI Filtering is in use, the advertising router MUST ensure that the AL signaled in the Inclusive Multicast Ethernet Tag route is equal to the AL signaled in the corresponding Ethernet A-D per ES route 🌸✨
3.3. Processing at Ingress PE ✨
okay so this is where the ingress PE gets to do its thing 💅 It receives the LOC:FUNC part of the SRv6 Service SID that's used for BUM traffic, and it gets that through Inclusive Multicast Ethernet Tag route advertisements 🦋
When ESI Filtering is not in use, the SRv6 Service SID is just the LOC:FUNC part that came in via the Inclusive Multicast Ethernet Tag route. Easy peasy 🎀
When ESI Filtering is in use, the ESI Filtering ARG gets signaled through the Ethernet A-D per ES route instead. That ARG, combined with the LOC:FUNC from the Inclusive Multicast Ethernet Tag route, makes up the SRv6 Service SID that gets used 🧚
Now here's the tea. The LOC:FUNC and ARG parts come in through different route advertisements, so the ingress PE might see mismatched AL values from the two route types 😭 If the ingress PE expects ESI Filtering to be in use (aka when it's forwarding BUM traffic to other PEs on a shared Ethernet Segment) but doesn't get a usable ARG value while processing, it SHOULD log a message so troubleshooting is less of a nightmare 🔥
The ingress PE router MUST follow the processing steps below whenever it handles SRv6 Service SID advertisements 👑
- If
AL=0is signaled via the Inclusive Multicast Ethernet Tag route, then the egress PE either doesn't support ESI Filtering or doesn't need an ESI Filtering ARG for that specific SID 💀 In this case the SRv6 Service SID is built using only the LOC:FUNC part, and all bits afterLBL + LNL + FLMUST be set to zero for encoding on the data path 🌸 On top of that, the router MUST ignore the SID value and its SID structure that were advertised in the matching Ethernet A-D per ES route 🙈 - If a non-zero AL is signaled via the Inclusive Multicast Ethernet Tag route, then the matching Ethernet A-D per ES route for the Ethernet Segment gets located, and the router checks that there's an SRv6 SID advertisement with the End.DT2M behavior 🔍
- a. If that SRv6 SID can't be verified, or if the AL is zero in the Ethernet A-D per ES route, then there's no usable ARG value. The SRv6 Service SID MUST be formed as described in (1) above 🫶
- b. If the AL values in the Ethernet A-D per ES route and the Inclusive Multicast Ethernet Tag route are both non-zero but not equal, then there's no usable ARG value either. This mismatch means the egress PE has a configuration error 🚨 To prevent potential looping, BUM traffic MUST NOT be forwarded for such routes from that specific Ethernet Segment. Implementations SHOULD log an error message so people can troubleshoot this one 😭
- c. If the AL values in the Ethernet A-D per ES route and the Inclusive Multicast Ethernet Tag route are both non-zero and equal, then the ARG value from the Ethernet A-D per ES route is valid ✅ This ARG value MUST be encoded within the SRv6 SID (LOC:FUNC) at the ARG offset given by the SID structure (i.e.,
LBL + LNL + FL) in the Inclusive Multicast Ethernet Tag route. All bits beyondLBL + LNL + FL + ALMUST be set to zero 🌈
Using the procedures above with the examples in Figures 1 and 3, the SRv6 Service SID encoding for the data plane without an ESI Filtering ARG looks like this 🍓
Inclusive Multicast Ethernet Tag route:
SID: 2001:db8:1:fbd1::
Structure: LBL: 32, LNL: 16, FL: 16, AL: 0
SRv6 Service SID Encoded for Datapath: 2001:db8:1:fbd1::
Figure 5: SRv6 Service SID Encoding for Data Plane Without ARGUsing the procedures above with the examples in Figures 2 and 4, the SRv6 Service SID encoding for the data plane with an ESI Filtering ARG looks like this 💖
Ethernet A-D per ES route:
SID: ::aaaa:0:0:0
Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
Inclusive Multicast Ethernet Tag route:
SID: 2001:db8:1:fbd1::
Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
SRv6 Service SID Encoded for Datapath: 2001:db8:1:fbd1:aaaa::
Figure 6: SRv6 Service SID Encoding for Data Plane with ARGFigure 7 is another example, showing how multiple bridge domains get signaled and processed in one deployment design 🦋
+--------------------------------+
| |
PE1 | |
+---------+ |
BUM on BD1 | +-----+ | |
+----------------> | BD1 |-------------+ |
| | +-----+ | | |
| BUM on BD2 | +-----+ | v PE3 |
| +--------------> | BD2 |-------+ +---------+
| | +-----| +-----+ | | | +-----+ |
+----+ | +---------+ v ^ | | BD1 |-----CE31
| | | | | | +-----+ |
|CE12|-----+ ESI-1 | ^ | | +-----+ |
| |-----+ | | | | | BD2 |-----CE32
+----+ | +---------+ ^ RT3 RT3 | +-----+ |
+-----| +-----+ | | dt2m dt2m +---------+
| | BD1 | | | BD2 BD1 |
| +-----+ | | FL:16 FL:32 |
| +-----+ | RT1 |
| | BD2 | | ESI-1 |
| +-----+ | AL:16 |
+---------+ |
PE2 | |
| |
| |
+-------------------------------+
Ethernet A-D per ES route for ESI-1:
SID: ::aaaa:0:0:0
Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
Inclusive Multicast Ethernet Tag route from BD1:
SID: 2001:db8:1:fbd1:fbd1:
Structure: LBL: 32, LNL: 16, FL: 32, AL: 16
Inclusive Multicast Ethernet Tag route from BD2:
SID: 2001:db8:1:fbd2::
Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
SRv6 Service SID for datapath from ingress PE1 to egress PE2 on BD1:
2001:db8:1:fbd1:fbd1:aaaa::
SRv6 Service SID for datapath from ingress PE1 to egress PE2 on BD2:
2001:db8:1:fbd2:aaaa::
Figure 7: Example with Multiple Bridge Domains4. Backward Compatibility 🌷
Existing implementations that rely on the bitwise logical-OR operation (as specified in Section 6.3 of [RFC9252]) only work correctly when the SID structures of the two EVPN route types are identical 🤓
Backward compatibility with implementations doing the bitwise logical-OR operation is kept when the Inclusive Multicast Ethernet Tag route and its matching Ethernet A-D per ES route advertise SIDs with the same SID structure, as outlined in Sections 3.1 and 3.2 🫶
However, when the SID structures of the two route types are not identical, the bitwise logical-OR operation specified in [RFC9252] can't be applied 😭 Instead, the alternative method in Section 3.3 MUST be used to correctly derive the SRv6 Service SID in those cases ✨
5. IANA Considerations 🧚
This document has no IANA actions. 💅
6. Security Considerations 🚨
This document provides a more detailed specification related to the signaling and processing of SRv6 SID advertisements for SRv6 Endpoint Behaviors with arguments. As such, it does not introduce any new security considerations over and above those already covered by [RFC9252]. 🔒
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>.
[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>.
[RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J.,
Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree)
Support in Ethernet VPN (EVPN) and Provider Backbone
Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317,
January 2018, <https://www.rfc-editor.org/info/rfc8317>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>.7.2. Informative References
[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>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC9800] Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, Ed., "Compressed SRv6 Segment List Encoding",
RFC 9800, DOI 10.17487/RFC9800, June 2025,
<https://www.rfc-editor.org/info/rfc9800>.Acknowledgments 🫶
The authors would like to acknowledge Jayshree Subramanian, Sonal Agarwal, Swadesh Agrawal, Dongling Duan, Luc André Burdet, Patrice Brissette, Senthil Sathappan, Erel Ortacdag, Neil Hart, Will Lockhart, and Vinod Prabhu for their review of the document and input on aspects related to the signaling of the End.DT2M SRv6 Endpoint Behavior that required clarification. The authors thank Jeffrey Zhang for his shepherd review and suggestions for improving the document. The authors would also like to thank Gunter Van de Velde for his extensive review and suggestions for improving the readability of the document. 💜
Authors' Addresses 🌈
Ketan Talaulikar Cisco Systems India Email: ketant.ietf@gmail.com
Kamran Raza Cisco Systems Canada Email: skraza@cisco.com
Jorge Rabadan Nokia United States of America Email: jorge.rabadan@nokia.com
Wen Lin Juniper Networks United States of America Email: wlin@juniper.net
📦 where this page comes from
- ietf: rfc9819 2025-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms