Network Working Group | Z. Li |
Internet-Draft | Z. Hu |
Intended status: Standards Track | D. Cheng |
Expires: April 22, 2018 | Huawei Technologies |
October 19, 2017 |
OSPFv3 Extensions for SRv6
draft-li-ospf-ospfv3-srv6-extensions-00
Segment routing architecture (refer to [I-D.ietf-spring-segment-routing]) can be implemented over a MPLS data plane, an IPv4 data plane, as well as an IPv6 data plane. [I-D.filsfils-spring-srv6-network-programming] introduces the network programming concept in IPv6 data plane using segment routing technology, called SRv6, and it also defines some basic functions. 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
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 April 22, 2018.
Copyright (c) 2017 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.
This document proposes some extensions to OSPFv3 in order to support SRv6 as defined in [I-D.filsfils-spring-srv6-network-programming], and they are as follows:
For consistency in IGP's behavior, ideas are borrowed from [I-D.bashandy-isis-srv6-extensions] including SRv6 functions supported and data format.
When apply Segment Routing to IPv6 data plane, the list of segments is stored in segment routing header, referred to as "SRH", which is defined in [I-D.ietf-6man-segment-routing-header].
A router that supports SRv6 MUST be able to process the segment routing header as described in [I-D.ietf-6man-segment-routing-header], as well as apply behaviors and flavors as described in [I-D.filsfils-spring-srv6-network-programming]. In either case, there exists a limit to which the router can perform according to its own ability that needs to be advertised to other routers in the same SR domain.
The OSPFv3-SRv6-Capbilities Sub-TLV is designed for an OSPFv3 router to make announcement in the SRv6 domain about its ability in the context of SRv6 support.
The format of OSPFv3-SRv6-Capabilities Sub-TLV is shown in Figure 1.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Sub-TLVs .... 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
Type (one octet)
Length (one octet)
Flags (16 bits)
The Maximum Segments Left Sub-Sub-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.
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 SL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
Type (one octet)
Length (one octet)
Max SL (8 bits)
If the sub-sub-TLV is NOT advertised, the value is assumed to be 0.
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 "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)
Length (one octet)
Max-End-Pop-SRH (8 bits)
If the value is zero or the sub-sub-TLV is NOT advertised, then it is assumed that the router cannot apply PSP or USP flavors.
The Maximum T.Insert SRH Sub-Sub-TLV specifies the maximum number of SIDs that can be inserted as part of the "T.insert" behavior([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.Insert | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
Type (one octet)
Length (one octet)
Max-T.Insert (8 bits)
If the value is zero or the sub-sub-TLV is omitted, then the router is assumed not to support any variation of the "T.insert" behavior.
The Maximum T.Encap SRH Sub-Sub-TLV specifies the maximum number of SIDs that can be included as part of the "T.Encap" behavior([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)
Length (one octet)
Max-T.Encap (8 bits)
If this value is zero or the Sub-Sub-TLV is omitted and the "E" flag is set in the associated SRv6 Capabilities Sub-TLV, then it is assumed that the router can apply T.Encap by encapsulating the incoming packet in another IPv6 header without SRH the same way IPinIP encapsulation is performed. If the "E" flag is clear, then this Sub-Sub-TLV SHOULD NOT be transmitted and MUST be ignored on reception.
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.
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 D | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
Type (one octet)
Length (one octet)
Max End D (8 bits)
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.
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) 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.
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-|-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7
Type (one octet)
Length (one octet)
Flags
0 1 2 3 4 5 6 7 +-+-|-+-+-+-+-+-+ |P|U| Reserved | +-+-+-+-+-+-+-+-+
Figure 8
P bit
U bit
Reserved
The second two octets encode the function. Function code points are defined in Section 2.3.
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:
1:
2:
3:
4:
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)
Length (one octet)
One or more SID entries, each of which has the following format:
Flags (One octet)
0 1 2 3 4 5 6 7 +-+-|-+-+-+-+-+-+ |D| Reserved | +-+-+-+-+-+-+-+-+
Figure 10
D bit:
Reserved:
SID-Size (one octet)
SID (1-16 octet)
Sub-Sub-TLV-Length(one octet)
Sub-Sub-TLVs (Variable)
The advertising of some SRv6 functions must be associated with a 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 [I-D.filsfils-spring-srv6-network-programming], other documents, or locally configured.
This document specifies how to advertise End.X and End.DX6 defined in [I-D.filsfils-spring-srv6-network-programming] using OSPFv3 extersons.
This Sub-TLV is used to advertise one or more SRv6 SIDs associated with End.X and End.DX6 SRv6 functions over a point-to-point adjacency.
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)
Length (one octet)
One or more SID entries, each of which has the following format:
Flags (One octet)
SID-Size (one octet)
SID (1-16 octet)
Sub-Sub-TLV-Length(one octet)
Sub-Sub-TLVs (Variable)
This Sub-TLV is used to advertise one or more SRv6 SIDs associated with End.X and End.DX6 SRv6 functions over a LAN adjacency.
The format of the "LAN SRv6 Adj-SID" Sub-TLV is shown in Figure 12.
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 12
Type (one octet)
Length (one octet)
One or more SID entries, each of which has the following format:
Flags (One octet)
SID-Size (one octet)
SID (1-16 octet)
Sub-Sub-TLV-Length(one octet)
Sub-Sub-TLVs (Variable)
This document does not introduce any security issue.
This document proposes IANA considerations as described in the following sections.
This document proposes the following OSPFv3 Extensions in order to support SRv6:
TBD.
[I-D.ietf-ospf-ospfv3-lsa-extend] | Lindem, A., Roy, A., Goethals, D., Vallem, V. and F. Baker, "OSPFv3 LSA Extendibility", Internet-Draft draft-ietf-ospf-ospfv3-lsa-extend-15, October 2017. |
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
[RFC5340] | Coltun, R., Ferguson, D., Moy, J. and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008. |
[RFC7770] | Lindem, A., 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. |