OSPFv3 Extensions for SRv6
draft-ietf-lsr-ospfv3-srv6-extensions-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9513.
|
|
|---|---|---|---|
| Authors | Zhenbin Li , Zhibo Hu, Ketan Talaulikar , Peter Psenak | ||
| Last updated | 2022-07-01 | ||
| Replaces | draft-li-lsr-ospfv3-srv6-extensions | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Acee Lindem | ||
| IESG | IESG state | Became RFC 9513 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | acee@cisco.com |
draft-ietf-lsr-ospfv3-srv6-extensions-05
Link State Routing Z. Li
Internet-Draft Z. Hu
Intended status: Standards Track Huawei Technologies
Expires: January 2, 2023 K. Talaulikar, Ed.
Arrcus Inc
P. Psenak
Cisco Systems
July 1, 2022
OSPFv3 Extensions for SRv6
draft-ietf-lsr-ospfv3-srv6-extensions-05
Abstract
The Segment Routing (SR) architecture allows a flexible definition of
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 data plane. This document describes the OSPFv3 extensions
required to support Segment Routing over the IPv6 data plane (SRv6).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Li, et al. Expires January 2, 2023 [Page 1]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. SRv6 Capabilities TLV . . . . . . . . . . . . . . . . . . . . 3
3. Advertisement of Supported Algorithms . . . . . . . . . . . . 5
4. Advertisement of SRH Operation Limits . . . . . . . . . . . . 5
4.1. Maximum Segments Left MSD Type . . . . . . . . . . . . . 5
4.2. Maximum End Pop MSD Type . . . . . . . . . . . . . . . . 6
4.3. Maximum H.Encaps MSD Type . . . . . . . . . . . . . . . . 6
4.4. Maximum End D MSD Type . . . . . . . . . . . . . . . . . 6
5. SRv6 SIDs and Reachability . . . . . . . . . . . . . . . . . 6
5.1. SRv6 Flexible Algorithm . . . . . . . . . . . . . . . . . 8
6. SRv6 Locator LSA . . . . . . . . . . . . . . . . . . . . . . 8
6.1. SRv6 Locator TLV . . . . . . . . . . . . . . . . . . . . 10
7. Advertisement of SRv6 End SIDs . . . . . . . . . . . . . . . 12
8. Advertisement of SRv6 SIDs Associated with Adjacencies . . . 14
8.1. SRv6 End.X SID Sub-TLV . . . . . . . . . . . . . . . . . 14
8.2. SRv6 LAN End.X SID Sub-TLV . . . . . . . . . . . . . . . 16
9. SRv6 SID Structure Sub-TLV . . . . . . . . . . . . . . . . . 18
10. Advertising Endpoint Behaviors . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12.1. OSPF Router Information TLVs . . . . . . . . . . . . . . 21
12.2. OSPFv3 LSA Function Codes . . . . . . . . . . . . . . . 21
12.3. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . . . 22
12.4. OSPFv3 Locator LSA TLVs . . . . . . . . . . . . . . . . 22
12.5. OSPFv3 Locator LSA Sub-TLVs . . . . . . . . . . . . . . 22
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
14.1. Normative References . . . . . . . . . . . . . . . . . . 23
14.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
Segment Routing (SR) architecture [RFC8402] specifies how a node can
steer a packet through an ordered list of instructions, called
segments. These segments are identified through Segment Identifiers
(SIDs).
Li, et al. Expires January 2, 2023 [Page 2]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
Segment Routing can be instantiated on the IPv6 data plane through
the use of the Segment Routing Header (SRH) defined in [RFC8754].
SRv6 refers to this SR instantiation on the IPv6 dataplane.
The network programming paradigm for SRv6 is specified in [RFC8986].
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
describes several well-known behaviors that can be bound to SRv6
SIDs.
This document specifies OSPFv3 extensions to support SRv6 as defined
in [RFC8986]. The extensions include advertisement of an OSPFv3
router's SRv6 capabilities, SRv6 Locators, and required SRv6 SIDs
along with their supported endpoint behaviors. Familiarity with
[RFC8986] is necessary to understand the extensions specified in this
document.
At a high level, the extensions to OSPFv3 are comprised of the
following:
1. An SRv6 Capabilities TLV to advertise the SRv6 features and SRH
operations supported by an OSPFv3 router
2. Several new sub-TLVs are defined to advertise various SRv6
Maximum SID Depths.
3. An SRv6 Locator TLV to advertise the SRv6 Locator - a form of
summary address for the algorithm-specific SIDs instantiated on
an OSPFv3 router
4. TLVs and Sub-TLVs to advertise the SRv6 SIDs instantiated on an
OSPFv3 router along with their endpoint behaviors
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. SRv6 Capabilities TLV
The SRv6 Capabilities TLV is used by an OSPFv3 router to advertise
its support for the SR Segment Endpoint Node [RFC8754] functionality
along with its SRv6-related capabilities. This is an optional top
level TLV of the OSPFv3 Router Information LSA [RFC7770] which MUST
be advertised by an SRv6-enabled router.
Li, et al. Expires January 2, 2023 [Page 3]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
This TLV SHOULD be advertised only once in the OSPFv3 Router
Information LSA. When multiple SRv6 Capabilities TLVs are received
from a given router, the receiver MUST use the first occurrence of
the TLV in the OSPFv3 Router Information LSA. If the SRv6
Capabilities TLV appears in multiple OSPFv3 Router Information LSAs
that have different flooding scopes, the TLV in the OSPFv3 Router
Information LSA with the area-scoped flooding scope MUST be used. If
the SRv6 Capabilities TLV appears in multiple OSPFv3 Router
Information LSAs that have the same flooding scope, the TLV in the
OSPFv3 Router Information LSA with the numerically smallest Instance
ID MUST be used and subsequent instances of the TLV MUST be ignored.
The OSPFv3 Router Information LSA can be advertised at any of the
defined flooding scopes (link, area, or Autonomous System (AS)). For
the purpose of SRv6 Capabilities TLV advertisement, area-scoped
flooding is REQUIRED.
The format of OSPFv3 SRv6 Capabilities 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SRv6 Capabilities TLV
Where:
o Type: 2-octet field. The value for this type is TBD.
o Length: 2-octet field. The total length (in octets) of the value
portion of the TLV including nested Sub-TLVs.
o Reserved: 2-octet field. It MUST be set to 0 on transmission and
MUST be ignored on receipt.
o Flags: 2-octet field. The flags are defined as follows:
Li, et al. Expires January 2, 2023 [Page 4]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |O| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
* O-flag: If set, then the router is capable of supporting the
O-bit in the SRH flags, as specified in [RFC9259].
* Other flags are not defined and reserved for future use. They
MUST be set to 0 on transmission and MUST be ignored on
receipt.
The SRv6 Capabilities TLV may contain optional Sub-TLVs. No Sub-TLVs
are defined in this specification.
3. Advertisement of Supported Algorithms
An SRv6-enabled OSPFv3 router advertises its algorithm support using
the SR Algorithm TLV defined in [RFC8665] as described in [RFC8666].
4. Advertisement of SRH Operation Limits
An SRv6-enabled router may have different capabilities and limits
when it comes to SRH processing and this needs to be advertised to
other OSPFv3 routers in the SRv6 domain.
[RFC8476] defines the means to advertise node and link specific
values for Maximum SID Depth (MSD) types. Node MSDs are advertised
using the Node MSD TLV in the OSPFv3 Router Information LSA [RFC7770]
while Link MSDs are advertised using the Link MSD Sub-TLV of the
Router-Link TLV [RFC8362]. The format of the MSD types for OSPFv3 is
defined in [RFC8476].
The MSD types for SRv6 that are defined in section 4 of
[I-D.ietf-lsr-isis-srv6-extensions] for IS-IS are also used by
OSPFv3. These MSD Types are allocated under the IGP MSD Types
registry maintained by IANA that are shared by IS-IS and OSPF. They
are described below:
4.1. Maximum Segments Left MSD Type
The Maximum Segments Left MSD Type signals the maximum value of the
"Segments Left" field of the SRH of a received packet before applying
the Endpoint behavior associated with a SID. If no value is
advertised, the supported value is assumed to be 0.
Li, et al. Expires January 2, 2023 [Page 5]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
4.2. Maximum End Pop MSD Type
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)
of the SRH" or "Ultimate Segment Pop (USP) of the SRH", as defined in
[RFC8986] flavors. If the advertised value is zero or no value is
advertised, then the router cannot apply PSP or USP flavors.
4.3. Maximum H.Encaps MSD Type
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
[RFC8986]. If the advertised value is zero or no value is advertised
then the headend can apply an SR Policy that only contains one
segment, without inserting any SRH. A non-zero SRH Max H.encaps MSD
indicates that the headend can insert an SRH with SIDs up to the
advertised value.
4.4. Maximum End D MSD Type
The Maximum End D MSD Type specifies the maximum number of SIDs
present in an SRH when performing decapsulation. These includes, but
not limited to, End.DX6, End.DT4, End.DT46, End with USD, 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 behavior that
results in decapsulation and forwarding of the inner packet when the
outer IPv6 header contains an SRH.
5. SRv6 SIDs and Reachability
An SRv6 Segment Identifier (SID) is 128 bits and consists of Locator,
Function, and Argument parts as described in [RFC8986].
An OSPFv3 router is provisioned with algorithm-specific locators for
each algorithm supported by that router. Each locator is a covering
prefix for all SIDs provisioned on that router which have the
matching algorithm.
Locators MUST be advertised in the SRv6 Locator TLV (see
Section 6.1). Forwarding entries for the locators advertised in the
SRv6 Locator TLV MUST be installed in the forwarding plane of
receiving SRv6-capable routers when the associated algorithm is
supported by the receiving OSPFv3 router. Locators can be of
different route types similar to existing OSPFv3 route types - Intra-
Area, Inter-Area, External, and NSSA. The processing of the prefix
advertised in the SRv6 Locator TLV, the calculation of its
reachability, and the installation in the forwarding plane follows
the OSPFv3 [RFC5340] specifications for the respective route types.
Li, et al. Expires January 2, 2023 [Page 6]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
Locators associated with algorithms 0 and 1 SHOULD be advertised
using the respective OSPFv3 Extended LSA types with extended TLVs
[RFC8362] so that routers that do not support SRv6 will install a
forwarding entry for SRv6 traffic matching those locators. When
operating in Extended LSA sparse-mode [RFC8362], these locators
SHOULD be also advertised using the respective legacy OSPFv3 LSAs
[RFC5340].
In cases where a locator advertisement is received both in a prefix
reachability advertisement (i.e., via legacy OSPFv3 LSAs and/or
Extended Prefix TLVs using OSPFv3 Extended LSAs) and an SRv6 Locator
TLV, the prefix reachability advertisement in the OSPFv3 legacy LSA
or Extended LSA MUST be preferred over the advertisement in the SRv6
Locator TLV when installing entries in the forwarding plane. This is
to prevent inconsistent forwarding entries between SRv6 capable and
SRv6 incapable OSPFv3 routers. Such preference of prefix
reachability advertisement does not have any impact on the rest of
the data advertised in the SRv6 Locator TLV.
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
specific Neighbor/Link and are therefore advertised as Sub-TLVs of E-
Router-Link TLV.
SRv6 SIDs received from other OSFPv3 routers are not directly
routable and MUST NOT be installed in the forwarding plane.
Reachability to SRv6 SIDs depends upon the existence of a covering
locator.
Adherence to the rules defined in this section will assure that SRv6
SIDs associated with a supported algorithm will be forwarded
correctly, while SRv6 SIDs associated with an unsupported algorithm
will be dropped. NOTE: The drop behavior depends on the absence of a
default/summary route matching the locator prefix.
For forwarding to work correctly, the locator associated with SRv6
SID advertisements must be the longest prefix match installed in the
forwarding plane for those SIDs. To ensure correct forwarding,
network operators should take steps to make sure that this
requirement is not compromised. For example, the following
situations should be avoided:
o Another locator associated with a different topology/algorithm is
the longest prefix match
o Another prefix advertised via OSPFv3 legacy or Extended LSA
advertisement is the longest prefix match
Li, et al. Expires January 2, 2023 [Page 7]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
5.1. SRv6 Flexible Algorithm
[I-D.ietf-lsr-flex-algo] specifies IGP Flexible Algorithm mechanisms
for OSPFv3. Section 14.2 of [I-D.ietf-lsr-flex-algo] explains SRv6
forwarding for Flex-Algorithm and the same applies to supporting SRv6
Flex-Algorithm using OSPFv3. When the algorithm value that is
advertised in the SRv6 Locator TLV (refer to Section 6.1) represents
a Flex-Algorithm, the procedures described in section 14.2 of
[I-D.ietf-lsr-flex-algo] are followed for the programming of those
specific SRv6 Locators. Locators associated with Flexible Algorithms
SHOULD NOT be advertised in the base OSPFv3 prefix reachability
advertisements. Advertising the Flexible Algorithm locator in a
regular prefix reachability advertisement would make them available
for non-Flex-Algo forwarding (i.e., algorithm 0).
The procedures for OSPFv3 Flex-Algorithm for SR-MPLS, as specified in
[I-D.ietf-lsr-flex-algo], like ASBR reachability, inter-area,
external, and NSSA prefix advertisements and their use in Flex-
Algorithm route computation also apply for SRv6.
6. SRv6 Locator LSA
The SRv6 Locator LSA has a function code of TBD while the S1/S2 bits
are dependent on the desired flooding scope for the LSA. The
flooding 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 U bit will be set indicating that the LSA should be
flooded even if it is not understood.
Multiple SRv6 Locator LSAs can be advertised by an OSPFv3 router and
they are distinguished by their Link State IDs (which are chosen
arbitrarily by the originating router).
The format of SRv6 Locator LSA is shown below:
Li, et al. Expires January 2, 2023 [Page 8]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
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 |1|S12| Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
Figure 2: SRv6 Locator LSA
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
consists of one or more nested TLV tuples. Nested TLVs are also
referred to as Sub-TLVs. The format of each TLV is:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
o
o
o
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SRv6 Locator LSA TLV Format
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
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
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
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.
Li, et al. Expires January 2, 2023 [Page 9]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
6.1. SRv6 Locator TLV
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
associated with it. Multiple SRv6 Locator TLVs MAY be advertised in
each SRv6 Locator LSA. However, since the S12 bits define the
flooding scope, the LSA flooding scope MUST satisfy the application-
specific requirements for all the locators included in a single SRv6
Locator LSA.
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
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
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
the same Locator appears in multiple SRv6 Locator LSAs that have the
same flooding scope, the TLV in the SRv6 Locator LSA with the
numerically smallest Link-State ID MUST be used and subsequent
instances of the TLV MUST be ignored.
The format of SRv6 Locator 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Algorithm | Locator Length| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| ... |
Figure 4: SRv6 Locator TLV
Where:
Li, et al. Expires January 2, 2023 [Page 10]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
Type: 2-octet field. The value for this type is 1.
Length: 2-octet field. The total length (in octets) of the value
portion of the TLV including nested Sub-TLVs.
Route Type: 1-octet field. The type of the locator route. The
only supported types are the ones listed below and the SRv6
Locator TLV MUST be ignored on receipt of any other type.
1 - Intra-Area
2 - Inter-Area
3 - AS External Type 1
4 - AS External Type 2
5 - NSSA External Type 1
6 - NSSA External Type 2
Algorithm: 1-octet field. The algorithm associated with the SRv6
Locator. Algorithm values are defined in the IGP Algorithm Type
registry.
Locator Length: 1-octet field. Carries the length of the Locator
prefix as the number of locator bits from the range (1-128).
Flags: 1-octet field. The flags are defined as follows:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|N|A| Reserved |
+-+-+-+-+-+-+-+-+
* N-flag: When the locator uniquely identifies a router node in
the network (i.e., it is provisioned on one and only one
router), the N bit MUST be set. Otherwise, this bit MUST be
clear.
* A-flag: When the Locator is configured as anycast, the A bit
SHOULD be set. Otherwise, this bit MUST be clear. If both the
N and A bits are set, then receiving routers MUST ignore the N
bit (i.e., consider it as not set).
* Other flags are not defined and reserved for future use. They
MUST be set to 0 on transmission and MUST be ignored on
receipt.
Metric: 4-octet field. The metric value associated with the SRv6
Locator.
Li, et al. Expires January 2, 2023 [Page 11]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
Locator: 16-octet field. This field encodes the advertised SRv6
Locator.
Sub-TLVs: Used to advertise Sub-TLVs that provide additional
attributes for the given SRv6 Locator and SRv6 SIDs associated
with the SRv6 Locator.
7. Advertisement of SRv6 End SIDs
The SRv6 End SID Sub-TLV is a Sub-TLV of the SRv6 Locator TLV in the
SRv6 Locator LSA (defined in Section 6). It is used to advertise the
SRv6 SIDs belonging to the router along with their associated
endpoint behaviors. SIDs associated with adjacencies are advertised
as described in Section 8. Every SRv6-enabled OSPFv3 router SHOULD
advertise at least one SRv6 SID associated with an END behavior for
itself as specified in [RFC8986].
SRv6 End SIDs inherit the algorithm from the parent locator. The
SRv6 End SID MUST be allocated from its associated locator. SRv6 End
SIDs that are NOT allocated from the associated locator MUST be
ignored.
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
advertised. When multiple SRv6 End SID Sub-TLVs are received in the
SRv6 Locator TLV from a given router for the same SRv6 SID value, the
receiver MUST use the first occurrence of the Sub-TLV in the SRv6
Locator TLV.
The format of SRv6 End SID Sub-TLV is shown below
Li, et al. Expires January 2, 2023 [Page 12]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SRv6 End SID Sub-TLV
Where:
Type: 2-octet field. The value for this type is 1.
Length: 2-octet field. The total length (in octets) of the value
portion of the Sub-TLV including its further nested Sub-TLVs.
Reserved: 1-octet field. It MUST be set to 0 on transmission and
MUST be ignored on receipt.
Flags: 1-octet field. It carries the flags associated with the
SID. No flags are currently defined and this field MUST be set to
0 on transmission and MUST be ignored on receipt.
Endpoint Behavior: 2 octets field. The endpoint behavior code
point for this SRv6 SID as defined in [RFC8986]. Supported
behavior values for this sub-TLV are defined in Section 10 of this
document. Unsupported or unrecognized behavior values are ignored
by the receiver.
SID: 16-octet field. This field encodes the advertised SRv6 SID.
Sub-TLVs: Used to advertise Sub-TLVs that provide additional
attributes for the given SRv6 SID.
Li, et al. Expires January 2, 2023 [Page 13]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
8. Advertisement of SRv6 SIDs Associated with Adjacencies
The SRv6 endpoint behaviors defined in [RFC8986] include certain
behaviors that are specific to links or adjacencies. The most basic
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
specific neighbor on a specific link. These SRv6 SIDs and others
that are defined in [RFC8986] which are specific to links or
adjacencies need to be advertised to OSPFv3 routers within an area to
steer SRv6 traffic over a specific link or adjacency.
The advertisement of SRv6 SIDs that are specific to a particular
neighbor is accomplished via two different optional Sub-TLVs of the
E-Router-Link TLV defined in [RFC8362]:
o 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
Designated Router (DR) over broadcast and Non-Broadcast-Multi-
Access (NBMA) links.
o SRv6 LAN End.X SID Sub-TLV: Used for OSPFv3 adjacencies on
broadcast and NBMA links to the Backup DR and DR-Other neighbors.
This Sub-TLV includes the OSPFv3 Router-ID of the neighbor and
thus allows for an instance of this Sub-TLV for each neighbor to
be explicitly advertised as a Sub-TLV of the E-Router-Link TLV for
the same link.
Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one
unique SRv6 End.X SID corresponding to each of its neighbors. A
router MAY instantiate more than one SRv6 End.X SID for a single
neighbor. The same SRv6 End.X SID MAY be advertised for more than
one neighbor. Thus multiple instances of the SRv6 End.X SID and SRv6
LAN End.X SID Sub-TLVs MAY be advertised 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
Locator with the matching algorithm which is advertised by the same
OSPFv3 router in an SRv6 Locator TLV. End.X SIDs which do not meet
this requirement MUST be ignored. This ensures that the OSPFv3
router advertising the End.X or LAN End.X SID is also advertising its
corresponding Locator with the algorithm that will be used for
computing paths destined to the SID.
8.1. SRv6 End.X SID Sub-TLV
The format of the SRv6 End.X SID Sub-TLV is shown below
Li, et al. Expires January 2, 2023 [Page 14]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
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 continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SRv6 End.X SID Sub-TLV
Where:
Type: 2-octet field. The value for this type is TBD.
Length: 2-octet field. The total length (in octets) of the value
portion of the Sub-TLV including its further nested Sub-TLVs.
Endpoint Behavior: 2-octet field. The endpoint behavior code
point for this SRv6 SID as defined in [RFC8986]. Supported
behavior values for this sub-TLV are defined in Section 10 of this
document. Unsupported or unrecognized behavior values are ignored
by the receiver.
Flags: 1-octet field. The flags are defined as follows:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| Reserved|
+-+-+-+-+-+-+-+-+
* B-Flag: Backup Flag. If set, the SID refers to a path that is
eligible for protection.
Li, et al. Expires January 2, 2023 [Page 15]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
* S-Flag: Set Flag. When set, the S-Flag indicates that the
End.X SID refers to a set of adjacencies (and therefore MAY be
assigned to other adjacencies as well).
* P-Flag: Persistent Flag: If set, the SID is persistently
allocated, i.e., the SID value remains consistent across router
restart and session/interface flap.
* Other flags are not defined and reserved for future use. They
MUST be set to 0 on transmission and MUST be ignored on
receipt.
Reserved1: 1-octet field. It MUST be set to 0 on transmission and
MUST be ignored on receipt.
Algorithm: 1-octet field. The algorithm associated with the SRv6
Locator from which the SID is allocated. Algorithm values are
defined in the IGP Algorithm Type registry.
Weight: 1-octet field. Its value represents the weight of the
End.X SID for load-balancing. The use of the weight is defined in
[RFC8402].
Reserved2: 2-octet field. It MUST be set to 0 on transmission and
MUST be ignored on receipt.
SID: 16-octet field. This field encodes the advertised SRv6 SID.
Sub-TLVs: Used to advertise Sub-TLVs that provide additional
attributes for the given SRv6 End.X SID.
8.2. SRv6 LAN End.X SID Sub-TLV
The format of the SRv6 LAN End.X SID Sub-TLV is as shown below:
Li, et al. Expires January 2, 2023 [Page 16]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPFv3 Router-ID of neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: SRv6 LAN End.X SID Sub-TLV
Where:
o Type: 2-octet field. The value for this type is TBD.
o Length: 2-octet field. The total length (in octets) of the value
portion of the Sub-TLV including its further nested Sub-TLVs.
o Endpoint Behavior: 2-octet field. The code point for the endpoint
behavior for this SRv6 SID as defined in section 9.2 of [RFC8986].
o Flags: 1-octet field. The flags are defined as follows:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| Reserved|
+-+-+-+-+-+-+-+-+
* B-Flag: Backup Flag. If set, the SID refers to a path that is
eligible for protection.
Li, et al. Expires January 2, 2023 [Page 17]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
* S-Flag: Set Flag. When set, the S-Flag indicates that the
End.X SID refers to a set of adjacencies (and therefore MAY be
assigned to other adjacencies as well).
* P-Flag: Persistent Flag: If set, the SID is persistently
allocated, i.e., the SID value remains consistent across router
restart and session/interface flap.
* Other flags are not defined and reserved for future use. They
MUST be set to 0 on transmission and MUST be ignored on
receipt.
o Reserved1: 1-octet field. It MUST be set to 0 on transmission and
MUST be ignored on receipt.
o Algorithm: 1-octet field. The algorithm associated with the SRv6
Locator from which the SID is allocated. Algorithm values are
defined in the IGP Algorithm Type registry.
o Weight: 1-octet field. Its value represents the weight of the
End.X SID for load balancing. The use of the weight is defined in
[RFC8402].
o Reserved2: 2-octet field. It MUST be set to 0 on transmission and
MUST be ignored on receipt.
o Neighbor ID: 4-octet field. It carries the OSPFv3 Router-id of
the neighbor.
o SID: 16-octet field. This field encodes the advertised SRv6 SID.
o Sub-TLVs: Used to advertise Sub-TLVs that provide additional
attributes for the given SRv6 SID.
9. SRv6 SID Structure Sub-TLV
SRv6 SID Structure Sub-TLV is used to advertise the structure of the
SRv6 SID as defined in [RFC8986]. It is used as an optional Sub-TLV
of the following:
o SRv6 End SID Sub-TLV (refer to Section 7)
o SRv6 End.X SID Sub-TLV (refer to Section 8.1)
o SRv6 LAN End.X SID Sub-TLV (refer to Section 8.2)
The Sub-TLV has the following format:
Li, et al. Expires January 2, 2023 [Page 18]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB Length | LN Length | Fun. Length | Arg. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: SRv6 SID Structure Sub-TLV
Where:
Type: 2-octet field. The value for this type is TBD.
Length: 2-octet field. It carries the value of 4.
LB Length: 1-octet field. SRv6 SID Locator Block length in bits.
LN Length: 1-octet bit field. SRv6 SID Locator Node 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.
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,
the parent Sub-TLV MUST be ignored by the receiver.
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
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 SRv6 SID Structure Sub-TLV is intended for informational use by
the control and management planes. It MUST NOT be used at a transit
node (as defined in [RFC8754]) for forwarding packets. As an
example, this information could be used for:
o validation of SRv6 SIDs being instantiated in the network and
advertised via OSPFv3. These can be learned by controllers via
BGP-LS and then be monitored for conformance to the SRv6 SID
allocation scheme chosen by the operator as described in
Section 3.2 of [RFC8986].
Li, et al. Expires January 2, 2023 [Page 19]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
o verification and the automation for securing the SRv6 domain by
provisioning filtering rules at SR domain boundaries as described
in Section 5 of [RFC8754].
The details of these potential applications are outside the scope of
this document.
10. Advertising Endpoint Behaviors
Endpoint behaviors are defined in [RFC8986]. The codepoints for the
Endpoint behaviors are defined in the "SRv6 Endpoint Behaviors"
registry of [RFC8986]. This section lists the Endpoint behaviors and
their codepoints, which MAY be advertised by OSPFv3 and the Sub-TLVs
in which each type MAY appear.
|-----------------------|--------------------|-----|-------|-----------|
| Endpoint | Endpoint | End | End.X | LAN End.X |
| Behavior | Behavior Codepoint | SID | SID | SID |
|-----------------------|--------------------|-----|-------|-----------|
| End (PSP, USP, USD) | 1-4, 28-31 | Y | N | N |
|-----------------------|--------------------|-----|-------|-----------|
| End.X (PSP, USP, USD) | 5-8, 32-35 | N | Y | Y |
|-----------------------|--------------------|-----|-------|-----------|
| End.DX6 | 16 | N | Y | Y |
|-----------------------|--------------------|-----|-------|-----------|
| End.DX4 | 17 | N | Y | Y |
|-----------------------|--------------------|-----|-------|-----------|
| End.DT6 | 18 | Y | N | N |
|-----------------------|--------------------|-----|-------|-----------|
| End.DT4 | 19 | Y | N | N |
|-----------------------|--------------------|-----|-------|-----------|
| End.DT64 | 20 | Y | N | N |
|-----------------------|--------------------|-----|-------|-----------|
Figure 9: SRv6 Endpoint Behaviors in OSPFv3
11. Security Considerations
Existing security extensions as described in [RFC5340] and [RFC8362]
apply to these SRv6 extensions. While OSPFv3 is under a single
administrative domain, there can be deployments where potential
attackers have access to one or more networks in the OSPFv3 routing
domain. In these deployments, stronger authentication mechanisms
such as those specified in [RFC4552] or [RFC7166] SHOULD be used.
Implementations MUST assure that malformed TLV and Sub-TLV defined in
this document are detected and do not provide a vulnerability for
Li, et al. Expires January 2, 2023 [Page 20]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
attackers to crash the OSPFv3 router or routing process. Reception
of malformed TLV or Sub-TLV SHOULD be counted and/or logged for
further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be
rate-limited to prevent a Denial of Service (DoS) attack (distributed
or otherwise) from overloading the OSPFv3 control plane.
This document describes the OSPFv3 extensions required to support
Segment Routing over an IPv6 data plane. The security considerations
for Segment Routing are discussed in [RFC8402]. [RFC8986] defines
the SRv6 Network Programming concept and specifies the main Segment
Routing behaviors to enable the creation of interoperable overlays;
the security considerations from that document apply too.
The advertisement for an incorrect MSD value may have negative
consequences, see [RFC8476] for additional considerations.
Security concerns associated with the setting of the O-flag are
described in [RFC9259].
Security concerns associated with the usage of Flex-Algorithms are
described in [I-D.ietf-lsr-flex-algo].
12. IANA Considerations
This document requests IANA to perform allocations from OSPF and
OSPFv3 related registries as well as creating of new registries as
follows.
12.1. OSPF Router Information TLVs
This document requests the allocation of a new code point in the
"OSPF Router Information (RI) TLVs" registry under the "OSPF
Parameters" registry for the new TLV below:
Type TBD (suggested 20): SRv6-Capabilities TLV: Refer to
Section 2.
12.2. OSPFv3 LSA Function Codes
This document requests the allocation of a new code point in the
"OSPFv3 LSA Function Codes" registry under the "OSPFv3 Parameters"
registry for the new LSA below:
o Type TBD (suggested 42): SRv6 Locator LSA: Refer to Section 6.
Li, et al. Expires January 2, 2023 [Page 21]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
12.3. OSPFv3 Extended-LSA Sub-TLVs
This document requests allocation of the following new code points in
the "OSPFv3 Extended-LSA Sub-TLVs" registry under the "OSPFv3
Parameters" registry for the new Sub-TLVs below:
o Type TBD (suggested 30): SRv6 SID Structure Sub-TLV: Refer to
Section 9.
o Type TBD (suggested 31): SRv6 End.X SID Sub-TLV: Refer to
Section 8.1.
o Type TBD (suggested 32): SRv6 LAN End.X SID Sub-TLV: Refer to
Section 8.2.
12.4. OSPFv3 Locator LSA TLVs
This document requests the creation of an "OSPFv3 Locator LSA TLVs"
registry, that defines top-level TLVs for the OSPFv3 SRv6 Locator
LSA, under the "OSPFv3 Parameters" registry. The initial code-points
assignment is as below:
o Type 0: Reserved.
o Type 1: SRv6 Locator TLV: Refer to Section 6.1.
Types in the range 2-32767 are allocated via IETF Review or IESG
Approval [RFC8126].
Types in the range 32768-33023 are Reserved for Experimental Use;
these will not be registered with IANA and MUST NOT be mentioned by
RFCs.
Types in the range 33024-45055 are to be assigned on a First Come
First Served (FCFS) basis.
Types in the range 45056-65535 are not to be assigned at this time.
Before any assignments can be made in the 33024-65535 range, there
MUST be an IETF specification that specifies IANA Considerations that
cover the range being assigned.
12.5. OSPFv3 Locator LSA Sub-TLVs
This document requests the creation of an "OSPFv3 Locator LSA Sub-
TLVs" registry, that defines Sub-TLVs at any level of nesting for the
SRv6 Locator LSA, to be added under the "OSPFv3 Parameters" registry.
The initial code-points assignment is as below:
Li, et al. Expires January 2, 2023 [Page 22]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
o Type 0: Reserved.
o Type 1: SRv6 End SID Sub-TLV: Refer to Section 7.
o Type 10: SRv6 SID Structure Sub-TLV: Refer to Section 9.
Types in the range 2-9 and 11-32767 are allocated via IETF Review or
IESG Approval [RFC8126].
Types in the range 32768-33023 are Reserved for Experimental Use;
these will not be registered with IANA and MUST NOT be mentioned by
RFCs.
Types in the range 33024-45055 are to be assigned on a First Come
First Served (FCFS) basis.
Types in the range 45056-65535 are not to be assigned at this time.
Before any assignments can be made in the 33024-65535 range, there
MUST be an IETF specification that specifies IANA Considerations that
cover the range being assigned.
13. 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 Chenzichao 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.
14. References
14.1. Normative References
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-20 (work in progress), May 2022.
[I-D.ietf-lsr-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Z. Hu, "IS-IS Extensions to Support Segment Routing over
IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-18
(work in progress), October 2021.
Li, et al. Expires January 2, 2023 [Page 23]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak,
"Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476,
DOI 10.17487/RFC8476, December 2018,
<https://www.rfc-editor.org/info/rfc8476>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", RFC 8665,
DOI 10.17487/RFC8665, December 2019,
<https://www.rfc-editor.org/info/rfc8665>.
[RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions
for Segment Routing", RFC 8666, DOI 10.17487/RFC8666,
December 2019, <https://www.rfc-editor.org/info/rfc8666>.
Li, et al. Expires January 2, 2023 [Page 24]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9259] Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M.
Chen, "Operations, Administration, and Maintenance (OAM)
in Segment Routing over IPv6 (SRv6)", RFC 9259,
DOI 10.17487/RFC9259, June 2022,
<https://www.rfc-editor.org/info/rfc9259>.
14.2. Informative References
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<https://www.rfc-editor.org/info/rfc4552>.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166,
DOI 10.17487/RFC7166, March 2014,
<https://www.rfc-editor.org/info/rfc7166>.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Email: lizhenbin@huawei.com
Zhibo Hu
Huawei Technologies
Email: huzhibo@huawei.com
Li, et al. Expires January 2, 2023 [Page 25]
Internet-Draft OSPFv3 Extensions for SRV6 July 2022
Ketan Talaulikar (editor)
Arrcus Inc
India
Email: ketant.ietf@gmail.com
Peter Psenak
Cisco Systems
Slovakia
Email: ppsenak@cisco.com
Li, et al. Expires January 2, 2023 [Page 26]