rfc9513.original   rfc9513.txt 
Link State Routing Z. Li Internet Engineering Task Force (IETF) Z. Li
Internet-Draft Z. Hu Request for Comments: 9513 Z. Hu
Intended status: Standards Track Huawei Technologies Category: Standards Track Huawei Technologies
Expires: 23 December 2023 K. Talaulikar, Ed. ISSN: 2070-1721 K. Talaulikar, Ed.
P. Psenak P. Psenak
Cisco Systems Cisco Systems
21 June 2023 November 2023
OSPFv3 Extensions for SRv6 OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)
draft-ietf-lsr-ospfv3-srv6-extensions-15
Abstract Abstract
The Segment Routing (SR) architecture allows a flexible definition of The Segment Routing (SR) architecture allows a flexible definition of
the end-to-end path by encoding it as a sequence of topological the end-to-end path by encoding it as a sequence of topological
elements called segments. It can be implemented over an MPLS or IPv6 elements called segments. It can be implemented over an MPLS or IPv6
data plane. This document describes the OSPFv3 extensions required data plane. This document describes the OSPFv3 extensions required
to support Segment Routing over the IPv6 data plane (SRv6). to support SR over the IPv6 data plane.
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 23 December 2023. 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/rfc9513.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
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 Capabilities TLV . . . . . . . . . . . . . . . . . . . . 4 2. SRv6 Capabilities TLV
3. Advertisement of Supported Algorithms . . . . . . . . . . . . 5 3. Advertisement of Supported Algorithms
4. Advertisement of Maximum SRv6 SID Depths . . . . . . . . . . 5 4. Advertisement of Maximum SRv6 SID Depths
4.1. Maximum Segments Left MSD Type . . . . . . . . . . . . . 6 4.1. Maximum Segments Left MSD Type
4.2. Maximum End Pop MSD Type . . . . . . . . . . . . . . . . 6 4.2. Maximum End Pop MSD Type
4.3. Maximum H.Encaps MSD Type . . . . . . . . . . . . . . . . 6 4.3. Maximum H.Encaps MSD Type
4.4. Maximum End D MSD Type . . . . . . . . . . . . . . . . . 6 4.4. Maximum End D MSD Type
5. SRv6 SIDs and Reachability . . . . . . . . . . . . . . . . . 6 5. SRv6 SIDs and Reachability
5.1. SRv6 Flexible Algorithm . . . . . . . . . . . . . . . . . 8 5.1. SRv6 Flexible Algorithm
6. Advertisement of Anycast Property . . . . . . . . . . . . . . 9 6. Advertisement of Anycast Property
7. SRv6 Locator LSA . . . . . . . . . . . . . . . . . . . . . . 10 7. SRv6 Locator LSA
7.1. SRv6 Locator TLV . . . . . . . . . . . . . . . . . . . . 11 7.1. SRv6 Locator TLV
7.2. SRv6 Locator Sub-TLVs . . . . . . . . . . . . . . . . . . 13 7.2. SRv6 Locator Sub-TLVs
8. Advertisement of SRv6 End SIDs . . . . . . . . . . . . . . . 14 8. Advertisement of SRv6 End SIDs
9. Advertisement of SRv6 SIDs Associated with Adjacencies . . . 15 9. Advertisement of SRv6 SIDs Associated with Adjacencies
9.1. SRv6 End.X SID Sub-TLV . . . . . . . . . . . . . . . . . 16 9.1. SRv6 End.X SID Sub-TLV
9.2. SRv6 LAN End.X SID Sub-TLV . . . . . . . . . . . . . . . 18 9.2. SRv6 LAN End.X SID Sub-TLV
10. SRv6 SID Structure Sub-TLV . . . . . . . . . . . . . . . . . 19 10. SRv6 SID Structure Sub-TLV
11. Advertising Endpoint Behaviors . . . . . . . . . . . . . . . 21 11. Advertising Endpoint Behaviors
12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 12. Security Considerations
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 13. IANA Considerations
13.1. OSPF Router Information TLVs . . . . . . . . . . . . . . 22 13.1. OSPF Router Information TLVs
13.2. OSPFv3 LSA Function Codes . . . . . . . . . . . . . . . 23 13.2. OSPFv3 LSA Function Codes
13.3. OSPFv3 Prefix Options . . . . . . . . . . . . . . . . . 23 13.3. OSPFv3 Prefix Options
13.4. OSPFv3 SRv6 Capabilities TLV Flags . . . . . . . . . . . 23 13.4. OSPFv3 SRv6 Capabilities TLV Flags
13.5. OSPFv3 SRv6 End SID Sub-TLV Flags . . . . . . . . . . . 23 13.5. OSPFv3 SRv6 End SID Sub-TLV Flags
13.6. OSPFv3 SRv6 Adjacency SID Sub-TLV Flags . . . . . . . . 24 13.6. OSPFv3 SRv6 Adjacency SID Sub-TLV Flags
13.7. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . . . 24 13.7. OSPFv3 Extended-LSA Sub-TLVs
13.8. OSPFv3 SRv6 Locator LSA TLVs . . . . . . . . . . . . . . 24 13.8. OSPFv3 SRv6 Locator LSA TLVs
13.9. OSPFv3 SRv6 Locator LSA Sub-TLVs . . . . . . . . . . . . 25 13.9. OSPFv3 SRv6 Locator LSA Sub-TLVs
13.10. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . . . 26 13.10. OSPFv3 Extended-LSA Sub-TLVs
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 14. References
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 14.1. Normative References
15.1. Normative References . . . . . . . . . . . . . . . . . . 27 14.2. Informative References
15.2. Informative References . . . . . . . . . . . . . . . . . 29 Acknowledgements
Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The Segment Routing (SR) architecture [RFC8402] specifies how a node The Segment Routing (SR) architecture [RFC8402] specifies how a node
can steer a packet using an ordered list of instructions, called can steer a packet using an ordered list of instructions called
segments. These segments are identified using Segment Identifiers segments. These segments are identified using Segment Identifiers
(SIDs). (SIDs).
Segment Routing can be instantiated on the IPv6 data plane through SR can be instantiated on the IPv6 data plane through the use of the
the use of the Segment Routing Header (SRH) defined in [RFC8754]. Segment Routing Header (SRH) defined in [RFC8754]. SR instantiation
Segment Routing instantiation on the IPv6 dataplane is referred to as on the IPv6 data plane is referred to as SRv6.
SRv6.
The network programming paradigm for SRv6 is specified in [RFC8986]. The network programming paradigm for SRv6 is specified in [RFC8986].
It describes how any behavior can be bound to a SID and how any It describes how any behavior can be bound to a SID and how any
network program can be expressed as a combination of SIDs. It also network program can be expressed as a combination of SIDs. It also
describes several well-known behaviors that can be bound to SRv6 describes several well-known behaviors that can be bound to SRv6
SIDs. SIDs.
This document specifies OSPFv3 extensions to support SRv6 This document specifies OSPFv3 extensions to support SRv6
capabilities as defined in [RFC8986], [RFC8754], and [RFC9259]. The capabilities as defined in [RFC8986], [RFC8754], and [RFC9259]. The
extensions include advertisement of an OSPFv3 router's SRv6 extensions include advertisement of an OSPFv3 router's SRv6
capabilities, SRv6 Locators, and required SRv6 SIDs along with their capabilities, SRv6 Locators, and required SRv6 SIDs along with their
supported endpoint behaviors. Familiarity with [RFC8986] is supported Endpoint behaviors. Familiarity with [RFC8986] is
necessary to understand the extensions specified in this document. necessary to understand the extensions specified in this document.
At a high level, the extensions to OSPFv3 are comprised of the At a high level, the extensions to OSPFv3 are comprised of the
following: following:
1. An SRv6 Capabilities TLV to advertise the SRv6 features and SRH 1. An SRv6 Capabilities TLV to advertise the SRv6 features and SRH
operations supported by an OSPFv3 router operations supported by an OSPFv3 router.
2. Several sub-TLVs to advertise various SRv6 Maximum SID Depths. 2. Several sub-TLVs to advertise various SRv6 Maximum SID Depths.
3. An SRv6 Locator TLV using an SRv6 Locator Link-State 3. An SRv6 Locator TLV using an SRv6 Locator Link State
Advertisement (LSA) to advertise the SRv6 Locator - a form of Advertisement (LSA) to advertise the SRv6 Locator -- a form of
summary address for the IGP algorithm-specific SIDs instantiated summary address for the IGP algorithm-specific SIDs instantiated
on an OSPFv3 router on an OSPFv3 router.
4. TLVs and Sub-TLVs to advertise the SRv6 SIDs instantiated on an 4. TLVs and sub-TLVs to advertise the SRv6 SIDs instantiated on an
OSPFv3 router along with their endpoint behaviors OSPFv3 router along with their Endpoint behaviors.
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 Capabilities TLV 2. SRv6 Capabilities TLV
The SRv6 Capabilities TLV is used by an OSPFv3 router to advertise The SRv6 Capabilities TLV is used by an OSPFv3 router to advertise
its support for the SR Segment Endpoint Node [RFC8754] functionality its support for the SR Segment Endpoint Node [RFC8754] functionality
along with its SRv6-related capabilities. This is an optional top along with its SRv6-related capabilities. This is an optional top-
level TLV of the OSPFv3 Router Information LSA [RFC7770] which MUST level TLV of the OSPFv3 Router Information LSA [RFC7770] that MUST be
be advertised by an SRv6-enabled router. advertised by an SRv6-enabled router.
This TLV MUST be advertised only once in the OSPFv3 Router This TLV MUST be advertised only once in the OSPFv3 Router
Information LSA. When multiple SRv6 Capabilities TLVs are received Information LSA. When multiple SRv6 Capabilities TLVs are received
from a given router, the receiver MUST use the first occurrence of from a given router, the receiver MUST use the first occurrence of
the TLV in the OSPFv3 Router Information LSA. If the SRv6 the TLV in the OSPFv3 Router Information LSA. If the SRv6
Capabilities TLV appears in multiple OSPFv3 Router Information LSAs Capabilities TLV appears in multiple OSPFv3 Router Information LSAs
that have different flooding scopes, the TLV in the OSPFv3 Router that have different flooding scopes, the TLV in the OSPFv3 Router
Information LSA with the area-scoped flooding scope MUST be used. If Information LSA with the area-scoped flooding scope MUST be used. If
the SRv6 Capabilities TLV appears in multiple OSPFv3 Router the SRv6 Capabilities TLV appears in multiple OSPFv3 Router
Information LSAs that have the same flooding scope, the TLV in the Information LSAs that have the same flooding scope, the TLV in the
OSPFv3 Router Information LSA with the numerically smallest Link OSPFv3 Router Information LSA with the numerically smallest Link
State ID MUST be used and subsequent instances of the TLV MUST be State ID MUST be used, and subsequent instances of the TLV MUST be
ignored. ignored.
The OSPFv3 Router Information LSA can be advertised at any of the The OSPFv3 Router Information LSA can be advertised at any of the
defined flooding scopes (link, area, or Autonomous System (AS)). For defined flooding scopes (link, area, or Autonomous System (AS)). For
the purpose of SRv6 Capabilities TLV advertisement, area-scoped the purpose of SRv6 Capabilities TLV advertisement, area-scoped
flooding is REQUIRED. Link and AS-scoped flooding is OPTIONAL. flooding is REQUIRED. Link and AS-scoped flooding is OPTIONAL.
The format of OSPFv3 SRv6 Capabilities TLV is shown below: The format of the OSPFv3 SRv6 Capabilities TLV is shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs... | Sub-TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SRv6 Capabilities TLV Figure 1: SRv6 Capabilities TLV
Where: where:
* Type: 2-octet field. The value for this type is 20. Type: 2-octet field. The value for this type is 20.
* Length: 2-octet field. The total length (in octets) of the value Length: 2-octet field. The total length (in octets) of the value
portion of the TLV including nested Sub-TLVs. portion of the TLV, including nested sub-TLVs.
* Reserved: 2-octet field. It MUST be set to 0 on transmission and Reserved: 2-octet field. It MUST be set to 0 on transmission and
MUST be ignored on receipt. MUST be ignored on receipt.
* Flags: 2-octet field. The flags are defined as follows: Flags: 2-octet field. The flags are defined as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |O| | | |O| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
- O-flag: If set, then the router is capable of supporting the O-flag: If set, then the router is capable of supporting the
O-bit in the SRH flags, as specified in [RFC9259]. O-flag in the SRH flags, as specified in [RFC9259].
- Other flags are not defined and are reserved for future use. Other flags are not defined and are reserved for future use.
They MUST be set to 0 on transmission and MUST be ignored on They MUST be set to 0 on transmission and MUST be ignored on
receipt. receipt.
The SRv6 Capabilities TLV may contain optional Sub-TLVs. No Sub-TLVs The SRv6 Capabilities TLV may contain optional sub-TLVs. No sub-TLVs
are defined in this specification. are defined in this specification.
3. Advertisement of Supported Algorithms 3. Advertisement of Supported Algorithms
An SRv6-enabled OSPFv3 router advertises its algorithm support using An SRv6-enabled OSPFv3 router advertises its algorithm support using
the SR-Algorithm TLV defined in [RFC8665] as described in [RFC8666]. the SR-Algorithm TLV defined in [RFC8665] and as described in
[RFC8666].
4. Advertisement of Maximum SRv6 SID Depths 4. Advertisement of Maximum SRv6 SID Depths
An SRv6-enabled router may have different capabilities and limits An SRv6-enabled router may have different capabilities and limits
related to SRH processing and these need to be advertised to other related to SRH processing. These need to be advertised to other
OSPFv3 routers in the SRv6 domain. OSPFv3 routers in the SRv6 domain.
[RFC8476] defines the means to advertise node and link specific [RFC8476] defines the means to advertise node- and link-specific
values for Maximum SID Depth (MSD) types. Node MSDs are advertised values for Maximum SID Depth (MSD) types. Node MSDs are advertised
using the Node MSD TLV in the OSPFv3 Router Information LSA [RFC7770] using the Node MSD TLV in the OSPFv3 Router Information LSA
while Link MSDs are advertised using the Link MSD Sub-TLV of the [RFC7770], while Link MSDs are advertised using the Link MSD sub-TLV
Router-Link TLV [RFC8362]. The format of the MSD types for OSPFv3 is of the Router-Link TLV [RFC8362]. The format of the MSD types for
defined in [RFC8476]. OSPFv3 is defined in [RFC8476].
The MSD types for SRv6 that are defined in section 4 of [RFC9352] for The MSD types for SRv6 that are defined in Section 4 of [RFC9352] for
IS-IS are also used by OSPFv3. These MSD Types are allocated under IS-IS are also used by OSPFv3. These MSD types are allocated in the
the IGP MSD Types registry maintained by IANA that are shared by IS- "IGP MSD-Types" registry maintained by IANA and are shared by IS-IS
IS and OSPF. They are described below: and OSPF. They are described in the subsections below.
4.1. Maximum Segments Left MSD Type 4.1. Maximum Segments Left MSD Type
The Maximum Segments Left MSD Type signals the maximum value of the The Maximum Segments Left MSD Type signals the maximum value of the
"Segments Left" field of the SRH of a received packet before applying Segments Left field of the SRH of a received packet before applying
the Endpoint behavior associated with a SID. If no value is the Endpoint behavior associated with a SID. If no value is
advertised, the supported value is assumed to be 0. advertised, the supported value is assumed to be 0.
4.2. Maximum End Pop MSD Type 4.2. Maximum End Pop MSD Type
The Maximum End Pop MSD Type signals the maximum number of SIDs in The Maximum End Pop MSD Type signals the maximum number of SIDs in
the SRH to which the router can apply "Penultimate Segment Pop (PSP) the SRH to which the router can apply "Penultimate Segment Pop (PSP)
of the SRH" or "Ultimate Segment Pop (USP) of the SRH", as defined in of the SRH" or "Ultimate Segment Pop (USP) of the SRH", which are
[RFC8986] flavors. If the advertised value is zero or no value is flavors defined in [RFC8986]. If the advertised value is zero or no
advertised, then the router cannot apply PSP or USP flavors. value is advertised, then the router cannot apply the PSP or USP
flavors.
4.3. Maximum H.Encaps MSD Type 4.3. Maximum H.Encaps MSD Type
The Maximum H.Encaps MSD Type signals the maximum number of SIDs that The Maximum H.Encaps MSD Type signals the maximum number of SIDs that
can be added as part of the "H.Encaps" behavior as defined in can be added as part of the H.Encaps behavior as defined in
[RFC8986]. If the advertised value is zero or no value is advertised [RFC8986]. If the advertised value is zero or no value is
then the headend can apply an SR Policy that only contains one advertised, then the headend can apply an SR Policy that only
segment, without inserting any SRH. A non-zero SRH Max H.encaps MSD contains one segment without inserting any SRH. A non-zero SRH Max
indicates that the headend can insert an SRH with SIDs up to the H.Encaps MSD indicates that the headend can insert an SRH with SIDs
advertised value. up to the advertised value.
4.4. Maximum End D MSD Type 4.4. Maximum End D MSD Type
The Maximum End D MSD Type specifies the maximum number of SIDs The Maximum End D MSD Type specifies the maximum number of SIDs
present in an SRH when performing decapsulation. These include, but present in an SRH when performing decapsulation. These include, but
are not limited to, End.DX6, End.DT4, End.DT46, End with USD, and are not limited to, End.DX6, End.DT4, End.DT46, End with USD, and
End.X with USD as defined in [RFC8986]. If the advertised value is End.X with USD as defined in [RFC8986]. If the advertised value is
zero or no value is advertised, then the router cannot apply any zero or no value is advertised, then the router cannot apply any
behavior that results in decapsulation and forwarding of the inner behavior that results in decapsulation and forwarding of the inner
packet when the outer IPv6 header contains an SRH. packet when the outer IPv6 header contains an SRH.
5. SRv6 SIDs and Reachability 5. SRv6 SIDs and Reachability
An SRv6 Segment Identifier (SID) is 128 bits and consists of Locator, An SRv6 SID is 128 bits and consists of locator, function, and
Function, and Argument parts as described in [RFC8986]. argument parts as described in [RFC8986].
An OSPFv3 router is provisioned with algorithm-specific locators for An OSPFv3 router is provisioned with algorithm-specific locators for
each algorithm supported by that router. Each locator is a covering each algorithm supported by that router. Each locator is a covering
prefix for all SIDs provisioned on that router that have the matching prefix for all SIDs provisioned on that router that have the matching
algorithm. algorithm.
Locators MUST be advertised within an SRv6 Locator TLV (see Locators MUST be advertised within an SRv6 Locator TLV (see
Section 7.1) using an SRv6 Locator LSA (see Section 7). The SRv6 Section 7.1) using an SRv6 Locator LSA (see Section 7). The SRv6
Locator LSA is introduced instead of reusing the respective Extended Locator LSA is introduced instead of reusing the respective Extended
Prefix LSAs [RFC8362] for a clear distinction between the two Prefix LSAs [RFC8362] for a clear distinction between the two
different types of reachability advertisements (viz., the base OSPFv3 different types of reachability advertisements (viz., the base OSPFv3
prefix reachability advertisements and the SRv6 Locator reachability prefix reachability advertisements and the SRv6 Locator reachability
advertisements). advertisements).
Forwarding entries for the locators advertised in the SRv6 Locator Forwarding entries for the locators advertised in the SRv6 Locator
TLV MUST be installed in the forwarding plane of receiving TLV MUST be installed in the forwarding plane of receiving
SRv6-capable routers when the associated algorithm is supported by SRv6-capable routers when the associated algorithm is supported by
the receiving OSPFv3 router. Locators can be of different route the receiving OSPFv3 router. Locators can be of different route
types that map to existing OSPFv3 LSA types - Intra-Area, Inter-Area, types that map to existing OSPFv3 LSA types: Intra-Area, Inter-Area,
External, and NSSA. The advertisement and propagation of the SRv6 External, and Not-So-Stubby Area (NSSA). The advertisement and
Locator LSAs also follow the OSPFv3 [RFC5340] specifications for the propagation of the SRv6 Locator LSAs also follow the OSPFv3 [RFC5340]
respective LSA types. The processing of the prefix advertised in the specifications for the respective LSA types. The processing of the
SRv6 Locator TLV, the calculation of its reachability, and the prefix advertised in the SRv6 Locator TLV, the calculation of its
installation in the forwarding plane follows the OSPFv3 [RFC5340] reachability, and the installation in the forwarding plane follows
specifications for the respective LSA types. the OSPFv3 [RFC5340] specifications for the respective LSA types.
Locators associated with algorithms 0 and 1 (refer section 3.1.1 of Locators associated with algorithms 0 and 1 (refer to Section 3.1.1
[RFC8402]) SHOULD also be advertised using OSPFv3 Extended LSA types of [RFC8402]) SHOULD also be advertised using Extended LSA types with
with extended TLVs [RFC8362] so that routers that do not support SRv6 extended TLVs [RFC8362] so that routers that do not support SRv6 will
will install a forwarding entry for SRv6 traffic matching those install a forwarding entry for SRv6 traffic matching those locators.
locators. When operating in Extended LSA sparse-mode [RFC8362], When operating in Extended LSA sparse-mode [RFC8362], these locators
these locators SHOULD be also advertised using legacy OSPFv3 LSAs SHOULD also be advertised using Legacy LSAs [RFC5340].
[RFC5340].
When SRv6 Locators are also advertised as Intra-Area-Prefix-LSAs and/ When SRv6 Locators are also advertised as Intra-Area-Prefix-LSAs and/
or E-Intra-Area-Prefix-LSAs, the SRv6 Locator MUST be considered as a or E-Intra-Area-Prefix-LSAs, the SRv6 Locator MUST be considered as a
prefix associated with the router and the referenced LSA type MUST prefix associated with the router, and the referenced LSA type MUST
point to the Router LSA of the advertising router as specified in point to the Router LSA of the advertising router as specified in
Section 4.4.3.9 of [RFC5340]. Section 4.4.3.9 of [RFC5340].
In cases where a locator advertisement is received both in a prefix In cases where a locator advertisement is received both in a prefix
reachability advertisement (i.e., via legacy OSPFv3 LSAs and/or reachability advertisement (i.e., via Legacy LSAs and/or Extended
Extended Prefix TLVs using OSPFv3 Extended LSAs) and an SRv6 Locator Prefix TLVs using Extended LSAs) and an SRv6 Locator TLV, the prefix
TLV, the prefix reachability advertisement in the OSPFv3 legacy LSA reachability advertisement in the Legacy LSA or Extended LSA MUST be
or Extended LSA MUST be preferred over the advertisement in the SRv6 preferred over the advertisement in the SRv6 Locator TLV when
Locator TLV when installing entries in the forwarding plane. This is installing entries in the forwarding plane. This prevents
to prevent inconsistent forwarding entries between SRv6 capable and inconsistent forwarding entries between SRv6-capable and
SRv6 incapable OSPFv3 routers. Such preference for prefix SRv6-incapable OSPFv3 routers. Such preference for prefix
reachability advertisement does not have any impact on the rest of reachability advertisement does not have any impact on the rest of
the data advertised in the SRv6 Locator TLV. the data advertised in the SRv6 Locator TLV.
SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except SRv6 SIDs are advertised as sub-TLVs in the SRv6 Locator TLV except
for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a for SRv6 End.X SIDs and LAN End.X SIDs, which are associated with a
specific Neighbor/Link and are therefore advertised as Sub-TLVs of specific neighbor/link and are therefore advertised as sub-TLVs of
the E-Router-Link TLV. the E-Router-Link TLV.
SRv6 SIDs received from other OSFPv3 routers are not directly SRv6 SIDs received from other OSFPv3 routers are not directly
routable and MUST NOT be installed in the forwarding plane. routable and MUST NOT be installed in the forwarding plane.
Reachability to SRv6 SIDs depends upon the existence of a covering Reachability to SRv6 SIDs depends upon the existence of a covering
locator. locator.
Adherence to the rules defined in this section will ensure that SRv6 Adherence to the rules defined in this section will ensure that SRv6
SIDs associated with a supported algorithm will be forwarded SIDs associated with a supported algorithm will be forwarded
correctly, while SRv6 SIDs associated with an unsupported algorithm correctly, while SRv6 SIDs associated with an unsupported algorithm
will be dropped. NOTE: The drop behavior depends on the absence of a will be dropped.
default/summary route matching the locator prefix.
| NOTE: The drop behavior depends on the absence of a default/
| summary route matching the locator prefix.
If the locator associated with SRv6 SID advertisements is the longest If the locator associated with SRv6 SID advertisements is the longest
prefix match installed in the forwarding plane for those SIDs, this prefix match installed in the forwarding plane for those SIDs, this
will ensure correct forwarding. Network operators should take steps will ensure correct forwarding. Network operators should take steps
to make sure that this requirement is not compromised. For example, to make sure that this requirement is not compromised. For example,
the following situations should be avoided: the following situations should be avoided:
* Another locator associated with a different algorithm is the * Another locator associated with a different algorithm is the
longest prefix match longest prefix match.
* Another prefix advertised via OSPFv3 legacy or Extended LSA * Another prefix advertised via Legacy or Extended LSA advertisement
advertisement is the longest prefix match is the longest prefix match.
5.1. SRv6 Flexible Algorithm 5.1. SRv6 Flexible Algorithm
[RFC9350] specifies IGP Flexible Algorithm mechanisms for OSPFv3. [RFC9350] specifies IGP Flexible Algorithm mechanisms for OSPFv3.
Section 14.2 of [RFC9350] explains SRv6 forwarding for Flexible Section 14.2 of [RFC9350] explains SRv6 forwarding for Flexible
Algorithm and analogous procedures apply for supporting SRv6 Flexible Algorithms, and analogous procedures apply for supporting SRv6
Algorithm using OSPFv3. When the algorithm value that is advertised Flexible Algorithms using OSPFv3. When the algorithm value that is
in the SRv6 Locator TLV (refer to Section 7.1) represents a Flexible advertised in the SRv6 Locator TLV (refer to Section 7.1) represents
Algorithm, the procedures described in section 14.2 of [RFC9350] are a Flexible Algorithm, the procedures described in Section 14.2 of
followed for the programming of those specific SRv6 Locators. [RFC9350] are followed for the programming of those specific SRv6
Locators.
Locators associated with Flexible Algorithms SHOULD NOT be advertised Locators associated with Flexible Algorithms SHOULD NOT be advertised
in the base OSPFv3 prefix reachability advertisements. Advertising in the base OSPFv3 prefix reachability advertisements. Advertising
the Flexible Algorithm locator in a regular prefix reachability the Flexible Algorithm locator in a regular prefix reachability
advertisement would make it available for non-Flexible Algorithm advertisement would make it available for non-Flexible Algorithm
forwarding (i.e., algorithm 0). forwarding (i.e., algorithm 0).
The procedures for OSPFv3 Flexible Algorithm for SR-MPLS, as The procedures for OSPFv3 Flexible Algorithm for SR-MPLS, as
specified in [RFC9350], like ASBR reachability, inter-area, external, specified in [RFC9350], also apply for SRv6; these procedures include
and NSSA prefix advertisements and their use in Flexible Algorithm a) ASBR reachability, b) inter-area, external, and NSSA prefix
route computation also apply for SRv6. advertisements, and c) the use of those prefix advertisements in
Flexible Algorithm route computation.
6. Advertisement of Anycast Property 6. Advertisement of Anycast Property
Both prefixes and SRv6 Locators may be configured as anycast and as Both prefixes and SRv6 Locators may be configured as anycast, and as
such the same value can be advertised by multiple routers. It is such, the same value can be advertised by multiple routers. It is
useful for other routers to know that the advertisement is for an useful for other routers to know that the advertisement is for an
anycast identifier. anycast identifier.
A new bit in OSPFv3 PrefixOptions [RFC5340] is defined to advertise The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340]
the anycast property: is defined to advertise the anycast property:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
|AC|EL| N|DN| P| x|LA|NU| |AC|EL| N|DN| P| x|LA|NU|
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
Figure 2: OSPFv3 Prefix Options Field Figure 2: OSPFv3 Prefix Options Field
Value: 0x80
Description: Anycast (AC-bit)
When the prefix/SRv6 Locator is configured as anycast, the AC-bit When the prefix/SRv6 Locator is configured as anycast, the AC-bit
MUST be set. Otherwise, this flag MUST be clear. MUST be set. Otherwise, this flag MUST be clear.
The AC-bit MUST be preserved when re-advertising the prefix/SRv6 The AC-bit MUST be preserved when re-advertising the prefix/SRv6
Locator across areas. Locator across areas.
The AC-bit and the N-bit MUST NOT both be set. If both N-bit and AC- The AC-bit and the N-bit MUST NOT both be set. If the N-bit and AC-
bit are set in the prefix/SRv6 Locator advertisement, the receiving bit are both set in the prefix/SRv6 Locator advertisement, the
routers MUST ignore the N-bit. receiving routers MUST ignore the N-bit.
The same prefix/SRv6 Locator can be advertised by multiple routers. The same prefix/SRv6 Locator can be advertised by multiple routers.
If at least one of them sets the AC-bit in its advertisement, the If at least one of them sets the AC-bit in its advertisement, the
prefix/SRv6 Locator is considered as anycast. prefix/SRv6 Locator is considered as anycast.
A prefix/SRv6 Locator that is advertised by a single node and without A prefix/SRv6 Locator that is advertised by a single node and without
an AC-bit is considered node-specific. an AC-bit is considered node-specific.
All the nodes advertising the same anycast SRv6 Locator MUST All the nodes advertising the same anycast SRv6 Locator MUST
instantiate the exact same set of SIDs under that anycast SRv6 instantiate the exact same set of SIDs under that anycast SRv6
Locator. Failure to do so may result in traffic being dropped or Locator. Failure to do so may result in traffic being dropped or
misrouted. misrouted.
The PrefixOptions field is common to the prefix reachability The PrefixOptions field is common to the prefix reachability
advertisements (i.e., the base OSPFv3 prefix LSA types defined in advertisements (i.e., the base OSPFv3 prefix LSA types defined in
[RFC5340] and the OSPFv3 Extended Prefix TLV types defined in [RFC5340], the OSPFv3 Extended Prefix TLV types defined in
[RFC8362]) and the SRv6 Locator TLV advertisements specified in [RFC8362]), and the SRv6 Locator TLV advertisements specified in
Section 7.1 of this document. When a router originates both the Section 7.1 of this document. When a router originates both the
prefix reachability advertisement and the SRv6 Locator advertisement prefix reachability advertisement and the SRv6 Locator advertisement
for a given prefix, the router SHOULD advertise the same for a given prefix, the router SHOULD advertise the same
PrefixOptions bits in both advertisements. In the case of any PrefixOptions bits in both advertisements. In the case of any
inconsistency between the PrefixOptions advertised in the SRv6 inconsistency between the PrefixOptions advertised in the SRv6
Locator and in the prefix reachability advertisements, the ones Locator and in the prefix reachability advertisements, the ones
advertised in prefix reachability advertisement MUST be preferred. advertised in the prefix reachability advertisement MUST be
preferred.
7. SRv6 Locator LSA 7. SRv6 Locator LSA
The SRv6 Locator LSA has a function code of 42. The S1/S2 bits are The SRv6 Locator LSA has a function code of 42. The S1/S2 bits are
dependent on the desired flooding scope for the LSA. The flooding dependent on the desired flooding scope for the LSA. The flooding
scope of the SRv6 Locator LSA depends on the scope of the advertised scope of the SRv6 Locator LSA depends on the scope of the advertised
SRv6 Locator and is under the control of the advertising router. The SRv6 Locator and is under the control of the advertising router. The
U-bit will be set indicating that the LSA should be flooded even if U-bit will be set indicating that the LSA should be flooded even if
it is not understood. it is not understood.
Multiple SRv6 Locator LSAs can be advertised by an OSPFv3 router and Multiple SRv6 Locator LSAs can be advertised by an OSPFv3 router, and
they are distinguished by their Link State IDs (which are chosen they are distinguished by their Link State IDs (which are chosen
arbitrarily by the originating router). arbitrarily by the originating router).
The format of SRv6 Locator LSA is shown below: The format of the SRv6 Locator LSA is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |U|S12| Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |U|S12| Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
Figure 3: SRv6 Locator LSA Figure 3: SRv6 Locator LSA
The format of the TLVs within the body of the SRv6 Locator LSA is the The format of the TLVs within the body of the SRv6 Locator LSA is the
same as the format used by [RFC3630]. The variable TLV section same as the format used by [RFC3630]. The variable TLV section
consists of one or more nested TLV tuples. Nested TLVs are also consists of one or more nested TLV tuples. Nested TLVs are also
referred to as Sub-TLVs. The format of each TLV is: referred to as sub-TLVs. The format of each TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | | Value... |
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SRv6 Locator LSA TLV Format Figure 4: SRv6 Locator LSA TLV Format
The Length field defines the length of the value portion in octets The Length field defines the length of the value portion in octets
(thus, a TLV with no value portion would have a length of 0). The (thus, a TLV with no value portion would have a length of 0). The
TLV is padded to 4-octet alignment; padding is not included in the TLV is padded to 4-octet alignment; padding is not included in the
Length field (so a 3-octet value would have a length of 3, but the Length field (so a 3-octet value would have a length of 3, but the
total size of the TLV would be 8 octets). Nested TLVs are also total size of the TLV would be 8 octets). Nested TLVs are also
32-bit aligned. For example, a 1-byte value would have the Length 32-bit aligned. For example, a 1-byte value would have the Length
field set to 1 and 3 octets of padding would be added to the end of field set to 1, and 3 octets of padding would be added to the end of
the value portion of the TLV. The padding is composed of zeros. the value portion of the TLV. The padding is composed of zeros.
7.1. SRv6 Locator TLV 7.1. SRv6 Locator TLV
The SRv6 Locator TLV is a top-level TLV of the SRv6 Locator LSA that The SRv6 Locator TLV is a top-level TLV of the SRv6 Locator LSA that
is used to advertise an SRv6 Locator, its attributes, and SIDs is used to advertise an SRv6 Locator, its attributes, and SIDs
associated with it. Multiple SRv6 Locator TLVs MAY be advertised in associated with it. Multiple SRv6 Locator TLVs MAY be advertised in
each SRv6 Locator LSA. However, since the S12 bits define the each SRv6 Locator LSA. However, since the S12 bits define the
flooding scope, the LSA flooding scope has to satisfy the flooding scope, the LSA flooding scope has to satisfy the
application-specific requirements for all the locators included in a application-specific requirements for all the locators included in a
single SRv6 Locator LSA. single SRv6 Locator LSA.
When multiple SRv6 Locator TLVs are received from a given router in When multiple SRv6 Locator TLVs are received from a given router in
an SRv6 Locator LSA for the same Locator, the receiver MUST use the an SRv6 Locator LSA for the same locator, the receiver MUST use the
first occurrence of the TLV in the LSA. If the SRv6 Locator TLV for first occurrence of the TLV in the LSA. If the SRv6 Locator TLV for
the same Locator appears in multiple SRv6 Locator LSAs that have the same locator appears in multiple SRv6 Locator LSAs that have
different flooding scopes, the TLV in the SRv6 Locator LSA with the different flooding scopes, the TLV in the SRv6 Locator LSA with the
area-scoped flooding scope MUST be used. If the SRv6 Locator TLV for area-scoped flooding scope MUST be used. If the SRv6 Locator TLV for
the same Locator appears in multiple SRv6 Locator LSAs that have the the same locator appears in multiple SRv6 Locator LSAs that have the
same flooding scope, the TLV in the SRv6 Locator LSA with the same flooding scope, the TLV in the SRv6 Locator LSA with the
numerically smallest Link-State ID MUST be used and subsequent numerically smallest Link State ID MUST be used, and subsequent
instances of the TLV MUST be ignored. instances of the TLV MUST be ignored.
The format of SRv6 Locator TLV is shown below: The format of the SRv6 Locator TLV is shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Algorithm | Locator Length| PrefixOptions | | Route Type | Algorithm | Locator Length| PrefixOptions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator (up to 16 octets) ... | | Locator (up to 16 octets) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Locator continued ... | | ... Locator continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Locator continued ... | | ... Locator continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Locator concluded | | ... Locator concluded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) | | Sub-TLVs (variable) |
+- -+ +- -+
| ... | | ... |
Figure 5: SRv6 Locator TLV Figure 5: SRv6 Locator TLV
Where: where:
Type: 2-octet field. The value for this type is 1. Type: 2-octet field. The value for this type is 1.
Length: 2-octet field. The total length (in octets) of the value Length: 2-octet field. The total length (in octets) of the value
portion of the TLV including nested Sub-TLVs. portion of the TLV, including nested sub-TLVs.
Route Type: 1-octet field. The type of the locator route. The Route Type: 1-octet field. The type of the locator route. The only
only supported types are the ones listed below and the SRv6 supported types are the ones listed below, and the SRv6 Locator
Locator TLV MUST be ignored on receipt of any other type. TLV MUST be ignored on receipt of any other type.
1 - Intra-Area 1: Intra-Area
2 - Inter-Area 2: Inter-Area
3 - AS External Type 1 3: AS External Type 1
4 - AS External Type 2 4: AS External Type 2
5 - NSSA External Type 1 5: NSSA External Type 1
6 - NSSA External Type 2 6: NSSA External Type 2
Algorithm: 1-octet field. The algorithm associated with the SRv6 Algorithm: 1-octet field. The algorithm associated with the SRv6
Locator. Algorithm values are defined in the IGP Algorithm Type Locator. Algorithm values are defined in the "IGP Algorithm
registry [RFC8665]. Types" registry [RFC8665].
Locator Length: 1-octet field. Specifies the length of the Locator Length: 1-octet field. Specifies the length of the locator
Locator prefix as the number of locator bits from the range prefix as the number of locator bits from the range (1-128).
(1-128).
PrefixOptions: 1-octet field. Specifies the prefix options bits/ PrefixOptions: 1-octet field. Specifies the prefix options bits/
flags as specified in [RFC5340] and further extended by [RFC8362] flags as specified in [RFC5340] and further extended by [RFC8362]
and Section 6 of this document. and Section 6 of this document.
Metric: 4-octet field. The metric value associated with the SRv6 Metric: 4-octet field. The metric value associated with the SRv6
Locator. The metric value of 0xFFFFFFFF MUST be considered as Locator. The metric value of 0xFFFFFFFF MUST be considered as
unreachable. unreachable.
Locator: Up to 16-octet field. This field encodes the advertised Locator: 1-16 octets. This field encodes the advertised SRv6
SRv6 Locator as an IPv6 Prefix as specified in section A.4.1 of Locator as an IPv6 Prefix as specified in Appendix A.4.1 of
[RFC5340]. [RFC5340].
Sub-TLVs: Used to advertise Sub-TLVs that provide additional Sub-TLVs: Used to advertise sub-TLVs that provide additional
attributes for the given SRv6 Locator and SRv6 SIDs associated attributes for the given SRv6 Locator and SRv6 SIDs associated
with the SRv6 Locator. with the SRv6 Locator.
7.2. SRv6 Locator Sub-TLVs 7.2. SRv6 Locator Sub-TLVs
The following OSPFv3 Extended-LSA sub-TLVs corresponding to the The following OSPFv3 Extended-LSA sub-TLVs corresponding to the
Extended Prefix LSAs are also applicable for use as sub-TLVs of the Extended Prefix LSAs are also applicable for use as sub-TLVs of the
SRv6 Locator TLV using code points as specified in Section 13.9: SRv6 Locator TLV using code points as specified in Section 13.9:
* IPv6-Forwarding-Address sub-TLV [RFC8362] * IPv6-Forwarding-Address sub-TLV [RFC8362]
* Route-Tag sub-TLV [RFC8362] * Route-Tag sub-TLV [RFC8362]
* Prefix Source OSPF Router-ID sub-TLV [RFC9084] * Prefix Source OSPF Router-ID sub-TLV [RFC9084]
* Prefix Source Router Address sub-TLV [RFC9084] * Prefix Source Router Address sub-TLV [RFC9084]
8. Advertisement of SRv6 End SIDs 8. Advertisement of SRv6 End SIDs
The SRv6 End SID Sub-TLV is a Sub-TLV of the SRv6 Locator TLV in the The SRv6 End SID sub-TLV is a sub-TLV of the SRv6 Locator TLV in the
SRv6 Locator LSA (defined in Section 7). It is used to advertise the SRv6 Locator LSA (defined in Section 7). It is used to advertise the
SRv6 SIDs belonging to the router along with their associated SRv6 SIDs belonging to the router along with their associated
endpoint behaviors. SIDs associated with adjacencies are advertised Endpoint behaviors. SIDs associated with adjacencies are advertised
as described in Section 9. Every SRv6-enabled OSPFv3 router SHOULD as described in Section 9. Every SRv6-enabled OSPFv3 router SHOULD
advertise at least one SRv6 SID associated with an END behavior for advertise at least one SRv6 SID associated with an End behavior for
itself as specified in [RFC8986], although it MAY omit doing so if itself as specified in [RFC8986], although it MAY omit doing so if
that node is not going to be used as a Segment Endpoint (e.g., for TE that node is not going to be used as a Segment Endpoint (e.g., for TE
or TI-LFA) by any SR Source Node. or Topology Independent Loop-Free Alternate (TI-LFA)) by any SR
Source Node.
SRv6 End SIDs inherit the algorithm from the parent locator. The SRv6 End SIDs inherit the algorithm from the parent locator. The
SRv6 End SID MUST be allocated from its associated locator. SRv6 End SRv6 End SID MUST be allocated from its associated locator. SRv6 End
SIDs that are NOT allocated from the associated locator MUST be SIDs that are NOT allocated from the associated locator MUST be
ignored. ignored.
The router MAY advertise multiple instances of the SRv6 End SID Sub- The router MAY advertise multiple instances of the SRv6 End SID sub-
TLV within the SRv6 Locator TLV - one for each of the SRv6 SIDs to be TLV within the SRv6 Locator TLV -- one for each of the SRv6 SIDs to
advertised. When multiple SRv6 End SID Sub-TLVs are received in the be advertised. When multiple SRv6 End SID sub-TLVs are received in
SRv6 Locator TLV from a given router for the same SRv6 SID value, the the SRv6 Locator TLV from a given router for the same SRv6 SID value,
receiver MUST use the first occurrence of the Sub-TLV in the SRv6 the receiver MUST use the first occurrence of the sub-TLV in the SRv6
Locator TLV. Locator TLV.
The format of SRv6 End SID Sub-TLV is shown below The format of the SRv6 End SID sub-TLV is shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Endpoint Behavior | | Flags | Reserved | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... | | SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... | | ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... | | ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID concluded | | ... SID concluded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . . | Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SRv6 End SID Sub-TLV Figure 6: SRv6 End SID Sub-TLV
Where: where:
Type: 2-octet field. The value for this type is 1. Type: 2-octet field. The value for this type is 1.
Length: 2-octet field. The total length (in octets) of the value Length: 2-octet field. The total length (in octets) of the value
portion of the Sub-TLV including its further nested Sub-TLVs. portion of the sub-TLV, including its nested sub-TLVs.
Flags: 1-octet field. It specifies the flags associated with the Flags: 1-octet field. Specifies the flags associated with the SID.
SID. No flags are currently defined and this field MUST be set to No flags are currently defined, and this field MUST be set to 0 on
0 on transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
Reserved: 1-octet field. It MUST be set to 0 on transmission and Reserved: 1-octet field. It MUST be set to 0 on transmission and
MUST be ignored on receipt. MUST be ignored on receipt.
Endpoint Behavior: 2 octets field. The endpoint behavior code Endpoint Behavior: 2-octet field. The Endpoint behavior code point
point for this SRv6 SID as defined in [RFC8986]. Supported for this SRv6 SID as defined in [RFC8986]. Supported behavior
behavior values for this sub-TLV are defined in Section 11 of this values for this sub-TLV are defined in Section 11 of this
document. Unsupported or unrecognized behavior values are ignored document. Unsupported or unrecognized behavior values are ignored
by the receiver. by the receiver.
SID: 16-octet field. This field encodes the advertised SRv6 SID. SID: 16-octet field. This field encodes the advertised SRv6 SID.
Sub-TLVs: Used to advertise Sub-TLVs that provide additional Sub-TLVs: Used to advertise sub-TLVs that provide additional
attributes for the given SRv6 SID. attributes for the given SRv6 SID.
9. Advertisement of SRv6 SIDs Associated with Adjacencies 9. Advertisement of SRv6 SIDs Associated with Adjacencies
The SRv6 endpoint behaviors defined in [RFC8986] include certain The SRv6 Endpoint behaviors defined in [RFC8986] include certain
behaviors that are specific to links or adjacencies. The most basic behaviors that are specific to links or adjacencies. The most basic
of these, which is critical for link-state routing protocols like of these (which is critical for link-state routing protocols like
OSPFv3, is the End.X behavior that is an instruction to forward to a OSPFv3) is the End.X behavior, which is an instruction to forward to
specific neighbor on a specific link. These SRv6 SIDs and others a specific neighbor on a specific link. These SRv6 SIDs and others
that are defined in [RFC8986] which are specific to links or that are defined in [RFC8986], which are specific to links or
adjacencies need to be advertised to OSPFv3 routers within an area to adjacencies, need to be advertised to OSPFv3 routers within an area
steer SRv6 traffic over a specific link or adjacency. to steer SRv6 traffic over a specific link or adjacency.
Therefore, SRv6 SIDs that are specific to a particular neighbor, such Therefore, SRv6 SIDs that are specific to a particular neighbor, such
as End.X, are not advertised as a sub-TLVs of the SRv6 Locator TLV as End.X, are not advertised as a sub-TLVs of the SRv6 Locator TLV.
but via two different optional Sub-TLVs of the E-Router-Link TLV Instead, they are advertised via two different optional sub-TLVs of
defined in [RFC8362]: the E-Router-Link TLV defined in [RFC8362]:
* SRv6 End.X SID Sub-TLV: Used for OSPFv3 adjacencies over point-to- SRv6 End.X SID sub-TLV: Used for OSPFv3 adjacencies over point-to-
point or point-to-multipoint links and for the adjacency to the point or point-to-multipoint links and for the adjacency to the
Designated Router (DR) over broadcast and Non-Broadcast-Multi- Designated Router (DR) over broadcast and Non-Broadcast-Multi-
Access (NBMA) links. Access (NBMA) links.
* SRv6 LAN End.X SID Sub-TLV: Used for OSPFv3 adjacencies on SRv6 LAN End.X SID sub-TLV: Used for OSPFv3 adjacencies on broadcast
broadcast and NBMA links to the Backup DR and DR-Other neighbors. and NBMA links to the Backup DR and DR-Other neighbors. This sub-
This Sub-TLV includes the OSPFv3 Router-ID of the neighbor and TLV includes the OSPFv3 Router-ID of the neighbor and thus allows
thus allows for an instance of this Sub-TLV for each neighbor to for an instance of this sub-TLV for each neighbor to be explicitly
be explicitly advertised as a Sub-TLV of the E-Router-Link TLV for advertised as a sub-TLV of the E-Router-Link TLV for the same
the same link. link.
Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one Every SRv6-enabled OSPFv3 router SHOULD instantiate at least one
unique SRv6 End.X SID corresponding to each of its neighbors, unique SRv6 End.X SID corresponding to each of its neighbors,
although it MAY omit doing so if features like traffic engineering or although it MAY omit doing so if features like TE or TI-LFA that
Topology-Independent Loop Free Alternate (TI-LFA) that require End.X require End.X SID are not in use. A router MAY instantiate more than
SID are not in use. A router MAY instantiate more than one SRv6 one SRv6 End.X SID for a single neighbor. The same SRv6 End.X SID
End.X SID for a single neighbor. The same SRv6 End.X SID MAY be MAY be advertised for more than one neighbor. Thus, multiple
advertised for more than one neighbor. Thus multiple instances of instances of the SRv6 End.X SID and SRv6 LAN End.X SID sub-TLVs MAY
the SRv6 End.X SID and SRv6 LAN End.X SID Sub-TLVs MAY be advertised be advertised within the E-Router-Link TLV for a single link.
within the E-Router-Link TLV for a single link.
All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a
Locator with the matching algorithm which is advertised by the same locator with the matching algorithm that is advertised by the same
OSPFv3 router in an SRv6 Locator TLV. End.X SIDs which do not meet OSPFv3 router in an SRv6 Locator TLV. End.X SIDs that do not meet
this requirement MUST be ignored. This ensures that the OSPFv3 this requirement MUST be ignored. This ensures that the OSPFv3
router advertising the End.X or LAN End.X SID is also advertising its router advertising the End.X or LAN End.X SID is also advertising its
corresponding Locator with the algorithm that will be used for corresponding locator with the algorithm that will be used for
computing paths destined to the SID. computing paths destined to the SID.
9.1. SRv6 End.X SID Sub-TLV 9.1. SRv6 End.X SID Sub-TLV
The format of the SRv6 End.X SID Sub-TLV is shown below The format of the SRv6 End.X SID sub-TLV is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Flags | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Weight | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID concluded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Flags | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Weight | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID concluded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: SRv6 End.X SID Sub-TLV Figure 7: SRv6 End.X SID Sub-TLV
Where: where:
Type: 2-octet field. The value for this type is 31. Type: 2-octet field. The value for this type is 31.
Length: 2-octet field. The total length (in octets) of the value Length: 2-octet field. The total length (in octets) of the value
portion of the Sub-TLV including its further nested Sub-TLVs. portion of the sub-TLV, including its nested sub-TLVs.
Endpoint Behavior: 2-octet field. The endpoint behavior code Endpoint Behavior: 2-octet field. The Endpoint behavior code point
point for this SRv6 SID as defined in [RFC8986]. Supported for this SRv6 SID as defined in [RFC8986]. Supported behavior
behavior values for this sub-TLV are defined in Section 11 of this values for this sub-TLV are defined in Section 11 of this
document. Unsupported or unrecognized behavior values are ignored document. Unsupported or unrecognized behavior values are ignored
by the receiver. by the receiver.
Flags: 1-octet field. The flags are defined as follows: Flags: 1-octet field. The flags are defined as follows:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|B|S|P| Reserved| |B|S|P| Reserved|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
- B-Flag: Backup Flag. If set, the SID refers to a path that is B-Flag: Backup Flag. If set, the SID refers to a path that is
eligible for protection. eligible for protection.
- S-Flag: Set Flag. When set, the S-Flag indicates that the S-Flag: Set Flag. When set, the S-Flag indicates that the End.X
End.X SID refers to a set of adjacencies (and therefore MAY be SID refers to a set of adjacencies (and therefore MAY be
assigned to other adjacencies as well). assigned to other adjacencies as well).
- P-Flag: Persistent Flag: If set, the SID is persistently P-Flag: Persistent Flag. If set, the SID is persistently
allocated, i.e., the SID value remains consistent across router allocated, i.e., the SID value remains consistent across router
restart and session/interface flap. restart and session/interface flap.
- Other flags are not defined and are reserved for future use. Other flags are not defined and are reserved for future use.
They MUST be set to 0 on transmission and MUST be ignored on They MUST be set to 0 on transmission and MUST be ignored on
receipt. receipt.
Reserved1: 1-octet field. It MUST be set to 0 on transmission and Reserved1: 1-octet field. It MUST be set to 0 on transmission and
MUST be ignored on receipt. MUST be ignored on receipt.
Algorithm: 1-octet field. The algorithm associated with the SRv6 Algorithm: 1-octet field. The algorithm associated with the SRv6
Locator from which the SID is allocated. Algorithm values are Locator from which the SID is allocated. Algorithm values are
defined in the IGP Algorithm Type registry [RFC8665]. defined in the "IGP Algorithm Types" registry [RFC8665].
Weight: 1-octet field. Its value represents the weight of the Weight: 1-octet field. Its value represents the weight of the End.X
End.X SID for load-balancing. The use of the weight is defined in SID for load-balancing. The use of the weight is defined in
[RFC8402]. [RFC8402].
Reserved2: 2-octet field. It MUST be set to 0 on transmission and Reserved2: 2-octet field. It MUST be set to 0 on transmission and
MUST be ignored on receipt. MUST be ignored on receipt.
SID: 16-octet field. This field encodes the advertised SRv6 SID. SID: 16-octet field. This field encodes the advertised SRv6 SID.
Sub-TLVs: Used to advertise Sub-TLVs that provide additional Sub-TLVs: Used to advertise sub-TLVs that provide additional
attributes for the given SRv6 End.X SID. attributes for the given SRv6 End.X SID.
9.2. SRv6 LAN End.X SID Sub-TLV 9.2. SRv6 LAN End.X SID Sub-TLV
The format of the SRv6 LAN End.X SID Sub-TLV is as shown below: The format of the SRv6 LAN End.X SID sub-TLV is as shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Flags | Reserved1 | | Endpoint Behavior | Flags | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Weight | Reserved2 | | Algorithm | Weight | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router-ID | | Neighbor Router-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... | | SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... | | ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... | | ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID concluded | | ... SID concluded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . . | Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: SRv6 LAN End.X SID Sub-TLV Figure 8: SRv6 LAN End.X SID Sub-TLV
Where: where:
* Type: 2-octet field. The value for this type is 32. Type: 2-octet field. The value for this type is 32.
* Length: 2-octet field. The total length (in octets) of the value Length: 2-octet field. The total length (in octets) of the value
portion of the Sub-TLV including its further nested Sub-TLVs. portion of the sub-TLV, including its nested sub-TLVs.
* Endpoint Behavior: 2-octet field. The code point for the endpoint Endpoint Behavior: 2-octet field. The code point for the Endpoint
behavior for this SRv6 SID as defined in section 9.2 of [RFC8986]. behavior for this SRv6 SID as defined in Section 9.2 of [RFC8986].
* Flags: 1-octet field. The flags are defined as follows: Flags: 1-octet field. The flags are defined as follows:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|B|S|P| Reserved| |B|S|P| Reserved|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
- B-Flag: Backup Flag. If set, the SID refers to a path that is B-Flag: Backup Flag. If set, the SID refers to a path that is
eligible for protection. eligible for protection.
- S-Flag: Set Flag. When set, the S-Flag indicates that the S-Flag: Set Flag. When set, the S-Flag indicates that the End.X
End.X SID refers to a set of adjacencies (and therefore MAY be SID refers to a set of adjacencies (and therefore MAY be
assigned to other adjacencies as well). assigned to other adjacencies as well).
- P-Flag: Persistent Flag: If set, the SID is persistently P-Flag: Persistent Flag. If set, the SID is persistently
allocated, i.e., the SID value remains consistent across router allocated, i.e., the SID value remains consistent across router
restart and session/interface flap. restart and session/interface flap.
- Other flags are not defined and are reserved for future use. Other flags are not defined and are reserved for future use.
They MUST be set to 0 on transmission and MUST be ignored on They MUST be set to 0 on transmission and MUST be ignored on
receipt. receipt.
* Reserved1: 1-octet field. It MUST be set to 0 on transmission and Reserved1: 1-octet field. It MUST be set to 0 on transmission and
MUST be ignored on receipt. MUST be ignored on receipt.
* Algorithm: 1-octet field. The algorithm associated with the SRv6 Algorithm: 1-octet field. The algorithm associated with the SRv6
Locator from which the SID is allocated. Algorithm values are Locator from which the SID is allocated. Algorithm values are
defined in the IGP Algorithm Type registry [RFC8665]. defined in the "IGP Algorithm Types" registry [RFC8665].
* Weight: 1-octet field. Its value represents the weight of the Weight: 1-octet field. Its value represents the weight of the End.X
End.X SID for load balancing. The use of the weight is defined in SID for load balancing. The use of the weight is defined in
[RFC8402]. [RFC8402].
* Reserved2: 2-octet field. It MUST be set to 0 on transmission and Reserved2: 2-octet field. It MUST be set to 0 on transmission and
MUST be ignored on receipt. MUST be ignored on receipt.
* Neighbor Router-ID: 4-octet field. It specifies the OSPFv3 Neighbor Router-ID: 4-octet field. It specifies the OSPFv3 Router-
Router-id of the neighbor. ID of the neighbor.
* SID: 16-octet field. This field encodes the advertised SRv6 SID. SID: 16-octet field. This field encodes the advertised SRv6 SID.
* Sub-TLVs: Used to advertise Sub-TLVs that provide additional Sub-TLVs: Used to advertise sub-TLVs that provide additional
attributes for the given SRv6 SID. attributes for the given SRv6 SID.
10. SRv6 SID Structure Sub-TLV 10. SRv6 SID Structure Sub-TLV
SRv6 SID Structure Sub-TLV is used to advertise the structure of the The SRv6 SID Structure sub-TLV is used to advertise the structure of
SRv6 SID as defined in [RFC8986]. It is used as an optional Sub-TLV the SRv6 SID as defined in [RFC8986]. It is used as an optional sub-
of the following: TLV of the following:
* SRv6 End SID Sub-TLV (refer to Section 8) * SRv6 End SID sub-TLV (refer to Section 8)
* SRv6 End.X SID Sub-TLV (refer to Section 9.1) * SRv6 End.X SID sub-TLV (refer to Section 9.1)
* SRv6 LAN End.X SID Sub-TLV (refer to Section 9.2) * SRv6 LAN End.X SID sub-TLV (refer to Section 9.2)
The Sub-TLV has the following format: The sub-TLV has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB Length | LN Length | Fun. Length | Arg. Length | | LB Length | LN Length | Fun. Length | Arg. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: SRv6 SID Structure Sub-TLV Figure 9: SRv6 SID Structure Sub-TLV
Where: where:
Type: 2-octet field. The value for this type is 30. Type: 2-octet field. The value for this type is 30.
Length: 2-octet field. The value MUST be 4. Length: 2-octet field. The value MUST be 4.
LB Length: 1-octet field. SRv6 SID Locator Block length in bits. LB Length: 1-octet field. SRv6 SID Locator Block length in bits.
LN Length: 1-octet bit field. SRv6 SID Locator Node length in LN Length: 1-octet field. SRv6 SID Locator Node length in bits.
bits.
Function Length: 1-octet field. SRv6 SID Function length in bits. Function Length: 1-octet field. SRv6 SID Function length in bits.
Argument Length: 1-octet field. SRv6 SID Argument length in bits. Argument Length: 1-octet field. SRv6 SID Argument length in bits.
The SRv6 SID Structure Sub-TLV MUST NOT appear more than once in its The SRv6 SID Structure sub-TLV MUST NOT appear more than once in its
parent Sub-TLV. If it appears more than once in its parent Sub-TLV, parent sub-TLV. If it appears more than once in its parent sub-TLV,
the parent Sub-TLV MUST be ignored by the receiver. the parent sub-TLV MUST be ignored by the receiver.
The sum of all four sizes advertised in SRv6 SID Structure Sub-TLV The sum of all four sizes advertised in SRv6 SID Structure sub-TLV
MUST be less than or equal to 128 bits. If the sum of all four sizes MUST be less than or equal to 128 bits. If the sum of all four sizes
advertised in the SRv6 SID Structure Sub-TLV is larger than 128 bits, advertised in the SRv6 SID Structure sub-TLV is larger than 128 bits,
the parent TLV/Sub-TLV MUST be ignored by the receiver. the parent TLV or sub-TLV MUST be ignored by the receiver.
The SRv6 SID Structure Sub-TLV is intended for informational use by The SRv6 SID Structure sub-TLV is intended for informational use by
the control and management planes. It MUST NOT be used at a transit the control and management planes. It MUST NOT be used at a transit
node (as defined in [RFC8754]) for forwarding packets. As an node (as defined in [RFC8754]) for forwarding packets. As an
example, this information could be used for: example, this information could be used for the following:
* validation of SRv6 SIDs being instantiated in the network and * Validation of SRv6 SIDs being instantiated in the network and
advertised via OSPFv3. These can be learned by controllers via advertised via OSPFv3. These can be learned by controllers via
BGP-LS [I-D.ietf-idr-bgpls-srv6-ext] and then be monitored for BGP-LS [RFC9514] and then monitored for conformance to the SRv6
conformance to the SRv6 SID allocation scheme chosen by the SID allocation scheme chosen by the operator as described in
operator as described in Section 3.2 of [RFC8986]. Section 3.2 of [RFC8986].
* verification and the automation for securing the SRv6 domain by * Verification and the automation for securing the SRv6 domain by
provisioning filtering rules at SR domain boundaries as described provisioning filtering rules at SR domain boundaries as described
in Section 5 of [RFC8754]. in Section 5 of [RFC8754].
The details of these potential applications are outside the scope of The details of these potential applications are outside the scope of
this document. this document.
11. Advertising Endpoint Behaviors 11. Advertising Endpoint Behaviors
Endpoint behaviors are defined in [RFC8986]. The codepoints for the Endpoint behaviors are defined in [RFC8986]. The code points for the
Endpoint behaviors are defined in the "SRv6 Endpoint Behaviors" Endpoint behaviors are defined in the "SRv6 Endpoint Behaviors"
registry of [RFC8986]. This section lists the Endpoint behaviors and registry of [RFC8986]. This section lists the Endpoint behaviors and
their codepoints, which MAY be advertised by OSPFv3 and the Sub-TLVs their code points, which MAY be advertised by OSPFv3 and the sub-TLVs
in which each type MAY appear. in which each type MAY appear.
|-----------------------|--------------------|-----|-------|-----------| +===================+===================+=====+=======+===========+
| Endpoint | Endpoint | End | End.X | LAN End.X | | Endpoint Behavior | Endpoint Behavior | End | End.X | LAN End.X |
| Behavior | Behavior Codepoint | SID | SID | SID | | | Code Point | SID | SID | SID |
|-----------------------|--------------------|-----|-------|-----------| +===================+===================+=====+=======+===========+
| End (PSP, USP, USD) | 1-4, 28-31 | Y | N | N | | End (PSP, USP, | 1-4, 28-31 | Y | N | N |
|-----------------------|--------------------|-----|-------|-----------| | USD) | | | | |
| End.X (PSP, USP, USD) | 5-8, 32-35 | N | Y | Y | +-------------------+-------------------+-----+-------+-----------+
|-----------------------|--------------------|-----|-------|-----------| | End.X (PSP, USP, | 5-8, 32-35 | N | Y | Y |
| End.DX6 | 16 | N | Y | Y | | USD) | | | | |
|-----------------------|--------------------|-----|-------|-----------| +-------------------+-------------------+-----+-------+-----------+
| End.DX4 | 17 | N | Y | Y | | End.DX6 | 16 | N | Y | Y |
|-----------------------|--------------------|-----|-------|-----------| +-------------------+-------------------+-----+-------+-----------+
| End.DT6 | 18 | Y | N | N | | End.DX4 | 17 | N | Y | Y |
|-----------------------|--------------------|-----|-------|-----------| +-------------------+-------------------+-----+-------+-----------+
| End.DT4 | 19 | Y | N | N | | End.DT6 | 18 | Y | N | N |
|-----------------------|--------------------|-----|-------|-----------| +-------------------+-------------------+-----+-------+-----------+
| End.DT64 | 20 | Y | N | N | | End.DT4 | 19 | Y | N | N |
|-----------------------|--------------------|-----|-------|-----------| +-------------------+-------------------+-----+-------+-----------+
| End.DT64 | 20 | Y | N | N |
+-------------------+-------------------+-----+-------+-----------+
Figure 10: SRv6 Endpoint Behaviors in OSPFv3 Table 1: SRv6 Endpoint Behaviors in OSPFv3
12. Security Considerations 12. Security Considerations
This document introduces extensions to the OSPFv3 protocol and as This document introduces extensions to the OSPFv3 protocol and, as
such does not affect existing security considerations for OSPFv3 as such, does not affect existing security considerations for OSPFv3 as
documented in [RFC5340]. [RFC7166] describes an alternative and documented in [RFC5340]. [RFC7166] describes an alternative and
improved authentication mechanism to IPsec for OSPFv3. The use of improved authentication mechanism to IPsec for OSPFv3. The use of
authentication is RECOMMENDED for OSPFv3 deployment. authentication is RECOMMENDED for OSPFv3 deployment.
Reception of malformed TLV or Sub-TLV SHOULD be counted and/or logged Reception of a malformed TLV or sub-TLV SHOULD be counted and/or
in a rate-limited manner for further analysis. logged in a rate-limited manner for further analysis.
This document describes the OSPFv3 extensions required to support This document describes the OSPFv3 extensions required to support SR
Segment Routing over an IPv6 data plane. The security considerations over an IPv6 data plane. The security considerations for SR are
for Segment Routing are discussed in [RFC8402]. [RFC8986] defines discussed in [RFC8402]. [RFC8986] defines the SRv6 Network
the SRv6 Network Programming concept and specifies the main Segment Programming concept and specifies the main SR behaviors to enable the
Routing behaviors to enable the creation of interoperable overlays; creation of interoperable overlays. The security considerations from
the security considerations from that document apply too. that document apply as well.
The advertisement of an incorrect MSD value may have negative The advertisement of an incorrect MSD value may have negative
consequences, see [RFC8476] for additional considerations. consequences. See [RFC8476] for additional considerations.
Security concerns associated with the setting of the O-flag are Security concerns associated with the setting of the O-flag are
described in [RFC9259]. described in [RFC9259].
Security concerns associated with the usage of Flexible Algorithms Security concerns associated with the usage of Flexible Algorithms
are described in [RFC9350]. are described in [RFC9350].
13. IANA Considerations 13. IANA Considerations
This document requests IANA to perform allocations from OSPF and Per this document, IANA has made allocations in OSPF- and
OSPFv3 related registries as well as creating of new registries as OSPFv3-related registries and created new registries, as detailed in
follows. the following subsections.
13.1. OSPF Router Information TLVs 13.1. OSPF Router Information TLVs
IANA has allocated a code point via the early allocation process in IANA has allocated the following code point in the "OSPF Router
the "OSPF Router Information (RI) TLVs" registry under the "OSPF Information (RI) TLVs" registry within the "Open Shortest Path First
Parameters" registry group for the new TLV below that needs to be (OSPF) Parameters" registry group:
made permanent:
Type 20: SRv6-Capabilities TLV: Refer to Section 2 of this +=======+===================+=====================+
document. | Value | TLV Name | Reference |
+=======+===================+=====================+
| 20 | SRv6 Capabilities | RFC 9513, Section 2 |
+-------+-------------------+---------------------+
Table 2
13.2. OSPFv3 LSA Function Codes 13.2. OSPFv3 LSA Function Codes
IANA has allocated a code point via the early allocation process in IANA has allocated the following code point in the "OSPFv3 LSA
the "OSPFv3 LSA Function Codes" registry under the "OSPFv3 Function Codes" registry within the "Open Shortest Path First v3
Parameters" registry group for the new LSA below that needs to be (OSPFv3) Parameters" registry group:
made permanent:
* Type 42: SRv6 Locator LSA: Refer to Section 7 of this document. +=======+========================+=====================+
| Value | LSA Function Code Name | Reference |
+=======+========================+=====================+
| 42 | SRv6 Locator LSA | RFC 9513, Section 7 |
+-------+------------------------+---------------------+
Table 3
13.3. OSPFv3 Prefix Options 13.3. OSPFv3 Prefix Options
IANA has allocated a code point via the early allocation process in IANA has allocated the following code point in the "OSPFv3 Prefix
the "OSPFv3 Prefix Options" registry under the "OSPFv3 Parameters" Options (8 bits)" registry within the "Open Shortest Path First v3
registry group as below that needs to be made permanent: (OSPFv3) Parameters" registry group:
* Value 0x80: AC-bit: Refer to Section 6 of this document. +=======+=============+=====================+
| Value | Description | Reference |
+=======+=============+=====================+
| 0x80 | AC-bit | RFC 9513, Section 6 |
+-------+-------------+---------------------+
Table 4
13.4. OSPFv3 SRv6 Capabilities TLV Flags 13.4. OSPFv3 SRv6 Capabilities TLV Flags
This document requests a new IANA sub-registry name "OSPFv3 SRv6 IANA has created a new subregistry named "OSPFv3 SRv6 Capabilities
Capabilities TLV Flags" be created under the "OSPFv3 Parameters" TLV Flags" within the "Open Shortest Path First v3 (OSPFv3)
registry group to control the assignment of bits 0 to 15 in the Flags Parameters" registry group to control the assignment of bits 0 to 15
field of the OSPFv3 SRv6 Capabilities TLV specified in this document. in the Flags field of the OSPFv3 SRv6 Capabilities TLV specified in
The registration procedure is "Standards Action" as defined in this document. The registration procedure is "Standards Action" as
[RFC8126]. defined in [RFC8126].
The following assignments are made by this document: The following assignment has been made per this document:
* Bit 1: Description: O-flag. Reference: Section 2 of this +=====+=============+=====================+
document. | Bit | Description | Reference |
+=====+=============+=====================+
| 1 | O-flag | RFC 9513, Section 2 |
+-----+-------------+---------------------+
Table 5
13.5. OSPFv3 SRv6 End SID Sub-TLV Flags 13.5. OSPFv3 SRv6 End SID Sub-TLV Flags
This document requests a new IANA sub-registry name "OSPFv3 SRv6 End IANA has created a new subregistry named "OSPFv3 SRv6 End SID Sub-TLV
SID Sub-TLV Flags" be created under the "OSPFv3 Parameters" registry Flags" within the "Open Shortest Path First v3 (OSPFv3) Parameters"
group to control the assignment of bits 0 to 7 in the Flags field of registry group to control the assignment of bits 0 to 7 in the Flags
the OSPFv3 SRv6 End SID Sub-TLV specified in this document. The field of the OSPFv3 SRv6 End SID sub-TLV specified in this document.
registration procedure is "Standards Action" as defined in [RFC8126]. The registration procedure is "Standards Action" as defined in
[RFC8126].
No assignments are made by this document. No assignments are made by this document.
13.6. OSPFv3 SRv6 Adjacency SID Sub-TLV Flags 13.6. OSPFv3 SRv6 Adjacency SID Sub-TLV Flags
This document requests a new IANA sub-registry name "OSPFv3 SRv6 IANA has created a new subregistry named "OSPFv3 SRv6 Adjacency SID
Adjacency SID Sub-TLV Flags" be created under the "OSPFv3 Parameters" Sub-TLV Flags" within the "Open Shortest Path First v3 (OSPFv3)
registry group to control the assignment of bits 0 to 7 in the Flags Parameters" registry group to control the assignment of bits 0 to 7
field of the OSPFv3 SRv6 End.X SID and OSPFv3 SRv6 LAN End.X SID Sub- in the Flags field of the OSPFv3 SRv6 End.X SID and OSPFv3 SRv6 LAN
TLVs specified in this document. The registration procedure is End.X SID sub-TLVs specified in this document. The registration
"Standards Action" as defined in [RFC8126]. procedure is "Standards Action" as defined in [RFC8126].
The following assignments are made by this document:
* Bit 0: Description: B-flag. Reference: Section 9.1 and The following assignments have been made per this document:
Section 9.2 of this document.
* Bit 1: Description: S-flag. Reference: Section 9.1 and +=====+=============+================================+
Section 9.2 of this document. | Bit | Description | Reference |
+=====+=============+================================+
| 0 | B-flag | RFC 9513, Sections 9.1 and 9.2 |
+-----+-------------+--------------------------------+
| 1 | S-flag | RFC 9513, Sections 9.1 and 9.2 |
+-----+-------------+--------------------------------+
| 2 | P-flag | RFC 9513, Sections 9.1 and 9.2 |
+-----+-------------+--------------------------------+
* Bit 2: Description: P-flag. Reference: Section 9.1 and Table 6
Section 9.2 of this document.
13.7. OSPFv3 Extended-LSA Sub-TLVs 13.7. OSPFv3 Extended-LSA Sub-TLVs
IANA has allocated the following code points via the early allocation IANA has allocated the following code points in the "OSPFv3 Extended-
process in the "OSPFv3 Extended-LSA Sub-TLVs" registry under the LSA Sub-TLVs" registry within the "Open Shortest Path First v3
"OSPFv3 Parameters" registry group for the new Sub-TLVs below that (OSPFv3) Parameters" registry group:
need to be made permanent:
* Type 30: SRv6 SID Structure Sub-TLV: Refer to Section 10 of this
document.
* Type 31: SRv6 End.X SID Sub-TLV: Refer to Section 9.1 of this
document.
* Type 32: SRv6 LAN End.X SID Sub-TLV: Refer to Section 9.2 of this +=======+====================+======+=======================+
document. | Value | Description | L2BM | Reference |
+=======+====================+======+=======================+
| 30 | SRv6 SID Structure | Y | RFC 9513, Section 10 |
+-------+--------------------+------+-----------------------+
| 31 | SRv6 End.X SID | Y | RFC 9513, Section 9.1 |
+-------+--------------------+------+-----------------------+
| 32 | SRv6 LAN End.X SID | Y | RFC 9513, Section 9.2 |
+-------+--------------------+------+-----------------------+
For all 3 of these sub-TLVs the column L2BM in the registry is set to Table 7
"Y".
13.8. OSPFv3 SRv6 Locator LSA TLVs 13.8. OSPFv3 SRv6 Locator LSA TLVs
This document requests the creation of an "OSPFv3 SRv6 Locator LSA IANA has created a new subregistry named "OSPFv3 SRv6 Locator LSA
TLVs" registry, that defines top-level TLVs for the OSPFv3 SRv6 TLVs" within the "Open Shortest Path First v3 (OSPFv3) Parameters"
Locator LSA, under the "OSPFv3 Parameters" registry group. The registry group to define top-level TLVs for the OSPFv3 SRv6 Locator
initial code-points assignment is as below: LSA. The initial assignments are below:
* Type 0: Reserved. +=======+==============+=======================+
| Value | Description | Reference |
+=======+==============+=======================+
| 0 | Reserved | RFC 9513 |
+-------+--------------+-----------------------+
| 1 | SRv6 Locator | RFC 9513, Section 7.1 |
+-------+--------------+-----------------------+
* Type 1: SRv6 Locator TLV: Refer to Section 7.1 of this document. Table 8
Types in the range 2-32767 are allocated via IETF Review or IESG Types in the range 0-32767 are allocated via IETF Review or IESG
Approval [RFC8126]. Approval [RFC8126].
Types in the range 32768-33023 are Reserved for Experimental Use; Types in the range 32768-33023 are Reserved for Experimental Use;
these will not be registered with IANA and MUST NOT be mentioned by these will not be registered with IANA and MUST NOT be mentioned by
RFCs. RFCs.
Types in the range 33024-45055 are to be assigned on a First Come Types in the range 33024-45055 are to be assigned on a First Come
First Served (FCFS) basis. First Served (FCFS) basis.
Types in the range 45056-65535 are not to be assigned at this time. Types in the range 45056-65535 are not to be assigned at this time.
Before any assignments can be made in the 45056-65535 range, there Before any assignments can be made in the 45056-65535 range, there
MUST be an IETF specification that specifies IANA Considerations that MUST be an IETF specification that specifies IANA Considerations that
cover the range being assigned. cover the range being assigned.
13.9. OSPFv3 SRv6 Locator LSA Sub-TLVs 13.9. OSPFv3 SRv6 Locator LSA Sub-TLVs
This document requests the creation of an "OSPFv3 SRv6 Locator LSA IANA has created a new subregistry named "OSPFv3 SRv6 Locator LSA
Sub-TLVs" registry, that defines Sub-TLVs at any level of nesting for Sub-TLVs" within the "Open Shortest Path First v3 (OSPFv3)
the SRv6 Locator LSA, to be added under the "OSPFv3 Parameters" Parameters" registry group to define sub-TLVs at any level of nesting
registry group. The initial code-points assignment is as below: for the SRv6 Locator LSA TLV. The initial assignment are below:
* Type 0: Reserved.
* Type 1: SRv6 End SID Sub-TLV: Refer to Section 8 of this document.
* Type 2: IPv6-Forwarding-Address sub-TLV: Refer to [RFC8362] and
Section 7.2 of this document.
* Type 3: Route-Tag sub-TLV: Refer to [RFC8362] and Section 7.2 of
this document.
* Type 4: Prefix Source OSPF Router-ID sub-TLV: Refer to [RFC9084]
and Section 7.2 of this document.
* Type 5: Prefix Source Router Address sub-TLV: Refer to [RFC9084] +=======+=========================+=====================+
and Section 7.2 of this document. | Value | Description | Reference |
+=======+=========================+=====================+
| 0 | Reserved | RFC 9513 |
+-------+-------------------------+---------------------+
| 1 | SRv6 End SID | RFC 9513, Section 8 |
+-------+-------------------------+---------------------+
| 2 | IPv6-Forwarding-Address | [RFC8362]; RFC |
| | | 9513, Section 7.2 |
+-------+-------------------------+---------------------+
| 3 | Route-Tag | [RFC8362]; RFC |
| | | 9513, Section 7.2 |
+-------+-------------------------+---------------------+
| 4 | Prefix Source OSPF | [RFC9084]; RFC |
| | Router-ID | 9513, Section 7.2 |
+-------+-------------------------+---------------------+
| 5 | Prefix Source Router | [RFC9084]; RFC |
| | Address | 9513, Section 7.2 |
+-------+-------------------------+---------------------+
| 10 | SRv6 SID Structure | RFC 9513, |
| | | Section 10 |
+-------+-------------------------+---------------------+
* Type 10: SRv6 SID Structure Sub-TLV: Refer to Section 10 of this Table 9
document.
Types in the range 6-9 and 11-32767 are allocated via IETF Review or Types in the range 0-32767 are allocated via IETF Review or IESG
IESG Approval [RFC8126]. Approval [RFC8126].
Types in the range 32768-33023 are Reserved for Experimental Use; Types in the range 32768-33023 are Reserved for Experimental Use;
these will not be registered with IANA and MUST NOT be mentioned by these will not be registered with IANA and MUST NOT be mentioned by
RFCs. RFCs.
Types in the range 33024-45055 are to be assigned on a First Come Types in the range 33024-45055 are to be assigned on a FCFS basis.
First Served (FCFS) basis.
Types in the range 45056-65535 are not to be assigned at this time. Types in the range 45056-65535 are not to be assigned at this time.
Before any assignments can be made in the 45056-65535 range, there Before any assignments can be made in the 45056-65535 range, there
MUST be an IETF specification that specifies IANA Considerations that MUST be an IETF specification that specifies IANA Considerations that
cover the range being assigned. cover the range being assigned.
The note indicated below needs to be added under this registry to The following note has been added to this registry to ensure that any
ensure that any document requesting allocations under this registry document requesting allocations in this registry for sub-TLVs of any
for sub-TLVs of any of the OSPFv3 SRv6 Locator TLVs checks if of the OSPFv3 SRv6 Locator TLVs checks if allocations are also
allocations are also applicable for the "OSPFv3 Extended-LSA Sub- applicable for the "OSPFv3 Extended-LSA Sub-TLVs" registry.
TLVs" registry.
Note: Allocations made under this registry for any sub-TLVs that are | Note: Allocations made in this registry for sub-TLVs that are
associated with OSPFv3 SRv6 Locator TLVs MUST be also evaluated for | associated with OSPFv3 SRv6 Locator TLVs MUST be evaluated for
their applicability as OSPFv3 Extended-LSA Sub-TLVs and, therefore, | their applicability as OSPFv3 Extended-LSA sub-TLVs, which are
also requiring allocation under the "OSPFv3 Extended-LSA Sub-TLVs" | required to be allocated in the "OSPFv3 Extended-LSA Sub-TLVs"
registry. | registry.
13.10. OSPFv3 Extended-LSA Sub-TLVs 13.10. OSPFv3 Extended-LSA Sub-TLVs
This document requests IANA to add the note indicated below under the IANA has added the following note to the "OSPFv3 Extended-LSA Sub-
"OSPFv3 Extended-LSA Sub-TLVs" registry under the "OSPFv3 Parameters" TLVs" registry within the "Open Shortest Path First v3 (OSPFv3)
registry group. The purpose of this note is to ensure that any Parameters" registry group. The purpose of this note is to ensure
document requesting allocations under this registry for sub-TLVs of that any document requesting allocations in this registry for sub-
any of the OSPFv3 Extended Prefix TLVs checks if allocations are also TLVs of any of the OSPFv3 Extended Prefix TLVs checks if allocations
applicable for the "OSPFv3 SRv6 Locator LSA Sub-TLVs" registry that are also applicable for the "OSPFv3 SRv6 Locator LSA Sub-TLVs"
is created by this document. registry defined in this document.
Note: Allocations made under this registry for any sub-TLVs that are
associated with OSPFv3 Extended TLVs related to prefix advertisements
MUST be also evaluated for their applicability as OSPFv3 SRv6 Locator
Sub-TLVs and, therefore, also requiring allocation under the "OSPFv3
SRv6 Locator LSA Sub-TLVs" registry.
14. Acknowledgements
The authors would like to acknowledge the contributions of Dean Cheng
in the early versions of this document. The authors would like to
thank Ran Chen and Detao Zhao for their suggestions related to the
extension of PrefixOptions for the signaling of the anycast property.
The authors would like to thank Chenzichao, Dirk Goethals, Baalajee | Note: Allocations made in this registry for sub-TLVs that are
S, Yingzhen Qu, Shraddha Hegde, Dhruv Dhody, Martin Vigoureux, and | associated with OSPFv3 Extended TLVs related to prefix
Reese Enghardt for their review and comments on this document. The | advertisements MUST be evaluated for their applicability as OSPFv3
authors would like to thank Acee Lindem for his detailed shepherd | SRv6 Locator sub-TLVs, which are required to be allocated in the
review and feedback for improvement of this document. The authors | "OSPFv3 SRv6 Locator LSA Sub-TLVs" registry.
would like to thank John Scudder for his AD review and suggestions to
improve this document.
15. References 14. References
15.1. Normative References 14.1. Normative References
[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>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
skipping to change at page 29, line 10 skipping to change at line 1304
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350, and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023, DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>. <https://www.rfc-editor.org/info/rfc9350>.
[RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., [RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B.,
and Z. Hu, "IS-IS Extensions to Support Segment Routing and Z. Hu, "IS-IS Extensions to Support Segment Routing
over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352, over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352,
February 2023, <https://www.rfc-editor.org/info/rfc9352>. February 2023, <https://www.rfc-editor.org/info/rfc9352>.
15.2. Informative References 14.2. Informative References
[I-D.ietf-idr-bgpls-srv6-ext]
Dawra, G., Filsfils, C., Talaulikar, K., Chen, M.,
Bernier, D., and B. Decraene, "BGP Link State Extensions
for SRv6", Work in Progress, Internet-Draft, draft-ietf-
idr-bgpls-srv6-ext-14, 17 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
bgpls-srv6-ext-14>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3630>.
[RFC9514] Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M.,
Bernier, D., and B. Decraene, "Border Gateway Protocol -
Link State (BGP-LS) Extensions for Segment Routing over
IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, November
2023, <https://www.rfc-editor.org/info/rfc9514>.
Acknowledgements
The authors would like to acknowledge the contributions of Dean Cheng
in the early draft versions of this document. The authors would like
to thank Ran Chen and Detao Zhao for their suggestions related to the
extension of PrefixOptions for the signaling of the anycast property.
The authors would like to thank Chenzichao, Dirk Goethals, Baalajee
S, Yingzhen Qu, Shraddha Hegde, Dhruv Dhody, Martin Vigoureux, and
Reese Enghardt for their review and comments on this document. The
authors would like to thank Acee Lindem for his detailed shepherd
review and feedback for improvement of this document. The authors
would like to thank John Scudder for his AD review and suggestions to
improve this document.
Authors' Addresses Authors' Addresses
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
Zhibo Hu Zhibo Hu
Huawei Technologies Huawei Technologies
Email: huzhibo@huawei.com Email: huzhibo@huawei.com
 End of changes. 206 change blocks. 
641 lines changed or deleted 671 lines changed or added

This html diff was produced by rfcdiff 1.48.