rfc9252.original   rfc9252.txt 
BESS Working Group G. Dawra, Ed. Internet Engineering Task Force (IETF) G. Dawra, Ed.
Internet-Draft LinkedIn Request for Comments: 9252 LinkedIn
Intended status: Standards Track K. Talaulikar, Ed. Category: Standards Track K. Talaulikar, Ed.
Expires: September 23, 2022 Cisco Systems ISSN: 2070-1721 Cisco Systems
R. Raszuk R. Raszuk
NTT Network Innovations NTT Network Innovations
B. Decraene B. Decraene
Orange Orange
S. Zhuang S. Zhuang
Huawei Technologies Huawei Technologies
J. Rabadan J. Rabadan
Nokia Nokia
March 22, 2022 July 2022
SRv6 BGP based Overlay Services BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)
draft-ietf-bess-srv6-services-15
Abstract Abstract
This document defines procedures and messages for SRv6-based BGP This document defines procedures and messages for SRv6-based BGP
services including L3VPN, EVPN, and Internet services. It builds on services, including Layer 3 Virtual Private Network (L3VPN), Ethernet
RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432 VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual
"BGP MPLS-Based Ethernet VPN". Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN"
(RFC 7432).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on September 23, 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9252.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language
2. SRv6 Services TLVs . . . . . . . . . . . . . . . . . . . . . 4 2. SRv6 Services TLVs
3. SRv6 Service Sub-TLVs . . . . . . . . . . . . . . . . . . . . 5 3. SRv6 Service Sub-TLVs
3.1. SRv6 SID Information Sub-TLV . . . . . . . . . . . . . . 6 3.1. SRv6 SID Information Sub-TLV
3.2. SRv6 Service Data Sub-Sub-TLVs . . . . . . . . . . . . . 8 3.2. SRv6 Service Data Sub-Sub-TLVs
3.2.1. SRv6 SID Structure Sub-Sub-TLV . . . . . . . . . . . 8 3.2.1. SRv6 SID Structure Sub-Sub-TLV
4. Encoding SRv6 SID Information . . . . . . . . . . . . . . . . 11 4. Encoding SRv6 SID Information
5. BGP based L3 Service over SRv6 . . . . . . . . . . . . . . . 12 5. BGP-Based L3 Service over SRv6
5.1. IPv4 VPN Over SRv6 Core . . . . . . . . . . . . . . . . . 13 5.1. IPv4 VPN over SRv6 Core
5.2. IPv6 VPN Over SRv6 Core . . . . . . . . . . . . . . . . . 13 5.2. IPv6 VPN over SRv6 Core
5.3. Global IPv4 over SRv6 Core . . . . . . . . . . . . . . . 14 5.3. Global IPv4 over SRv6 Core
5.4. Global IPv6 over SRv6 Core . . . . . . . . . . . . . . . 14 5.4. Global IPv6 over SRv6 Core
6. BGP based Ethernet VPN (EVPN) over SRv6 . . . . . . . . . . . 14 6. BGP-Based Ethernet VPN (EVPN) over SRv6
6.1. Ethernet Auto-discovery Route over SRv6 Core . . . . . . 16 6.1. Ethernet Auto-Discovery Route over SRv6 Core
6.1.1. Ethernet A-D per ES Route . . . . . . . . . . . . . . 16 6.1.1. Ethernet A-D per ES Route
6.1.2. Ethernet A-D per EVI Route . . . . . . . . . . . . . 17 6.1.2. Ethernet A-D per EVI Route
6.2. MAC/IP Advertisement Route over SRv6 Core . . . . . . . . 17 6.2. MAC/IP Advertisement Route over SRv6 Core
6.2.1. MAC/IP Advertisement Route with MAC Only . . . . . . 19 6.2.1. MAC/IP Advertisement Route with MAC Only
6.2.2. MAC/IP Advertisement Route with MAC+IP . . . . . . . 19 6.2.2. MAC/IP Advertisement Route with MAC+IP
6.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core . . 20 6.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core
6.4. Ethernet Segment Route over SRv6 Core . . . . . . . . . . 21 6.4. Ethernet Segment Route over SRv6 Core
6.5. IP Prefix Route over SRv6 Core . . . . . . . . . . . . . 22 6.5. IP Prefix Route over SRv6 Core
6.6. EVPN Multicast Routes (Route Types 6, 7, 8) over SRv6 6.6. EVPN Multicast Routes (Route Types 6, 7, and 8) over SRv6
Core . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Core
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 7. Error Handling
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8.1. BGP Prefix-SID TLV Types Registry
9.1. BGP Prefix-SID TLV Types Registry . . . . . . . . . . . . 24 8.2. SRv6 Service Sub-TLV Types Registry
9.2. SRv6 Service Sub-TLV Types Registry . . . . . . . . . . . 25 8.3. SRv6 Service Data Sub-Sub-TLV Types Registry
9.3. SRv6 Service Data Sub-Sub-TLV Types Registry . . . . . . 25 8.4. BGP SRv6 Service SID Flags Registry
9.4. BGP SRv6 Service SID Flags Registry . . . . . . . . . . . 26 8.5. SAFI Values Registry
9.5. Subsequent Address Family Identifiers (SAFI) Parameters 9. Security Considerations
Registry . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. Considerations Related to BGP Sessions
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9.2. Considerations Related to BGP Services
10.1. BGP Session Related Considerations . . . . . . . . . . . 26 9.3. Considerations Related to SR over IPv6 Data Plane
10.2. BGP Services Related Considerations . . . . . . . . . . 26 10. References
10.3. SR over IPv6 Data Plane Related Considerations . . . . . 27 10.1. Normative References
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 10.2. Informative References
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 Acknowledgements
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 Contributors
13.1. Normative References . . . . . . . . . . . . . . . . . . 30 Authors' Addresses
13.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
SRv6 refers to Segment Routing instantiated on the IPv6 dataplane SRv6 refers to Segment Routing instantiated on the IPv6 data plane
[RFC8402]. [RFC8402].
BGP is used to advertise the reachability of prefixes of a particular BGP is used to advertise the reachability of prefixes of a particular
service from an egress PE to ingress PE nodes. service from an egress Provider Edge (PE) to ingress PE nodes.
SRv6 based BGP services refers to the Layer-3 and Layer-2 overlay SRv6-based BGP services refer to the Layer 3 (L3) and Layer 2 (L2)
services with BGP as control plane and SRv6 as dataplane. This overlay services with BGP as the control plane and SRv6 as the data
document defines procedures and messages for SRv6-based BGP services plane. This document defines procedures and messages for SRv6-based
including L3VPN, EVPN, and Internet services. It builds on [RFC4364] BGP services, including L3VPN, EVPN, and Internet services. It
"BGP/MPLS IP Virtual Private Networks (VPNs)" and [RFC7432] "BGP builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" [RFC4364] and
MPLS-Based Ethernet VPN". "BGP MPLS-Based Ethernet VPN" [RFC7432].
SRv6 SID refers to an SRv6 Segment Identifier as defined in SRv6 SID refers to an SRv6 Segment Identifier, as defined in
[RFC8402]. [RFC8402].
SRv6 Service SID refers to an SRv6 SID associated with one of the SRv6 Service SID refers to an SRv6 SID associated with one of the
service-specific SRv6 Endpoint behaviors on the advertising Provider service-specific SRv6 Endpoint Behaviors on the advertising PE
Edge (PE) router, such as (but not limited to), End.DT (Table lookup router, such as (but not limited to) End.DT (look up in the Virtual
in a VRF) or End.DX (cross-connect to a nexthop) behaviors in the Routing and Forwarding (VRF) table) or End.DX (cross-connect to a
case of Layer-3 Virtual Private Network (L3VPN) service as defined in next hop) behaviors in the case of L3VPN service, as defined in
[RFC8986]. This document describes how existing BGP messages between [RFC8986]. This document describes how existing BGP messages between
PEs may carry SRv6 Service SIDs to interconnect PEs and form VPNs. PEs may carry SRv6 Service SIDs to interconnect PEs and form VPNs.
To provide SRv6 service with best-effort connectivity, the egress PE To provide SRv6 service with best-effort connectivity, the egress PE
signals an SRv6 Service SID with the BGP overlay service route. The signals an SRv6 Service SID with the BGP overlay service route. The
ingress PE encapsulates the payload in an outer IPv6 header where the ingress PE encapsulates the payload in an outer IPv6 header where the
destination address is the SRv6 Service SID provided by the egress destination address is the SRv6 Service SID provided by the egress
Provider Edge (PE). The underlay between the PEs only needs to PE. The underlay between the PEs only needs to support plain IPv6
support plain IPv6 forwarding [RFC8200]. forwarding [RFC8200].
To provide SRv6 service in conjunction with an underlay SLA from the To provide SRv6 service in conjunction with an underlay Service Level
ingress PE to the egress PE, the egress PE colors the overlay service Agreement (SLA) from the ingress PE to the egress PE, the egress PE
route with a Color Extended Community colors the overlay service route with a Color Extended Community
[I-D.ietf-idr-segment-routing-te-policy] for steering of flows for [RFC9012] for steering flows for those routes, as specified in
those routes as specified in section 8 of Section 8 of [SEGMENT-ROUTING-POLICY]. The ingress PE encapsulates
[I-D.ietf-spring-segment-routing-policy]. The ingress PE the payload packet in an outer IPv6 header with the SR Policy segment
encapsulates the payload packet in an outer IPv6 header with the list associated with the related SLA along with the SRv6 Service SID
segment list of SR policy associated with the related SLA along with associated with the route using the Segment Routing Header (SRH)
the SRv6 Service SID associated with the route using the Segment [RFC8754]. The underlay nodes whose SRv6 SIDs are part of the SRH
Routing Header (SRH) [RFC8754]. The underlay nodes whose SRv6 SID's segment list MUST support the SRv6 data plane.
are part of the SRH segment list MUST support SRv6 data plane.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. SRv6 Services TLVs 2. SRv6 Services TLVs
This document extends the use of the BGP Prefix-SID attribute This document extends the use of the BGP Prefix-SID attribute
[RFC8669] to carry SRv6 SIDs and their associated information with [RFC8669] to carry SRv6 SIDs and their associated information with
the BGP address-families that are listed further in this section. the BGP address families that are listed further in this section.
The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix- The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix-
SID Attribute to achieve signaling of SRv6 SIDs for L3 and L2 SID attribute to achieve signaling of SRv6 SIDs for L3 and L2
services. services.
o SRv6 L3 Service TLV: This TLV encodes Service SID information for SRv6 L3 Service TLV:
SRv6 based L3 services. It corresponds to the equivalent This TLV encodes Service SID information for SRv6-based L3
functionality provided by an MPLS Label when received with a Layer services. It corresponds to the equivalent functionality provided
3 service route as defined in [RFC4364] [RFC4659] [RFC8950] by an MPLS label when received with a Layer 3 service route, as
[RFC9136]. Some SRv6 Endpoint behaviors which may be encoded, but defined in [RFC4364], [RFC4659], [RFC8950], and [RFC9136]. Some
not limited to, are End.DX4, End.DT4, End.DX6, End.DT6, and SRv6 Endpoint Behaviors that may be encoded are, but not limited
End.DT46. to, End.DX4, End.DT4, End.DX6, End.DT6, and End.DT46.
o SRv6 L2 Service TLV: This TLV encodes Service SID information for SRv6 L2 Service TLV:
SRv6 based L2 services. It corresponds to the equivalent This TLV encodes Service SID information for SRv6-based L2
functionality provided by an MPLS Label1 for Ethernet VPN (EVPN) services. It corresponds to the equivalent functionality provided
Route-Types as defined in [RFC7432]. Some SRv6 Endpoint behaviors by an MPLS label for Ethernet VPN (EVPN) Route Types for Layer 2
which may be encoded, but not limited to, are End.DX2, End.DX2V, services, as defined in [RFC7432]. Some SRv6 Endpoint Behaviors
that may be encoded are, but not limited to, End.DX2, End.DX2V,
End.DT2U, and End.DT2M. End.DT2U, and End.DT2M.
When an egress PE is enabled for BGP Services over SRv6 data-plane, When an egress PE is enabled for BGP Services over the SRv6 data
it signals one or more SRv6 Service SIDs enclosed in SRv6 Service plane, it signals one or more SRv6 Service SIDs enclosed in an SRv6
TLV(s) within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs Service TLV(s) within the BGP Prefix-SID attribute attached to
defined in [RFC4760] [RFC4659] [RFC8950] [RFC7432] [RFC4364] Multiprotocol BGP (MP-BGP) Network Layer Reachability Information
[RFC9136] where applicable as described in Section 5 and Section 6. (NLRI) defined in [RFC4760], [RFC4659], [RFC8950], [RFC7432],
[RFC4364], and [RFC9136], where applicable, as described in Sections
5 and 6.
The support for BGP Multicast VPN (MVPN) Services [RFC6513] with SRv6 The support for BGP Multicast VPN (MVPN) Services [RFC6513] with SRv6
is outside the scope of this document. is outside the scope of this document.
The following depicts the SRv6 Service TLVs encoded in the BGP The following depicts the SRv6 Service TLVs encoded in the BGP
Prefix-SID Attribute: Prefix-SID attribute:
0 1 2 3 0 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length | RESERVED | | TLV Type | TLV Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service Sub-TLVs // | SRv6 Service Sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SRv6 Service TLVs Figure 1: SRv6 Service TLVs
o TLV Type (1 octet): This field is assigned values from the IANA TLV Type (1 octet):
registry "BGP Prefix-SID TLV Types". It is set to 5 for SRv6 L3 This field is assigned a value from IANA's "BGP Prefix-SID TLV
Service TLV. It is set to 6 for SRv6 L2 Service TLV. Types" subregistry. It is set to 5 for the SRv6 L3 Service TLV.
It is set to 6 for the SRv6 L2 Service TLV.
o TLV Length (2 octets): Specifies the total length, in octets, of TLV Length (2 octets):
the TLV Value. This field specifies the total length, in octets, of the TLV
Value.
o RESERVED (1 octet): This field is reserved; it MUST be set to 0 by RESERVED (1 octet):
the sender and ignored by the receiver. This field is reserved; it MUST be set to 0 by the sender and
ignored by the receiver.
o SRv6 Service Sub-TLVs (variable): This field contains SRv6 Service SRv6 Service Sub-TLVs (variable):
related information and is encoded as an unordered list of Sub- This field contains SRv6 service-related information and is
TLVs whose format is described below. encoded as an unordered list of Sub-TLVs whose format is described
below.
A BGP speaker receiving a route containing BGP Prefix-SID Attribute A BGP speaker receiving a route containing the BGP Prefix-SID
with one or more SRv6 Service TLVs observes the following rules when attribute with one or more SRv6 Service TLVs observes the following
advertising the received route to other peers: rules when advertising the received route to other peers:
o if the nexthop is unchanged during the advertisement, the SRv6 * If the BGP next hop is unchanged during the advertisement, the
Service TLVs, including any unrecognized Types of Sub-TLV and Sub- SRv6 Service TLVs, including any unrecognized Types of Sub-TLV and
Sub-TLV, SHOULD be propagated further. In addition, all Reserved Sub-Sub-TLV, SHOULD be propagated further. In addition, all
fields in the TLV or Sub-TLV or Sub-Sub-TLV MUST be propagated Reserved fields in the TLV, Sub-TLV, or Sub-Sub-TLV MUST be
unchanged. propagated unchanged.
o if the nexthop is changed, the TLVs, Sub-TLVs, and Sub-Sub-TLVs * If the BGP next hop is changed, the TLVs, Sub-TLVs, and Sub-Sub-
SHOULD be updated with the locally allocated SRv6 SID information. TLVs SHOULD be updated with the locally allocated SRv6 SID
Any unrecognized received Sub-TLVs and Sub-Sub-TLVs MUST be information. Any received Sub-TLVs and Sub-Sub-TLVs that are
removed. unrecognized MUST be removed.
3. SRv6 Service Sub-TLVs 3. SRv6 Service Sub-TLVs
The format of a single SRv6 Service Sub-TLV is depicted below: The format of a single SRv6 Service Sub-TLV is depicted below:
0 1 2 3 0 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service | SRv6 Service | SRv6 Service // | SRv6 Service | SRv6 Service | SRv6 Service //
| Sub-TLV | Sub-TLV | Sub-TLV // | Sub-TLV | Sub-TLV | Sub-TLV //
| Type | Length | value // | Type | Length | Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SRv6 Service Sub-TLVs Figure 2: SRv6 Service Sub-TLVs
o SRv6 Service Sub-TLV Type (1 octet): Identifies the type of SRv6 SRv6 Service Sub-TLV Type (1 octet):
service information. It is assigned values from the IANA Registry This field identifies the type of SRv6 service information. It is
"SRv6 Service Sub-TLV Types". assigned a value from IANA's "SRv6 Service Sub-TLV Types"
subregistry.
o SRv6 Service Sub-TLV Length (2 octets): Specifies the total SRv6 Service Sub-TLV Length (2 octets):
length, in octets, of the Sub-TLV Value field. This field specifies the total length, in octets, of the Sub-TLV
Value field.
o SRv6 Service Sub-TLV Value (variable): Contains data specific to SRv6 Service Sub-TLV Value (variable):
the Sub-TLV Type. In addition to fixed-length data, it contains This field contains data specific to the Sub-TLV Type. In
other properties of the SRv6 Service encoded as a set of SRv6 addition to fixed-length data, it contains other properties of the
Service Data Sub-Sub-TLVs whose format is described in Section 3.2 SRv6 service encoded as a set of SRv6 Service Data Sub-Sub-TLVs
below. whose format is described in Section 3.2 below.
3.1. SRv6 SID Information Sub-TLV 3.1. SRv6 SID Information Sub-TLV
SRv6 Service Sub-TLV Type 1 is assigned for SRv6 SID Information Sub- SRv6 Service Sub-TLV Type 1 is assigned for the SRv6 SID Information
TLV. This Sub-TLV contains a single SRv6 SID along with its Sub-TLV. This Sub-TLV contains a single SRv6 SID along with its
properties. Its encoding is depicted below: properties. Its encoding is depicted below:
0 1 2 3 0 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service | SRv6 Service | | | SRv6 Service | SRv6 Service | |
| Sub-TLV | Sub-TLV | | | Sub-TLV | Sub-TLV | |
| Type=1 | Length | RESERVED1 | | Type=1 | Length | RESERVED1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 SID Value (16 octets) // | SRv6 SID Value (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Svc SID Flags | SRv6 Endpoint Behavior | RESERVED2 | | Svc SID Flags | SRv6 Endpoint Behavior | RESERVED2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service Data Sub-Sub-TLVs // | SRv6 Service Data Sub-Sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SRv6 SID Information Sub-TLV Figure 3: SRv6 SID Information Sub-TLV
o SRv6 Service Sub-TLV Type (1 octet): This field is set to 1 to SRv6 Service Sub-TLV Type (1 octet):
represent SRv6 SID Information Sub-TLV. This field is set to 1 to represent the SRv6 SID Information Sub-
TLV.
o SRv6 Service Sub-TLV Length (2 octets): This field contains the SRv6 Service Sub-TLV Length (2 octets):
total length, in octets, of the Value field of the Sub-TLV. This field contains the total length, in octets, of the Value
field of the Sub-TLV.
o RESERVED1 (1 octet): MUST be set to 0 by the sender and ignored by RESERVED1 (1 octet):
the receiver. This field MUST be set to 0 by the sender and ignored by the
receiver.
o SRv6 SID Value (16 octets): Encodes an SRv6 SID as defined in SRv6 SID Value (16 octets):
[RFC8986] This field encodes an SRv6 SID, as defined in [RFC8986].
o SRv6 Service SID Flags (1 octet): Encodes SRv6 Service SID Flags - SRv6 Service SID Flags (1 octet):
none are currently defined. SHOULD be set to 0 by the sender and This field encodes SRv6 Service SID Flags -- none are currently
any unknown flags MUST be ignored by the receiver. defined. It MUST be set to 0 by the sender and any unknown flags
MUST be ignored by the receiver.
o SRv6 Endpoint Behavior (2 octets): Encodes SRv6 Endpoint behavior SRv6 Endpoint Behavior (2 octets):
codepoint value that is associated with SRv6 SID. The codepoints This field encodes the SRv6 Endpoint Behavior codepoint value that
used are from the "SRv6 Endpoint Behavior" registry under the IANA is associated with the SRv6 SID. The codepoints used are from
"Segment Routing" parameters registry that was introduced by IANA's "SRv6 Endpoint Behaviors" subregistry under the "Segment
[RFC8986]. The opaque endpoint behavior (i.e., value 0xFFFF) MAY Routing" registry that was introduced by [RFC8986]. The opaque
be used when the advertising router wishes to abstract the actual SRv6 Endpoint Behavior (i.e., value 0xFFFF) MAY be used when the
behavior of it's locally instantiated SRv6 SID. advertising router wishes to abstract the actual behavior of its
locally instantiated SRv6 SID.
o RESERVED2 (1 octet): MUST be set to 0 by the sender and ignored by RESERVED2 (1 octet):
the receiver. This field MUST be set to 0 by the sender and ignored by the
receiver.
o SRv6 Service Data Sub-Sub-TLV Value (variable): Used to advertise SRv6 Service Data Sub-Sub-TLV Value (variable):
properties of the SRv6 SID. It is encoded as a set of SRv6 This field is used to advertise properties of the SRv6 SID. It is
Service Data Sub-Sub-TLVs. encoded as a set of SRv6 Service Data Sub-Sub-TLVs.
The choice of SRv6 Endpoint behavior of the SRv6 SID is entirely up The choice of SRv6 Endpoint Behavior of the SRv6 SID is entirely up
to the originator of the advertisement. While Section 5 and to the originator of the advertisement. While Sections 5 and 6 list
Section 6 list the SRv6 Endpoint Behaviors that are normally expected the SRv6 Endpoint Behaviors that are normally expected to be used by
to be used by the specific route advertisements, the reception of the specific route advertisements, the reception of other SRv6
other SRv6 Endpoint behaviors (e.g., new behaviors that may be Endpoint Behaviors (e.g., new behaviors that may be introduced in the
introduced in the future) is not considered an error. An future) is not considered an error. An unrecognized SRv6 Endpoint
unrecognized endpoint behavior MUST NOT be considered invalid by the Behavior MUST NOT be considered invalid by the receiver, except for
receiver except for behaviors that involve the use of arguments behaviors that involve the use of arguments (refer to Section 3.2.1
(refer to Section 3.2.1 for details on argument validation). An for details on argument validation). An implementation MAY log a
implementation MAY log a rate-limited warning when it receives an rate-limited warning when it receives an unexpected behavior.
unexpected behavior.
When multiple SRv6 SID Information Sub-TLVs are present, the ingress When multiple SRv6 SID Information Sub-TLVs are present, the ingress
PE SHOULD use the SRv6 SID from the first instance of the Sub-TLV. PE SHOULD use the SRv6 SID from the first instance of the Sub-TLV.
An implementation MAY provide a local policy to override this An implementation MAY provide a local policy to override this
selection. selection.
3.2. SRv6 Service Data Sub-Sub-TLVs 3.2. SRv6 Service Data Sub-Sub-TLVs
The format of the SRv6 Service Data Sub-Sub-TLV is depicted below: The format of the SRv6 Service Data Sub-Sub-TLV is depicted below:
0 1 2 3 0 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Data | Sub-Sub-TLV Length |Sub-Sub TLV // | Service Data | Sub-Sub-TLV Length |Sub-Sub TLV //
| Sub-Sub-TLV | | Value // | Sub-Sub-TLV | | Value //
| Type | | // | Type | | //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SRv6 Service Data Sub-Sub-TLVs Figure 4: SRv6 Service Data Sub-Sub-TLVs
o SRv6 Service Data Sub-Sub-TLV Type (1 octet): Identifies the type SRv6 Service Data Sub-Sub-TLV Type (1 octet):
of Sub-Sub-TLV. It is assigned values from the IANA Registry This field identifies the type of Sub-Sub-TLV. It is assigned a
"SRv6 Service Data Sub-Sub-TLVs". value from IANA's "SRv6 Service Data Sub-Sub-TLV Types"
subregistry.
o SRv6 Service Data Sub-Sub-TLV Length (2 octets): Specifies the SRv6 Service Data Sub-Sub-TLV Length (2 octets):
total length, in octets, of the Sub-Sub-TLV Value field. This field specifies the total length, in octets, of the Sub-Sub-
TLV Value field.
o SRv6 Service Data Sub-Sub-TLV Value (variable): Contains data SRv6 Service Data Sub-Sub-TLV Value (variable):
specific to the Sub-Sub-TLV Type. This field contains data specific to the Sub-Sub-TLV Type.
3.2.1. SRv6 SID Structure Sub-Sub-TLV 3.2.1. SRv6 SID Structure Sub-Sub-TLV
SRv6 Service Data Sub-Sub-TLV Type 1 is assigned for SRv6 SID SRv6 Service Data Sub-Sub-TLV Type 1 is assigned for the SRv6 SID
structure Sub-Sub-TLV. SRv6 SID Structure Sub-Sub-TLV is used to Structure Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV is used to
advertise the lengths of the individual parts of the SRv6 SID as advertise the lengths of the individual parts of the SRv6 SID, as
defined in [RFC8986]. The terms Locator Block and Locator Node defined in [RFC8986]. The terms Locator Block and Locator Node
correspond to the B and N parts respectively of the SRv6 Locator that correspond to the B and N parts, respectively, of the SRv6 Locator
are defined in section 3.1 of [RFC8986]. It is carried as Sub-Sub- that is defined in Section 3.1 of [RFC8986]. It is carried as Sub-
TLV in SRv6 SID Information Sub-TLV Sub-TLV in the SRv6 SID Information Sub-TLV.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service | SRv6 Service | Locator Block |
| Data Sub-Sub | Data Sub-Sub-TLV | Length |
| -TLV Type=1 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Node | Function | Argument | Transposition |
| Length | Length | Length | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transposition |
| Offset |
+-+-+-+-+-+-+-+-+
Figure 5: SRv6 SID Structure Sub-Sub-TLV 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service | SRv6 Service | Locator Block |
| Data Sub-Sub | Data Sub-Sub-TLV | Length |
| -TLV Type=1 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Node | Function | Argument | Transposition |
| Length | Length | Length | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transposition |
| Offset |
+-+-+-+-+-+-+-+-+
o SRv6 Service Data Sub-Sub-TLV Type (1 octet): This field is set to Figure 5: SRv6 SID Structure Sub-Sub-TLV
1 to represent SRv6 SID Structure Sub-Sub-TLV.
o SRv6 Service Data Sub-Sub-TLV Length (2 octets): This field SRv6 Service Data Sub-Sub-TLV Type (1 octet):
contains a total length of 6 octets. This field is set to 1 to represent the SRv6 SID Structure Sub-
Sub-TLV.
o Locator Block Length (1 octet): Contains the length of SRv6 SID SRv6 Service Data Sub-Sub-TLV Length (2 octets):
Locator Block in bits. This field contains a total length of 6 octets.
o Locator Node Length (1 octet): Contains the length of SRv6 SID Locator Block Length (1 octet):
Locator Node in bits. This field contains the length of the SRv6 SID Locator Block in
bits.
o Function Length (1 octet): Contains the length of SRv6 SID Locator Node Length (1 octet):
Function in bits. This field contains the length of the SRv6 SID Locator Node in
bits.
o Argument Length (1 octet): Contains the length of SRv6 SID Function Length (1 octet):
Argument in bits. This field contains the length of the SRv6 SID Function in bits.
o Transposition Length (1 octet): Size in bits for the part of SID Argument Length (1 octet):
that has been transposed (or shifted) into a MPLS label field This field contains the length of the SRv6 SID Argument in bits.
o Transposition Offset (1 octet): The offset position in bits for Transposition Length (1 octet):
the part of SID that has been transposed (or shifted) into a MPLS This field is the size in bits for the part of the SID that has
label field. been transposed (or shifted) into an MPLS Label field.
Section 4 describes mechanisms for signaling of the SRv6 Service SID Transposition Offset (1 octet):
by transposing a variable part of the SRv6 SID value and carrying This field is the offset position in bits for the part of the SID
them in existing MPLS label fields to achieve more efficient packing that has been transposed (or shifted) into an MPLS Label field.
of those service prefix NLRIs in BGP update messages. The SRv6 SID
Structure Sub-Sub-TLV contains appropriate length fields when the
SRv6 Service SID is signaled in split parts to enable the receiver to
put together the SID accurately.
Transposition Offset indicates the bit position and Transposition Section 4 describes mechanisms for the signaling of the SRv6 Service
SID by transposing a variable part of the SRv6 SID value and carrying
this variable part in existing MPLS Label fields to achieve more
efficient packing of those service prefix NLRIs in BGP update
messages. The SRv6 SID Structure Sub-Sub-TLV contains appropriate
length fields when the SRv6 Service SID is signaled in split parts to
enable the receiver to put together the SID accurately.
Transposition Offset indicates the bit position, and Transposition
Length indicates the number of bits that are being taken out of the Length indicates the number of bits that are being taken out of the
SRv6 SID value and put into high order bits of MPLS label field. The SRv6 SID value and encoded in the MPLS Label field. The bits that
bits that have been shifted out MUST be set to 0 in the SID value. have been shifted out MUST be set to 0 in the SID value.
Transposition Length of 0 indicates nothing is transposed and that A Transposition Length of 0 indicates nothing is transposed and that
the entire SRv6 SID value is encoded in the SID Information Sub-TLV. the entire SRv6 SID value is encoded in the SID Information Sub-TLV.
In this case, the Transposition Offset MUST be set to 0. In this case, the Transposition Offset MUST be set to 0.
The size of the MPLS label field limits the bits transposed from the The size of the MPLS Label field limits the bits transposed from the
SRv6 SID value into it. E.g., the size of MPLS label field in SRv6 SID value into it. For example, the size of the MPLS Label
[RFC4364] [RFC8277] is 20 bits while in [RFC7432] is 24 bits. field is 20 bits in [RFC4364] and [RFC8277], and the size is 24 bits
in [RFC7432].
As defined in [RFC8986], the sum of the Locator Block Length (LBL), As defined in [RFC8986], the sum of the Locator Block Length (LBL),
Locator Node Length (LNL), Function Length (FL), and Argument Length Locator Node Length (LNL), Function Length (FL), and Argument Length
(AL) fields MUST be less than or equal to 128 and greater than the (AL) fields MUST be less than or equal to 128 and greater than the
sum of Transposition Offset and Transposition Length. sum of Transposition Offset and Transposition Length.
As an example, consider that the sum of the Locator Block and the As an example, consider that the sum of the Locator Block and the
Locator Node parts is 64. For an SRv6 SID where the entire Function Locator Node parts is 64. For an SRv6 SID where the entire Function
part of size 16 bits is transposed, then the transposition offset is part of size 16 bits is transposed, the transposition offset is set
set to 64 and the transposition length is set to 16. While for an to 64 and the transposition length is set to 16. While for an SRv6
SRv6 SID where the Function length is 24 bits and only the lower SID for which the FL is 24 bits and only the lower order 20 bits are
order 20 bits are transposed (e.g. due to the limit of the MPLS label transposed (e.g., due to the limit of the MPLS Label field size), the
field size), then the transposition offset is set to 68 and the transposition offset is set to 68 and the transposition length is set
transposition length is set to 20. to 20.
BGP speakers that do not support this specification may misinterpret, BGP speakers that do not support this specification may misinterpret,
on the reception of an SRv6-based BGP service route update, the part on the reception of an SRv6-based BGP service route update, the part
of the SRv6 SID encoded in MPLS label field(s) as MPLS label values of the SRv6 SID encoded in an MPLS Label field(s) as MPLS label
for MPLS-based services. Implementations supporting this values for MPLS-based services. Implementations supporting this
specification MUST provide a mechanism to control the advertisement specification MUST provide a mechanism to control the advertisement
of SRv6-based BGP service routes on a per-neighbor and per-service of SRv6-based BGP service routes on a per-neighbor and per-service
basis. The details of deployment designs and implementation options basis. The details of deployment designs and implementation options
are outside the scope of this document. are outside the scope of this document.
Arguments may be generally applicable for SIDs of only specific SRv6 Arguments may be generally applicable for SIDs of only specific SRv6
Endpoint behaviors (e.g., End.DT2M) and therefore the Argument length Endpoint Behaviors (e.g., End.DT2M); therefore, the AL MUST be set to
MUST be set to 0 for SIDs where the Argument is not applicable. A 0 for SIDs where the Argument is not applicable. A receiver is
receiver is unable to validate the applicability of arguments for unable to validate the applicability of arguments for SRv6 Endpoint
SRv6 Endpoint behaviors that are unknown to it and hence MUST ignore Behaviors that are unknown to it and hence MUST ignore SRv6 SIDs with
SRv6 SIDs with arguments (indicated by non-zero argument length) with arguments (indicated by a non-zero AL) with unknown SRv6 Endpoint
unknown endpoint behaviors. For SIDs corresponding to an endpoint Behaviors. For SIDs corresponding to an SRv6 Endpoint Behavior that
behavior that is known, a receiver MUST validate that the consistency is known, a receiver MUST validate that the consistency of the AL
of the argument length with the specific endpoint behavior with the specific SRv6 Endpoint Behavior definition.
definition.
4. Encoding SRv6 SID Information 4. Encoding SRv6 SID Information
The SRv6 Service SID(s) for a BGP Service Prefix are carried in the The SRv6 Service SID(s) for a BGP service prefix is carried in the
SRv6 Services TLVs of the BGP Prefix-SID Attribute. SRv6 Services TLVs of the BGP Prefix-SID attribute.
For certain types of BGP Services like L3VPN where a per-VRF SID For certain types of BGP Services, like L3VPN where a per-VRF SID
allocation is used (i.e., End.DT4 or End.DT6 behaviors), the same SID allocation is used (i.e., End.DT4 or End.DT6 behaviors), the same SID
is shared across multiple NLRIs thus providing efficient packing. is shared across multiple NLRIs, thus providing efficient packing.
However, for certain other types of BGP Services like EVPN VPWS where However, for certain other types of BGP Services, like EVPN Virtual
a per-PW SID allocation is required (i.e., End.DX2 behavior), each Private Wire Service (VPWS) where a per-PW SID allocation is required
NLRI would have its own unique SID thereby resulting in inefficient (i.e., End.DX2 behavior), each NLRI would have its own unique SID,
packing. thereby resulting in inefficient packing.
To achieve efficient packing, this document allows the encoding of To achieve efficient packing, this document allows either 1) the
the SRv6 Service SID either as a whole in the SRv6 Services TLVs or encoding of the SRv6 Service SID as a whole in the SRv6 Services TLVs
the encoding of only the common part of the SRv6 SID (e.g., Locator) or 2) the encoding of only the common part of the SRv6 SID (e.g.,
in the SRv6 Services TLVs and encoding the variable (e.g., Function Locator) in the SRv6 Services TLVs and the encoding of the variable
or Argument parts) in the existing label fields specific to that (e.g., Function or Argument parts) in the existing label fields
service encoding. This later form of encoding is referred to as the specific to that service encoding. This later form of encoding is
Transposition Scheme where the SRv6 SID Structure Sub-Sub-TLV referred to as the Transposition Scheme, where the SRv6 SID Structure
describes the sizes of the parts of the SRv6 SID and also indicates Sub-Sub-TLV describes the sizes of the parts of the SRv6 SID and also
the offset of the variable part along with its length in SRv6 SID indicates the offset of the variable part along with its length in
value. The use of the Transposition Scheme is RECOMMENDED for the the SRv6 SID value. The use of the Transposition Scheme is
specific service encodings that allow it as described further in RECOMMENDED for the specific service encodings that allow it, as
Section 5 and Section 6. described further in Sections 5 and 6.
As an example, for the EVPN VPWS service prefix described further in As an example, for the EVPN VPWS service prefix described further in
Section 6.1.2, the Function part of the SRv6 SID is encoded in the Section 6.1.2, the Function part of the SRv6 SID is encoded in the
MPLS Label field of the NLRI and the SID value in the SRv6 Services MPLS Label field of the NLRI, and the SID value in the SRv6 Services
TLV carries only the Locator part with the SRv6 SID Structure Sub- TLV carries only the Locator part with the SRv6 SID Structure Sub-
Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV defines the lengths of Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV defines the lengths of
Locator Block, Locator Node, and Function parts (Arguments are not Locator Block, Locator Node, and Function parts (Arguments are not
applicable for the End.DX2 behavior). Transposition Offset indicates applicable for the End.DX2 behavior). Transposition Offset indicates
the bit position and Transposition Length indicates the number of the bit position, and Transposition Length indicates the number of
bits that are being taken out of the SID and put into the label bits that are being taken out of the SID and put into the label
field. field.
In yet another example, for the EVPN Ethernet A-D per Ethernet In yet another example, for the EVPN Ethernet Auto-Discovery (A-D)
Segment (ES) route described further in Section 6.1.1, only the per Ethernet Segment (ES) route described further in Section 6.1.1,
Argument of the SID needs to be signaled. This Argument part of the only the Argument of the SID needs to be signaled. This Argument
SRv6 SID MAY be transposed in the Ethernet Segment Identifier (ESI) part of the SRv6 SID MAY be transposed in the Ethernet Segment
Label field of the ESI Label Extended Community and the SID value in Identifier (ESI) Label field of the ESI Label extended community, and
the SRv6 Services TLV is set to 0 along with the inclusion of SRv6 the SID value in the SRv6 Services TLV is set to 0 along with the
SID Structure Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV inclusion of the SRv6 SID Structure Sub-Sub-TLV. The SRv6 SID
defines the lengths of Locator Block, Locator Node, Function and Structure Sub-Sub-TLV defines the lengths of Locator Block, Locator
Argument parts. The offset and length of the Argument part SID value Node, Function, and Argument parts. The offset and length of the
moved to label field is set in transposition offset and length of SID Argument part SID value moved to the label field is set in
structure TLV. The receiving router is then able to put together the transposition offset and length of the SID Structure TLV. The
entire SRv6 Service SID (e.g., for the End.DT2M behavior) placing the receiving router is then able to put together the entire SRv6 Service
label value received in the ESI Label field of the Ethernet A-D per SID (e.g., for the End.DT2M behavior), placing the label value
ES route into the correct transposition offset and length in the SRv6 received in the ESI Label field of the Ethernet A-D per ES route into
SID with the End.DT2M behavior received for an EVPN Route Type 3 the correct transposition offset and length in the SRv6 SID with the
value. End.DT2M behavior received for an EVPN Route Type 3 value.
5. BGP based L3 Service over SRv6 5. BGP-Based L3 Service over SRv6
BGP egress nodes (egress PEs) advertise a set of reachable prefixes. BGP egress nodes (egress PEs) advertise a set of reachable prefixes.
Standard BGP update propagation schemes [RFC4271], which may make use Standard BGP update propagation schemes [RFC4271], which may make use
of route reflectors [RFC4456], are used to propagate these prefixes. of route reflectors [RFC4456], are used to propagate these prefixes.
BGP ingress nodes (ingress PEs) receive these advertisements and may BGP ingress nodes (ingress PEs) receive these advertisements and may
add the prefix to the RIB in an appropriate VRF. add the prefix to the RIB in an appropriate VRF.
Egress PEs which supports SRv6 based L3 services advertises overlay Egress PEs that support SRv6-based L3 services advertise overlay
service prefixes along with a Service SID enclosed in an SRv6 L3 service prefixes along with a Service SID enclosed in an SRv6 L3
Service TLV within the BGP Prefix-SID Attribute. This TLV serves two Service TLV within the BGP Prefix-SID attribute. This TLV serves two
purposes - first, it indicates that the egress PE supports SRv6 purposes -- first, it indicates that the egress PE supports SRv6
overlay and the BGP ingress PE receiving this route MUST perform IPv6 overlay, and the BGP ingress PE receiving this route MUST perform
encapsulation and insert an SRH [RFC8754] when required; second, it IPv6 encapsulation and insert an SRH [RFC8754] when required; second,
indicates the value of the Service SID to be used in the it indicates the value of the Service SID to be used in the
encapsulation. encapsulation.
The Service SID thus signaled only has local significance at the Thus, the Service SID signaled only has local significance at the
egress PE, where it may be allocated or configured on a per-CE or egress PE, where it may be allocated or configured on a per-Customer-
per-VRF basis. In practice, the SID may encode a cross-connect to a Edge (CE) or per-VRF basis. In practice, the SID may encode a cross-
specific Address Family table (End.DT) or next-hop/interface (End.DX) connect to a specific address family table (End.DT) or next hop /
as defined in [RFC8986]. interface (End.DX), as defined in [RFC8986].
The SRv6 Service SID SHOULD be routable (refer section 3.3 of The SRv6 Service SID SHOULD be routable (refer to Section 3.3 of
[RFC8986]) within the AS of the egress PE and serves the dual purpose [RFC8986]) within the Autonomous System (AS) of the egress PE and
of providing reachability between ingress PE and egress PE while also serves the dual purpose of providing reachability between ingress PE
encoding the SRv6 Endpoint behavior. and egress PE while also encoding the SRv6 Endpoint Behavior.
When steering for SRv6 services is based on shortest path forwarding When steering for SRv6 services is based on shortest path forwarding
(e.g., best-effort or IGP Flexible Algorithm (e.g., best effort or IGP Flexible Algorithm [IGP-FLEX-ALGO]) to the
[I-D.ietf-lsr-flex-algo]) to the egress PE, the ingress PE egress PE, the ingress PE encapsulates the IPv4 or IPv6 customer
encapsulates the IPv4 or IPv6 customer packet in an outer IPv6 header packet in an outer IPv6 header (using H.Encaps or H.Encaps.Red
(using H.Encaps or H.Encaps.Red flavors specified in [RFC8986]) where flavors specified in [RFC8986]), where the destination address is the
the destination address is the SRv6 Service SID associated with the SRv6 Service SID associated with the related BGP route update.
related BGP route update. Therefore, the ingress PE MUST perform Therefore, the ingress PE MUST perform a resolvability check for the
resolvability check for the SRv6 Service SID before considering the SRv6 Service SID before considering the received prefix for the BGP
received prefix for the BGP best path computation. The resolvability best path computation. The resolvability is evaluated as per
is evaluated as per [RFC4271]. If the SRv6 SID is reachable via more [RFC4271]. If the SRv6 SID is reachable via more than one forwarding
than one forwarding table, local policy is used to determine which table, local policy is used to determine which table to use. The
table to use. The result of an SRv6 Service SID resolvability (e.g., result of an SRv6 Service SID resolvability (e.g., when provided via
when provided via IGP Flexible Algorithm) can be ignored if the IGP Flexible Algorithm) can be ignored if the ingress PE has a local
ingress PE has a local policy that allows an alternate steering policy that allows an alternate steering mechanism to reach the
mechanism to reach the egress PE. The details of such steering egress PE. The details of such steering mechanisms are outside the
mechanisms are outside the scope of this document. scope of this document.
For service over SRv6 core, the egress PE sets the next-hop to one of For service over SRv6 core, the egress PE sets the BGP next hop to
its IPv6 addresses. Such an address MAY be covered by the SRv6 one of its IPv6 addresses. Such an address MAY be covered by the
Locator from which the SRv6 Service SID is allocated. The next-hop SRv6 Locator from which the SRv6 Service SID is allocated. The BGP
is used for tracking the reachability of the egress PE based on next hop is used for tracking the reachability of the egress PE based
existing BGP procedures. on existing BGP procedures.
When the BGP route is received at an ingress PE is colored with a When the BGP route received at an ingress PE is colored with a Color
Color Extended community and a valid SRv6 Policy is available, the Extended Community and a valid SRv6 Policy is available, the steering
steering for service flows is performed as described in Section 8 of for service flows is performed as described in Section 8 of
[I-D.ietf-spring-segment-routing-policy]. When the ingress PE [SEGMENT-ROUTING-POLICY]. When the ingress PE determines (with the
determines (with the help of SRv6 SID Structure) that the Service SID help of the SRv6 SID Structure) that the Service SID belongs to the
belongs to the same SRv6 Locator as the last SRv6 SID (of the egress same SRv6 Locator as the last SRv6 SID (of the egress PE) in the SR
PE) in the SR Policy segment list, it MAY exclude that last SRv6 SID Policy segment list, it MAY exclude that last SRv6 SID when steering
when steering the service flow. For example, the effective segment the service flow. For example, the effective segment list of the
list of the SRv6 Policy associated with SID list <S1, S2, S3> would SRv6 Policy associated with SID list <S1, S2, S3> would be <S1, S2,
be <S1, S2, S3-Service-SID>. S3-Service-SID>.
5.1. IPv4 VPN Over SRv6 Core 5.1. IPv4 VPN over SRv6 Core
The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN
Over IPv6 Core defined in [RFC8950]. unicast over IPv6 core defined in [RFC8950].
Label field of IPv4-VPN NLRI is encoded as specified in [RFC8277] The label field of IPv4-VPN NLRI is encoded as specified in [RFC8277]
with the 20-bit Label Value set to the whole or a portion of the with the 20-bit Label Value set to the whole or a portion of the
Function part of the SRv6 SID when the Transposition Scheme of Function part of the SRv6 SID when the Transposition Scheme of
encoding (Section 4) is used and otherwise set to Implicit NULL. encoding (Section 4) is used; otherwise, it is set to Implicit NULL.
When using the Transposition Scheme, the Transposition Length MUST be When using the Transposition Scheme, the Transposition Length MUST be
less than or equal to 20 and less than or equal to the Function less than or equal to 20 and less than or equal to the FL.
Length.
SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.
SRv6 Endpoint behavior SHOULD be one of these: End.DX4, End.DT4, The SRv6 Endpoint Behavior SHOULD be one of these: End.DX4, End.DT4,
End.DT46. or End.DT46.
5.2. IPv6 VPN Over SRv6 Core 5.2. IPv6 VPN over SRv6 Core
The MP_REACH_NLRI over SRv6 core is encoded according to IPv6 VPN The MP_REACH_NLRI over SRv6 core is encoded according to IPv6 VPN
over IPv6 Core is defined in [RFC4659]. over IPv6 core, as defined in [RFC4659].
Label field of the IPv6-VPN NLRI is encoded as specified in [RFC8277] The label field of the IPv6-VPN NLRI is encoded as specified in
with the 20-bit Label Value set to the whole or a portion of the [RFC8277] with the 20-bit Label Value set to the whole or a portion
Function part of the SRv6 SID when the Transposition Scheme of of the Function part of the SRv6 SID when the Transposition Scheme of
encoding (Section 4) is used and otherwise set to Implicit NULL. encoding (Section 4) is used; otherwise, it is set to Implicit NULL.
When using the Transposition Scheme, the Transposition Length MUST be When using the Transposition Scheme, the Transposition Length MUST be
less than or equal to 20 and less than or equal to the Function less than or equal to 20 and less than or equal to the FL.
Length.
SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.
SRv6 Endpoint behavior SHOULD be one of these: End.DX6, End.DT6, The SRv6 Endpoint Behavior SHOULD be one of these: End.DX6, End.DT6,
End.DT46. or End.DT46.
5.3. Global IPv4 over SRv6 Core 5.3. Global IPv4 over SRv6 Core
The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 over The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 over
IPv6 Core is defined in [RFC8950]. IPv6 core, as defined in [RFC8950].
SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The
SRv6 Endpoint behavior SHOULD be one of these: End.DX4, End.DT4, SRv6 Endpoint Behavior SHOULD be one of these: End.DX4, End.DT4, or
End.DT46. End.DT46.
5.4. Global IPv6 over SRv6 Core 5.4. Global IPv6 over SRv6 Core
The MP_REACH_NLRI over SRv6 core is encoded according to [RFC2545] The MP_REACH_NLRI over SRv6 core is encoded according to [RFC2545].
SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.
SRv6 Endpoint behavior SHOULD be one of these: End.DX6, End.DT6, The SRv6 Endpoint Behavior SHOULD be one of these: End.DX6, End.DT6,
End.DT46. or End.DT46.
6. BGP based Ethernet VPN (EVPN) over SRv6 6. BGP-Based Ethernet VPN (EVPN) over SRv6
[RFC7432] provides an extendable method of building an Ethernet VPN [RFC7432] provides an extendable method of building an EVPN overlay.
(EVPN) overlay. It primarily focuses on MPLS based EVPNs and It primarily focuses on MPLS-based EVPNs, and [RFC8365] extends to
[RFC8365] extends to IP-based EVPN overlays. [RFC7432] defines Route IP-based EVPN overlays. [RFC7432] defines Route Types 1, 2, and 3,
Types 1, 2, and 3 which carry prefixes and MPLS Label fields; the which carry prefixes and MPLS Label fields; the Label fields have a
Label fields have a specific use for MPLS encapsulation of EVPN specific use for MPLS encapsulation of EVPN traffic. Route Type 5
traffic. Route Type 5 carrying MPLS label information (and thus carrying MPLS label information (and thus encapsulation information)
encapsulation information) for EVPN is defined in [RFC9136]. Route for an EVPN is defined in [RFC9136]. Route Types 6, 7, and 8 are
Types 6, 7, and 8 are defined in [I-D.ietf-bess-evpn-igmp-mld-proxy]. defined in [RFC9251].
o Ethernet Auto-discovery Route (Route Type 1) * Ethernet Auto-Discovery (A-D) route (Route Type 1)
o MAC/IP Advertisement Route (Route Type 2) * MAC/IP Advertisement route (Route Type 2)
o Inclusive Multicast Ethernet Tag Route (Route Type 3) * Inclusive Multicast Ethernet Tag route (Route Type 3)
o Ethernet Segment route (Route Type 4) * Ethernet Segment route (Route Type 4)
o IP prefix route (Route Type 5) * IP Prefix route (Route Type 5)
o Selective Multicast Ethernet Tag route (Route Type 6) * Selective Multicast Ethernet Tag route (Route Type 6)
o Multicast Membership Report Synch route (Route Type 7) * Multicast Membership Report Synch route (Route Type 7)
o Multicast Leave Synch route (Route Type 8)
* Multicast Leave Synch route (Route Type 8)
The specifications for other EVPN Route Types are outside the scope The specifications for other EVPN Route Types are outside the scope
of this document. of this document.
To support SRv6 based EVPN overlays, one or more SRv6 Service SIDs To support SRv6-based EVPN overlays, one or more SRv6 Service SIDs
are advertised with Route Type 1, 2, 3, and 5. The SRv6 Service are advertised with Route Types 1, 2, 3, and 5. The SRv6 Service
SID(s) per Route Type are advertised in SRv6 L3/L2 Service TLVs SID(s) per Route Type is advertised in SRv6 L3/L2 Service TLVs within
within the BGP Prefix-SID Attribute. Signaling of SRv6 Service the BGP Prefix-SID attribute. Signaling of the SRv6 Service SID(s)
SID(s) serves two purposes - first, it indicates that the BGP egress serves two purposes -- first, it indicates that the BGP egress device
device supports SRv6 overlay and the BGP ingress device receiving supports SRv6 overlay, and the BGP ingress device receiving this
this route MUST perform IPv6 encapsulation and insert an SRH route MUST perform IPv6 encapsulation and insert an SRH [RFC8754]
[RFC8754] when required; second, it indicates the value of the when required; second, it indicates the value of the Service SID(s)
Service SID(s) to be used in the encapsulation. to be used in the encapsulation.
The SRv6 Service SID SHOULD be routable (refer section 3.3 of The SRv6 Service SID SHOULD be routable (refer to Section 3.3 of
[RFC8986]) within the AS of the egress PE and serves the dual purpose [RFC8986]) within the AS of the egress PE and serves the dual purpose
of providing reachability between ingress PE and egress PE while also of providing reachability between the ingress PE and egress PE while
encoding the SRv6 Endpoint behavior. also encoding the SRv6 Endpoint Behavior.
When steering for SRv6 services is based on shortest path forwarding When steering for SRv6 services is based on shortest path forwarding
(e.g., best-effort or IGP Flexible Algorithm (e.g., best effort or IGP Flexible Algorithm [IGP-FLEX-ALGO]) to the
[I-D.ietf-lsr-flex-algo]) to the egress PE, the ingress PE egress PE, the ingress PE encapsulates the customer Layer 2 Ethernet
encapsulates the customer Layer 2 Ethernet packet in an outer IPv6 packet in an outer IPv6 header (using H.Encaps.L2 or H.Encaps.L2.Red
header (using H.Encaps.L2 or H.Encaps.L2.Red flavors specified in flavors specified in [RFC8986]) where the destination address is the
[RFC8986]) where the destination address is the SRv6 Service SID SRv6 Service SID associated with the related BGP route update.
associated with the related BGP route update. Therefore, the ingress Therefore, the ingress PE MUST perform a resolvability check for the
PE MUST perform resolvability check for the SRv6 Service SID before SRv6 Service SID before considering the received prefix for the BGP
considering the received prefix for the BGP best path computation. best path computation. The resolvability is evaluated as per
The resolvability is evaluated as per [RFC4271]. If the SRv6 SID is [RFC4271]. If the SRv6 SID is reachable via more than one forwarding
reachable via more than one forwarding table, local policy is used to table, local policy is used to determine which table to use. The
determine which table to use. The result of an SRv6 Service SID result of an SRv6 Service SID resolvability (e.g., when provided via
resolvability (e.g., when provided via IGP Flexible Algorithm) can be IGP Flexible Algorithm) can be ignored if the ingress PE has a local
ignored if the ingress PE has a local policy that allows an alternate policy that allows an alternate steering mechanism to reach the
steering mechanism to reach the egress PE. The details of such egress PE. The details of such steering mechanisms are outside the
steering mechanisms are outside the scope of this document. scope of this document.
For service over SRv6 core, the egress PE sets the next-hop to one of For service over SRv6 core, the egress PE sets the BGP next hop to
its IPv6 addresses. Such an address MAY be covered by the SRv6 one of its IPv6 addresses. Such an address MAY be covered by the
Locator from which the SRv6 Service SID is allocated. The next-hop SRv6 Locator from which the SRv6 Service SID is allocated. The BGP
is used for tracking the reachability of the egress PE based on next hop is used for tracking the reachability of the egress PE based
existing BGP procedures. on existing BGP procedures.
When the BGP route is received at an ingress PE is colored with a When the BGP route received at an ingress PE is colored with a Color
Color Extended community and a valid SRv6 Policy is available, the Extended Community and a valid SRv6 Policy is available, the steering
steering for service flows is performed as described in Section 8 of for service flows is performed as described in Section 8 of
[I-D.ietf-spring-segment-routing-policy]. When the ingress PE [SEGMENT-ROUTING-POLICY]. When the ingress PE determines (with the
determines (with the help of SRv6 SID Structure) that the Service SID help of the SRv6 SID Structure) that the Service SID belongs to the
belongs to the same SRv6 Locator as the last SRv6 SID (of the egress same SRv6 Locator as the last SRv6 SID (of the egress PE) in the SR
PE) in the SR Policy segment list, it MAY exclude that last SRv6 SID Policy segment list, it MAY exclude that last SRv6 SID when steering
when steering the service flow. For example, the effective segment the service flow. For example, the effective segment list of the
list of the SRv6 Policy associated with SID list <S1, S2, S3> would SRv6 Policy associated with SID list <S1, S2, S3> would be <S1, S2,
be <S1, S2, S3-Service-SID>. S3-Service-SID>.
6.1. Ethernet Auto-discovery Route over SRv6 Core 6.1. Ethernet Auto-Discovery Route over SRv6 Core
Ethernet Auto-Discovery (A-D) routes are Route Type 1 defined in Ethernet A-D routes are Route Type 1, as defined in [RFC7432], and
[RFC7432] and may be used to achieve split-horizon filtering, fast may be used to achieve split-horizon filtering, fast convergence, and
convergence, and aliasing. EVPN Route Type 1 is also used in EVPN- aliasing. EVPN Route Type 1 is also used in EVPN-VPWS as well as in
VPWS as well as in EVPN flexible cross-connect; mainly used to EVPN-flexible cross-connect, mainly to advertise point-to-point
advertise point-to-point services ID. service IDs.
As a reminder, EVPN Route Type 1 is encoded as follows: As a reminder, EVPN Route Type 1 is encoded as follows:
+---------------------------------------+ +-----------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +-----------------------------------------+
|Ethernet Segment Identifier (10 octets)| | Ethernet Segment Identifier (10 octets)|
+---------------------------------------+ +-----------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +-----------------------------------------+
| MPLS label (3 octets) | | MPLS label (3 octets) |
+---------------------------------------+ +-----------------------------------------+
Figure 6: EVPN Route Type 1 Figure 6: EVPN Route Type 1
6.1.1. Ethernet A-D per ES Route 6.1.1. Ethernet A-D per ES Route
Ethernet A-D per ES route NLRI encoding over SRv6 core is as per Ethernet A-D per ES route NLRI encoding over SRv6 core is as per
[RFC7432]. [RFC7432].
The 24-bit ESI label field of the ESI label extended community The 24-bit ESI Label field of the ESI Label extended community
carries the whole or a portion of the Argument part of the SRv6 SID carries the whole or a portion of the Argument part of the SRv6 SID
when the ESI filtering approach is used along with the Transposition when the ESI filtering approach is used along with the Transposition
Scheme of encoding (Section 4) and otherwise set to Implicit NULL Scheme of encoding (Section 4); otherwise, it is set to Implicit NULL
value. In either case, the value is set in the high order 20 bits in the higher-order 20 bits (i.e., as 0x000030). In either case, the
(e.g., as 0x000030 in the case of Implicit NULL). When using the value is set in the 24 bits. When using the Transposition Scheme,
Transposition Scheme, the Transposition Length MUST be less than or the Transposition Length MUST be less than or equal to 24 and less
equal to 24 and less than or equal to the Argument Length. than or equal to the AL.
A Service SID enclosed in an SRv6 L2 Service TLV within the BGP A Service SID enclosed in an SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the A-D route. The Prefix-SID attribute is advertised along with the A-D route. The
SRv6 Endpoint behavior SHOULD be End.DT2M. When the ESI filtering SRv6 Endpoint Behavior SHOULD be End.DT2M. When the ESI filtering
approach is used, the Service SID is used to signal Arg.FE2 SID approach is used, the Service SID is used to signal the Arg.FE2 SID
Argument for applicable End.DT2M behavior [RFC8986]. When the local- Argument for applicable End.DT2M behavior [RFC8986]. When the local-
bias approach [RFC8365] is used, the Service SID MAY be of value 0. bias approach [RFC8365] is used, the Service SID MAY be of value 0.
6.1.2. Ethernet A-D per EVI Route 6.1.2. Ethernet A-D per EVI Route
Ethernet A-D per EVI route NLRI encoding over SRv6 core is similar to Ethernet A-D per EVPN Instance (EVI) route NLRI encoding over SRv6
[RFC7432] and [RFC8214] with the following change: core is similar to what is described in [RFC7432] and [RFC8214] with
the following change:
o MPLS Label: 24-bit field carries the whole or a portion of the MPLS Label:
Function part of the SRv6 SID when the Transposition Scheme of The 24-bit field carries the whole or a portion of the Function
encoding (Section 4) is used and otherwise set to Implicit NULL part of the SRv6 SID when the Transposition Scheme of encoding
value. In either case, the value is set in the high order 20 bits (Section 4) is used; otherwise, it is set to Implicit NULL in the
(e.g., as 0x000030 in the case of Implicit NULL). When using the higher-order 20 bits (i.e., as 0x000030). In either case, the
Transposition Scheme, the Transposition Length MUST be less than value is set in the 24 bits. When using the Transposition Scheme,
or equal to 24 and less than or equal to the Function Length. the Transposition Length MUST be less than or equal to 24 and less
than or equal to the FL.
A Service SID enclosed in an SRv6 L2 Service TLV within the BGP A Service SID enclosed in an SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the A-D route. The Prefix-SID attribute is advertised along with the A-D route. The
SRv6 Endpoint behavior SHOULD be one of these: End.DX2, End.DX2V, SRv6 Endpoint Behavior SHOULD be one of these: End.DX2, End.DX2V, or
End.DT2U. End.DT2U.
6.2. MAC/IP Advertisement Route over SRv6 Core 6.2. MAC/IP Advertisement Route over SRv6 Core
EVPN Route Type 2 is used to advertise unicast traffic MAC+IP address EVPN Route Type 2 is used to advertise unicast traffic Media Access
reachability through MP-BGP to all other PEs in a given EVPN Control (MAC) + IP address reachability through MP-BGP to all other
instance. PEs in a given EVPN instance.
As a reminder, EVPN Route Type 2 is encoded as follows: As a reminder, EVPN Route Type 2 is encoded as follows:
+---------------------------------------+ +-----------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +-----------------------------------------+
|Ethernet Segment Identifier (10 octets)| | Ethernet Segment Identifier (10 octets)|
+---------------------------------------+ +-----------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +-----------------------------------------+
| MAC Address Length (1 octet) | | MAC Address Length (1 octet) |
+---------------------------------------+ +-----------------------------------------+
| MAC Address (6 octets) | | MAC Address (6 octets) |
+---------------------------------------+ +-----------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +-----------------------------------------+
| IP Address (0, 4, or 16 octets) | | IP Address (0, 4, or 16 octets) |
+---------------------------------------+ +-----------------------------------------+
| MPLS Label1 (3 octets) | | MPLS Label1 (3 octets) |
+---------------------------------------+ +-----------------------------------------+
| MPLS Label2 (0 or 3 octets) | | MPLS Label2 (0 or 3 octets) |
+---------------------------------------+ +-----------------------------------------+
Figure 7: EVPN Route Type 2 Figure 7: EVPN Route Type 2
NLRI encoding over SRv6 core is similar to [RFC7432] with the NLRI encoding over SRv6 core is similar to what is described in
following changes: [RFC7432] with the following changes:
o MPLS Label1: Is associated with the SRv6 L2 Service TLV. This MPLS Label1:
24-bit field carries the whole or a portion of the Function part This is associated with the SRv6 L2 Service TLV. This 24-bit
of the SRv6 SID when the Transposition Scheme of encoding field carries the whole or a portion of the Function part of the
(Section 4) is used and otherwise set to Implicit NULL value. In SRv6 SID when the Transposition Scheme of encoding (Section 4) is
either case, the value is set in the high order 20 bits (e.g., as used; otherwise, it is set to Implicit NULL in the higher-order 20
0x000030 in the case of Implicit NULL). When using the bits (i.e., as 0x000030). In either case, the value is set in the
Transposition Scheme, the Transposition Length MUST be less than 24 bits. When using the Transposition Scheme, the Transposition
or equal to 24 and less than or equal to the Function Length. Length MUST be less than or equal to 24 and less than or equal to
the FL.
o MPLS Label2: Is associated with the SRv6 L3 Service TLV. This MPLS Label2:
24-bit field carries the whole or a portion of the Function part This is associated with the SRv6 L3 Service TLV. This 24-bit
of the SRv6 SID when the Transposition Scheme of encoding field carries the whole or a portion of the Function part of the
(Section 4) is used and otherwise set to Implicit NULL value. In SRv6 SID when the Transposition Scheme of encoding (Section 4) is
either case, the value is set in the high order 20 bits (e.g., as used; otherwise, it is set to Implicit NULL in the higher-order 20
0x000030 in the case of Implicit NULL). When using the bits (i.e., as 0x000030). In either case, the value is set in the
Transposition Scheme, the Transposition Length MUST be less than 24 bits. When using the Transposition Scheme, the Transposition
or equal to 24 and less than or equal to the Function Length. Length MUST be less than or equal to 24 and less than or equal to
the FL.
Service SIDs enclosed in SRv6 L2 Service TLV and optionally in SRv6 Service SIDs enclosed in the SRv6 L2 Service TLV and optionally in
L3 Service TLV within the BGP Prefix-SID attribute is advertised the SRv6 L3 Service TLV within the BGP Prefix-SID attribute are
along with the MAC/IP Advertisement route. advertised along with the MAC/IP Advertisement route.
Described below are different types of Route Type 2 advertisements. Described below are different types of Route Type 2 advertisements.
6.2.1. MAC/IP Advertisement Route with MAC Only 6.2.1. MAC/IP Advertisement Route with MAC Only
o MPLS Label1: Is associated with the SRv6 L2 Service TLV. This MPLS Label1:
24-bit field carries the whole or a portion of the Function part This is associated with the SRv6 L2 Service TLV. This 24-bit
of the SRv6 SID when the Transposition Scheme of encoding field carries the whole or a portion of the Function part of the
(Section 4) is used and otherwise set to Implicit NULL value. In SRv6 SID when the Transposition Scheme of encoding (Section 4) is
either case, the value is set in the high order 20 bits (e.g., as used; otherwise, it is set to Implicit NULL in the higher-order 20
0x000030 in the case of Implicit NULL). When using the bits (i.e., as 0x000030). In either case, the value is set in the
Transposition Scheme, the Transposition Length MUST be less than 24 bits. When using the Transposition Scheme, the Transposition
or equal to 24 and less than or equal to the Function Length. Length MUST be less than or equal to 24 and less than or equal to
the FL.
A Service SID enclosed in an SRv6 L2 Service TLV within the BGP A Service SID enclosed in an SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the route. The SRv6 Prefix-SID attribute is advertised along with the route. The SRv6
Endpoint behavior SHOULD be one of these: End.DX2, End.DT2U. Endpoint Behavior SHOULD be one of these: End.DX2 or End.DT2U.
6.2.2. MAC/IP Advertisement Route with MAC+IP 6.2.2. MAC/IP Advertisement Route with MAC+IP
o MPLS Label1: Is associated with the SRv6 L2 Service TLV. This MPLS Label1:
24-bit field carries the whole or a portion of the Function part This is associated with the SRv6 L2 Service TLV. This 24-bit
of the SRv6 SID when the Transposition Scheme of encoding field carries the whole or a portion of the Function part of the
(Section 4) is used and otherwise set to Implicit NULL value. In SRv6 SID when the Transposition Scheme of encoding (Section 4) is
either case, the value is set in the high order 20 bits (e.g., as used; otherwise, it is set to Implicit NULL in the higher-order 20
0x000030 in the case of Implicit NULL). When using the bits (i.e., as 0x000030). In either case, the value is set in the
Transposition Scheme, the Transposition Length MUST be less than 24 bits. When using the Transposition Scheme, the Transposition
or equal to 24 and less than or equal to the Function Length. Length MUST be less than or equal to 24 and less than or equal to
the FL.
o MPLS Label2: Is associated with the SRv6 L3 Service TLV. This MPLS Label2:
24-bit field carries the whole or a portion of the Function part This is associated with the SRv6 L3 Service TLV. This 24-bit
of the SRv6 SID when the Transposition Scheme of encoding field carries the whole or a portion of the Function part of the
(Section 4) is used and otherwise set to Implicit NULL value. In SRv6 SID when the Transposition Scheme of encoding (Section 4) is
either case, the value is set in the high order 20 bits (e.g., as used; otherwise, it is set to Implicit NULL in the higher-order 20
0x000030 in the case of Implicit NULL). When using the bits (i.e., as 0x000030). In either case, the value is set in the
Transposition Scheme, the Transposition Length MUST be less than 24 bits. When using the Transposition Scheme, the Transposition
or equal to 24 and less than or equal to the Function Length. Length MUST be less than or equal to 24 and less than or equal to
the FL.
An L2 Service SID enclosed in an SRv6 L2 Service TLV within the BGP An L2 Service SID enclosed in an SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the route. In Prefix-SID attribute is advertised along with the route. In
addition, an L3 Service SID enclosed in an SRv6 L3 Service TLV within addition, an L3 Service SID enclosed in an SRv6 L3 Service TLV within
the BGP Prefix-SID attribute MAY also be advertised along with the the BGP Prefix-SID attribute MAY also be advertised along with the
route. The SRv6 Endpoint behavior SHOULD be one of these: for the L2 route. The SRv6 Endpoint Behavior SHOULD be one of these: for the L2
Service SID - End.DX2, End.DT2U; for the L3 Service SID - End.DT46, Service SID, End.DX2 or End.DT2U and for the L3 Service SID,
End.DT4, End.DT6, End.DX4, End.DX6. End.DT46, End.DT4, End.DT6, End.DX4, or End.DX6.
6.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core 6.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core
EVPN Route Type 3 is used to advertise multicast traffic reachability EVPN Route Type 3 is used to advertise multicast traffic reachability
information through MP-BGP to all other PEs in a given EVPN instance. information through MP-BGP to all other PEs in a given EVPN instance.
As a reminder, EVPN Route Type 3 is encoded as follows: As a reminder, EVPN Route Type 3 is encoded as follows:
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
skipping to change at page 20, line 25 skipping to change at line 907
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| Originating Router's IP Address | | Originating Router's IP Address |
| (4 or 16 octets) | | (4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
Figure 8: EVPN Route Type 3 Figure 8: EVPN Route Type 3
NLRI encoding over SRv6 core is similar to [RFC7432]. NLRI encoding over SRv6 core is similar to what is described in
[RFC7432].
PMSI Tunnel Attribute [RFC6514] is used to identify the P-tunnel used The P-Multicast Service Interface (PMSI) Tunnel Attribute [RFC6514]
for sending broadcast, unknown unicast, or multicast (BUM) traffic. is used to identify the Provider tunnel (P-tunnel) used for sending
The format of PMSI Tunnel Attribute is encoded as follows over SRv6 Broadcast, Unknown Unicast, or Multicast (BUM) traffic. The format
Core: of the PMSI Tunnel Attribute is encoded as follows over SRv6 core:
+---------------------------------------+ +---------------------------------------+
| Flag (1 octet) | | Flag (1 octet) |
+---------------------------------------+ +---------------------------------------+
| Tunnel Type (1 octet) | | Tunnel Type (1 octet) |
+---------------------------------------+ +---------------------------------------+
| MPLS label (3 octet) | | MPLS label (3 octets) |
+---------------------------------------+ +---------------------------------------+
| Tunnel Identifier (variable) | | Tunnel Identifier (variable) |
+---------------------------------------+ +---------------------------------------+
Figure 9: PMSI Tunnel Attribute Figure 9: PMSI Tunnel Attribute
o Flag: zero value defined per [RFC7432] Flag:
This field has a value of 0, as defined per [RFC7432].
o Tunnel Type: defined per [RFC6514] Tunnel Type:
This field is defined per [RFC6514].
o MPLS label: This 24-bit field carries the whole or a portion of MPLS label:
the Function part of the SRv6 SID when ingress replication is used This 24-bit field carries the whole or a portion of the Function
and the Transposition Scheme of encoding (Section 4) is used and part of the SRv6 SID when ingress replication is used and the
otherwise, it is set as defined in [RFC6514]. When using the Transposition Scheme of encoding (Section 4) is used; otherwise,
Transposition Scheme, the Transposition Length MUST be less than it is set as defined in [RFC6514]. When using the Transposition
or equal to 24 and less than or equal to the Function Length. Scheme, the Transposition Length MUST be less than or equal to 24
and less than or equal to the FL.
o Tunnel Identifier: IP address of egress PE Tunnel Identifier:
This field is the IP address of egress PE.
A Service SID enclosed in an SRv6 L2 Service TLV within the BGP A Service SID enclosed in an SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the route. The SRv6 Prefix-SID attribute is advertised along with the route. The SRv6
Endpoint behavior SHOULD be End.DT2M. Endpoint Behavior SHOULD be End.DT2M.
o When ESI-based filtering is used for Multi-Homing or E-Tree * When ESI-based filtering is used for multihoming or Ethernet Tree
procedures, the ESI Filtering Argument (the Arg.FE2 notation (E-Tree) procedures, the ESI Filtering Argument (the Arg.FE2
introduced in [RFC8986]) of the Service SID carried along with notation introduced in [RFC8986]) of the Service SID carried along
EVPN Route Type 1 route SHOULD be merged with the applicable with EVPN Route Type 1 SHOULD be merged with the applicable
End.DT2M SID of Type 3 route advertised by remote PE by doing a End.DT2M SID of Route Type 3 advertised by the remote PE by doing
bit-wise logical-OR operation to create a single SID on the a bitwise logical-OR operation to create a single SID on the
ingress PE. Details of split-horizon ESI-based filtering ingress PE. Details of split-horizon, ESI-based filtering
mechanisms for multihoming are described in [RFC7432]. Details of mechanisms for multihoming are described in [RFC7432]. Details of
filtering mechanisms for Leaf-originated BUM traffic in EVPN filtering mechanisms for Leaf-originated BUM traffic in EVPN
E-Tree services are provided in [RFC8317]. E-Tree services are provided in [RFC8317].
o When "local-bias" is used as the Multi-Homing split-horizon * When "local-bias" is used as the multihoming split-horizon method,
method, the ESI Filtering Argument SHOULD NOT be merged with the the ESI Filtering Argument SHOULD NOT be merged with the
corresponding End.DT2M SID on the ingress PE. Details of the corresponding End.DT2M SID on the ingress PE. Details of the
"local-bias" procedures are described in [RFC8365]. local-bias procedures are described in [RFC8365].
Usage of multicast trees as P-tunnels is outside the scope of this Usage of multicast trees as P-tunnels is outside the scope of this
document. document.
6.4. Ethernet Segment Route over SRv6 Core 6.4. Ethernet Segment Route over SRv6 Core
As a reminder, an Ethernet Segment route (i.e., EVPN Route Type 4) is As a reminder, an Ethernet Segment route (i.e., EVPN Route Type 4) is
encoded as follows: encoded as follows:
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| Originating Router's IP Address | | Originating Router's IP Address |
| (4 or 16 octets) | | (4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
Figure 10: EVPN Route Type 4 Figure 10: EVPN Route Type 4
NLRI encoding over SRv6 core is similar to [RFC7432]. NLRI encoding over SRv6 core is similar to what is described in
[RFC7432].
SRv6 Service TLVs within the BGP Prefix-SID attribute are not SRv6 Service TLVs within the BGP Prefix-SID attribute are not
advertised along with this route. The processing of the route has advertised along with this route. The processing of the route has
not changed - it remains as described in [RFC7432]. not changed -- it remains as described in [RFC7432].
6.5. IP Prefix Route over SRv6 Core 6.5. IP Prefix Route over SRv6 Core
EVPN Route Type 5 is used to advertise IP address reachability EVPN Route Type 5 is used to advertise IP address reachability
through MP-BGP to all other PEs in a given EVPN instance. The IP through MP-BGP to all other PEs in a given EVPN instance. The IP
address may include a host IP prefix or any specific subnet. address may include a host IP prefix or any specific subnet.
As a reminder, EVPN Route Type 5 is encoded as follows: As a reminder, EVPN Route Type 5 is encoded as follows:
+---------------------------------------+ +-----------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +-----------------------------------------+
|Ethernet Segment Identifier (10 octets)| | Ethernet Segment Identifier (10 octets)|
+---------------------------------------+ +-----------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +-----------------------------------------+
| IP Prefix Length (1 octet) | | IP Prefix Length (1 octet) |
+---------------------------------------+ +-----------------------------------------+
| IP Prefix (4 or 16 octets) | | IP Prefix (4 or 16 octets) |
+---------------------------------------+ +-----------------------------------------+
| GW IP Address (4 or 16 octets) | | GW IP Address (4 or 16 octets) |
+---------------------------------------+ +-----------------------------------------+
| MPLS Label (3 octets) | | MPLS Label (3 octets) |
+---------------------------------------+ +-----------------------------------------+
Figure 11: EVPN Route Type 5 Figure 11: EVPN Route Type 5
NLRI encoding over SRv6 core is similar to [RFC9136] with the NLRI encoding over SRv6 core is similar to what is described in
following change: [RFC9136] with the following change:
o MPLS Label: This 24-bit field carries the whole or a portion of MPLS Label:
the Function part of the SRv6 SID when the Transposition Scheme of This 24-bit field carries the whole or a portion of the Function
encoding (Section 4) is used and otherwise set to Implicit NULL part of the SRv6 SID when the Transposition Scheme of encoding
value. In either case, the value is set in the high order 20 bits (Section 4) is used; otherwise, it is set to Implicit NULL in the
(e.g., as 0x000030 in the case of Implicit NULL). When using the higher-order 20 bits (i.e., as 0x000030). In either case, the
Transposition Scheme, the Transposition Length MUST be less than value is set in the 24 bits. When using the Transposition Scheme,
or equal to 24 and less than or equal to the Function Length. the Transposition Length MUST be less than or equal to 24 and less
than or equal to the FL.
SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.
SRv6 Endpoint behavior SHOULD be one of these: End.DT4, End.DT6, The SRv6 Endpoint Behavior SHOULD be one of these: End.DT4, End.DT6,
End.DT46, End.DX4, End.DX6. End.DT46, End.DX4, or End.DX6.
6.6. EVPN Multicast Routes (Route Types 6, 7, 8) over SRv6 Core 6.6. EVPN Multicast Routes (Route Types 6, 7, and 8) over SRv6 Core
These routes do not require the advertisement of SRv6 Service TLVs These routes do not require the advertisement of SRv6 Service TLVs
along with them. Similar to EVPN Route Type 4, the BGP Nexthop is along with them. Similar to EVPN Route Type 4, the BGP next hop is
equal to the IPv6 address of egress PE. equal to the IPv6 address of egress PE.
7. Implementation Status 7. Error Handling
[Note to RFC Editor: This section needs to be removed before
publication as RFC.]
The [I-D.matsushima-spring-srv6-deployment-status] describes the
current deployment and implementation status of SRv6 which also
includes the BGP services over SRv6 as specified in this document.
8. Error Handling
In case of any errors encountered while processing SRv6 Service TLVs, In case of any errors encountered while processing SRv6 Service TLVs,
the details of the error SHOULD be logged for further analysis. the details of the error SHOULD be logged for further analysis.
If multiple instances of SRv6 L3 Service TLV are encountered, all but If multiple instances of the SRv6 L3 Service TLV are encountered, all
the first instance MUST be ignored. but the first instance MUST be ignored.
If multiple instances of SRv6 L2 Service TLV are encountered, all but If multiple instances of the SRv6 L2 Service TLV are encountered, all
the first instance MUST be ignored. but the first instance MUST be ignored.
An SRv6 Service TLV is considered malformed in the following cases: An SRv6 Service TLV is considered malformed in the following cases:
o the TLV Length is less than 1 * The TLV Length is less than 1.
o the TLV Length is inconsistent with the length of BGP Prefix-SID * The TLV Length is inconsistent with the length of the BGP Prefix-
attribute SID attribute.
o at least one of the constituent Sub-TLVs is malformed * At least one of the constituent Sub-TLVs is malformed.
An SRv6 Service Sub-TLV is considered malformed in the following An SRv6 Service Sub-TLV is considered malformed in the following
cases: case:
o the Sub-TLV Length is inconsistent with the length of the * The Sub-TLV Length is inconsistent with the length of the
enclosing SRv6 Service TLV enclosing SRv6 Service TLV.
An SRv6 SID Information Sub-TLV is considered malformed in the An SRv6 SID Information Sub-TLV is considered malformed in the
following cases: following cases:
* the Sub-TLV Length is less than 21 * The Sub-TLV Length is less than 21.
* the Sub-TLV Length is inconsistent with the length of the
enclosing SRv6 Service TLV
* at least one of the constituent Sub-Sub-TLVs is malformed * The Sub-TLV Length is inconsistent with the length of the
enclosing SRv6 Service TLV.
* At least one of the constituent Sub-Sub-TLVs is malformed.
An SRv6 Service Data Sub-Sub-TLV is considered malformed in the An SRv6 Service Data Sub-Sub-TLV is considered malformed in the
following cases: following case:
o the Sub-Sub-TLV Length is inconsistent with the length of the * The Sub-Sub-TLV Length is inconsistent with the length of the
enclosing SRv6 service Sub-TLV enclosing SRv6 service Sub-TLV.
Any TLV or Sub-TLV or Sub-Sub-TLV is not considered malformed because Any TLV, Sub-TLV, or Sub-Sub-TLV is not considered malformed because
its Type is unrecognized. its Type is unrecognized.
Any TLV or Sub-TLV or Sub-Sub-TLV is not considered malformed because Any TLV, Sub-TLV, or Sub-Sub-TLV is not considered malformed because
of failing any semantic validation of its Value field. of failing any semantic validation of its Value field.
SRv6 overlay service requires Service SID for forwarding. The treat- The SRv6 overlay service requires the Service SID for forwarding.
as-withdraw action [RFC7606] MUST be performed when at least one The treat-as-withdraw action [RFC7606] MUST be performed when at
malformed SRV6 Service TLV is present in the BGP Prefix-SID least one malformed SRv6 Service TLV is present in the BGP Prefix-SID
attribute. attribute.
SRv6 SID value in SRv6 SID Information Sub-TLV is invalid when SID The SRv6 SID value in the SRv6 SID Information Sub-TLV is invalid
Structure Sub-Sub-TLV transposition length is greater than the number when the SID Structure Sub-Sub-TLV transposition length is greater
of bits of the label field or if any of the conditions for the fields than the number of bits of the label field or if any of the
of the sub-sub-TLV as specified in Section 3.2.1 is not met. The conditions for the fields of the Sub-Sub-TLV, as specified in
transposition offset and length MUST be 0 when the Sub-Sub-TLV is Section 3.2.1, is not met. The transposition offset and length MUST
advertised along with routes where transposition scheme is not be 0 when the Sub-Sub-TLV is advertised along with routes where the
applicable (e.g., for Global IPv6 Service [RFC2545] where there is no Transposition Scheme is not applicable (e.g., for global IPv6 service
label field). The path having such Prefix-SID Attribute without any [RFC2545] where there is no label field). The path having any such
valid SRv6 SID information MUST be considered ineligible during the Prefix-SID attribute without any valid SRv6 SID information MUST be
selection of the best path for the corresponding prefix. considered ineligible during the selection of the best path for the
corresponding prefix.
9. IANA Considerations 8. IANA Considerations
9.1. BGP Prefix-SID TLV Types Registry 8.1. BGP Prefix-SID TLV Types Registry
This document introduces two new TLV Types of the BGP Prefix-SID This document introduces two new TLV Types of the BGP Prefix-SID
attribute. IANA has assigned Type values in the registry "BGP attribute. IANA has assigned Type values in the "BGP Prefix-SID TLV
Prefix-SID TLV Types" as follows: Types" subregistry as follows:
Value Type Reference +=======+=====================+===========+
-------------------------------------------- | Value | Type | Reference |
4 Deprecated <this document> +=======+=====================+===========+
5 SRv6 L3 Service TLV <this document> | 4 | Deprecated | RFC 9252 |
6 SRv6 L2 Service TLV <this document> +-------+---------------------+-----------+
| 5 | SRv6 L3 Service TLV | RFC 9252 |
+-------+---------------------+-----------+
| 6 | SRv6 L2 Service TLV | RFC 9252 |
+-------+---------------------+-----------+
Figure 12: BGP Prefix-SID TLV Types Table 1: BGP Prefix-SID TLV Types
Subregistry
The value 4 previously corresponded to the SRv6-VPN SID TLV, which Value 4 previously corresponded to the SRv6-VPN SID TLV, which was
was specified in previous versions of this document and used by early specified in earlier draft versions of this document and used by
implementations of this specification. It was deprecated and early implementations of this specification. It was deprecated and
replaced by the SRv6 L3 Service and SRv6 L2 Service TLVs. replaced by the SRv6 L3 Service and SRv6 L2 Service TLVs.
9.2. SRv6 Service Sub-TLV Types Registry 8.2. SRv6 Service Sub-TLV Types Registry
IANA is requested to create and maintain a new registry called "SRv6 IANA has created and now maintains a new subregistry called "SRv6
Service Sub-TLV Types" under the "Border Gateway Protocol (BGP) Service Sub-TLV Types" under the "Border Gateway Protocol (BGP)
Parameters" registry. The allocation policy for this registry is: Parameters" registry. The registration procedures, per [RFC8126],
for this subregistry are according to Table 2.
0 : Reserved +=========+=========================+
1-127 : IETF Review | Range | Registration Procedures |
128-254 : First Come First Served +=========+=========================+
255 : Reserved | 1-127 | IETF Review |
+---------+-------------------------+
| 128-254 | First Come First Served |
+---------+-------------------------+
| 255 | IETF Review |
+---------+-------------------------+
Figure 13: SRv6 Service Sub-TLV Types Allocation Policy Table 2: SRv6 Service Sub-TLV
Types Subregistry Registration
Procedures
The following Sub-TLV Type is defined in this document: IANA has populated this subregistry as follows. Note that the SRv6
SID Information Sub-TLV is defined in this document:
Value Type Reference +=======+==============================+===========+
---------------------------------------------------- | Value | Type | Reference |
1 SRv6 SID Information Sub-TLV <this document> +=======+==============================+===========+
| 0 | Reserved | RFC 9252 |
+-------+------------------------------+-----------+
| 1 | SRv6 SID Information Sub-TLV | RFC 9252 |
+-------+------------------------------+-----------+
| 255 | Reserved | RFC 9252 |
+-------+------------------------------+-----------+
Figure 14: SRv6 Service Sub-TLV Types Table 3: SRv6 Service Sub-TLV Types Subregistry
Initial Contents
9.3. SRv6 Service Data Sub-Sub-TLV Types Registry 8.3. SRv6 Service Data Sub-Sub-TLV Types Registry
IANA is requested to create and maintain a new registry called "SRv6 IANA has created and now maintains a new subregistry called "SRv6
Service Data Sub-Sub-TLV Types" under the "Border Gateway Protocol Service Data Sub-Sub-TLV Types" under the "Border Gateway Protocol
(BGP) Parameters" registry. The allocation policy for this registry (BGP) Parameters" registry. The registration procedures for this
is: subregistry are according to Table 4.
0 : Reserved +=========+=========================+
1-127 : IETF Review | Range | Registration Procedure |
128-254 : First Come First Served +=========+=========================+
255 : Reserved | 1-127 | IETF Review |
+---------+-------------------------+
| 128-254 | First Come First Served |
+---------+-------------------------+
| 255 | IETF Review |
+---------+-------------------------+
Figure 15: SRv6 Service Data Sub-Sub-TLV Types Allocation Policy Table 4: SRv6 Service Data Sub-
Sub-TLV Types Subregistry
Registration Procedures
The following Sub-Sub-TLV Type is defined in this document: The following Sub-Sub-TLV Type is defined in this document:
Value Type Reference +=======+================================+===========+
---------------------------------------------------- | Value | Type | Reference |
1 SRv6 SID Structure Sub-Sub-TLV <this document> +=======+================================+===========+
| 0 | Reserved | RFC 9252 |
+-------+--------------------------------+-----------+
| 1 | SRv6 SID Structure Sub-Sub-TLV | RFC 9252 |
+-------+--------------------------------+-----------+
| 255 | Reserved | RFC 9252 |
+-------+--------------------------------+-----------+
Figure 16: SRv6 Service Data Sub-Sub-TLV Types Table 5: SRv6 Service Data Sub-Sub-TLV Types
Subregistry Initial Contents
9.4. BGP SRv6 Service SID Flags Registry 8.4. BGP SRv6 Service SID Flags Registry
IANA is requested to create and maintain a new registry called "BGP IANA has created and now maintains a new subregistry called "BGP SRv6
SRv6 Service SID Flags" under the "Border Gateway Protocol (BGP) Service SID Flags" under the "Border Gateway Protocol (BGP)
Parameters" registry. The allocation policy for this registry is Parameters" registry. The registration procedure for this
IETF Review and all 8 bit positions of the flags are currently subregistry is IETF Review, and all 8-bit positions of the flags are
unassigned. currently unassigned.
9.5. Subsequent Address Family Identifiers (SAFI) Parameters Registry 8.5. SAFI Values Registry
IANA is requested to add this document as a reference for value 128 IANA has added this document as a reference for value 128 ("MPLS-
in the "Subsequent Address Family Identifiers (SAFI) Parameters" labeled VPN address") in the "SAFI Values" subregistry under the
registry. "Subsequent Address Family Identifiers (SAFI) Parameters" registry.
10. Security Considerations 9. Security Considerations
This document specifies extensions to the BGP protocol for signaling This document specifies extensions to the BGP protocol for the
of services for SRv6. These specifications leverage existing BGP signaling of services for SRv6. These specifications leverage
protocol mechanisms for the signaling of various types of services. existing BGP protocol mechanisms for the signaling of various types
It also builds upon existing elements of the SR architecture (more of services. It also builds upon existing elements of the SR
specifically SRv6). As such, this section largely provides pointers architecture (more specifically, SRv6). As such, this section
(as a reminder) to the security considerations of those existing largely provides pointers (as a reminder) to the security
specifications while also covering certain newer security aspects for considerations of those existing specifications while also covering
the specifications newly introduced by this document. certain, newer security aspects for the specifications newly
introduced by this document.
10.1. BGP Session Related Considerations 9.1. Considerations Related to BGP Sessions
Techniques related to authentication of BGP sessions for securing Techniques related to authentication of BGP sessions for securing
messages between BGP peers as discussed in the BGP specification messages between BGP peers, as discussed in the BGP specification
[RFC4271] and, in the security analysis for BGP [RFC4272] apply. The [RFC4271] and in the security analysis for BGP [RFC4272], apply. The
discussion of the use of the TCP Authentication option to protect BGP discussion of the use of the TCP Authentication Option to protect BGP
sessions is found in [RFC5925], while [RFC6952] includes an analysis sessions is found in [RFC5925], while [RFC6952] includes an analysis
of BGP keying and authentication issues. This document does not of BGP keying and authentication issues. This document does not
introduce any additional BGP session security considerations. introduce any additional BGP session security considerations.
10.2. BGP Services Related Considerations 9.2. Considerations Related to BGP Services
This document does not introduce new services or BGP NLRI types but This document does not introduce new services or BGP NLRI types but
extends the signaling of existing ones for SRv6. Therefore, the extends the signaling of existing ones for SRv6. Therefore, the
security considerations for the respective BGP services BGP IPv4 over security considerations for the respective BGP services, such as BGP
IPv6 NH [RFC8950], BGP IPv6 L3VPN [RFC4659], BGP IPv6 [RFC2545], BGP IPv4 over IPv6 NH [RFC8950], BGP IPv6 L3VPN [RFC4659], BGP IPv6
EVPN [RFC7432] and IP EVPN [RFC9136] apply as discussed in their [RFC2545], BGP EVPN [RFC7432], and IP EVPN [RFC9136], apply as
respective documents. [RFC8669] discusses mechanisms to prevent discussed in their respective documents. [RFC8669] discusses
leaking of BGP Prefix-SID attribute, that carries SR information, mechanisms to prevent the leaking of the BGP Prefix-SID attribute,
outside the SR domain. which carries SR information, outside the SR domain.
As a reminder, several of the BGP services (i.e., the AFI/SAFI used As a reminder, several of the BGP services (i.e., the AFI/SAFI used
for their signaling) were initially introduced for one encapsulation for their signaling) were initially introduced for one encapsulation
mechanism and later extended for others e.g., EVPN MPLS [RFC7432] was mechanism and later extended for others, e.g., EVPN MPLS [RFC7432]
extended for VXLAN/NVGRE encapsulation [RFC8365]. [RFC9012] enables was extended for Virtual eXtensible Local Area Network (VXLAN)
the use of various IP encapsulation mechanisms along with different encapsulation and Network Virtualization Using Generic Routing
BGP SAFIs for their respective services. The existing filtering Encapsulation (NVGRE) [RFC8365]. [RFC9012] enables the use of
mechanisms for preventing the leak of the encapsulation information various IP encapsulation mechanisms along with different BGP SAFIs
(carried in BGP attributes) and to prevent the advertisement of for their respective services. The existing filtering mechanisms for
prefixes from the provider's internal address space (especially the preventing the leak of the encapsulation information (carried in BGP
SRv6 Block as discussed in [RFC8986]) to external peers (or into the attributes) and preventing the advertisement of prefixes from the
Internet) also apply in the case of SRv6. provider's internal address space (especially the SRv6 Block, as
discussed in [RFC8986]) to external peers (or into the Internet) also
apply in the case of SRv6.
Specific to SRv6, a misconfig or error in the above mentioned BGP Specific to SRv6, a misconfiguration or error in the BGP filtering
filtering mechanisms may result in exposing information such as SRv6 mechanisms mentioned above may result in exposing information, such
Service SIDs to external peers or other unauthorized entities. as SRv6 Service SIDs to external peers or other unauthorized
However, an attempt to exploit this information or to raise an attack entities. However, an attempt to exploit this information or to
by injecting packets into the network (e.g. customer networks in case raise an attack by injecting packets into the network (e.g., customer
of VPN services) is mitigated by the existing SRv6 data plane networks in case of VPN services) is mitigated by the existing SRv6
security mechanisms as described in the next section. data plane security mechanisms, as described in the next section.
10.3. SR over IPv6 Data Plane Related Considerations 9.3. Considerations Related to SR over IPv6 Data Plane
This section provides a brief reminder and an overview of the This section provides a brief reminder and an overview of the
security considerations related to SRv6 with pointers to existing security considerations related to SRv6 with pointers to existing
specifications. This document introduces no new security specifications. This document introduces no new security
considerations of its own from the SRv6 data plane perspective. considerations of its own from the SRv6 data plane perspective.
SRv6 operates within a trusted SR domain. The data packets SRv6 operates within a trusted SR domain. The data packets
corresponding to service flows between PE routers are encapsulated corresponding to service flows between PE routers are encapsulated
(using SRv6 SIDs advertised via BGP) and carried within this trusted (using SRv6 SIDs advertised via BGP) and carried within this trusted
SR domain (e.g., within a single AS or between multiple ASes within a SR domain (e.g., within a single AS or between multiple ASes within a
single provider network). single provider network).
The security considerations of the Segment Routing architecture are The security considerations of the SR architecture are covered by
covered by [RFC8402]. More detailed security considerations [RFC8402]. More detailed security considerations, specifically of
specifically of SRv6 and SRH are covered by [RFC8754] as they relate SRv6 and SRH, are covered by [RFC8754] as they relate to SR Attacks
to SR Attacks (section 7.1), Service Theft (section 7.2) and Topology (Section 7.1), Service Theft (Section 7.2), and Topology Disclosure
Disclosure (section 7.3). As such an operator deploying SRv6 MUST (Section 7.3). As such, an operator deploying SRv6 MUST follow the
follow the considerations described in [RFC8754] section 7 to considerations described in Section 7 of [RFC8754] to implement the
implement the infrastructure ACLs, BCP 38 [RFC2827] and BCP 84 infrastructure Access Control Lists (ACLs) and the recommendations
[RFC3704] recommendations. described in BCP 38 [RFC2827] and BCP 84 [RFC3704].
The SRv6 deployment and SID allocation guidelines as described in The SRv6 deployment and SID allocation guidelines, as described in
[RFC8986] simplify the deployment of the ACL filters (e.g., a single [RFC8986], simplify the deployment of the ACL filters (e.g., a single
ACL corresponding to the SRv6 Block applied to the external ACL corresponding to the SRv6 Block applied to the external
interfaces on border nodes is sufficient to block packets destined to interfaces on border nodes is sufficient to block packets destined to
any SRv6 SID in the domain from external/unauthorized networks). any SRv6 SID in the domain from external/unauthorized networks).
While there is an assumed trust model within a SR domain such that While there is an assumed trust model within an SR domain, such that
any node sending packet to an SRv6 SID is assumed to be allowed to do any node sending a packet to an SRv6 SID is assumed to be allowed to
so, there is also the option of using SRH HMAC TLV [RFC8754] as do so, there is also the option of using an SRH Hashed Message
described in [RFC8986] for validation. Authentication Code (HMAC) TLV [RFC8754], as described in [RFC8986],
for validation.
The SRv6 SID Endpoint behaviors implementing the services signalled The SRv6 Endpoint Behaviors implementing the services signaled in
in this document are defined in [RFC8986] and hence the security this document are defined in [RFC8986]; hence, the security
considerations of that document apply. These considerations are considerations of that document apply. These considerations are
independent of the protocol used for service deployment, i.e. independent of the protocol used for service deployment, i.e.,
independent of BGP signaling of SRv6 services. independent of BGP signaling of SRv6 services.
These considerations help protect transit traffic as well as These considerations help protect transit traffic as well as
services, such as VPNs, to avoid service theft or injection of services, such as VPNs, to avoid service theft or injection of
traffic into customer VPN. traffic into customer VPNs.
11. Acknowledgments
The authors of this document would like to thank Stephane Litkowski,
Rishabh Parekh, Xiejingrong, Rajesh M, Mustapha Aissaoui, Alexander
Vainshtein, Eduard Metz, Shraddha Hegde, Eduard Vasilenko, Ron
Bonica, and Joel Halpern for their comments and review of this
document. The authors would also like to thank Matthew Bocci for his
document shepherd review and Martin Vigoureux for his AD review that
resulted in helpful comments for improving this document.
12. Contributors
Clarence Filsfils
Cisco
Email: cfilsfil@cisco.com
Satoru Matsushima
SoftBank
Email: satoru.matsushima@g.softbank.co.jp
Dirk Steinberg
Steinberg Consulting
Email: dirk@lapishills.com
Daniel Bernier
Bell Canada
Email: daniel.bernier@bell.ca
Daniel Voyer
Bell Canada
Email: daniel.voyer@bell.ca
Jonn Leddy
Individual
Email: john@leddy.net
Swadesh Agrawal
Cisco
Email: swaagraw@cisco.com
Patrice Brissette
Cisco
Email: pbrisset@cisco.com
Ali Sajassi
Cisco
Email: sajassi@cisco.com
Bart Peirens
Proximus
Belgium
Email: bart.peirens@proximus.com
Darren Dukes
Cisco
Email: ddukes@cisco.com
Pablo Camarilo
Cisco
Email: pcamaril@cisco.com
Shyam Sethuram
Cisco
Email: shyam.ioml@gmail.com
Zafar Ali
Cisco
Email: zali@cisco.com
13. References
13.1. Normative References 10. References
[I-D.ietf-bess-evpn-igmp-mld-proxy] 10.1. Normative References
Sajassi, A., Thoria, S., Mishra, M., Drake, J., and W.
Lin, "IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn-
igmp-mld-proxy-20 (work in progress), March 2022.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545, Extensions for IPv6 Inter-Domain Routing", RFC 2545,
DOI 10.17487/RFC2545, March 1999, DOI 10.17487/RFC2545, March 1999,
<https://www.rfc-editor.org/info/rfc2545>. <https://www.rfc-editor.org/info/rfc2545>.
skipping to change at page 32, line 38 skipping to change at line 1432
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, (SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021, DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>. <https://www.rfc-editor.org/info/rfc8986>.
[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and [RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
A. Sajassi, "IP Prefix Advertisement in Ethernet VPN A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021, (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
<https://www.rfc-editor.org/info/rfc9136>. <https://www.rfc-editor.org/info/rfc9136>.
13.2. Informative References [RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
and W. Lin, "Internet Group Management Protocol (IGMP) and
[I-D.ietf-idr-segment-routing-te-policy] Multicast Listener Discovery (MLD) Proxies for Ethernet
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,
Jain, D., and S. Lin, "Advertising Segment Routing <https://www.rfc-editor.org/info/rfc9251>.
Policies in BGP", draft-ietf-idr-segment-routing-te-
policy-16 (work in progress), March 2022.
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-18 (work in progress), October 2021.
[I-D.ietf-spring-segment-routing-policy] 10.2. Informative References
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-21 (work in progress),
March 2022.
[I-D.matsushima-spring-srv6-deployment-status] [IGP-FLEX-ALGO]
Matsushima, S., Filsfils, C., Ali, Z., Li, Z., Rajaraman, Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
K., and A. Dhamija, "SRv6 Implementation and Deployment and A. Gulko, "IGP Flexible Algorithm", Work in Progress,
Status", draft-matsushima-spring-srv6-deployment-status-13 Internet-Draft, draft-ietf-lsr-flex-algo-20, 18 May 2022,
(work in progress), March 2022. <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-
flex-algo-20>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>. May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>. 2004, <https://www.rfc-editor.org/info/rfc3704>.
skipping to change at page 33, line 44 skipping to change at line 1474
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>. <https://www.rfc-editor.org/info/rfc6952>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012, "The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021, DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>. <https://www.rfc-editor.org/info/rfc9012>.
[SEGMENT-ROUTING-POLICY]
Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
Work in Progress, Internet-Draft, draft-ietf-spring-
segment-routing-policy-22, 22 March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
segment-routing-policy-22>.
Acknowledgements
The authors of this document would like to thank Stephane Litkowski,
Rishabh Parekh, Xiejingrong, Rajesh M., Mustapha Aissaoui, Alexander
Vainshtein, Eduard Metz, Shraddha Hegde, Eduard Vasilenko, Ron
Bonica, and Joel Halpern for their comments and review of this
document. The authors would also like to thank Document Shepherd
Matthew Bocci for his review and AD Martin Vigoureux for his review
that resulted in helpful comments for improving this document.
Contributors
Clarence Filsfils
Cisco
Email: cfilsfil@cisco.com
Satoru Matsushima
SoftBank
Email: satoru.matsushima@g.softbank.co.jp
Dirk Steinberg
Steinberg Consulting
Email: dirk@lapishills.com
Daniel Bernier
Bell Canada
Email: daniel.bernier@bell.ca
Daniel Voyer
Bell Canada
Email: daniel.voyer@bell.ca
Jonn Leddy
Individual
Email: john@leddy.net
Swadesh Agrawal
Cisco
Email: swaagraw@cisco.com
Patrice Brissette
Cisco
Email: pbrisset@cisco.com
Ali Sajassi
Cisco
Email: sajassi@cisco.com
Bart Peirens
Proximus
Belgium
Email: bart.peirens@proximus.com
Darren Dukes
Cisco
Email: ddukes@cisco.com
Pablo Camarilo
Cisco
Email: pcamaril@cisco.com
Shyam Sethuram
Cisco
Email: shyam.ioml@gmail.com
Zafar Ali
Cisco
Email: zali@cisco.com
Authors' Addresses Authors' Addresses
Gaurav Dawra (editor) Gaurav Dawra (editor)
LinkedIn LinkedIn
USA United States of America
Email: gdawra.ietf@gmail.com Email: gdawra.ietf@gmail.com
Ketan Talaulikar (editor) Ketan Talaulikar (editor)
Cisco Systems Cisco Systems
India India
Email: ketant.ietf@gmail.com Email: ketant.ietf@gmail.com
Robert Raszuk Robert Raszuk
NTT Network Innovations NTT Network Innovations
940 Stewart Dr 940 Stewart Dr.
Sunnyvale, CA 94085 Sunnyvale, CA 94085
USA United States of America
Email: robert@raszuk.net Email: robert@raszuk.net
Bruno Decraene Bruno Decraene
Orange Orange
France France
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Shunwan Zhuang Shunwan Zhuang
Huawei Technologies Huawei Technologies
China China
Email: zhuangshunwan@huawei.com Email: zhuangshunwan@huawei.com
Jorge Rabadan Jorge Rabadan
Nokia Nokia
USA United States of America
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
 End of changes. 226 change blocks. 
896 lines changed or deleted 936 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/