< draft-li-ospf-ospfv3-srv6-extensions-00.txt   draft-li-ospf-ospfv3-srv6-extensions-01.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: April 22, 2018 Huawei Technologies Expires: September 6, 2018 Huawei Technologies
October 19, 2017 K. Talaulikar
P. Psenak
Cisco Systems
March 5, 2018
OSPFv3 Extensions for SRv6 OSPFv3 Extensions for SRv6
draft-li-ospf-ospfv3-srv6-extensions-00 draft-li-ospf-ospfv3-srv6-extensions-01
Abstract Abstract
Segment routing architecture (refer to Segment Routing (SR) allows for a flexible definition of end-to-end
[I-D.ietf-spring-segment-routing]) can be implemented over a MPLS paths by encoding paths as sequences of topological sub-paths, called
data plane, an IPv4 data plane, as well as an IPv6 data plane. "segments". Segment routing architecture can be implemented over an
[I-D.filsfils-spring-srv6-network-programming] introduces the network MPLS data plane as well as an IPv6 data plane. This draft describes
programming concept in IPv6 data plane using segment routing the IS-IS extensions required to support Segment Routing over an IPv6
technology, called SRv6, and it also defines some basic functions. data plane.
The SRv6 functions can be advertised by routing protocols including
OSPFv3, IS-IS and BGP-LS. This draft proposes some extensions to
OSPFv3 ([RFC5340]) required to support 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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
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
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 April 22, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . 4 2. OSPFv3 Extensions for SRv6 . . . . . . . . . . . . . . . . . 3
2.1. SRv6-Capabilities Sub-TLV . . . . . . . . . . . . . . . . 4 2.1. SRv6-Capabilities TLV . . . . . . . . . . . . . . . . . . 3
2.1.1. Maximum SL Sub-Sub-TLV . . . . . . . . . . . . . . . 5 2.1.1. Maximum SL Sub-TLV . . . . . . . . . . . . . . . . . 5
2.1.2. Maximum End Pop SRH Sub-Sub-TLV . . . . . . . . . . . 6 2.1.2. Maximum End Pop SRH Sub-TLV . . . . . . . . . . . . . 5
2.1.3. Maximum T.Insert SRH Sub-Sub-TLV . . . . . . . . . . 7 2.1.3. Maximum T.Insert SRH Sub-TLV . . . . . . . . . . . . 6
2.1.4. Maximum T.Encap SRH Sub-Sub-TLV . . . . . . . . . . . 7 2.1.4. Maximum T.Encap SRH Sub-TLV . . . . . . . . . . . . . 6
2.1.5. Maximum End D SRH Sub-Sub-TLV . . . . . . . . . . . . 8 2.1.5. Maximum End D SRH Sub-TLV . . . . . . . . . . . . . . 7
2.2. SRv6 Function Descriptor . . . . . . . . . . . . . . . . 9 2.2. SRv6 Node SID TLV . . . . . . . . . . . . . . . . . . . . 8
2.3. SRv6 Function Code Points . . . . . . . . . . . . . . . . 10 2.3. SRv6 SIDs Associated with Adjacencies . . . . . . . . . . 10
2.4. SRv6 SID TLV . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1. SRv6 SID Link Attribute Sub-TLV . . . . . . . . . . . 11
2.5. SRv6 Neighbor SID TLV . . . . . . . . . . . . . . . . . . 12 2.3.2. SRv6 SID LAN Link Attribute Sub-TLV . . . . . . . . . 12
2.5.1. Point to Popint SRv6 Adj-SID Sub-TLV . . . . . . . . 13 3. Security Considerations . . . . . . . . . . . . . . . . . . . 14
2.5.2. LAN SRv6 Adj-SID sub-TLV . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
3. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4.1. OSPF Parameters . . . . . . . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4.2. OSPFv3 Parameters . . . . . . . . . . . . . . . . . . . . 14
4.1. OSPFv3 Extensions for SRv6 Support . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Normative References . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 16 6.2. Informative References . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document proposes some extensions to OSPFv3 in order to support Segment Routing (SR) architecture [I-D.ietf-spring-segment-routing]
SRv6 as defined in [I-D.filsfils-spring-srv6-network-programming], specifies how a node can steer a packet through an ordered list of
and they are as follows: instructions, called segments. These segments are identified through
Segment Identifiers (SIDs).
1. SRv6-Capabilities Sub-TLV: Refer to Section 2.1. This Sub-TLV is
used to announce the capability of an OSPFv3 router for SRv6
support with a list of parameters. This Sub-TLV, if used, is
included in OSPFv3 Router Information LSA TLV LSA([RFC7770]).
2. Maximum SL Sub-Sub-TLV: Refer to Section 2.1.1. This Sub-Sub-TLV
carries the maximum value of the "SL" field in the SRH
([I-D.ietf-6man-segment-routing-header]) of a received packet
before applying the function associated with a SID. It may be
included in the SRv6-Capabilities Sub-TLV.
3. Maximum End Pop SRH Sub-Sub-TLV: Refer to Section 2.1.2. This
Sub-Sub-TLV carries the maximum number of the SIDs in the top SRH
in an SRH stack to which the router can apply "PSP" or "USP"
flavors (refer to
[I-D.filsfils-spring-srv6-network-programming]). It may be
included in the SRv6-Capabilities Sub-TLV.
4. Maximum T.Insert SRH Sub-Sub-TLV: Refer to Section 2.1.3. This
Sub-Sub-TLV carries the maximum number of the SIDs that can be
inserted as part of the "T.insert" behavior (refer to
[I-D.filsfils-spring-srv6-network-programming]). It may be
included in the SRv6-Capabilities Sub-TLV.
5. Maximum T.Encap SRH Sub-Sub-TLV: Refer to Section 2.1.4. This Segment Routing can be instantiated on the IPv6 data plane through
Sub-Sub-TLV carries the maximum number of the SIDs that can be the use of the Segment Routing Header (SRH) defined in
inserted as part of the "T.Encap" behavior (refer to
[I-D.filsfils-spring-srv6-network-programming]). It may be
included in the SRv6-Capabilities Sub-TLV.
6. Maximum End D SRH Sub-Sub-TLV: Refer to Section 2.1.5. This Sub- [I-D.ietf-6man-segment-routing-header]. SRv6 refers to this SR
Sub-TLV carries the maximum number of the SIDs in an SRH when instantiation on the IPv6 dataplane. The network programming
applying "End.DX6" and "End.DT6" function (refer to paradigm for SRv6 is specified in
[I-D.filsfils-spring-srv6-network-programming]). It may be [I-D.filsfils-spring-srv6-network-programming] which describes
included in the SRv6-Capabilities Sub-TLV. several well-known functions that can be bound to SRv6 SIDs.
7. SRv6 SID TLV: Refer to Section 2.4. This TLV is used to This document proposes extensions to OSPFv3 in order to support SRv6
advertise one or more SIDs along with their associated SRv6 as defined in [I-D.filsfils-spring-srv6-network-programming] by
functions. These SRv6 functions are well-known and defined in signaling the SRv6 capabilities of the node and certain functions
[I-D.filsfils-spring-srv6-network-programming], but may also be (e.g. END, END.X, etc.) that are instantiated on the SRv6 capable
others defined in the future. This TLV is a top-level TLV and is router.
included in OSPFv3 Router Information LSA([RFC7770]).
8. SRv6 Point-to-Point Adj-SID Sub-TLV: Refer to Section 2.5.1. At a high level, the extensions to OSPFv3 comprise of a SRv6
This Sub-TLV is used to advertise one or more SIDs on an OSPFv3 Capabilities TLV to advertise the support for SRv6 features supported
point-to-point adjacency for the support of SRv6 along with their by the router. Also included are extensions in the form of TLVs and
associated functions. These SRv6 functions are well-known and sub-TLVs for advertising the SRv6 SIDs corresponding the to functions
defined in [I-D.filsfils-spring-srv6-network-programming], but related to the node (e.g. END) and those related to the adjacencies
may also be others defined in the future. This Sub-TLV is (e.g. END.X) for the SRv6 enabled OSPFv3 router.
included in Router-Link TLV as defined in
[I-D.ietf-ospf-ospfv3-lsa-extend].
9. SRv6 LAN SRv6 Adj-SID Sub-TLV: Refer to Section 2.5.2. This Sub- 2. OSPFv3 Extensions for SRv6
TLV is used to advertise one or more SIDs on an OSPFv3 LAN
adjacency for the support of SRv6 along with their associated
functions. These SRv6 functions are well-known and defined in
[I-D.filsfils-spring-srv6-network-programming], but may also be
others defined in the future. This Sub-TLV is included in
Router-Link TLV as defined in [I-D.ietf-ospf-ospfv3-lsa-extend].
For consistency in IGP's behavior, ideas are borrowed from 2.1. SRv6-Capabilities TLV
[I-D.bashandy-isis-srv6-extensions] including SRv6 functions
supported and data format.
2. OSPFv3 Extensions for SRv6 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].
2.1. SRv6-Capabilities Sub-TLV 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
function behaviors and flavors as described in
[I-D.filsfils-spring-srv6-network-programming]. 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.
When apply Segment Routing to IPv6 data plane, the list of segments The SRv6 Capabilities TLV is designed for an OSPFv3 router to
is stored in segment routing header, referred to as "SRH", which is advertise its SRv6 support along with its related capabilities for
defined in [I-D.ietf-6man-segment-routing-header]. SRv6 functionality. This is a new optional top level TLV of OSPFv3
Router Information LSA TLV LSA ([RFC7770]) which MUST be advertised
by a SRv6 enabled router.
A router that supports SRv6 MUST be able to process the segment This TLV SHOULD be advertised only once in the OSPFv3 Router
routing header as described in Information LSA. When multiple SRv6 Capabilities TLVs are received
[I-D.ietf-6man-segment-routing-header], as well as apply behaviors from a given router, the receiver MUST use the first occurrence of
and flavors as described in the TLV in the OSPFV3 Router Information Opaque LSA. If the SRv6
[I-D.filsfils-spring-srv6-network-programming]. In either case, Capabilities TLV appears in multiple OSPFv3 Router Information Opaque
there exists a limit to which the router can perform according to its LSAs that have different flooding scopes, the TLV in the OSPFv3
own ability that needs to be advertised to other routers in the same Router Information Opaque LSA with the area-scoped flooding scope
SR domain. 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-SRv6-Capbilities Sub-TLV is designed for an OSPFv3 router The OSPFv3 Router Information Opaque LSA can be advertised at any of
to make announcement in the SRv6 domain about its ability in the the defined opaque flooding scopes (link, area, or Autonomous System
context of SRv6 support. (AS)). For the purpose of SRv6 Capabilities TLV advertisement, area-
scoped flooding is REQUIRED.
The format of OSPFv3-SRv6-Capabilities Sub-TLV is shown in Figure 1. The format of OSPFv3-SRv6-Capabilities TLV is shown below
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Sub-TLVs .... | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 Where:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 o Type: 16 bit field. TBD
Type (one octet) o Length: 16 bit field. Length of Capability TLV + length of Sub-
TLVs
TBD-1 o Reserved : 16 bit field. SHOULD be set to 0 and MUST be ignored
by receiver.
Length (one octet) o Flags: 16 bit field. The following flags are defined:
2 + length of sub-sub-TLVs 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|O| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (16 bits) where:
E-Flag: If set, the router is able to apply "T.Encap" operation. * E-flag: If set, then router is able to apply "T.Encap"
operation as specified in
[I-D.filsfils-spring-srv6-network-programming]
2.1.1. Maximum SL Sub-Sub-TLV * 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 Maximum Segments Left Sub-Sub-TLV specifies the maximum value of The following sections define the supported sub-TLVs.
the "SL" field (refer to [I-D.ietf-6man-segment-routing-header]) in
the SRH of a received packet before applying the function associated
with a SID.
0 1 2 2.1.1. Maximum SL Sub-TLV
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Max SL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 The Maximum Segments Left Sub-TLV of the SRv6 Capabilities TLV
specifies the maximum value of the "SL" field (refer to
[I-D.ietf-6man-segment-routing-header]) in the SRH of a received
packet before applying the function associated with a SID.
Type (one octet) 0 1 2 3
TBD-2 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 |
+-+-+-+-+-+-+-+-+
Length (one octet) o Type: 1
1 o Length: 4 (including padding to 32 bit aligned boundary for OSPF
TLVs)
Max SL (8 bits) o SL Value: 1 octet
SL Value o An 8 bit unsigned integer.
If the sub-sub-TLV is NOT advertised, the value is assumed to be 0. If the sub-TLV is not advertised by an SRv6 capable router, then the
value MUST be considered to be 0.
2.1.2. Maximum End Pop SRH Sub-Sub-TLV 2.1.2. Maximum End Pop SRH Sub-TLV
The Maximum End Pop SRH Sub-Sub-TLV specifies the maximum number of The Maximum End Pop SRH Sub-Sub-TLV specifies the maximum number of
SIDs in the top SRH in an SRH stack to which the router can apply SIDs in the top SRH in an SRH stack to which the router can apply
"PSP" or USP" flavors([I-D.filsfils-spring-srv6-network-programming] "PSP" or USP" flavors
). ([I-D.filsfils-spring-srv6-network-programming]).
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Max-End-Pop-SRH|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
Type (one octet)
TBD-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Max-End-Pop-SRH|
+-+-+-+-+-+-+-+-+
Length (one octet) o Type: 2
1 o Length: 4 (including padding to 32 bit aligned boundary for OSPF
TLVs)
Max-End-Pop-SRH (8 bits) o Max-End-Pop-SRH Value: 1 octet
Max End Pop SRH value Value o An 8 bit unsigned integer.
If the value is zero or the sub-sub-TLV is NOT advertised, then it is If the value is 0 or the sub-TLV is not advertised by an SRv6 capable
assumed that the router cannot apply PSP or USP flavors. router, then it MUST be considered that the router cannot apply PSP
or USP flavors.
2.1.3. Maximum T.Insert SRH Sub-Sub-TLV 2.1.3. Maximum T.Insert SRH Sub-TLV
The Maximum T.Insert SRH Sub-Sub-TLV specifies the maximum number of The Maximum T.Insert SRH Sub-Sub-TLV specifies the maximum number of
SIDs that can be inserted as part of the "T.insert" SIDs that can be inserted as part of the "T.insert"
behavior([I-D.filsfils-spring-srv6-network-programming]). behavior([I-D.filsfils-spring-srv6-network-programming]).
0 1 2 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 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-T.Insert | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-T.Insert |
Figure 4 +-+-+-+-+-+-+-+-+
Type (one octet)
TBD-4
Length (one octet) o Type: 3
1 o Length: 4 (including padding to 32 bit aligned boundary for OSPF
TLVs)
Max-T.Insert (8 bits) o Max-T.Insert Value: 1 octet
Max-T.Insert Value o An 8 bit unsigned integer.
If the value is zero or the sub-sub-TLV is omitted, then the router If the value is 0 or the sub-TLV is not advertised by an SRv6 capable
is assumed not to support any variation of the "T.insert" behavior. router, then it MUST be considered that the router does not support
any variation of the "T.insert" behavior.
2.1.4. Maximum T.Encap SRH Sub-Sub-TLV 2.1.4. Maximum T.Encap SRH Sub-TLV
The Maximum T.Encap SRH Sub-Sub-TLV specifies the maximum number of The Maximum T.Encap SRH Sub-Sub-TLV specifies the maximum number of
SIDs that can be included as part of the "T.Encap" SIDs that can be included as part of the "T.Encap" behavior
behavior([I-D.filsfils-spring-srv6-network-programming]). ([I-D.filsfils-spring-srv6-network-programming]).
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Max-T.Encap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
Type (one octet) 0 1 2 3
TBD-5 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-T.Encap |
+-+-+-+-+-+-+-+-+
Length (one octet) o Type: 4
1 o Length: 4 (including padding to 32 bit aligned boundary for OSPF
TLVs)
Max-T.Encap (8 bits) o Max-T.Encap Value: 1 octet
Max-T.Encap Value o An 8 bit unsigned integer.
If this value is zero or the Sub-Sub-TLV is omitted and the "E" flag If this value is 0 or the sub-TLV is not advertised by an SRv6
is set in the associated SRv6 Capabilities Sub-TLV, then it is capable router and the "E" flag is set in the associated SRv6
assumed that the router can apply T.Encap by encapsulating the Capabilities sub-TLV, then it MUST be considered that the router can
incoming packet in another IPv6 header without SRH the same way apply T.Encap by encapsulating the incoming packet in another IPv6
IPinIP encapsulation is performed. If the "E" flag is clear, then header without SRH the same way as IP-in-IP encapsulation is
this Sub-Sub-TLV SHOULD NOT be transmitted and MUST be ignored on performed. If the "E" flag is clear, then this sub-TLV SHOULD NOT be
reception. advertised and MUST be ignored on receipt.
2.1.5. Maximum End D SRH Sub-Sub-TLV 2.1.5. Maximum End D SRH Sub-TLV
The Maximum End D SRH sub-sub-TLV specifies the maximum number of The Maximum End D SRH sub-sub-TLV specifies the maximum number of
SIDs in an SRH when applying "End.DX6" and "End.DT6" functions. SIDs in an SRH when applying "End.DX6" and "End.DT6" functions.
0 1 2 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 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 End D | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-End-D |
Figure 6 +-+-+-+-+-+-+-+-+
Type (one octet)
TBD-6
Length (one octet)
1
Max End D (8 bits)
Max End D Value
If this value is zero or the sub-sub-TLV is omitted, then it is
assumed that the router cannot apply "End.DX6" or "End.DT6" functions
if the extension header right underneath the outer IPv6 header is an
SRH.
2.2. SRv6 Function Descriptor
The SRv6 SID TLV (defined in Section 2.4), P2P SRv6 SID Sub-TLV
(defined in Section 2.5.1), and LAN SRv6 SID Sub-TLV (defined in
Section 2.5.2), MUST include one SRv6 function Descriptor.
When included in the SRv6 SID TLV, the descriptor is encoded as a
Sub-TLV. When included in a P2P/LAN SRv6 SID sub-TLV, the descriptor
is encoded as a Sub-Sub-TLV.
The SRv6-function Descriptor encodes the function (and its flavors) o Type: 5
bound to the SRv6 SID advertised in the SRv6 dodmain
([I-D.filsfils-spring-srv6-network-programming]).
The format of OSPFv3 SRv6 Function Descriptor is shown in Figure 7. o Length: 4 (including padding to 32 bit aligned boundary for OSPF
TLVs)
0 1 o Max End D Value: 1 octet
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-|-+-+-+-+-+-+
| Type |
+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Function (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 o An 8 bit unsigned integer.
Type (one octet) If this value is zero or the sub-TLV is not advertised by an SRv6
capable router, then it MUST be considered that the router cannot
apply "End.DX6" or "End.DT6" functions if the extension header right
underneath the outer IPv6 header is an SRH.
TBD-7 2.2. SRv6 Node SID TLV
Length (one octet) An OSPFv3 SRv6 enabled router may have multiple SRv6 SIDs
instantiated in its "My Local SID Table" (refer
[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.
3 SRv6 Node SID TLV is a new optional top-level TLV of OSPFv3 Router
Information LSA ([RFC7770]) and is used to advertise the SRv6 SIDs
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].
Flags The router MAY advertise multiple instances of the SRv6 Node SID TLV
in its OSPFv3 Router Information LSA - one for each of the SRv6 SIDs
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.
This document defines two flags to specify the flavor(s) When multiple SRv6 Node SID TLVs are received from a given router for
([I-D.filsfils-spring-srv6-network-programming]) associated with the same SRv6 SID value, the receiver MUST use the first occurrence
the SRv6 function specified in the "Function" field: of the TLV in the OSPFV3 Router Information Opaque LSA. If the SRv6
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.
0 1 2 3 4 5 6 7 The OSPFv3 Router Information Opaque LSA can be advertised at any of
+-+-|-+-+-+-+-+-+ the defined opaque flooding scopes (link, area, or Autonomous System
|P|U| Reserved | (AS)). For the purpose of SRv6 Node SID TLV advertisement, area-
+-+-+-+-+-+-+-+-+ scoped flooding is REQUIRED.
Figure 8 The format of OSPFv3 SRv6 Node SID TLV is shown below
P bit 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Function-Flags| Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SID Flags | SID-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (variable - 32 bit aligned) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If set, then the PSP flavor Figure 1: SRv6 SID Node TLV
([I-D.filsfils-spring-srv6-network-programming]) is associated
with the function encoded in the "function" field.
U bit Where:
If set, then the USP flavor Type: 16 bit field. TBD
([I-D.filsfils-spring-srv6-network-programming]) is associated
with the function encoded in the "function" field.
Reserved Length: 16 bit field. The total length of the value portion of
the TLV.
Reserved Bits SHOULD be transmitted as 0 and MUST be ignored on Reserved : 8 bit field. Should be set to 0 and MUST be ignored on
receipt. receipt.
The second two octets encode the function. Function code points are Function Flags: 8 bit field which define the flags associated with
defined in Section 2.3. the function. No flags are currently defined and SHOULD be set to
0 and MUST be ignored on receipt.
2.3. SRv6 Function Code Points
This section defines the code points for supported functions
associated with SRv6 SIDs. Refer
[I-D.filsfils-spring-srv6-network-programming] for SRv6 functions.
0:
Reserved.
1:
End Function.
2:
End.X Function.
3:
End.DX6 Function.
4:
End.DT6 Function.
2.4. SRv6 SID TLV
A new top level TLV is introduced in OSPFv3 to advertise one or more
SRv6 Segment Identifiers (SIDs) and each SID is associated one or
more SRv6 functions. [I-D.filsfils-spring-srv6-network-programming]
defined some basic functions. This document defines code points for
some of the basic SRv6 functions in Section 2.3. SRv6 functions may
also be defined in other documents or locally configured.
The format of OSPFv3 SRv6 SID TLV is shown in Figure 9.
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 | SID-Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Sub-TLV-Len| Sub-Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9
Type (one octet)
TBD-8
Length (one octet)
Variable
One or more SID entries, each of which has the following format:
Flags (One octet) Function Code: 16 bit field. The function code point for this
SRv6 SID as defined in
[I-D.filsfils-spring-srv6-network-programming].
The following flags are defined: 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 0 1 2 3 4 5 6 7
+-+-|-+-+-+-+-+-+ +-+-|-+-+-+-+-+-+
|D| Reserved | |D| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 10 Figure 2
D bit:
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.
Reserved:
The remaining bits are reserved for future use. They SHOULD be
set to zero on transmission and MUST be ignored on reception.
SID-Size (one octet)
Number of bits in the SID field.
SID (1-16 octet)
This field encodes the advertised SRv6 SID. The "SID-Size" field
can have the value in the range of 1-128 and indicates the number
of bits in the SID. The SRv6 SID is encoded in the minimal number
of octets for the given number of bits.
Sub-Sub-TLV-Length(one octet) * 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.
Number of octets used by sub-TLVs. * Other flags are not defined and SHOULD be set to 0 and MUST be
ignored on receipt.
Sub-Sub-TLVs (Variable) SID Size : 8 bit field. Number of bits in the SID field.
One or more functions associated with the advertised SID is SID : 1-16 octets. This field encodes the advertised SRv6 SID.
specified by the SRv6-Function Descriptor Sub-TLV specified in The "SID-size" field can have the values 1-128 and indicates the
Section 2.2. 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.
2.5. SRv6 Neighbor SID TLV Sub-TLVs : currently none defined. Used to advertise sub-TLVs
that provide additional attributes for the given SRv6 SID.
The advertising of some SRv6 functions must be associated with a 2.3. SRv6 SIDs Associated with Adjacencies
particular neighbor. As described in
[I-D.ietf-spring-segment-routing], there are two types of SR
adjacencies, one is on point-to-point link and another is on a
broadcast/mulcast LAN. This section defines OSPFv3 extensions in
order to advertise SRv6 SIDs and their associated functions for these
two cases.
A single SRv6 Adj-SID may associate with one or more SRv6 functions.
The SRv6 functions are defined in The SRv6 functions are defined in
[I-D.filsfils-spring-srv6-network-programming], other documents, or [I-D.filsfils-spring-srv6-network-programming] include certain
locally configured. functions which are specific to links or adjacencies. The most basic
of this which is critical for link state routing protocols like
This document specifies how to advertise End.X and End.DX6 defined in OSPFv3 is the END.X function that is an instruction to forward to a
[I-D.filsfils-spring-srv6-network-programming] using OSPFv3 specific neighbor on a specific link. These END.X SRv6 SIDs are
extersons. instantiated by SRv6 enabled OSPFv3 router for all its adjacencies
and installed in the local node's "My Local SID Table". These SRv6
2.5.1. Point to Popint SRv6 Adj-SID Sub-TLV SIDs along with others that are defined in
[I-D.filsfils-spring-srv6-network-programming] which are specific to
This Sub-TLV is used to advertise one or more SRv6 SIDs associated links or adjacencies need to be advertised by OSPFv3 so that this
with End.X and End.DX6 SRv6 functions over a point-to-point information is available with all routers in the domain to influence
adjacency. the packet path via these specific functions over the specified
adjacencies.
The format of the "P2P SRv6 Adj-SID" Sub-TLV is shown in Figure 11.
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 | SID-Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Sub-TLV-Len| Sub-Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11
Type (one octet)
TBD-9
Length (one octet)
Variable The advertising of SRv6 SIDs and their functions that are specific to
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]
as follows:
One or more SID entries, each of which has the following format: o SRv6 SID Link Attribute Sub-TLV: for OSPFv3 adjacency over point-
to-point or point-to-multipoint links and the adjacecny to the
Designated Router (DR) over broadcast and non-broadcast-multi-
access (NBMA) links.
Flags (One octet) o SRv6 SID LAN Link Attribute Sub-TLV: for OSPFv3 adjacency on
broadcast and NBMA links to the Backup DR and DR-Other neighbors.
This sub-TLV includes the OSPFv3 router-id of the neighbor and
thus allows for multiple instances of this TLV for each neighbor
to be explicitly advertised under the Router-Link TLV for the same
link.
No flags defined in this document. 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 SID Link Attribute and
SRv6 SID LAN Link Attribute sub-TLVs MAY be advertised within the
Router Link TLV for a single link.
SID-Size (one octet) 2.3.1. SRv6 SID Link Attribute Sub-TLV
Number of bits in the SID field. The format of the SRv6 SID Link Attribute Sub-TLV is shown below
SID (1-16 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Function-Flags| Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SID Flags | SID-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (variable - 32 bit aligned) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This field encodes the advertised SRv6 SID. The "SID-Size" field Where:
can have the value in the range of 1-128 and indicates the number
of bits in the SID. The SRv6 SID is encoded in the minimal number
of octets for the given number of bits.
Sub-Sub-TLV-Length(one octet) Type is TBD
Number of octets used by Sub-TLVs. Length: 16 bit field. The total length of the value portion of
the TLV.
Sub-Sub-TLVs (Variable) Reserved : 8 bit field. Should be set to 0 and MUST be ignored on
receipt.
One or more functions associated with the advertised SID is Function Flags: 8 bit field which define the flags associated with
specified by the SRv6 Function Descriptor Sub-TLV specified in the function. No flags are currently defined and SHOULD be set to
Section 2.2. If the SRv6 Function Descriptor is encoded in the 0 and MUST be ignored on receipt.
SRv6 P2P SID sub-TLV, the encoded SRv6 SID function MUST include
only the code points of SRv6 SID functions that require the
specification of a neighbor to be correctly applied.
2.5.2. LAN SRv6 Adj-SID sub-TLV Function Code: 16 bit field. The function code point for this
SRv6 SID as defined in
[I-D.filsfils-spring-srv6-network-programming].
This Sub-TLV is used to advertise one or more SRv6 SIDs associated Reserved : 16 bit field. Should be set to 0 and MUST be ignored
with End.X and End.DX6 SRv6 functions over a LAN adjacency. on receipt.
The format of the "LAN SRv6 Adj-SID" Sub-TLV is shown in Figure 12. 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.
0 1 2 3 SID-size: Number of bits in the SID field.
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 | SID-Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Sub-TLV-Len| Sub-Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12 SID: 1-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.
Type (one octet) Sub-TLVs : currently none defined. Used to advertise sub-TLVs
that provide additional attributes for the given SRv6 END.X SID.
TBD-10 2.3.2. SRv6 SID LAN Link Attribute Sub-TLV
Length (one octet) The format of the SRv6 SID LAN Link Attribute 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Function-Flags| Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SID Flags | SID-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (variable - 32 bit aligned) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPFv3 Router-ID of neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Variable Where
One or more SID entries, each of which has the following format: o Type: TBD
Flags (One octet) o Length: 16 bit value. Variable
No flags defined in this document. o Reserved : 8 bit field. Should be set to 0 and MUST be ignored on
receipt.
SID-Size (one octet) o Function Flags: 8 bit field which define the flags associated with
the function. No flags are currently defined and SHOULD be set to
0 and MUST be ignored on receipt.
Number of bits in the SID field. o Function Code: 16 bit field. The function code point for this
SRv6 SID as defined in
[I-D.filsfils-spring-srv6-network-programming].
SID (1-16 octet) o Reserved : 16 bit field. Should be set to 0 and MUST be ignored
on receipt.
This field encodes the advertised SRv6 SID. The "SID-Size" field o SID Flags: 8 bit field which define the flags associated with the
can have the value in the range of 1-128 and indicates the number SID. No flags are currently defined and SHOULD be set to 0 and
of bits in the SID. The SRv6 SID is encoded in the minimal number MUST be ignored on receipt.
of octets for the given number of bits.
Sub-Sub-TLV-Length(one octet) o SID Size : 8 bit field. Number of bits in the SID field.
Number of octets used by sub-TLVs. o SID : 1-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-Sub-TLVs (Variable) o Neighbor ID : 4 octets of OSPFv3 Router-id of the neighbor
One or more functions associated with the advertised SID is o Sub-TLVs : currently none defined. Used to advertise sub-TLVs
specified by the SRv6-Function Descriptor Sub-TLV specified in that provide additional attributes for the given SRv6 SID.
Section 2.2. If the SRv6 Function Descriptor is encoded in the
SRv6 P2P SID Sub-TLV, the encoded SRv6 SID function MUST include
only the code points of SRv6 SID functions that require the
specification of a neighbor to be correctly applied.
3. Security Considerations 3. Security Considerations
This document does not introduce any security issue. Existing security extensions as described in [RFC5340] and
[I-D.ietf-ospf-ospfv3-lsa-extend] apply to these SRv6 extensions.
4. IANA Considerations While OSPFv3 is under a single administrative domain, there can be
deployments where potential attackers have access to one or more
This document proposes IANA considerations as described in the networks in the OSPFv3 routing domain. In these deployments,
following sections. stronger authentication mechanisms such as those specified in
[RFC4552] SHOULD be used.
4.1. OSPFv3 Extensions for SRv6 Support
This document proposes the following OSPFv3 Extensions in order to Implementations MUST assure that malformed TLV and Sub-TLV defined in
support SRv6: 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.
1. SRv6-Capabilities Sub-TLV (Type TBD-1): Refer to Section 2.1. 4. IANA Considerations
2. Maximum SL Sub-Sub-TLV (Type TBD-2): Refer to Section 2.1.1. This document specifies updates to multiple OSPFv3 related IANA
registries as follows.
3. Maximum End Pop SRH Sub-Sub-TLV (Type TBD-3): Refer to 4.1. OSPF Parameters
Section 2.1.2.
4. Maximum T.Insert SRH Sub-Sub-TLV (Type TBD-4): Refer to This document proposes the following new code points in the OSPF
Section 2.1.3. Router Information (RI) TLVs registry for OSPFv3 Extensions in order
to support SRv6:
5. Maximum T.Encap SRH Sub-Sub-TLV (Type TBD-5): Refer to 1. Type TBD: SRv6-Capabilities TLV: Refer to Section 2.1.
Section 2.1.4.
6. Maximum End D SRH Sub-Sub-TLV (Type TBD-6): Refer to 2. Type TBD: SRv6 Node SID TLV : Refer to Section 2.2.
Section 2.1.5.
7. SRv6 Function Descriptor (Type TBD-7): Refer to Section 2.2. 4.2. OSPFv3 Parameters
8. SRv6 SID TLV (Type TBD-8): Refer to Section 2.4. This document proposes the following new code points in the OSPFv3
Extend-LSA Sub-TLV registry for OSPFv3 Extensions in order to support
SRv6:
9. SRv6 Point-to-Point Adj-SID Sub-TLV (Type TBD-9): Refer to 1. Type TBD: SRv6 SID Link Attribute Sub-TLV : Refer to
Section 2.5.1. Section 2.3.1.
10. SRv6 LAN SRv6 Adj-SID Sub-TLV (Type TBD-10): Refer to 2. Type TBD: SRv6 SID LAN Link Attribute Sub-TLV : Refer to
Section 2.5.2. Section 2.3.2.
5. Acknowledgements 5. Acknowledgements
TBD. TBD
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d.,
daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P.,
Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W.,
Bashandy, A., Raza, K., Dukes, D., Clad, F., and P.
Camarillo, "SRv6 Network Programming", draft-filsfils-
spring-srv6-network-programming-03 (work in progress),
December 2017.
[I-D.ietf-ospf-ospfv3-lsa-extend] [I-D.ietf-ospf-ospfv3-lsa-extend]
Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. Lindem, A., Roy, A., Goethals, D., Vallem, V., and F.
Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3-
lsa-extend-15 (work in progress), October 2017. lsa-extend-23 (work in progress), January 2018.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[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
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 [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 6.2. Informative References
[I-D.bashandy-isis-srv6-extensions]
Ginsberg, L., Bashandy, A., Filsfils, C., and B. Decraene,
"IS-IS Extensions to Support Routing over IPv6 Dataplane",
draft-bashandy-isis-srv6-extensions-01 (work in progress),
September 2017.
[I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d.,
daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P.,
Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W.,
Bashandy, A., Raza, K., Dukes, D., Clad, F., and P.
Camarillo, "SRv6 Network Programming", draft-filsfils-
spring-srv6-network-programming-01 (work in progress),
June 2017.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., Field, B., daniel.voyer@bell.ca, d.,
Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
"IPv6 Segment Routing Header (SRH)", draft-ietf-6man- D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
segment-routing-header-07 (work in progress), July 2017. Header (SRH)", draft-ietf-6man-segment-routing-header-08
(work in progress), January 2018.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-12 (work in progress), June 2017.
Authors' Addresses Authors' Addresses
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
Zhibo Hu Zhibo Hu
Huawei Technologies Huawei Technologies
Email: huzhibo@huawei.com Email: huzhibo@huawei.com
Dean Cheng Dean Cheng
Huawei Technologies Huawei Technologies
Email: dean.cheng@huawei.com Email: dean.cheng@huawei.com
Ketan Talaulikar
Cisco Systems
India
Email: ketant@cisco.com
Peter Psenak
Cisco Systems
Slovakia
Email: ppsenak@cisco.com
 End of changes. 146 change blocks. 
532 lines changed or deleted 472 lines changed or added

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