Network Working Group Z. Li
Internet-Draft Z. Hu
Intended status: Standards Track D. Cheng
Expires: May 7, 2020 Huawei Technologies
K. Talaulikar
P. Psenak
Cisco Systems
November 4, 2019
OSPFv3 Extensions for SRv6
draft-li-ospf-ospfv3-srv6-extensions-07
Abstract
Segment Routing (SR) allows for a flexible definition of end-to-end
paths by encoding paths as sequences of topological sub-paths, called
"segments". Segment routing architecture can be implemented over an
MPLS data plane as well as an IPv6 data plane. This draft describes
the OSPFv3 extensions required to support Segment Routing over an
IPv6 data plane (SRv6).
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.
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 May 7, 2020.
Li, et al. Expires May 7, 2020 [Page 1]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components 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
2. SRv6-Capabilities TLV . . . . . . . . . . . . . . . . . . . . 3
3. Advertisement of Supported Algorithms . . . . . . . . . . . . 5
4. Advertisement of SRH Operation Limits . . . . . . . . . . . . 5
5. Advertisement of SRv6 Locator and End SIDs . . . . . . . . . 5
6. SRv6 Locator LSA . . . . . . . . . . . . . . . . . . . . . . 6
6.1. SRv6 Locator TLV . . . . . . . . . . . . . . . . . . . . 8
7. Advertisment of SRv6 End SIDs . . . . . . . . . . . . . . . . 10
8. Advertisment of SRv6 SIDs Associated with Adjacencies . . . . 11
8.1. SRv6 End.X SID Sub-TLV . . . . . . . . . . . . . . . . . 12
8.2. SRv6 LAN End.X SID Sub-TLV . . . . . . . . . . . . . . . 14
9. SRv6 SID Structure sub-TLV . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11.1. OSPF Router Information TLVs . . . . . . . . . . . . . . 17
11.2. OSPFv3 LSA Function Codes . . . . . . . . . . . . . . . 17
11.3. OSPFv3 Extended-LSA sub-TLVs . . . . . . . . . . . . . . 17
11.4. OSPFv3 Locator LSA TLVs . . . . . . . . . . . . . . . . 17
11.5. OSPFv3 Locator LSA sub-TLVs . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 May 7, 2020 [Page 2]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
Segment Routing can be instantiated on the IPv6 data plane through
the use of the Segment Routing Header (SRH) defined in
[I-D.ietf-6man-segment-routing-header]. SRv6 refers to this SR
instantiation on the IPv6 dataplane. The network programming
paradigm for SRv6 is specified in
[I-D.ietf-spring-srv6-network-programming] which describes several
well-known functions that can be bound to SRv6 SIDs.
This document specifies extensions to OSPFv3 in order to support SRv6
as defined in [I-D.ietf-spring-srv6-network-programming] by signaling
the SRv6 capabilities of the node and certain SRv6 SIDs with their
endpoint behaviors (e.g. End, End.X, etc.) that are instantiated on
the SRv6 capable router.
At a high level, the extensions to OSPFv3 comprise of the following:
1. SRv6 Capabilities TLV to advertise the support for SRv6 features
and SRH operations supported by the router
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
(SRv6), the list of segments is expressed using the segment routing
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
described in [I-D.ietf-6man-segment-routing-header], as well as apply
endpoint behaviors as described in
[I-D.ietf-spring-srv6-network-programming].
The SRv6 Capabilities TLV is designed for an OSPFv3 router to
advertise its SRv6 support along with its related capabilities for
SRv6 functionality. This is a new optional top level TLV of OSPFv3
Router Information LSA [RFC7770] which MUST be advertised by a SRv6
enabled router.
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 Opaque LSA. If the SRv6
Capabilities TLV appears in multiple OSPFv3 Router Information Opaque
Li, et al. Expires May 7, 2020 [Page 3]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
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 Capabilities TLV 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
the defined opaque 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
o Type: 16 bit field. TBD
o Length: 16 bit field. Length of Capability TLV + length of Sub-
TLVs
o Reserved : 16 bit field. SHOULD be set to 0 and MUST be ignored
by receiver.
o Flags: 16 bit field. The following flags are defined:
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 router is capable of supporting SRH O-bit,
as specified in [I-D.ali-spring-srv6-oam].
Li, et al. Expires May 7, 2020 [Page 4]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
The SRv6 Capabilities TLV may contain optional sub-TLVs. No sub-TLVs
are currently defined.
3. Advertisement of Supported Algorithms
SRv6 enabled OSPFv3 router advertises its algorithm support using the
SR Algorithm TLV defined in
[I-D.ietf-ospf-segment-routing-extensions] as described in
[I-D.ietf-ospf-ospfv3-segment-routing-extensions].
4. Advertisement of SRH Operation Limits
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.
[RFC8476] defines the means to advertise node/link specific values
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].
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.
5. Advertisement of SRv6 Locator and End SIDs
An SRv6 Segment Identifier (SID) is 128 bits and represented as
LOC:FUNCT as described in [I-D.ietf-spring-srv6-network-programming].
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.
Locators MUST be advertised in the SRv6 Locator LSA (see Section 6).
Forwarding entries for the locators advertised in the SRv6 Locator
LSA MUST be installed in the forwarding plane of receiving SRv6
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.
Li, et al. Expires May 7, 2020 [Page 5]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
Locators are routable and MAY also be advertised via Prefix LSAs of
different types - Inter-Area Prefix LSA, AS-External LSA, NSSA LSA or
Intra-Area Prefix LSA (or their equivalent extended LSAs [RFC8362]).
Locators associated with Flexible Algorithms SHOULD NOT be advertised
via Prefix LSAs. Locators associated with algorithm 0 (for all
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.
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.
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 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.
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 May 7, 2020 [Page 6]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
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 1: 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 2: 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 May 7, 2020 [Page 7]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
6.1. SRv6 Locator TLV
The SRv6 Locator TLV is a top-level TLV of the SRv6 Locator LSA that
is used to advertise a 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 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 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 cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| ... |
Figure 3: SRv6 Locator TLV
Where:
Li, et al. Expires May 7, 2020 [Page 8]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
Type: 16 bit field. The value is 1 for this type.
Length: 16 bit field. The total length of the value portion of
the TLV including sub-TLVs.
Route Type : 8 bit field. The type of the locator route.
Supported types are the ones listed below and other other types
MUST be ignored by the receiver.
1 - Intra-Area
2 - Inter-Area
3 - AS External
4 - NSSA External
Figure 4
Algorithm: 8 bit field. Associated algorithm. Algorithm values
are defined in the IGP Algorithm Type registry.
Locator Length: 8 bit field. Carries the length of the Locator
prefix as number of bits (1-128).
Flags: 8 bit field. The following flags are defined
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|N|A| Reserved |
+-+-+-+-+-+-+-+-+
Figure 5
* N flag : When the locator uniquely identifies a node in the
network (i.e. it is provisioned on one and only one node), the
N bit MUST be set. Otherwise, this bit MUST be clear.
* A bit : When the Locator is configured as anycast, the A bit
SHOULD be set. Otherwise, this bit MUST be clear.
* Other flags are not defined and SHOULD be set to 0 and MUST be
ignored on receipt.
Metric : 32 bit field. The metric value associated with the
locator.
Locator : 16 octets. This field encodes the advertised SRv6
Locator.
Li, et al. Expires May 7, 2020 [Page 9]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
Sub-TLVs : Used to advertise sub-TLVs that provide additional
attributes for the given SRv6 Locator and SRv6 SIDs associated
with it.
7. Advertisment of SRv6 End SIDs
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 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 ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SRv6 End SID sub-TLV
Li, et al. Expires May 7, 2020 [Page 10]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
Where:
Type: 16 bit field. Value is 1 for this type.
Length: 16 bit field. The total length of the value portion of
the sub-TLV including sub-sub-TLVs.
Reserved : 8 bit field. Should be set to 0 and MUST be ignored on
receipt.
Flags: 8 bit field which define the flags associated with the SID.
No flags are currently defined and SHOULD be set to 0 and MUST be
ignored on receipt.
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 : 16 octets. This field encodes the advertised SRv6 SID.
Sub-Sub-TLVs : Used to advertise sub-sub-TLVs that provide
additional attributes for the given SRv6 SID.
8. Advertisment of SRv6 SIDs Associated with Adjacencies
The SRv6 endpoint behaviors are defined in
[I-D.ietf-spring-srv6-network-programming] include certain behaviors
which are specific to links or adjacencies. The most basic of this
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 along with others that
are defined in [I-D.ietf-spring-srv6-network-programming] which are
specific to links or adjacencies need to be advertised by OSPFv3 so
that this information is available with all routers in the area to
influence the packet path via these SRv6 SIDs over the specific
adjacencies.
The advertising of SRv6 SIDs and their behaviors that are specific to
a particular neighbor are done via two different optional sub-TLVs of
the E-Router-Link TLV defined in [RFC8362] as follows:
o SRv6 End.X SID Sub-TLV: for OSPFv3 adjacency over point-to-point
or point-to-multipoint links and the adjacency to the Designated
Router (DR) over broadcast and non-broadcast-multi-access (NBMA)
links.
o SRv6 LAN End.X SID Sub-TLV: for OSPFv3 adjacency on broadcast and
NBMA links to the Backup DR and DR-Other neighbors. This sub-TLV
Li, et al. Expires May 7, 2020 [Page 11]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
includes the OSPFv3 router-id of the neighbor and thus allows for
multiple instances of this TLV for each neighbor to be explicitly
advertised under the E-Router-Link TLV for the same link.
Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one
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
End.X function for a single neighbor. The same SRv6 SID MAY be
advertised for the End.X function corresponding to 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 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.
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 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 Behaviour ID | Flags | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Weight | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
Type is TBD
Length: 16 bit field. The total length of the value portion of
the TLV.
Li, et al. Expires May 7, 2020 [Page 12]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
Endpoint Behaviour ID: 16 bit field. The code point for the
endpoint behavior for this SRv6 SID as defined in
[I-D.ietf-spring-srv6-network-programming].
Flags: 8 bit field with the following definition:
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.
Reserved1 : 8 bit field. Should be set to 0 and MUST be ignored
on receipt.
Algorithm : 8 bit field. Associated algorithm. Algorithm values
are defined in the IGP Algorithm Type registry.
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].
Reserved2 : 16 bit field. Should be set to 0 and MUST be ignored
on receipt.
SID: 16 octets. 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.
Li, et al. Expires May 7, 2020 [Page 13]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
8.2. SRv6 LAN End.X SID Sub-TLV
The format of the SRv6 LAN End.X SID sub-TLV is as shown below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behaviour | Flags | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Weight | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPFv3 Router-ID of neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID cont ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where
o Type: TBD
o Length: 16 bit value. Variable
o Endpoint Behaviour: 16 bit field. The code point for the endpoint
behavior for this SRv6 SID as defined in
[I-D.ietf-spring-srv6-network-programming].
o SID Flags: 8 bit field which define the flags associated with the
SID. No flags are currently defined and SHOULD be set to 0 and
MUST be ignored on receipt.
o Flags: 8 bit field with the following definition:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| Rsvd |
+-+-+-+-+-+-+-+-+
Li, et al. Expires May 7, 2020 [Page 14]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
* 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.
o Algorithm : 8 bit field. Associated algorithm. Algorithm values
are defined in the IGP Algorithm Type registry.
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 Reserved2 : 16 bit field. Should be set to 0 and MUST be ignored
on receipt.
o Neighbor ID : 4 octets of OSPFv3 Router-id of the neighbor
o SID: 16 octets. 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 length of each
individual part of the SRv6 SID as defined in
[I-D.ietf-spring-srv6-network-programming]. It is used as an
optional sub-sub-TLV of the following:
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:
Li, et al. Expires May 7, 2020 [Page 15]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
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
this document are detected and do not provide a vulnerability for
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.
11. IANA Considerations
This document specifies updates to multiple OSPF and OSPFv3 related
IANA registries as follows.
Li, et al. Expires May 7, 2020 [Page 16]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
11.1. OSPF Router Information TLVs
This document proposes the following new code point in the "OSPF
Router Information (RI) TLVs" registry under the "OSPF Parameters"
registry for the new TLVs:
Type TBD (suggested 17): SRv6-Capabilities TLV: Refer to
Section 2.
11.2. OSPFv3 LSA Function Codes
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:
o Type TBD (suggested 42): SRv6 Locator LSA: Refer to Section 6.
11.3. OSPFv3 Extended-LSA sub-TLVs
This document proposes the following new code points in the "OSPFv3
Extended-LSA Sub-TLVs" registry under the "OSPFv3 Parameters"
registry for the new sub-TLVs:
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].
Li, et al. Expires May 7, 2020 [Page 17]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
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
The authors would like to thank Chenzichao for their review and
comments on this document.
Li, et al. Expires May 7, 2020 [Page 18]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
13. References
13.1. Normative References
[I-D.ali-spring-srv6-oam]
Ali, Z., Filsfils, C., Kumar, N., Pignataro, C.,
faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima,
S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G.,
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.
[]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
Routing Header (SRH)", draft-ietf-6man-segment-routing-
header-22 (work in progress), November 2019.
[I-D.ietf-lsr-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Z. Hu, "IS-IS Extension to Support Segment Routing over
IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-02
(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
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Li, et al. Expires May 7, 2020 [Page 19]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
[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>.
[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>.
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>.
Li, et al. Expires May 7, 2020 [Page 20]
Internet-Draft OSPFv3 Extensions for SRV6 November 2019
Authors' Addresses
Zhenbin Li
Huawei Technologies
Email: lizhenbin@huawei.com
Zhibo Hu
Huawei Technologies
Email: huzhibo@huawei.com
Dean Cheng
Huawei Technologies
Email: dean.cheng@huawei.com
Ketan Talaulikar
Cisco Systems
India
Email: ketant@cisco.com
Peter Psenak
Cisco Systems
Slovakia
Email: ppsenak@cisco.com
Li, et al. Expires May 7, 2020 [Page 21]