< draft-li-ospf-ospfv3-srv6-extensions-03.txt   draft-li-ospf-ospfv3-srv6-extensions-04.txt >
Network Working Group Z. Li Network Working Group Z. Li
Internet-Draft Z. Hu Internet-Draft Z. Hu
Intended status: Standards Track D. Cheng Intended status: Standards Track D. Cheng
Expires: September 7, 2019 Huawei Technologies Expires: January 9, 2020 Huawei Technologies
K. Talaulikar K. Talaulikar
P. Psenak P. Psenak
Cisco Systems Cisco Systems
March 6, 2019 July 8, 2019
OSPFv3 Extensions for SRv6 OSPFv3 Extensions for SRv6
draft-li-ospf-ospfv3-srv6-extensions-03 draft-li-ospf-ospfv3-srv6-extensions-04
Abstract Abstract
Segment Routing (SR) allows for a flexible definition of end-to-end Segment Routing (SR) allows for a flexible definition of end-to-end
paths by encoding paths as sequences of topological sub-paths, called paths by encoding paths as sequences of topological sub-paths, called
"segments". Segment routing architecture can be implemented over an "segments". Segment routing architecture can be implemented over an
MPLS data plane as well as an IPv6 data plane. This draft describes MPLS data plane as well as an IPv6 data plane. This draft describes
the OSPFv3 extensions required to support Segment Routing over an the OSPFv3 extensions required to support Segment Routing over an
IPv6 data plane (SRv6). IPv6 data plane (SRv6).
Requirements Language 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. OSPFv3 Extensions for SRv6 . . . . . . . . . . . . . . . . . 3 2. SRv6-Capabilities TLV . . . . . . . . . . . . . . . . . . . . 3
2.1. SRv6-Capabilities TLV . . . . . . . . . . . . . . . . . . 3 3. Advertisement of Supported Algorithms . . . . . . . . . . . . 5
2.1.1. Maximum SL Sub-TLV . . . . . . . . . . . . . . . . . 5 4. Advertisement of SRH Operation Limits . . . . . . . . . . . . 5
2.1.2. Maximum End Pop SRH Sub-TLV . . . . . . . . . . . . . 5 5. Advertisement of SRv6 Locator and End SIDs . . . . . . . . . 5
2.1.3. Maximum T.Insert SRH Sub-TLV . . . . . . . . . . . . 6 6. SRv6 Locator LSA . . . . . . . . . . . . . . . . . . . . . . 6
2.1.4. Maximum T.Encap SRH Sub-TLV . . . . . . . . . . . . . 6 6.1. SRv6 Locator TLV . . . . . . . . . . . . . . . . . . . . 8
2.1.5. Maximum End D SRH Sub-TLV . . . . . . . . . . . . . . 7 7. Advertisment of SRv6 End SIDs . . . . . . . . . . . . . . . . 10
2.2. SRv6 Node SID TLV . . . . . . . . . . . . . . . . . . . . 8 8. Advertisment of SRv6 SIDs Associated with Adjacencies . . . . 11
2.3. SRv6 SIDs Associated with Adjacencies . . . . . . . . . . 10 8.1. SRv6 End.X SID Sub-TLV . . . . . . . . . . . . . . . . . 12
2.3.1. SRv6 SID Link Attribute Sub-TLV . . . . . . . . . . . 11 8.2. SRv6 LAN End.X SID Sub-TLV . . . . . . . . . . . . . . . 14
2.3.2. SRv6 SID LAN Link Attribute Sub-TLV . . . . . . . . . 12 9. SRv6 SID Structure sub-TLV . . . . . . . . . . . . . . . . . 15
3. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
4.1. OSPF Parameters . . . . . . . . . . . . . . . . . . . . . 14 11.1. OSPF Router Information TLVs . . . . . . . . . . . . . . 17
4.2. OSPFv3 Parameters . . . . . . . . . . . . . . . . . . . . 14 11.2. OSPFv3 LSA Function Codes . . . . . . . . . . . . . . . 17
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11.3. OSPFv3 Extended-LSA sub-TLVs . . . . . . . . . . . . . . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.4. OSPFv3 Locator LSA TLVs . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.5. OSPFv3 Locator LSA sub-TLVs . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Segment Routing (SR) architecture [I-D.ietf-spring-segment-routing] Segment Routing (SR) architecture [RFC8402] specifies how a node can
specifies how a node can steer a packet through an ordered list of steer a packet through an ordered list of instructions, called
instructions, called segments. These segments are identified through segments. These segments are identified through Segment Identifiers
Segment Identifiers (SIDs). (SIDs).
Segment Routing can be instantiated on the IPv6 data plane through Segment Routing can be instantiated on the IPv6 data plane through
the use of the Segment Routing Header (SRH) defined in the use of the Segment Routing Header (SRH) defined in
[I-D.ietf-6man-segment-routing-header]. SRv6 refers to this SR [I-D.ietf-6man-segment-routing-header]. SRv6 refers to this SR
instantiation on the IPv6 dataplane. The network programming instantiation on the IPv6 dataplane. The network programming
paradigm for SRv6 is specified in paradigm for SRv6 is specified in
[I-D.filsfils-spring-srv6-network-programming] which describes [I-D.ietf-spring-srv6-network-programming] which describes several
several well-known functions that can be bound to SRv6 SIDs. well-known functions that can be bound to SRv6 SIDs.
This document proposes extensions to OSPFv3 in order to support SRv6 This document specifies extensions to OSPFv3 in order to support SRv6
as defined in [I-D.filsfils-spring-srv6-network-programming] by as defined in [I-D.ietf-spring-srv6-network-programming] by signaling
signaling the SRv6 capabilities of the node and certain functions the SRv6 capabilities of the node and certain SRv6 SIDs with their
(e.g. END, END.X, etc.) that are instantiated on the SRv6 capable endpoint behaviors (e.g. End, End.X, etc.) that are instantiated on
router. the SRv6 capable router.
At a high level, the extensions to OSPFv3 comprise of a SRv6 At a high level, the extensions to OSPFv3 comprise of the following:
Capabilities TLV to advertise the support for SRv6 features supported
by the router. A new LSA type Also included are extensions in the
form of TLVs and sub-TLVs for advertising the SRv6 SIDs corresponding
the to functions related to the node (e.g. END) and those related to
the adjacencies (e.g. END.X) for the SRv6 enabled OSPFv3 router.
2. OSPFv3 Extensions for SRv6 1. SRv6 Capabilities TLV to advertise the support for SRv6 features
and SRH operations supported by the router
2.1. SRv6-Capabilities TLV 2. SRv6 Locator TLV to advertise the SRv6 Locator - a form of
summary address for the algorithm specific SIDs associated with
the router
3. TLVs and sub-TLVs to advertise the SRv6 SIDs instantiated on the
router along with their endpoint behaviors
2. SRv6-Capabilities TLV
When Segment Routing (SR) is instantiated using the IPv6 data plane When Segment Routing (SR) is instantiated using the IPv6 data plane
(SRv6), the list of segments is expressed using the segment routing (SRv6), the list of segments is expressed using the segment routing
header (SRH) as defined in [I-D.ietf-6man-segment-routing-header]. header (SRH) as defined in [I-D.ietf-6man-segment-routing-header].
A router that supports SRv6 MUST be able to process the SRH as A router that supports SRv6 MUST be able to process the SRH as
described in [I-D.ietf-6man-segment-routing-header], as well as apply described in [I-D.ietf-6man-segment-routing-header], as well as apply
function behaviors and flavors as described in endpoint behaviors as described in
[I-D.filsfils-spring-srv6-network-programming]. A SRv6 enabled [I-D.ietf-spring-srv6-network-programming].
router may have different capabilities and limits when it comes to
SRH processing and this needs to be advertised to other routers in
the SRv6 domain.
The SRv6 Capabilities TLV is designed for an OSPFv3 router to The SRv6 Capabilities TLV is designed for an OSPFv3 router to
advertise its SRv6 support along with its related capabilities for advertise its SRv6 support along with its related capabilities for
SRv6 functionality. This is a new optional top level TLV of OSPFv3 SRv6 functionality. This is a new optional top level TLV of OSPFv3
Router Information LSA TLV LSA ([RFC7770]) which MUST be advertised Router Information LSA [RFC7770] which MUST be advertised by a SRv6
by a SRv6 enabled router. enabled router.
This TLV SHOULD be advertised only once in the OSPFv3 Router This TLV SHOULD 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 Opaque LSA. If the SRv6 the TLV in the OSPFV3 Router Information Opaque LSA. If the SRv6
Capabilities TLV appears in multiple OSPFv3 Router Information Opaque Capabilities TLV appears in multiple OSPFv3 Router Information Opaque
LSAs that have different flooding scopes, the TLV in the OSPFv3 LSAs that have different flooding scopes, the TLV in the OSPFv3
Router Information Opaque LSA with the area-scoped flooding scope Router Information Opaque LSA with the area-scoped flooding scope
MUST be used. If the SRv6 Capabilities TLV appears in multiple MUST be used. If the SRv6 Capabilities TLV appears in multiple
OSPFv3 Router Information Opaque LSAs that have the same flooding OSPFv3 Router Information Opaque LSAs that have the same flooding
skipping to change at page 4, line 42 skipping to change at page 4, line 44
TLVs TLVs
o Reserved : 16 bit field. SHOULD be set to 0 and MUST be ignored o Reserved : 16 bit field. SHOULD be set to 0 and MUST be ignored
by receiver. by receiver.
o Flags: 16 bit field. The following flags are defined: o Flags: 16 bit field. The following flags are defined:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|O| | | |O| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
* E-flag: If set, then router is able to apply "T.Encap" * O-flag: If set, then router is capable of supporting SRH O-bit,
operation as specified in as specified in [I-D.ali-spring-srv6-oam].
[I-D.filsfils-spring-srv6-network-programming]
* O-flag: If set, then router is capable of supporting SRH O-bit
Flags, as specified in [I-D.ietf-6man-segment-routing-header].
The following sections define the supported sub-TLVs. The SRv6 Capabilities TLV may contain optional sub-TLVs. No sub-TLVs
are currently defined.
2.1.1. Maximum SL Sub-TLV 3. Advertisement of Supported Algorithms
The Maximum Segments Left Sub-TLV of the SRv6 Capabilities TLV SRv6 enabled OSPFv3 router advertises its algorithm support using the
specifies the maximum value of the "SL" field (refer to SR Algorithm TLV defined in
[I-D.ietf-6man-segment-routing-header]) in the SRH of a received [I-D.ietf-ospf-segment-routing-extensions] as described in
packet before applying the function associated with a SID. [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
0 1 2 3 4. Advertisement of SRH Operation Limits
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max SL |
+-+-+-+-+-+-+-+-+
o Type: 1 A SRv6 enabled router may have different capabilities and limits when
it comes to SRH processing and this needs to be advertised to other
routers in the SRv6 domain.
o Length: 4 (including padding to 32 bit aligned boundary for OSPF [RFC8476] defines the means to advertise node/link specific values
TLVs) for Maximum SID Depths (MSD) of various 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 E-Router-LSA TLV [RFC8362]. The format of the MSD types
for OSPFv3 is defined in [RFC8476].
o SL Value: 1 octet The MSD types for SRv6 that are defined in
[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.
o An 8 bit unsigned integer. 5. Advertisement of SRv6 Locator and End SIDs
If the sub-TLV is not advertised by an SRv6 capable router, then the An SRv6 Segment Identifier (SID) is 128 bits and represented as
value MUST be considered to be 0. LOC:FUNCT as described in [I-D.ietf-spring-srv6-network-programming].
2.1.2. Maximum End Pop SRH Sub-TLV A node is provisioned with algorithm specific locators for each
algorithm supported by that node. Each locator is a covering prefix
for all SIDs provisioned on that node which have the matching
algorithm.
The Maximum End Pop SRH Sub-Sub-TLV specifies the maximum number of Locators MUST be advertised in the SRv6 Locator LSA (see Section 6).
SIDs in the top SRH in an SRH stack to which the router can apply Forwarding entries for the locators advertised in the SRv6 Locator
"PSP" or USP" flavors LSA MUST be installed in the forwarding plane of receiving SRv6
([I-D.filsfils-spring-srv6-network-programming]). capable routers when the associated algorithm is supported by the
receiving node. Locators can be of different route types similar to
existing OSPF LSA route types - Intra-Area, Inter-Area, External and
NSSA. The computation of locator reachability and their
advertisement are similar to how normal OSPF prefix reachability LSAs
are processed as part of the SPF computation.
0 1 2 3 Locators are routable and MAY also be advertised via Prefix LSAs of
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 different types - Inter-Area Prefix LSA, AS-External LSA, NSSA LSA or
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Intra-Area Prefix LSA (or their equivalent extended LSAs [RFC8362]).
| Type | Length | Locators associated with Flexible Algorithms SHOULD NOT be advertised
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ via Prefix LSAs. Locators associated with algorithm 0 (for all
|Max-End-Pop-SRH| supported topologies) SHOULD be advertised in Prefix LSAs so that
+-+-+-+-+-+-+-+-+ legacy routers (i.e., routers which do NOT support SRv6) will install
a forwarding entry for algorithm 0 SRv6 traffic.
o Type: 2 In cases where a locator advertisement is received in both in a
Prefix LSA and an SRv6 Locator LSA, the Prefix LSA advertisement MUST
be preferred when installing entries in the forwarding plane. This
is to prevent inconsistent forwarding entries on SRv6 capable/SRv6
incapable routers.
o Length: 4 (including padding to 32 bit aligned boundary for OSPF SRv6 SIDs are advertised as sub-TLVs in the SRv6 Locator TLV except
TLVs) 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.
o Max-End-Pop-SRH Value: 1 octet SRv6 SIDs 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 covering a
given locator.
o An 8 bit unsigned integer. 6. SRv6 Locator LSA
If the value is 0 or the sub-TLV is not advertised by an SRv6 capable The SRv6 Locator LSA has a function code of TBD while the S1/S2 bits
router, then it MUST be considered that the router cannot apply PSP are dependent on the desired flooding scope for the LSA. The
or USP flavors. 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.
2.1.3. Maximum T.Insert SRH Sub-TLV 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 Maximum T.Insert SRH Sub-Sub-TLV specifies the maximum number of The format of SRv6 Locator LSA is shown below:
SIDs that can be inserted as part of the "T.insert"
behavior([I-D.filsfils-spring-srv6-network-programming]).
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 | | LS age |1|S12| Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-T.Insert | | Link State ID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
o Type: 3 Figure 1: SRv6 Locator LSA
o Length: 4 (including padding to 32 bit aligned boundary for OSPF The format of the TLVs within the body of the SRv6 Locator LSA is the
TLVs) 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:
o Max-T.Insert Value: 1 octet 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
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o An 8 bit unsigned integer. Figure 2: SRv6 Locator LSA TLV Format
If the value is 0 or the sub-TLV is not advertised by an SRv6 capable The Length field defines the length of the value portion in octets
router, then it MUST be considered that the router does not support (thus, a TLV with no value portion would have a length of 0). The
any variation of the "T.insert" behavior. 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.
2.1.4. Maximum T.Encap SRH Sub-TLV 6.1. SRv6 Locator TLV
The Maximum T.Encap SRH Sub-Sub-TLV specifies the maximum number of The SRv6 Locator TLV is a top-level TLV of the SRv6 Locator LSA that
SIDs that can be included as part of the "T.Encap" behavior is used to advertise a SRv6 Locator, its attributes and SIDs
([I-D.filsfils-spring-srv6-network-programming]). 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 a
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-T.Encap | | Route Type | Algorithm | Reserved | Flags |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| ... |
o Type: 4 Figure 3: SRv6 Locator TLV
o Length: 4 (including padding to 32 bit aligned boundary for OSPF Where:
TLVs)
o Max-T.Encap Value: 1 octet Type: 16 bit field. The value is 1 for this type.
o An 8 bit unsigned integer. Length: 16 bit field. The total length of the value portion of
the TLV including sub-TLVs.
If this value is 0 or the sub-TLV is not advertised by an SRv6 Route Type : 8 bit field. The type of the locator route.
capable router and the "E" flag is set in the associated SRv6 Supported types are the ones listed below and other other types
Capabilities sub-TLV, then it MUST be considered that the router can MUST be ignored by the receiver.
apply T.Encap by encapsulating the incoming packet in another IPv6
header without SRH the same way as IP-in-IP encapsulation is
performed. If the "E" flag is clear, then this sub-TLV SHOULD NOT be
advertised and MUST be ignored on receipt.
2.1.5. Maximum End D SRH Sub-TLV 1 - Intra-Area
2 - Inter-Area
3 - AS External
4 - NSSA External
The Maximum End D SRH sub-sub-TLV specifies the maximum number of Figure 4
SIDs in an SRH when applying "End.DX6" and "End.DT6" functions.
0 1 2 3 Algorithm: 8 bit field. Associated algorithm. Algorithm values
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 are defined in the IGP Algorithm Type registry.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-End-D |
+-+-+-+-+-+-+-+-+
o Type: 5 Reserved: 8 bit field. SHOULD be set to 0 by sender and MUST be
ignored by receiver.
o Length: 4 (including padding to 32 bit aligned boundary for OSPF Flags: 8 bit field. The following flags are defined
TLVs)
o Max End D Value: 1 octet 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|N|A| Reserved |
+-+-+-+-+-+-+-+-+
o An 8 bit unsigned integer. Figure 5
If this value is zero or the sub-TLV is not advertised by an SRv6 * N flag : When the locator uniquely identifies a node in the
capable router, then it MUST be considered that the router cannot network (i.e. it is provisioned on one and only one node), the
apply "End.DX6" or "End.DT6" functions if the extension header right N bit MUST be set. Otherwise, this bit MUST be clear.
underneath the outer IPv6 header is an SRH.
2.2. SRv6 Node SID TLV * A bit : When the Locator is configured as anycast, the A bit
SHOULD be set. Otherwise, this bit MUST be clear.
An OSPFv3 SRv6 enabled router may have multiple SRv6 SIDs * Other flags are not defined and SHOULD be set to 0 and MUST be
instantiated in its "My Local SID Table" (refer ignored on receipt.
[I-D.filsfils-spring-srv6-network-programming]). OSPFv3 needs to
advertise the SRv6 SIDs associated with the node and its functions
(e.g. END, END.T, etc.) as specified in
[I-D.filsfils-spring-srv6-network-programming] so that other routers
in the area learn the SRv6 SIDs that can be used to program SRv6
paths through this node.
SRv6 Node SID TLV is a new optional top-level TLV of OSPFv3 Router Metric : 32 bit field. The metric value associated with the
Information LSA ([RFC7770]) and is used to advertise the SRv6 SIDs locator.
belonging to the node along with their associated functions. Every
SRv6 enabled OSPFv3 router SHOULD advertise at least one SRv6 SID
associated with END function for its node as specified in
[I-D.filsfils-spring-srv6-network-programming].
The router MAY advertise multiple instances of the SRv6 Node SID TLV Locator : 16 octets. This field encodes the advertised SRv6
in its OSPFv3 Router Information LSA - one for each of the SRv6 SIDs Locator.
to be advertised. It is RECOMMENDED that the TLVs are ordered by
increasing values of the SRv6 SIDs within a single instance of the
OSPFv3 Router LSA. When multiple instances of the OSPFv3 Router
Information LSA are necessary to accomodate a large number of SRv6
SIDs, it is RECOMMENDED that the SRv6 Node SID TLVs are ordered by
increasing values of the SRv6 SIDs across increasing instance numbers
of the OSPFv3 Router Information LSA.
When multiple SRv6 Node SID TLVs are received from a given router for Sub-TLVs : Used to advertise sub-TLVs that provide additional
the same SRv6 SID value, the receiver MUST use the first occurrence attributes for the given SRv6 Locator and SRv6 SIDs associated
of the TLV in the OSPFV3 Router Information Opaque LSA. If the SRv6 with it.
Node SID TLV for the same SRv6 SID value appears in multiple OSPFv3
Router Information Opaque LSAs that have different flooding scopes,
the TLV in the OSPFv3 Router Information Opaque LSA with the area-
scoped flooding scope MUST be used. If the SRv6 Node SID TLV for the
same SRv6 SID value appears in multiple OSPFv3 Router Information
Opaque LSAs that have the same flooding scope, the TLV in the OSPFv3
Router Information Opaque LSA with the numerically smallest Instance
ID MUST be used and subsequent instances of the TLV MUST be ignored.
The OSPFv3 Router Information Opaque LSA can be advertised at any of 7. Advertisment of SRv6 End SIDs
the defined opaque flooding scopes (link, area, or Autonomous System
(AS)). For the purpose of SRv6 Node SID TLV advertisement, area-
scoped flooding is REQUIRED.
The format of OSPFv3 SRv6 Node SID TLV is shown below SRv6 End SID sub-TLV is a new sub-TLV of SRv6 Locator TLV in the SRv6
Locator LSA (defined in Section 6). It is used to advertise the SRv6
SIDs belonging to the node along with their associated functions.
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 its node as
specified in [I-D.ietf-spring-srv6-network-programming].
SRv6 End SIDs inherit the algorithm from the parent locator. The
SRv6 End SID MUST be a subnet of the associated Locator. SRv6 End
SIDs which are NOT a subnet of 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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Function-Flags| Function Code | | Flags | Reserved | Endpoint Behavior ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SID Flags | SID-size | | SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (variable - 32 bit aligned) ... | SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . . | SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SRv6 SID Node TLV Figure 6: SRv6 End SID sub-TLV
Where: Where:
Type: 16 bit field. TBD Type: 16 bit field. Value is 1 for this type.
Length: 16 bit field. The total length of the value portion of Length: 16 bit field. The total length of the value portion of
the TLV. the sub-TLV including sub-sub-TLVs.
Reserved : 8 bit field. Should be set to 0 and MUST be ignored on Reserved : 8 bit field. Should be set to 0 and MUST be ignored on
receipt. receipt.
Function Flags: 8 bit field which define the flags associated with Flags: 8 bit field which define the flags associated with the SID.
the function. No flags are currently defined and SHOULD be set to No flags are currently defined and SHOULD be set to 0 and MUST be
0 and MUST be ignored on receipt. ignored on receipt.
Function Code: 16 bit field. The function code point for this
SRv6 SID as defined in
[I-D.filsfils-spring-srv6-network-programming].
Reserved : 16 bit field. Should be set to 0 and MUST be ignored
on receipt.
SID Flags: 8 bit field which define the flags associated with the
SID
0 1 2 3 4 5 6 7
+-+-|-+-+-+-+-+-+
|D| Reserved |
+-+-+-+-+-+-+-+-+
Figure 2
* D bit (0x1) : When the SID is leaked from OSPFv3 backbone area
to other areas, the D bit MUST be set. Otherwise, this bit
MUST be clear. SIDs with the D bit set MUST NOT be leaked to
OSPFv3 backbone area from others. This is to prevent looping.
* Other flags are not defined and SHOULD be set to 0 and MUST be
ignored on receipt.
SID Size : 8 bit field. Number of bits in the SID field. Endpoint Behavior ID: 16 bit field. The endpoint behavior code
point for this SRv6 SID as defined in
[I-D.ietf-spring-srv6-network-programming].
SID : 1-16 octets. This field encodes the advertised SRv6 SID. SID : 16 octets. This field encodes the advertised SRv6 SID.
The "SID-size" field can have the values 1-128 and indicates the
number of bits in the SID. The SRv6 SID is encoded in the minimal
number of 32-bit aligned space for the given number of bits.
Sub-TLVs : currently none defined. Used to advertise sub-TLVs Sub-Sub-TLVs : Used to advertise sub-sub-TLVs that provide
that provide additional attributes for the given SRv6 SID. additional attributes for the given SRv6 SID.
2.3. SRv6 SIDs Associated with Adjacencies 8. Advertisment of SRv6 SIDs Associated with Adjacencies
The SRv6 functions are defined in The SRv6 endpoint behaviors are defined in
[I-D.filsfils-spring-srv6-network-programming] include certain [I-D.ietf-spring-srv6-network-programming] include certain behaviors
functions which are specific to links or adjacencies. The most basic which are specific to links or adjacencies. The most basic of this
of this which is critical for link state routing protocols like which is critical for link state routing protocols like OSPFv3 is the
OSPFv3 is the END.X function that is an instruction to forward to a End.X behavior that is an instruction to forward to a specific
specific neighbor on a specific link. These END.X SRv6 SIDs are neighbor on a specific link. These SRv6 SIDs along with others that
instantiated by SRv6 enabled OSPFv3 router for all its adjacencies are defined in [I-D.ietf-spring-srv6-network-programming] which are
and installed in the local node's "My Local SID Table". These SRv6 specific to links or adjacencies need to be advertised by OSPFv3 so
SIDs along with others that are defined in that this information is available with all routers in the area to
[I-D.filsfils-spring-srv6-network-programming] which are specific to influence the packet path via these SRv6 SIDs over the specific
links or adjacencies need to be advertised by OSPFv3 so that this
information is available with all routers in the domain to influence
the packet path via these specific functions over the specified
adjacencies. adjacencies.
The advertising of SRv6 SIDs and their functions that are specific to The advertising of SRv6 SIDs and their behaviors that are specific to
a particular neighbor are done via two different optional sub-TLVs of a particular neighbor are done via two different optional sub-TLVs of
the Router-Link TLV as defined in [I-D.ietf-ospf-ospfv3-lsa-extend] the E-Router-Link TLV defined in [RFC8362] as follows:
as follows:
o SRv6 SID Link Attribute Sub-TLV: for OSPFv3 adjacency over point- o SRv6 End.X SID Sub-TLV: for OSPFv3 adjacency over point-to-point
to-point or point-to-multipoint links and the adjacecny to the or point-to-multipoint links and the adjacency to the Designated
Designated Router (DR) over broadcast and non-broadcast-multi- Router (DR) over broadcast and non-broadcast-multi-access (NBMA)
access (NBMA) links. links.
o SRv6 SID LAN Link Attribute Sub-TLV: for OSPFv3 adjacency on o SRv6 LAN End.X SID Sub-TLV: for OSPFv3 adjacency on broadcast and
broadcast and NBMA links to the Backup DR and DR-Other neighbors. NBMA links to the Backup DR and DR-Other neighbors. This sub-TLV
This sub-TLV includes the OSPFv3 router-id of the neighbor and includes the OSPFv3 router-id of the neighbor and thus allows for
thus allows for multiple instances of this TLV for each neighbor multiple instances of this TLV for each neighbor to be explicitly
to be explicitly advertised under the Router-Link TLV for the same advertised under the E-Router-Link TLV for the same link.
link.
Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one
END.X function with a unique SRv6 SID corresponding to each of its End.X function with a unique SRv6 SID corresponding to each of its
neighbor. A router MAY instantiate more than one SRv6 SID for the neighbor. A router MAY instantiate more than one SRv6 SID for the
END.X function for a single neighbor. The same SRv6 SID MAY be End.X function for a single neighbor. The same SRv6 SID MAY be
advertised for the END.X function corresponding to more than one advertised for the End.X function corresponding to more than one
neighbor. Thus multiple instances of the SRv6 SID Link Attribute and neighbor. Thus multiple instances of the SRv6 End.X SID and SRv6 LAN
SRv6 SID LAN Link Attribute sub-TLVs MAY be advertised within the End.X SID sub-TLVs MAY be advertised within the E-Router-Link TLV for
Router Link TLV for a single link. a single link.
2.3.1. SRv6 SID Link Attribute Sub-TLV All End.X SIDs MUST be a subnet of a Locator with matching algorithm
which is advertised by the same node in an SRv6 Locator TLV. End.X
SIDs which do not meet this requirement MUST be ignored.
The format of the SRv6 SID Link Attribute Sub-TLV is shown below 8.1. SRv6 End.X SID Sub-TLV
The format of the SRv6 End.X 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Function-Flags| Function Code | | Endpoint Behaviour ID | Flags | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SID Flags | SID-size | | Algorithm | Weight | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (variable - 32 bit aligned) ... | SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . . | Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where: Where:
Type is TBD Type is TBD
Length: 16 bit field. The total length of the value portion of Length: 16 bit field. The total length of the value portion of
the TLV. the TLV.
Reserved : 8 bit field. Should be set to 0 and MUST be ignored on Endpoint Behaviour ID: 16 bit field. The code point for the
receipt. endpoint behavior for this SRv6 SID as defined in
[I-D.ietf-spring-srv6-network-programming].
Function Flags: 8 bit field which define the flags associated with Flags: 8 bit field with the following definition:
the function. No flags are currently defined and SHOULD be set to
0 and MUST be ignored on receipt.
Function Code: 16 bit field. The function code point for this 0 1 2 3 4 5 6 7
SRv6 SID as defined in +-+-+-+-+-+-+-+-+
[I-D.filsfils-spring-srv6-network-programming]. |B|S|P| Rsvd |
+-+-+-+-+-+-+-+-+
Reserved : 16 bit field. Should be set to 0 and MUST be ignored * B-Flag: Backup Flag. If set, the SID refers to a path that is
eligible for protection.
* 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.
* Rsvd bits: Reserved for future use and MUST be zero when
originated and ignored when received.
Reserved1 : 8 bit field. Should be set to 0 and MUST be ignored
on receipt. on receipt.
SID Flags: 8 bit field which define the flags associated with the Algorithm : 8 bit field. Associated algorithm. Algorithm values
SID. No flags are currently defined and SHOULD be set to 0 and are defined in the IGP Algorithm Type registry.
MUST be ignored on receipt.
SID-size: Number of bits in the SID field. Weight: 8 bit field whose value represents the weight of the End.X
SID for the purpose of load balancing. The use of the weight is
defined in [RFC8402].
SID: 1-16 octets. This field encodes the advertised SRv6 SID. Reserved2 : 16 bit field. Should be set to 0 and MUST be ignored
The "SID-size" field can have the values 1-128 and indicates the on receipt.
number of bits in the SID. The SRv6 SID is encoded in the minimal
number of 32-bit aligned space for the given number of bits.
Sub-TLVs : currently none defined. Used to advertise sub-TLVs SID: 16 octets. This field encodes the advertised SRv6 SID.
that provide additional attributes for the given SRv6 END.X SID.
2.3.2. SRv6 SID LAN Link Attribute Sub-TLV 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
The format of the SRv6 SID LAN Link Attribute 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Function-Flags| Function Code | | Endpoint Behaviour | Flags | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SID Flags | SID-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (variable - 32 bit aligned) ... | Algorithm | Weight | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPFv3 Router-ID of neighbor | | OSPFv3 Router-ID of neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . . | Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where Where
o Type: TBD o Type: TBD
o Length: 16 bit value. Variable o Length: 16 bit value. Variable
o Reserved : 8 bit field. Should be set to 0 and MUST be ignored on o Endpoint Behaviour: 16 bit field. The code point for the endpoint
receipt. behavior for this SRv6 SID as defined in
[I-D.ietf-spring-srv6-network-programming].
o Function Flags: 8 bit field which define the flags associated with o SID Flags: 8 bit field which define the flags associated with the
the function. No flags are currently defined and SHOULD be set to SID. No flags are currently defined and SHOULD be set to 0 and
0 and MUST be ignored on receipt. MUST be ignored on receipt.
o Function Code: 16 bit field. The function code point for this o Flags: 8 bit field with the following definition:
SRv6 SID as defined in
[I-D.filsfils-spring-srv6-network-programming].
o Reserved : 16 bit field. Should be set to 0 and MUST be ignored 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| Rsvd |
+-+-+-+-+-+-+-+-+
* B-Flag: Backup Flag. If set, the SID refers to a path that is
eligible for protection.
* 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.
* Rsvd bits: Reserved for future use and MUST be zero when
originated and ignored when received.
o Reserved1 : 8 bit field. Should be set to 0 and MUST be ignored
on receipt. on receipt.
o SID Flags: 8 bit field which define the flags associated with the o Algorithm : 8 bit field. Associated algorithm. Algorithm values
SID. No flags are currently defined and SHOULD be set to 0 and are defined in the IGP Algorithm Type registry.
MUST be ignored on receipt.
o SID Size : 8 bit field. Number of bits in the SID field. o Weight: 8 bit field whose value represents the weight of the End.X
SID for the purpose of load balancing. The use of the weight is
defined in [RFC8402].
o SID : 1-16 octets. This field encodes the advertised SRv6 SID. o Reserved2 : 16 bit field. Should be set to 0 and MUST be ignored
The "SID-size" field can have the values 1-128 and indicates the on receipt.
number of bits in the SID. The SRv6 SID is encoded in the minimal
number of 32-bit aligned space for the given number of bits.
o Neighbor ID : 4 octets of OSPFv3 Router-id of the neighbor o Neighbor ID : 4 octets of OSPFv3 Router-id of the neighbor
o Sub-TLVs : currently none defined. Used to advertise sub-TLVs o SID: 16 octets. This field encodes the advertised SRv6 SID.
that provide additional attributes for the given SRv6 SID.
3. Security Considerations o Sub-TLVs : Used to advertise sub-TLVs that provide additional
attributes for the given SRv6 SID.
Existing security extensions as described in [RFC5340] and 9. SRv6 SID Structure sub-TLV
[I-D.ietf-ospf-ospfv3-lsa-extend] apply to these SRv6 extensions.
While OSPFv3 is under a single administrative domain, there can be SRv6 SID Structure sub-TLV is used to advertise the length of each
deployments where potential attackers have access to one or more individual part of the SRv6 SID as defined in
networks in the OSPFv3 routing domain. In these deployments, [I-D.ietf-spring-srv6-network-programming]. It is used as an
stronger authentication mechanisms such as those specified in optional sub-sub-TLV of the following:
[RFC4552] SHOULD be used.
o SRv6 End SID sub-TLV (refer Section 7)
o SRv6 End.X SID sub-TLV (refer Section 8.1)
o SRv6 LAN End.X SID sub-TLV (refer Section 8.2)
The sub-TLV has the following format:
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 7: SRv6 SID Structure sub-TLV
Where:
Type: 2 octet field with value TBD, see Section 11.
Length: 2 octet field with the value 4.
LB Length: 1 octet field. SRv6 SID Locator Block length in bits.
LN Length: 1 octet 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.
10. 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] SHOULD be used.
Implementations MUST assure that malformed TLV and Sub-TLV defined in Implementations MUST assure that malformed TLV and Sub-TLV defined in
this document are detected and do not provide a vulnerability for this document are detected and do not provide a vulnerability for
attackers to crash the OSPFv3 router or routing process. Reception attackers to crash the OSPFv3 router or routing process. Reception
of malformed TLV or Sub-TLV SHOULD be counted and/or logged for of malformed TLV or Sub-TLV SHOULD be counted and/or logged for
further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be
rate-limited to prevent a Denial of Service (DoS) attack (distributed rate-limited to prevent a Denial of Service (DoS) attack (distributed
or otherwise) from overloading the OSPFv3 control plane. or otherwise) from overloading the OSPFv3 control plane.
4. IANA Considerations 11. IANA Considerations
This document specifies updates to multiple OSPFv3 related IANA This document specifies updates to multiple OSPF and OSPFv3 related
registries as follows. IANA registries as follows.
4.1. OSPF Parameters 11.1. OSPF Router Information TLVs
This document proposes the following new code points in the OSPF This document proposes the following new code point in the "OSPF
Router Information (RI) TLVs registry for OSPFv3 Extensions in order Router Information (RI) TLVs" registry under the "OSPF Parameters"
to support SRv6: registry for the new TLVs:
1. Type TBD: SRv6-Capabilities TLV: Refer to Section 2.1. Type TBD (suggested 17): SRv6-Capabilities TLV: Refer to
Section 2.
2. Type TBD: SRv6 Node SID TLV : Refer to Section 2.2. 11.2. OSPFv3 LSA Function Codes
4.2. OSPFv3 Parameters This document proposes the following new code point in the "OSPFv3
LSA Function Codes" registry under the "OSPFv3 Parameters" registry
for the new SRv6 Locator LSA:
This document proposes the following new code points in the OSPFv3 o Type TBD (suggested 42): SRv6 Locator LSA: Refer to Section 6.
Extend-LSA Sub-TLV registry for OSPFv3 Extensions in order to support
SRv6:
1. Type TBD: SRv6 SID Link Attribute Sub-TLV : Refer to 11.3. OSPFv3 Extended-LSA sub-TLVs
Section 2.3.1.
2. Type TBD: SRv6 SID LAN Link Attribute Sub-TLV : Refer to This document proposes the following new code points in the "OSPFv3
Section 2.3.2. Extended-LSA Sub-TLVs" registry under the "OSPFv3 Parameters"
registry for the new sub-TLVs:
5. Acknowledgements o Type TBD (suggested 10): SRv6 SID Structure Sub-TLV : Refer to
Section 9.
o Type TBD (suggested 11): SRv6 End.X SID Sub-TLV : Refer to
Section 8.1.
o Type TBD (suggested 12): SRv6 LAN End.X SID Sub-TLV : Refer to
Section 8.2.
11.4. OSPFv3 Locator LSA TLVs
This document proposes setting up of a new "OSPFv3 Locator LSA TLVs"
registry that defines top-level TLVs for the OSPFv3 SRv6 Locator LSA
to be added 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.
11.5. OSPFv3 Locator LSA sub-TLVs
This document proposes setting up of a new "OSPFv3 Locator LSA Sub-
TLVs" registry that defines sub-TLVs at any level of nesting for the
SRv6 Locator TLVs to be added under the "OSPFv3 Parameters" registry.
The initial code-points assignment is as below:
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.
12. Acknowledgements
TBD TBD
6. References 13. References
6.1. Normative References 13.1. Normative References
[I-D.filsfils-spring-srv6-network-programming] [I-D.ali-spring-srv6-oam]
Filsfils, C., Camarillo, P., Leddy, J., Ali, Z., Filsfils, C., Kumar, N., Pignataro, C.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima,
Network Programming", draft-filsfils-spring-srv6-network- S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G.,
programming-07 (work in progress), February 2019. Peirens, B., Chen, M., and G. Naik, "Operations,
Administration, and Maintenance (OAM) in Segment Routing
Networks with IPv6 Data plane (SRv6)", draft-ali-spring-
srv6-oam-02 (work in progress), October 2018.
[I-D.ietf-ospf-ospfv3-lsa-extend] [I-D.ietf-6man-segment-routing-header]
Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
lsa-extend-23 (work in progress), January 2018. Routing Header (SRH)", draft-ietf-6man-segment-routing-
header-21 (work in progress), June 2019.
[I-D.ietf-spring-segment-routing] [I-D.ietf-lsr-isis-srv6-extensions]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Litkowski, S., and R. Shakir, "Segment Routing Z. Hu, "IS-IS Extension to Support Segment Routing over
Architecture", draft-ietf-spring-segment-routing-15 (work IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-02
in progress), January 2018. (work in progress), July 2019.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment
Routing", draft-ietf-ospf-ospfv3-segment-routing-
extensions-23 (work in progress), January 2019.
[I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-27 (work in progress), December 2018.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-ietf-spring-srv6-network-
programming-01 (work in progress), July 2019.
[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>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<https://www.rfc-editor.org/info/rfc4552>. <https://www.rfc-editor.org/info/rfc4552>.
[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>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <https://www.rfc-editor.org/info/rfc7770>. February 2016, <https://www.rfc-editor.org/info/rfc7770>.
6.2. Informative References [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>.
[I-D.ietf-6man-segment-routing-header] [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header May 2017, <https://www.rfc-editor.org/info/rfc8174>.
(SRH)", draft-ietf-6man-segment-routing-header-16 (work in
progress), February 2019. [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>.
13.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>.
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
 End of changes. 132 change blocks. 
365 lines changed or deleted 607 lines changed or added

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