draft-ietf-ospf-ospfv3-segment-routing-extensions-15.txt   draft-ietf-ospf-ospfv3-segment-routing-extensions-16.txt 
Open Shortest Path First IGP P. Psenak, Ed. Open Shortest Path First IGP P. Psenak, Ed.
Internet-Draft C. Filsfils Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track S. Previdi, Ed.
Expires: February 4, 2019 S. Previdi, Ed. Expires: April 24, 2019 Individual
Individual October 21, 2018
H. Gredler
RtBrick Inc.
R. Shakir
Google, Inc.
W. Henderickx
Nokia
J. Tantsura
Nuage Networks
August 3, 2018
OSPFv3 Extensions for Segment Routing OSPFv3 Extensions for Segment Routing
draft-ietf-ospf-ospfv3-segment-routing-extensions-15 draft-ietf-ospf-ospfv3-segment-routing-extensions-16
Abstract Abstract
Segment Routing (SR) allows a flexible definition of end-to-end paths Segment Routing (SR) allows a flexible definition of end-to-end paths
within IGP topologies by encoding paths as sequences of topological within IGP topologies by encoding paths as sequences of topological
sub-paths, called "segments". These segments are advertised by the sub-paths, called "segments". These segments are advertised by the
link-state routing protocols (IS-IS and OSPF). link-state routing protocols (IS-IS and OSPF).
This draft describes the OSPFv3 extensions required for Segment This draft describes the OSPFv3 extensions required for Segment
Routing. Routing.
skipping to change at page 2, line 7 skipping to change at page 1, line 43
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 February 4, 2019. This Internet-Draft will expire on April 24, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3
2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 3 2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 3
3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4
3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4 3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4
3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 6 3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 5
3.3. SR Local Block TLV . . . . . . . . . . . . . . . . . . . 8 3.3. SR Local Block TLV . . . . . . . . . . . . . . . . . . . 7
3.4. SRMS Preference TLV . . . . . . . . . . . . . . . . . . . 10 3.4. SRMS Preference TLV . . . . . . . . . . . . . . . . . . . 9
4. OSPFv3 Extended Prefix Range TLV . . . . . . . . . . . . . . 11 4. OSPFv3 Extended Prefix Range TLV . . . . . . . . . . . . . . 10
5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 14 5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 13
6. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 17 6. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 16
6.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 17 6.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 17
6.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 19 6.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 18
7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20 7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19
7.1. Intra-area Segment routing in OSPFv3 . . . . . . . . . . 20 7.1. Intra-area Segment routing in OSPFv3 . . . . . . . . . . 19
7.2. Inter-area Segment routing in OSPFv3 . . . . . . . . . . 21 7.2. Inter-area Segment routing in OSPFv3 . . . . . . . . . . 20
7.3. Segment Routing for External Prefixes . . . . . . . . . . 22 7.3. Segment Routing for External Prefixes . . . . . . . . . . 21
7.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 23 7.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 22
7.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 23 7.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 22
7.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 23 7.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. OSPFv3 Extended-LSA TLV Registry . . . . . . . . . . . . 23 8.1. OSPFv3 Extended-LSA TLV Registry . . . . . . . . . . . . 22
8.2. OSPFv3 Extended-LSA Sub-TLV registry . . . . . . . . . . 24 8.2. OSPFv3 Extended-LSA Sub-TLV registry . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Segment Routing (SR) allows a flexible definition of end-to-end paths Segment Routing (SR) allows a flexible definition of end-to-end paths
within IGP topologies by encoding paths as sequences of topological within IGP topologies by encoding paths as sequences of topological
sub-paths, called "segments". These segments are advertised by the sub-paths, called "segments". These segments are advertised by the
link-state routing protocols (IS-IS and OSPF). Prefix segments link-state routing protocols (IS-IS and OSPF). Prefix segments
represent an ECMP-aware shortest-path to a prefix (or a node), as per represent an ECMP-aware shortest-path to a prefix (or a node), as per
skipping to change at page 5, line 18 skipping to change at page 5, line 4
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm... | Algorithm n | | | Algorithm 1 | Algorithm... | Algorithm n | |
+- -+ +- -+
| | | |
+ + + +
where: where:
Type: 8 Type: 8
Length: Variable, in octets, dependent on number of algorithms Length: Variable, in octets, dependent on number of algorithms
advertised. advertised.
Algorithm: Single octet identifying the algorithm. The following Algorithm: Single octet identifying the algorithm. Algorithms are
values are defined by this document: defined in "IGP Algorithm Type" registry under "Interior Gateway
Protocol (IGP) Parameters", defined in
0: Shortest Path First (SPF) algorithm based on link metric. [I-D.ietf-ospf-segment-routing-extensions].
This is the standard shortest path algorithm as computed by the
OSPFv3 protocol. Consistent with the deployed practice for
link-state protocols, Algorithm 0 permits any node to overwrite
the SPF path with a different path based on its local policy.
If the SR-Algorithm TLV is advertised, Algorithm 0 MUST be
included.
1: Strict Shortest Path First (SPF) algorithm based on link
metric. The algorithm is identical to Algorithm 0 but
Algorithm 1 requires that all nodes along the path will honor
the SPF routing decision. Local policy at the node claiming
support for Algorithm 1 MUST NOT alter the SPF paths computed
by Algorithm 1.
When multiple SR-Algorithm TLVs are received from a given router, the When multiple SR-Algorithm TLVs are received from a given router, the
receiver MUST use the first occurrence of the TLV in the OSPFv3 receiver MUST use the first occurrence of the TLV in the OSPFv3
Router Information Opaque LSA. If the SR-Algorithm TLV appears in Router Information Opaque LSA. If the SR-Algorithm TLV appears in
multiple OSPFv3 Router Information Opaque LSAs that have different multiple OSPFv3 Router Information Opaque LSAs that have different
flooding scopes, the SR-Algorithm TLV in the OSPFv3 Router flooding scopes, the SR-Algorithm TLV in the OSPFv3 Router
Information Opaque LSA with the area-scoped flooding scope MUST be Information Opaque LSA with the area-scoped flooding scope MUST be
used. If the SR-Algorithm TLV appears in multiple OSPFv3 Router used. If the SR-Algorithm TLV appears in multiple OSPFv3 Router
Information Opaque LSAs that have the same flooding scope, the SR- Information Opaque LSAs that have the same flooding scope, the SR-
Algorithm TLV in the OSPFv3 Router Information Opaque LSA with the Algorithm TLV in the OSPFv3 Router Information Opaque LSA with the
skipping to change at page 14, line 5 skipping to change at page 12, line 50
a prefix of length 0. a prefix of length 0.
For the address family IPv6 unicast, the prefix, encoded as an For the address family IPv6 unicast, the prefix, encoded as an
even multiple of 32-bit words, padded with zeroed bits as even multiple of 32-bit words, padded with zeroed bits as
necessary. This encoding consumes ((PrefixLength + 31) / 32) necessary. This encoding consumes ((PrefixLength + 31) / 32)
32-bit words. 32-bit words.
Prefix encoding for other address families is beyond the scope Prefix encoding for other address families is beyond the scope
of this specification. of this specification.
If the OSPFv3 Extended Prefix Range TLVs advertising the exact same
range appears in multiple LSAs of the same type, originated by the
same OSPFv3 router, the LSA with the numerically smallest Instance ID
MUST be used and subsequent instances of the OSPFv3 Extended Prefix
Range TLVs MUST be ignored.
5. Prefix SID Sub-TLV 5. Prefix SID Sub-TLV
The Prefix SID Sub-TLV is a Sub-TLV of the following OSPFv3 TLVs as The Prefix SID Sub-TLV is a Sub-TLV of the following OSPFv3 TLVs as
defined in [RFC8362] and in Section 4: defined in [RFC8362] and in Section 4:
Intra-Area Prefix TLV Intra-Area Prefix TLV
Inter-Area Prefix TLV Inter-Area Prefix TLV
External Prefix TLV External Prefix TLV
skipping to change at page 23, line 51 skipping to change at page 22, line 51
network using the LAN-Adj-SID Sub-TLV as described in Section 6.2. network using the LAN-Adj-SID Sub-TLV as described in Section 6.2.
8. IANA Considerations 8. IANA Considerations
This specification updates several existing OSPFv3 registries. This specification updates several existing OSPFv3 registries.
8.1. OSPFv3 Extended-LSA TLV Registry 8.1. OSPFv3 Extended-LSA TLV Registry
Following values are allocated: Following values are allocated:
o suggested value 9 - OSPFv3 Extended Prefix Range TLV o 9 - OSPFv3 Extended Prefix Range TLV
8.2. OSPFv3 Extended-LSA Sub-TLV registry 8.2. OSPFv3 Extended-LSA Sub-TLV registry
o 4 - Prefix SID Sub-TLV o 4 - Prefix SID Sub-TLV
o 5 - Adj-SID Sub-TLV o 5 - Adj-SID Sub-TLV
o 6 - LAN Adj-SID Sub-TLV o 6 - LAN Adj-SID Sub-TLV
o 7 - SID/Label Sub-TLV o 7 - SID/Label Sub-TLV
9. Security Considerations 9. Security Considerations
With the OSPFv3 segment routing extensions defined herein, OSPFv3 With the OSPFv3 segment routing extensions defined herein, OSPFv3
will now program the MPLS data plane [RFC3031] in addition to the IP will now program the MPLS data plane [RFC3031]. Previously, LDP
data plane. Previously, LDP [RFC5036] or another label distribution [RFC5036] or another label distribution mechanism was required to
mechanism was required to advertise MPLS labels and program the MPLS advertise MPLS labels and program the MPLS data plane.
data plane.
In general, the same types of attacks that can be carried out on the In general, the same types of attacks that can be carried out on the
IP control plane can be carried out on the MPLS control plane IP control plane can be carried out on the MPLS control plane
resulting in traffic being misrouted in the respective data planes. resulting in traffic being misrouted in the respective data planes.
However, the latter can be more difficult to detect and isolate. However, the latter can be more difficult to detect and isolate.
Existing security extensions as described in [RFC5340] and [RFC8362] Existing security extensions as described in [RFC5340] and [RFC8362]
apply to these segment routing extensions. While OSPFv3 is under a apply to these segment routing extensions. While OSPFv3 is under a
single administrative domain, there can be deployments where single administrative domain, there can be deployments where
potential attackers have access to one or more networks in the OSPFv3 potential attackers have access to one or more networks in the OSPFv3
skipping to change at page 24, line 44 skipping to change at page 23, line 43
be used. be used.
Implementations MUST assure that malformed TLV and Sub-TLV defined in Implementations MUST assure that malformed TLV and Sub-TLV defined in
this document are detected and do not provide a vulnerability for this document are detected and do not provide a vulnerability for
attackers to crash the OSPFv3 router or routing process. Reception attackers to crash the OSPFv3 router or routing process. Reception
of a malformed TLV or Sub-TLV SHOULD be counted and/or logged for of a malformed TLV or Sub-TLV SHOULD be counted and/or logged for
further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be
rate-limited to prevent a Denial of Service (DoS) attack (distributed rate-limited to prevent a Denial of Service (DoS) attack (distributed
or otherwise) from overloading the OSPFv3 control plane. or otherwise) from overloading the OSPFv3 control plane.
10. Acknowledgements 10. Contributors
The following people gave a substantial contribution to the content
of this document and should be considered as co-authors:
Clarence Filsfils
Cisco Systems, Inc.
Brussels
Belgium
Email: cfilsfil@cisco.com
Hannes Gredler
RtBrick Inc.
Austria
Email: hannes@rtbrick.com
Rob Shakir
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: robjs@google.com
Wim Henderickx
Nokia
Copernicuslaan 50
Antwerp 2018
BE
Email: wim.henderickx@nokia.com
Jeff Tantsura
Nuage Networks
US
Email: jefftant.ietf@gmail.com
Thanks to Acee Lindem for his substantial contribution to the content Thanks to Acee Lindem for his substantial contribution to the content
of this document. of this document.
We would like to thank Anton Smirnov for his contribution as well. We would like to thank Anton Smirnov for his contribution as well.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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-25 (work in progress), April 2018.
[I-D.ietf-spring-segment-routing-ldp-interop] [I-D.ietf-spring-segment-routing-ldp-interop]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and
S. Litkowski, "Segment Routing interworking with LDP", S. Litkowski, "Segment Routing interworking with LDP",
draft-ietf-spring-segment-routing-ldp-interop-14 (work in draft-ietf-spring-segment-routing-ldp-interop-15 (work in
progress), July 2018. progress), September 2018.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-14 data plane", draft-ietf-spring-segment-routing-mpls-14
(work in progress), June 2018. (work in progress), June 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,
skipping to change at page 26, line 43 skipping to change at page 26, line 48
Peter Psenak (editor) Peter Psenak (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Eurovea Centre, Central 3 Eurovea Centre, Central 3
Pribinova Street 10 Pribinova Street 10
Bratislava 81109 Bratislava 81109
Slovakia Slovakia
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
Brussels
Belgium
Email: cfilsfil@cisco.com
Stefano Previdi (editor) Stefano Previdi (editor)
Individual Individual
Email: stefano.previdi@net Email: stefano.previdi@net
Hannes Gredler
RtBrick Inc.
Austria
Email: hannes@rtbrick.com
Rob Shakir
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: robjs@google.com
Wim Henderickx
Nokia
Copernicuslaan 50
Antwerp 2018
BE
Email: wim.henderickx@nokia.com
Jeff Tantsura
Nuage Networks
US
Email: jefftant.ietf@gmail.com
 End of changes. 16 change blocks. 
69 lines changed or deleted 89 lines changed or added

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