BESS Working Group K. Talaulikar
Internet-Draft K. Raza
Updates: 9252 (if approved) Cisco Systems
Intended status: Standards Track J. Rabadan
Expires: 4 September 2025 Nokia
W. Lin
Juniper Networks
3 March 2025
SRv6 Argument Signaling for BGP Services
draft-ietf-bess-bgp-srv6-args-06
Abstract
RFC9252 defines procedures and messages for SRv6-based BGP services
including L3VPN, EVPN, and Internet services. This document updates
RFC9252 and provides more detailed specifications for the signaling
and processing of SRv6 SID advertisements for BGP Service routes
associated with SRv6 Endpoint Behaviors that support arguments.
Status of This Memo
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 4 September 2025.
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) 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
Talaulikar, et al. Expires 4 September 2025 [Page 1]
Internet-Draft SRv6 Argument Signaling for BGP Services March 2025
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Advertisement of SRv6 SID and Arguments . . . . . . . . . . . 3
3. End.DT2M Signaling for EVPN ESI Filtering . . . . . . . . . . 4
3.1. Advertisement of Ethernet A-D per ES Route . . . . . . . 5
3.2. Advertisement of Inclusive Multicast Ethernet Tag
Route . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Processing at Ingress PE . . . . . . . . . . . . . . . . 8
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
SRv6 refers to Segment Routing instantiated on the IPv6 data plane
[RFC8402]. SRv6 Service Segment Identifier (SID) refers to an SRv6
SID [RFC8402] associated with one of the service specific SRv6
Endpoint behaviors on the advertising Provider Edge (PE) router for
Layer-3 Virtual Private Network (L3VPN), Global Internet Routing, and
Ethernet Virtual Private Network (EVPN) services as defined in
[RFC8986]. [RFC9252] defines the procedures and messages for the
signaling of BGP services including L3VPN, EVPN, and Internet
services using SRv6 as data plane.
For certain EVPN services, [RFC8986] introduced the End.DT2M SRv6
Endpoint Behavior, which utilizes arguments (i.e., Arg.FE2).
[RFC9252] subsequently specified the encoding and signaling
procedures for the SRv6 SID and its associated argument via EVPN
Route Type 3 and EVPN Route Type 1, respectively. However, during
implementation and interoperability testing, it was observed that the
specifications outlined in [RFC9252] lacked sufficient detail,
leading to ambiguities in interpretation and implementation.
This document updates [RFC9252] by providing additional details and
clarifications regarding the signaling of SRv6 Service SIDs
associated with SRv6 Endpoint Behaviors that utilize arguments.
While the focus is primarily on the signaling of the End.DT2M SRv6
Talaulikar, et al. Expires 4 September 2025 [Page 2]
Internet-Draft SRv6 Argument Signaling for BGP Services March 2025
Endpoint Behavior via EVPN Route Types 1 and 3, the procedures
described herein are also applicable to other similar endpoint
behaviors with arguments that may be signaled using BGP.
Section 6.3 of [RFC9252] specifies that the SRv6 Service SID used in
the data plane is derived by applying a bitwise logical-OR operation
between the SID with argument signaled via Route Type 1 and the SID
with the 'locator + function' components signaled via Route Type 3.
However, this approach assumes a uniform SID structure across all
SIDs advertised via EVPN Route Types 1 and 3. This assumption is not
universally valid, and the procedures in this document remove this
restriction, ensuring greater flexibility in SRv6 SID signaling.
The descriptions and examples presented in this document do not
utilize the Transposition Scheme (see section 4 of [RFC9252]).
Consequently, the Transposition Offset (TPOS-O) and Transposition
Length (TPOS-L) are set to zero, and references to MPLS label fields
where the function or argument portions may be transposed are
omitted. However, the same examples could be applied with the
Transposition Scheme. This document does not introduce any
modifications to the use of the Transposition Scheme in the signaling
of EVPN Routes. Implementations are expected to adhere to the
procedures and recommendations specified in [RFC9252] concerning 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
As specified in [RFC8986], an SRv6 SID comprises three components:
Locator (LOC), Function (FUNC), and Argument (ARG). For SRv6 SIDs
associated with SRv6 Endpoint Behaviors that do not support argument,
the ARG component is not present. Consequently, all bits following
the FUNC portion MUST be set to zero, and the argument length MUST be
zero.
Certain SRv6 Endpoint Behaviors (e.g., End.DT2M) 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 corresponding
to an endpoint behavior that supports argument. This ensures that
the receiving router can perform consistency verification of the
argument and correctly encode the ARG value within the SRv6 SID.
Talaulikar, et al. Expires 4 September 2025 [Page 3]
Internet-Draft SRv6 Argument Signaling for BGP Services March 2025
In certain use cases, the SRv6 SID can be signaled as a complete
structure, with the LOC:FUNC:ARG components fully encoded within the
SID. However, there are scenarios where the SRv6 SID, consisting
only of the LOC:FUNC portion, is signaled in one advertisement, while
the ARG value is either signaled through a separate advertisement or
learned via an alternative mechanism. It is the responsibility of
the SRv6 Source Node to append the ARG component to the LOC:FUNC
portion, thereby constructing the complete SRv6 SID (LOC:FUNC:ARG).
This fully-formed SID can then be utilized in the data plane, either
as the IPv6 destination address of a packet or as a segment within
the Segment Routing Header (SRH) [RFC8754], as required.
Since arguments may be optional, the SRv6 Endpoint Node that owns the
SID MUST advertise the SRv6 SID Structure along with the LOC:FUNC
portion of the SRv6 SID to indicate whether arguments are supported
for that specific SID. A zero Argument Length (AL) value indicates
that the node does not accept an argument for the given SRv6 SID.
Conversely, a non-zero AL value specifies the size of the supported
argument, along with the Locator Block Length (LBL), Locator Node
Length (LNL), and Function Length (FL) parameters, which define the
offset from which the node expects the ARG to be encoded. All bits
beyond LBL + LNL + FL + AL MUST be set to zero.
The advertisement of the ARG value may be performed either by the
node that owns the SRv6 SID and is advertising the LOC:FUNC portion
of that SID, or by another node/mechanism. The advertisement of the
ARG value MUST specify the size of the argument, its value, and the
associated SRv6 Endpoint Behavior of the SID. Additionally, the
specification of the association of the ARG advertisement with the
corresponding SID(s) for which the argument applies is REQUIRED.
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 EVPN Route Type 3 (Inclusive
Multicast Ethernet Tag Route), while the Ethernet Segment Identifier
(ESI) Filtering ARG (denoted as Arg.FE2 in [RFC8986]) is signaled via
EVPN Route Type 1 (Ethernet Auto-Discovery per Ethernet Segment (A-D
per ES) Route). The following subsections provide a more detailed
specification of the signaling and processing mechanisms compared to
[RFC9252].
ESI Filtering is a split-horizon mechanism used for Multi-Homing
[RFC7432] or Ethernet-Tree (E-Tree) procedures [RFC8317]. ESI
Filtering is not applicable in scenarios where:
* No E-Tree leaf Broadcast, Unknown Unicast, or Multicast (BUM)
traffic exists,
Talaulikar, et al. Expires 4 September 2025 [Page 4]
Internet-Draft SRv6 Argument Signaling for BGP Services March 2025
* No multi-homing 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 used as a general reference to
the procedure performed by the disposition PE node to prevent
forwarding of BUM traffic to local Ethernet Segments or local leaf
attachment circuits, based on the presence of the ESI Filtering ARG.
The signaling and processing descriptions outlined in the following
sections also apply to End.DT2M behavior flavors designed for SRv6
SID list compression [I-D.ietf-spring-srv6-srh-compression]. In
deployments where a mix of compressed and uncompressed SIDs is
present, the behaviors advertised in the Ethernet Auto-Discovery
(A-D) per ES Routes (EVPN Route Type 1) and Inclusive Multicast
Ethernet Tag Routes (EVPN Route Type 3) MAY consist of a combination
of compressed and uncompressed End.DT2M behavior flavors. The
procedures in this document remains valid for such deployments
provided that the argument length consistency checks between EVPN
Route Type 1 and EVPN Route Type 3, as described in the following
subsections, are satisfied.
3.1. Advertisement of Ethernet A-D per ES Route
Ethernet Auto-Discovery (A-D) per ES Routes (EVPN Route Type 1), as
defined in [RFC7432], are utilized to enable split-horizon filtering
and fast convergence in multi-homing scenarios. Additionally, A-D
per ES Routes facilitate egress filtering of BUM traffic originating
from a Leaf, as specified in [RFC8317].
When ESI Filtering is not in use, no ESI Filtering ARG is required to
be conveyed. However, 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 the End.DT2M behavior
supports the use of an ARG, an SRv6 SID Structure sub-sub-TLV MUST be
included. As no ARG value is required to be signaled in this case,
the AL MUST be set to 0.
Following is an example representation of the BGP Prefix-SID
Attribute encoding in this case:
Talaulikar, et al. Expires 4 September 2025 [Page 5]
Internet-Draft SRv6 Argument Signaling for BGP Services March 2025
BGP Prefix SID Attr:
SRv6 L2 Service TLV:
SRv6 SID Information sub-TLV:
SID: ::0
Behavior: End.DT2M
SRv6 SID Structure sub-sub-TLV:
LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0
Figure 1: EVPN Route Type 1 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. Since the End.DT2M behavior supports the use of an ARG, an
SRv6 SID Structure sub-sub-TLV MUST be included. Additionally, as a
non-zero ARG value is being signaled, the Argument Length (AL) MUST
be set to the size of the ARG, and the size SHOULD be a multiple of
8. The SRv6 SID Structure sub-sub-TLV MUST set the Locator Block
Length (LBL), Locator Node Length (LNL), and Function Length (FL)
fields with values that indicate the offset at which the ARG value is
encoded within the 128-bit SRv6 SID.
The following is an example representation of the BGP Prefix-SID
Attribute encoding in this scenario for a 16-bit argument value of
'aaaa':
BGP Prefix SID Attr:
SRv6 L2 Service TLV:
SRv6 SID Information sub-TLV:
SID: 0:0:0:0:aaaa::
Behavior: End.DT2M
SRv6 SID Structure sub-sub-TLV:
LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0
Figure 2: EVPN Route Type 1 with ARG for ESI Filtering
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::. However, such an encoding would not be backward compatible
with [RFC9252], as further detailed 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,
ensuring compliance with [RFC9252].
Talaulikar, et al. Expires 4 September 2025 [Page 6]
Internet-Draft SRv6 Argument Signaling for BGP Services March 2025
3.2. Advertisement of Inclusive Multicast Ethernet Tag Route
The Inclusive Multicast Ethernet Tag Route (EVPN Route Type 3), as
defined in [RFC7432], is used to advertise multicast traffic
reachability information via MP-BGP to all other PE routers within a
given EVPN instance. When utilizing SRv6 transport, the
advertisement of this route MUST include the BGP Prefix-SID Attribute
with an SRv6 L2 Service TLV to indicate the use of SRv6.
Regardless of 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 utilizing the Transposition Scheme),
with the SRv6 Endpoint Behavior set to End.DT2M. Since the End.DT2M
behavior supports the use of an ARG, 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. Therefore,
the AL MUST be set to 0.
Following is an example representation of the BGP Prefix-SID
Attribute encoding in this case:
BGP Prefix SID Attr:
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: 0
Figure 3: EVPN Route Type 3 without ESI Filtering
When ESI Filtering is in use, the router expects to receive traffic
in the data path to the SRv6 Service SID that it has signaled along
with the ARG portion embedded in it. Consequently, the AL MUST be
set to the size of the ARG supported by the advertising router for
the specific SRv6 Service SID. The AL value is unique per End.DT2M
behavior signaled by the egress PE. Therefore, the egress PE MUST
use the same AL for all local Ethernet Segments with Attachment
Circuits within the same Broadcast Domain.
The following is an example representation of the BGP Prefix-SID
Attribute encoding for this scenario with a 16-bit argument:
Talaulikar, et al. Expires 4 September 2025 [Page 7]
Internet-Draft SRv6 Argument Signaling for BGP Services March 2025
BGP Prefix SID Attr:
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: 0
Figure 4: EVPN Route Type 3 with ESI Filtering
When ESI Filtering is in use, the advertising router MUST ensure that
the AL signaled in the EVPN Route Type 3 is equal to the AL signaled
in the corresponding EVPN Route Type 1.
3.3. Processing at Ingress PE
An ingress PE receives the LOC:FUNC portion of the SRv6 Service SID
to be used for Broadcast, Unknown Unicast, or Multicast (BUM) traffic
through EVPN Route Type 3 advertisements.
When ESI Filtering is not in use, the SRv6 Service SID to be used
consists solely of the LOC:FUNC portion received via EVPN Route Type
3.
When ESI Filtering is in use, the ESI Filtering ARG of the SRv6
Service SID is signaled through EVPN Route Type 1 (Ethernet Auto-
Discovery per Ethernet Segment Route). The ARG, in combination with
the LOC:FUNC portion received via EVPN Route Type 3, forms the SRv6
Service SID to be used.
Since the LOC:FUNC and ARG portions of the SRv6 Service SID are
signaled via different route advertisements, there may be cases where
the ingress PE receives inconsistent AL values from the two route
types. If the ingress PE expects ESI Filtering to be in use (i.e.,
when forwarding BUM traffic to other PEs attached to a shared
Ethernet Segment) but does not receive a usable ARG value during
processing, it SHOULD log a message to facilitate troubleshooting.
The ingress Provider Edge (PE) router MUST follow the processing
steps outlined below when handling SRv6 Service SID advertisements:
Talaulikar, et al. Expires 4 September 2025 [Page 8]
Internet-Draft SRv6 Argument Signaling for BGP Services March 2025
1. If AL=0 is signaled via EVPN Route Type 3, then the egress PE
either does not support ESI Filtering or does not require ESI
Filtering ARG for the specific SID. In this case, the SRv6
Service SID is formed using only the LOC:FUNC portion, and all
bits after LBL+LNL+FL MUST be set to zero for encoding on the
data path. Additionally, the router MUST ignore the SID value
and its SID structure advertised in the corresponding EVPN Route
Type 1.
2. If a non-zero AL is signaled via EVPN Route Type 3, then the
matching EVPN Route Type 1 for the Ethernet Segment is located
and the presence of an SRv6 SID advertisement with the End.DT2M
behavior is verified.
a. If the presence of such a SRv6 SID is not verified, or if the
AL=0 in the EVPN Route Type 1, then no usable ARG value is
available. The SRv6 Service SID MUST be formed as described
in (1) above.
b. If the AL values in EVPN Route Type 1 and EVPN Route Type 3
are both non-zero and but not equal, then no usable ARG value
is available. This inconsistency in signaling from the
egress PE indicates a configuration error. To prevent
potential looping, BUM traffic MUST NOT be forwarded for such
routes from the specific Ethernet Segment. Implementations
SHOULD log an error message for troubleshooting this
condition.
c. If the AL values in EVPN Route Type 1 and EVPN Route Type 3
are both non-zero and equal, then the ARG value from EVPN
Route Type 1 is considered valid. This ARG value MUST be
encoded within the SRv6 SID (LOC:FUNC) at the ARG offset as
specified in the SID structure (i.e., LBL + LNL + FL) in EVPN
Route Type 3. All bits beyond LBL + LNL + FL + AL MUST be
set to zero.
Based on the above procedures, the SRv6 Service SID encoding for the
data plane without an ESI Filtering ARG, based on the examples in
Figure 1 and Figure 3, is as follows:
Route Type 3:
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 ARG
Talaulikar, et al. Expires 4 September 2025 [Page 9]
Internet-Draft SRv6 Argument Signaling for BGP Services March 2025
Based on the above procedures, the SRv6 Service SID encoding for the
data plane along with an ESI Filtering ARG, based on the examples in
Figure 2 and Figure 4, is as follows:
Route Type 1:
SID: 0:0:0:0:aaaa::
Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
Route Type 3:
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 ARG
Figure 7 below provides another example that illustrates the
signaling and processing of multiple bridge domains in a deployment
design.
Talaulikar, et al. Expires 4 September 2025 [Page 10]
Internet-Draft SRv6 Argument Signaling for BGP Services March 2025
+--------------------------------+
| |
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 | |
| |
| |
+-------------------------------+
Route Type 1 ESI-1:
SID: 0:0:0:0:aaaa::
Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
Route Type 3 from BD1:
SID: 2001:db8:1:fbd1:fbd1:
Structure: LBL: 32, LNL: 16, FL: 32, AL: 16
Route Type 3 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 Domains
Talaulikar, et al. Expires 4 September 2025 [Page 11]
Internet-Draft SRv6 Argument Signaling for BGP Services March 2025
4. Backward Compatibility
Existing implementations that rely on the bitwise logical-OR
operation, as specified in Section 6.3 of [RFC9252], function
correctly only when the SID structures of the two EVPN Route Types
are identical.
Backward compatibility with implementations performing the bitwise
logical-OR operation is maintained when EVPN Route Type 3 and its
corresponding EVPN Route Type 1 advertise SIDs with the same SID
structure, as outlined in Section 3.1 and Section 3.2.
However, when the SID structures of the two route types are not
identical, the bitwise logical-OR operation specified in [RFC9252]
cannot be applied. Instead, the alternative method specified in
document in Section 3.3 MUST be used to correctly derive the SRv6
Service SID in such cases.
5. IANA Considerations
This document does not require any action from IANA.
6. Security Considerations
This document only 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 what is already
covered by [RFC9252].
7. Acknowledgments
The authors would like to acknowledge Jayshree Subramanian, Sonal
Agarwal, Swadesh Agrawal, Dongling Duan, Luc Andre Burdet, Patrice
Brissette, Senthil Sathappan, Erel Ortacdag, Neil Hart, Will
Lockhart, and Vinod Prabhu for their inputs on aspects related to the
signaling of the End.DT2M SRv6 Endpoint behavior that required
clarification as also for their review of this document. The authors
thank Jeffrey Zhang for his shepherd review of the document and
suggestions for its improvements. The authors would also like to
thank Gunter van de Velde for his extensive review and suggestions
for improving the readability of the document.
8. References
8.1. Normative References
Talaulikar, et al. Expires 4 September 2025 [Page 12]
Internet-Draft SRv6 Argument Signaling for BGP Services March 2025
[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>.
8.2. Informative References
[I-D.ietf-spring-srv6-srh-compression]
Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, "Compressed SRv6 Segment List Encoding (CSID)", Work
in Progress, Internet-Draft, draft-ietf-spring-srv6-srh-
compression-23, 6 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-srh-compression-23>.
Talaulikar, et al. Expires 4 September 2025 [Page 13]
Internet-Draft SRv6 Argument Signaling for BGP Services March 2025
[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>.
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
Talaulikar, et al. Expires 4 September 2025 [Page 14]