idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-26.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 20, 2018) is 1955 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '100' on line 328 -- Looks like a reference, but probably isn't: '199' on line 328 -- Looks like a reference, but probably isn't: '1000' on line 329 -- Looks like a reference, but probably isn't: '1099' on line 329 -- Looks like a reference, but probably isn't: '500' on line 330 -- Looks like a reference, but probably isn't: '599' on line 330 == Missing Reference: 'RFC3031' is mentioned on line 1148, but not defined == Missing Reference: 'RFC5036' is mentioned on line 1149, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-15 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-18 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Shortest Path First IGP P. Psenak, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Standards Track C. Filsfils 5 Expires: May 24, 2019 Cisco Systems, Inc. 6 H. Gredler 7 RtBrick Inc. 8 R. Shakir 9 Google, Inc. 10 W. Henderickx 11 Nokia 12 J. Tantsura 13 Apstra, Inc. 14 November 20, 2018 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-26 19 Abstract 21 Segment Routing (SR) allows a flexible definition of end-to-end paths 22 within IGP topologies by encoding paths as sequences of topological 23 sub-paths, called "segments". These segments are advertised by the 24 link-state routing protocols (IS-IS and OSPF). 26 This draft describes the OSPFv2 extensions required for Segment 27 Routing. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 24, 2019. 51 Copyright Notice 53 Copyright (c) 2018 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 70 2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 71 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4 72 3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4 73 3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 6 74 3.3. SR Local Block TLV . . . . . . . . . . . . . . . . . . . 8 75 3.4. SRMS Preference TLV . . . . . . . . . . . . . . . . . . . 10 76 4. OSPF Extended Prefix Range TLV . . . . . . . . . . . . . . . 11 77 5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 13 78 6. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 16 79 6.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 16 80 6.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 18 81 7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19 82 7.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 20 83 7.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 20 84 7.3. Segment Routing for External Prefixes . . . . . . . . . . 21 85 7.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 22 86 7.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 22 87 7.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 22 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 89 8.1. OSPF Router Information (RI) TLVs Registry . . . . . . . 23 90 8.2. OSPFv2 Extended Prefix Opaque LSA TLVs Registry . . . . . 23 91 8.3. OSPFv2 Extended Prefix TLV Sub-TLVs Registry . . . . . . 23 92 8.4. OSPFv2 Extended Link TLV Sub-TLVs Registry . . . . . . . 23 93 8.5. IGP Algorithm Type Registry . . . . . . . . . . . . . . . 23 94 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 95 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 96 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 97 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 98 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 100 13.2. Informative References . . . . . . . . . . . . . . . . . 27 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 103 1. Introduction 105 Segment Routing (SR) allows a flexible definition of end-to-end paths 106 within IGP topologies by encoding paths as sequences of topological 107 sub-paths, called "segments". These segments are advertised by the 108 link-state routing protocols (IS-IS and OSPF). Prefix segments 109 represent an ECMP-aware shortest-path to a prefix (or a node), as per 110 the state of the IGP topology. Adjacency segments represent a hop 111 over a specific adjacency between two nodes in the IGP. A prefix 112 segment is typically a multi-hop path while an adjacency segment, in 113 most cases, is a one-hop path. SR's control-plane can be applied to 114 both IPv6 and MPLS data-planes, and does not require any additional 115 signalling (other than IGP extensions). The IPv6 data plane is out 116 of the scope of this specification - it is not applicable to OSPFv2 117 which only supports the IPv4 address-family. When used in MPLS 118 networks, SR paths do not require any LDP or RSVP-TE signalling. 119 However, SR can interoperate in the presence of LSPs established with 120 RSVP or LDP. 122 There are additional segment types, e.g., Binding SID defined in 123 [I-D.ietf-spring-segment-routing]. 125 This draft describes the OSPF extensions required for Segment 126 Routing. 128 Segment Routing architecture is described in 129 [I-D.ietf-spring-segment-routing]. 131 Segment Routing use cases are described in [RFC7855]. 133 2. Segment Routing Identifiers 135 Segment Routing defines various types of Segment Identifiers (SIDs): 136 Prefix-SID, Adjacency-SID, LAN Adjacency SID, and Binding SID. 138 Extended Prefix/Link Opaque LSAs defined in [RFC7684] are used for 139 advertisements of the various SID types. 141 2.1. SID/Label Sub-TLV 143 The SID/Label Sub-TLV appears in multiple TLVs or Sub-TLVs defined 144 later in this document. It is used to advertise the SID or label 145 associated with a prefix or adjacency. The SID/Label Sub-TLV has 146 following format: 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Type | Length | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | SID/Label (variable) | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 where: 158 Type: 1 160 Length: Variable, 3 or 4 octet 162 SID/Label: If length is set to 3, then the 20 rightmost bits 163 represent a label. If length is set to 4, then the value 164 represents a 32-bit SID. 166 The receiving router MUST ignore the SID/Label Sub-TLV if the 167 length is other then 3 or 4. 169 3. Segment Routing Capabilities 171 Segment Routing requires some additional router capabilities to be 172 advertised to other routers in the area. 174 These SR capabilities are advertised in the Router Information Opaque 175 LSA (defined in [RFC7770]). The TLVs defined below are applicable to 176 both OSPFv2 and OSPFv3; see also 177 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 179 3.1. SR-Algorithm TLV 181 The SR-Algorithm TLV is a top-level TLV of the Router Information 182 Opaque LSA (defined in [RFC7770]). 184 The SR-Algorithm TLV is optional. It SHOULD only be advertised once 185 in the Router Information Opaque LSA. If the SR-Algorithm TLV is not 186 advertised by the node, such node is considered as not being segment 187 routing capable. 189 An SR Router can use various algorithms when calculating reachability 190 to OSPF routers or prefixes in an OSPF area. Examples of these 191 algorithms are metric based Shortest Path First (SPF), various 192 flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a 193 router to advertise the algorithms currently used by the router to 194 other routers in an OSPF area. The SR-Algorithm TLV has following 195 format: 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Type | Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Algorithm 1 | Algorithm... | Algorithm n | | 203 +- -+ 204 | | 205 + + 207 where: 209 Type: 8 211 Variable, in octets, dependent on number of algorithms advertised. 213 Algorithm: Single octet identifying the algorithm. The following 214 values are defined by this document: 216 0: Shortest Path First (SPF) algorithm based on link metric. 217 This is the standard shortest path algorithm as computed by the 218 OSPF protocol. Consistent with the deployed practice for link- 219 state protocols, Algorithm 0 permits any node to overwrite the 220 SPF path with a different path based on its local policy. If 221 the SR-Algorithm TLV is advertised, Algorithm 0 MUST be 222 included. 224 1: Strict Shortest Path First (SPF) algorithm based on link 225 metric. The algorithm is identical to Algorithm 0 but 226 Algorithm 1 requires that all nodes along the path will honor 227 the SPF routing decision. Local policy at the node claiming 228 support for Algorithm 1 MUST NOT alter the SPF paths computed 229 by Algorithm 1. 231 When multiple SR-Algorithm TLVs are received from a given router, the 232 receiver MUST use the first occurrence of the TLV in the Router 233 Information LSA. If the SR-Algorithm TLV appears in multiple Router 234 Information LSAs that have different flooding scopes, the SR- 235 Algorithm TLV in the Router Information LSA with the area-scoped 236 flooding scope MUST be used. If the SR-Algorithm TLV appears in 237 multiple Router Information LSAs that have the same flooding scope, 238 the SR-Algorithm TLV in the Router Information (RI) LSA with the 239 numerically smallest Instance ID MUST be used and subsequent 240 instances of the SR-Algorithm TLV MUST be ignored. 242 The RI LSA can be advertised at any of the defined opaque flooding 243 scopes (link, area, or Autonomous System (AS)). For the purpose of 244 SR-Algorithm TLV advertisement, area-scoped flooding is REQUIRED. 246 3.2. SID/Label Range TLV 248 Prefix SIDs MAY be advertised in a form of an index as described in 249 Section 5. Such index defines the offset in the SID/Label space 250 advertised by the router. The SID/Label Range TLV is used to 251 advertise such SID/Label space. 253 The SID/Label Range TLV is a top-level TLV of the Router Information 254 Opaque LSA (defined in [RFC7770]). 256 The SID/Label Range TLV MAY appear multiple times and has the 257 following format: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type | Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Range Size | Reserved | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Sub-TLVs (variable) | 267 +- -+ 268 | | 269 + + 271 where: 273 Type: 9 275 Length: Variable, in octets, dependent on Sub-TLVs. 277 Range Size: 3-octet SID/label range size (i.e., the number of SIDs 278 or labels in the range including the first SID/label). It MUST be 279 greater than 0. 281 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 282 on reception. 284 Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as 285 defined in Section 2.1. The SID/Label Sub-TLV MUST be included in 286 the SID/Label Range TLV. The SID/Label advertised in the SID/Label 287 Sub-TLV represents the first SID/Label in the advertised range. 289 Only a single SID/Label Sub-TLV MAY be advertised in SID/Label Range 290 TLV. If more then one SID/Label Sub-TLVs are present, the SID/Label 291 Range TLV MUST be ignored. 293 Multiple occurrences of the SID/Label Range TLV MAY be advertised, in 294 order to advertise multiple ranges. In such case: 296 o The originating router MUST encode each range into a different 297 SID/Label Range TLV. 299 o The originating router decides the order in which the set of SID/ 300 Label Range TLVs are advertised inside the Router Information 301 Opaque LSA. The originating router MUST ensure the order is the 302 same after a graceful restart (using checkpointing, non-volatile 303 storage, or any other mechanism) in order to assure the SID/label 304 range and SID index correspondence is preserved across graceful 305 restarts. 307 o The receiving router MUST adhere to the order in which the ranges 308 are advertised when calculating a SID/label from a SID index. 310 o The originating router MUST NOT advertise overlapping ranges. 312 o When a router receives multiple overlapping ranges, it MUST 313 conform to the procedures defined in 314 [I-D.ietf-spring-segment-routing-mpls]. 316 The following example illustrates the advertisement of multiple 317 ranges: 319 The originating router advertises the following ranges: 321 Range 1: Range Size: 100 SID/Label Sub-TLV: 100 322 Range 1: Range Size: 100 SID/Label Sub-TLV: 1000 323 Range 1: Range Size: 100 SID/Label Sub-TLV: 500 325 The receiving routers concatenate the ranges and build the Segment 326 Routing Global Block (SRGB) as follows: 328 SRGB = [100, 199] 329 [1000, 1099] 330 [500, 599] 332 The indexes span multiple ranges: 334 index=0 means label 100 335 ... 336 index 99 means label 199 337 index 100 means label 1000 338 index 199 means label 1099 339 ... 340 index 200 means label 500 341 ... 343 The RI LSA can be advertised at any of the defined flooding scopes 344 (link, area, or autonomous system (AS)). For the purpose of SID/ 345 Label Range TLV advertisement, area-scoped flooding is REQUIRED. 347 3.3. SR Local Block TLV 349 The SR Local Block TLV (SRLB TLV) contains the range of labels the 350 node has reserved for local SIDs. SIDs from the SRLB MAY be used for 351 Adjacency-SIDs, but also by components other than the OSPF protocol. 352 As an example, an application or a controller can instruct the router 353 to allocate a specific local SID. Some controllers or applications 354 can use the control plane to discover the available set of local SIDs 355 on a particular router. In such cases, the SRLB is advertised in the 356 control plane. The requirement to advertise the SRLB is further 357 described in [I-D.ietf-spring-segment-routing-mpls]. The SRLB TLV is 358 used to advertise the SRLB. 360 The SRLB TLV is a top-level TLV of the Router Information Opaque LSA 361 (defined in [RFC7770]). 363 The SRLB TLV MAY appear multiple times in the Router Information 364 Opaque LSA and has the following format: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Type | Length | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Range Size | Reserved | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Sub-TLVs (variable) | 374 +- -+ 375 | | 376 + + 378 where: 380 Type: 14 382 Length: Variable, in octets, dependent on Sub-TLVs. 384 Range Size: 3-octet SID/label range size (i.e., the number of SIDs 385 or labels in the range including the first SID/label). It MUST be 386 greater than 0. 388 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 389 on reception. 391 Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as 392 defined in Section 2.1. The SID/Label Sub-TLV MUST be included in 393 the SRLB TLV. The SID/Label advertised in the SID/Label Sub-TLV 394 represents the first SID/Label in the advertised range. 396 Only a single SID/Label Sub-TLV MAY be advertised in the SRLB TLV. 397 If more then one SID/Label Sub-TLVs are present, the SRLB TLV MUST be 398 ignored. 400 The originating router MUST NOT advertise overlapping ranges. 402 Each time a SID from the SRLB is allocated, it SHOULD also be 403 reported to all components (e.g., controller or applications) in 404 order for these components to have an up-to-date view of the current 405 SRLB allocation. This is required to avoid collisions between 406 allocation instructions. 408 Within the context of OSPF, the reporting of local SIDs is done 409 through OSPF Sub-TLVs such as the Adjacency-SID (Section 6). 410 However, the reporting of allocated local SIDs can also be done 411 through other means and protocols which are outside the scope of this 412 document. 414 A router advertising the SRLB TLV MAY also have other label ranges, 415 outside of the SRLB, used for its local allocation purposes which are 416 not advertised in the SRLB TLV. For example, it is possible that an 417 Adjacency-SID is allocated using a local label that is not part of 418 the SRLB. 420 The RI LSA can be advertised at any of the defined flooding scopes 421 (link, area, or autonomous system (AS)). For the purpose of SRLB TLV 422 advertisement, area-scoped flooding is REQUIRED. 424 3.4. SRMS Preference TLV 426 The Segment Routing Mapping Server Preference TLV (SRMS Preference 427 TLV) is used to advertise a preference associated with the node that 428 acts as an SR Mapping Server. The role of an SRMS is described in 429 [I-D.ietf-spring-segment-routing-ldp-interop]. SRMS preference is 430 defined in [I-D.ietf-spring-segment-routing-ldp-interop]. 432 The SRMS Preference TLV is a top-level TLV of the Router Information 433 Opaque LSA (defined in [RFC7770]). 435 The SRMS Preference TLV MAY only be advertised once in the Router 436 Information Opaque LSA and has the following format: 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Type | Length | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Preference | Reserved | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 where: 448 Type: 15 450 Length: 4 octets 452 Preference: 1 octet. SRMS preference value from 0 to 255. 454 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 455 on reception. 457 When multiple SRMS Preference TLVs are received from a given router, 458 the receiver MUST use the first occurrence of the TLV in the Router 459 Information LSA. If the SRMS Preference TLV appears in multiple 460 Router Information LSAs that have different flooding scopes, the SRMS 461 Preference TLV in the Router Information LSA with the narrowest 462 flooding scope MUST be used. If the SRMS Preference TLV appears in 463 multiple Router Information LSAs that have the same flooding scope, 464 the SRMS Preference TLV in the Router Information LSA with the 465 numerically smallest Instance ID MUST be used and subsequent 466 instances of the SRMS Preference TLV MUST be ignored. 468 The RI LSA can be advertised at any of the defined flooding scopes 469 (link, area, or autonomous system (AS)). For the purpose of the SRMS 470 Preference TLV advertisement, AS-scoped flooding SHOULD be used. 471 This is because SRMS servers can be located in a different area then 472 consumers of the SRMS advertisements. If the SRMS advertisements 473 from the SRMS server are only used inside the SRMS server's area, 474 area-scoped flooding MAY be used. 476 4. OSPF Extended Prefix Range TLV 478 In some cases it is useful to advertise attributes for a range of 479 prefixes. The Segment Routing Mapping Server, which is described in 480 [I-D.ietf-spring-segment-routing-ldp-interop], is an example where we 481 need a single advertisement to advertise SIDs for multiple prefixes 482 from a contiguous address range. 484 The OSPF Extended Prefix Range TLV, which is a top level TLV of the 485 Extended Prefix LSA described in [RFC7684] is defined for this 486 purpose. 488 Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each 489 OSPF Extended Prefix Opaque LSA, but all prefix ranges included in a 490 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 491 scope. The OSPF Extended Prefix Range TLV has the following format: 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type | Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Prefix Length | AF | Range Size | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Flags | Reserved | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Address Prefix (variable) | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Sub-TLVs (variable) | 505 +- -+ 506 | | 508 where: 510 Type: 2 512 Length: Variable, in octets, dependent on Sub-TLVs. 514 Prefix length: Length of prefix in bits. 516 AF: Address family for the prefix. Currently, the only supported 517 value is 0 for IPv4 unicast. The inclusion of address family in 518 this TLV allows for future extension. 520 Range size: Represents the number of prefixes that are covered by 521 the advertisement. The Range Size MUST NOT exceed the number of 522 prefixes that could be satisfied by the prefix length without 523 including the IPv4 multicast address range (224.0.0.0/3). 525 Flags: Single octet field. The following flags are defined: 527 0 1 2 3 4 5 6 7 528 +--+--+--+--+--+--+--+--+ 529 |IA| | | | | | | | 530 +--+--+--+--+--+--+--+--+ 532 where: 534 IA-Flag: Inter-Area flag. If set, advertisement is of inter- 535 area type. An ABR that is advertising the OSPF Extended Prefix 536 Range TLV between areas MUST set this bit. 538 This bit is used to prevent redundant flooding of Prefix Range 539 TLVs between areas as follows: 541 An ABR only propagates an inter-area Prefix Range 542 advertisement from the backbone area to connected non- 543 backbone areas if the advertisement is considered to be the 544 best one. The following rules are used to select the best 545 range from the set of advertisements for the same Prefix 546 Range: 548 An ABR always prefers intra-area Prefix Range 549 advertisements over inter-area advertisements. 551 An ABR does not consider inter-area Prefix Range 552 advertisements coming from non-backbone areas. 554 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 555 on reception. 557 Address Prefix: For the address family IPv4 unicast, the prefix 558 itself is encoded as a 32-bit value. The default route is 559 represented by a prefix of length 0. Prefix encoding for other 560 address families is beyond the scope of this specification. 562 5. Prefix SID Sub-TLV 564 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV 565 described in [RFC7684] and the OSPF Extended Prefix Range TLV 566 described in Section 4. It MAY appear more than once in the parent 567 TLV and has the following format: 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Type | Length | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Flags | Reserved | MT-ID | Algorithm | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | SID/Index/Label (variable) | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 where: 581 Type: 2 583 Length: 7 or 8 octets, dependent on the V-flag 585 Flags: Single octet field. The following flags are defined: 587 0 1 2 3 4 5 6 7 588 +--+--+--+--+--+--+--+--+ 589 | |NP|M |E |V |L | | | 590 +--+--+--+--+--+--+--+--+ 592 where: 594 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 595 NOT pop the Prefix-SID before delivering packets to the node 596 that advertised the Prefix-SID. 598 M-Flag: Mapping Server Flag. If set, the SID was advertised by 599 a Segment Routing Mapping Server as described in 600 [I-D.ietf-spring-segment-routing-ldp-interop]. 602 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 603 the Prefix-SID originator MUST replace the Prefix-SID with the 604 Explicit-NULL label (0 for IPv4) before forwarding the packet. 606 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 607 an absolute value. If not set, then the Prefix-SID carries an 608 index. 610 L-Flag: Local/Global Flag. If set, then the value/index 611 carried by the Prefix-SID has local significance. If not set, 612 then the value/index carried by this Sub-TLV has global 613 significance. 615 Other bits: Reserved. These MUST be zero when sent and are 616 ignored when received. 618 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 619 on reception. 621 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 623 Algorithm: Single octet identifying the algorithm the Prefix-SID 624 is associated with as defined in Section 3.1. 626 A router receiving a Prefix-SID from a remote node and with an 627 algorithm value that such remote node has not advertised in the 628 SR-Algorithm Sub-TLV (Section 3.1) MUST ignore the Prefix-SID Sub- 629 TLV. 631 SID/Index/Label: According to the V and L flags, it contains 632 either: 634 A 32-bit index defining the offset in the SID/Label space 635 advertised by this router. 637 A 24-bit label where the 20 rightmost bits are used for 638 encoding the label value. 640 If an OSPF router advertises multiple Prefix-SIDs for the same 641 prefix, topology and algorithm, all of them MUST be ignored. 643 When calculating the outgoing label for the prefix, the router MUST 644 take into account, as described below, the E, NP and M flags 645 advertised by the next-hop router if that router advertised the SID 646 for the prefix. This MUST be done regardless of whether the next-hop 647 router contributes to the best path to the prefix. 649 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 650 Prefix-SIDs allocated to inter-area prefixes that are originated by 651 the ABR based on intra-area or inter-area reachability between areas, 652 unless the advertised prefix is directly attached to the ABR. 654 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 655 Prefix-SIDs allocated to redistributed prefixes, unless the 656 redistributed prefix is directly attached to the ASBR. 658 If the NP-Flag is not set, then any upstream neighbor of the Prefix- 659 SID originator MUST pop the Prefix-SID. This is equivalent to the 660 penultimate hop popping mechanism used in the MPLS dataplane. If the 661 NP-flag is not set, then the received E-flag is ignored. 663 If the NP-flag is set then: 665 If the E-flag is not set, then any upstream neighbor of the 666 Prefix-SID originator MUST keep the Prefix-SID on top of the 667 stack. This is useful when the originator of the Prefix-SID need 668 to stitch the incoming packet into a continuing MPLS LSP to the 669 final destination. This could occur at an Area Border Router 670 (prefix propagation from one area to another) or at an AS Boundary 671 Router (prefix propagation from one domain to another). 673 If the E-flag is set, then any upstream neighbor of the Prefix-SID 674 originator MUST replace the Prefix-SID with an Explicit-NULL 675 label. This is useful, e.g., when the originator of the Prefix- 676 SID is the final destination for the related prefix and the 677 originator wishes to receive the packet with the original EXP 678 bits. 680 When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at 681 reception. 683 As the Mapping Server does not specify the originator of a prefix 684 advertisement, it is not possible to determine PHP behavior solely 685 based on the Mapping Server advertisement. However, PHP behavior 686 SHOULD be done in following cases: 688 The Prefix is intra-area type and the downstream neighbor is the 689 originator of the prefix. 691 The Prefix is inter-area type and downstream neighbor is an ABR, 692 which is advertising prefix reachability and is also generating 693 the Extended Prefix TLV with the A-flag set for this prefix as 694 described in section 2.1 of [RFC7684]. 696 The Prefix is external type and downstream neighbor is an ASBR, 697 which is advertising prefix reachability and is also generating 698 the Extended Prefix TLV with the A-flag set for this prefix as 699 described in section 2.1 of [RFC7684]. 701 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 702 the value advertised in the Prefix SID Sub-TLV is interpreted as a 703 starting SID/Label value. 705 Example 1: If the following router addresses (loopback addresses) 706 need to be mapped into the corresponding Prefix SID indexes: 708 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 709 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 710 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 711 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 713 then the Prefix field in the Extended Prefix Range TLV would be set 714 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 715 set to 4, and the Index value in the Prefix-SID Sub-TLV would be set 716 to 1. 718 Example 2: If the following prefixes need to be mapped into the 719 corresponding Prefix-SID indexes: 721 192.0.2.0/30, Prefix-SID: Index 51 722 192.0.2.4/30, Prefix-SID: Index 52 723 192.0.2.8/30, Prefix-SID: Index 53 724 192.0.2.12/30, Prefix-SID: Index 54 725 192.0.2.16/30, Prefix-SID: Index 55 726 192.0.2.20/30, Prefix-SID: Index 56 727 192.0.2.24/30, Prefix-SID: Index 57 729 then the Prefix field in the Extended Prefix Range TLV would be set 730 to 192.0.2.0, Prefix Length would be set to 30, Range Size would be 731 7, and the Index value in the Prefix-SID Sub-TLV would be set to 51. 733 6. Adjacency Segment Identifier (Adj-SID) 735 An Adjacency Segment Identifier (Adj-SID) represents a router 736 adjacency in Segment Routing. 738 6.1. Adj-SID Sub-TLV 740 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 741 [RFC7684]. It MAY appear multiple times in the Extended Link TLV. 742 The Adj-SID Sub-TLV has the following format: 744 0 1 2 3 745 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 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Type | Length | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Flags | Reserved | MT-ID | Weight | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | SID/Label/Index (variable) | 752 +---------------------------------------------------------------+ 754 where: 756 Type: 2 758 Length: 7 or 8 octets, dependent on the V flag. 760 Flags: Single octet field containing the following flags: 762 0 1 2 3 4 5 6 7 763 +-+-+-+-+-+-+-+-+ 764 |B|V|L|G|P| | 765 +-+-+-+-+-+-+-+-+ 767 where: 769 B-Flag: Backup Flag. If set, the Adj-SID refers to an 770 adjacency that is eligible for protection (e.g., using IPFRR or 771 MPLS-FRR) as described in section 3.5 of 772 [I-D.ietf-spring-segment-routing]. 774 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 775 an absolute value. If not set, then the Adj-SID carries an 776 index. 778 The L-Flag: Local/Global Flag. If set, then the value/index 779 carried by the Adj-SID has local significance. If not set, 780 then the value/index carried by this Sub-TLV has global 781 significance. 783 The G-Flag: Group Flag. When set, the G-Flag indicates that 784 the Adj-SID refers to a group of adjacencies (and therefore MAY 785 be assigned to other adjacencies as well). 787 P-Flag. Persistent flag. When set, the P-Flag indicates that 788 the Adj-SID is persistently allocated, i.e., the Adj-SID value 789 remains consistent across router restart and/or interface flap. 791 Other bits: Reserved. These MUST be zero when sent and are 792 ignored when received. 794 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 795 on reception. 797 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 799 Weight: Weight used for load-balancing purposes. The use of the 800 weight is defined in [I-D.ietf-spring-segment-routing]. 802 SID/Index/Label: According to the V and L flags, it contains 803 either: 805 A 32-bit index defining the offset in the SID/Label space 806 advertised by this router. 808 A 24-bit label where the 20 rightmost bits are used for 809 encoding the label value. 811 An SR capable router MAY allocate an Adj-SID for each of its 812 adjacencies and set the B-Flag when the adjacency is eligible for 813 protection by an FRR mechanism (IP or MPLS) as described in section 814 3.5 of [I-D.ietf-spring-segment-routing]. 816 An SR capable router MAY allocate more than one Adj-SID to an 817 adjacency 819 An SR capable router MAY allocate the same Adj-SID to different 820 adjacencies 822 When the P-flag is not set, the Adj-SID MAY be persistent. When the 823 P-flag is set, the Adj-SID MUST be persistent. 825 6.2. LAN Adj-SID Sub-TLV 827 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 828 in [RFC7684]. It MAY appear multiple times in the Extended-Link TLV. 829 It is used to advertise a SID/Label for an adjacency to a non-DR 830 router on a broadcast, NBMA, or hybrid [RFC6845] network. 832 0 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Type | Length | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Flags | Reserved | MT-ID | Weight | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Neighbor ID | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | SID/Label/Index (variable) | 842 +---------------------------------------------------------------+ 844 where: 846 Type: 3 848 Length: 11 or 12 octets, dependent on V-flag. 850 Flags: same as in Section 6.1 852 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 853 on reception. 855 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 857 Weight: Weight used for load-balancing purposes. The use of the 858 weight is defined in [I-D.ietf-spring-segment-routing]. 860 Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- 861 SID is advertised. 863 SID/Index/Label: According to the V and L flags, it contains 864 either: 866 A 32-bit index defining the offset in the SID/Label space 867 advertised by this router. 869 A 24-bit label where the 20 rightmost bits are used for 870 encoding the label value. 872 When the P-flag is not set, the Adj-SID MAY be persistent. When 873 the P-flag is set, the Adj-SID MUST be persistent. 875 7. Elements of Procedure 876 7.1. Intra-area Segment routing in OSPFv2 878 An OSPFv2 router that supports segment routing MAY advertise Prefix- 879 SIDs for any prefix to which it is advertising reachability (e.g., a 880 loopback IP address as described in Section 5). 882 A Prefix-SID can also be advertised by the SR Mapping Servers (as 883 described in [I-D.ietf-spring-segment-routing-ldp-interop]). A 884 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 885 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 886 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 887 MUST be advertised by all of them. The flooding scope of the OSPF 888 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 889 could be either area-scoped or AS-scoped and is determined based on 890 the configuration of the SR Mapping Server. 892 An SR Mapping Server MUST use the OSPF Extended Prefix Range TLV when 893 advertising SIDs for prefixes. Prefixes of different route-types can 894 be combined in a single OSPF Extended Prefix Range TLV advertised by 895 an SR Mapping Server. Because the OSPF Extended Prefix Range TLV 896 doesn't include a Route-Type field, as in the OSPF Extended Prefix 897 TLV, it is possible to include adjacent prefixes from different 898 Route-Types in the OSPF Extended Prefix Range TLV. 900 Area-scoped OSPF Extended Prefix Range TLVs are propagated between 901 areas. Similar to propagation of prefixes between areas, an ABR only 902 propagates the OSPF Extended Prefix Range TLV that it considers to be 903 the best from the set it received. The rules used to pick the best 904 OSPF Extended Prefix Range TLV are described in Section 4. 906 When propagating an OSPF Extended Prefix Range TLV between areas, 907 ABRs MUST set the IA-Flag, that is used to prevent redundant flooding 908 of the OSPF Extended Prefix Range TLV between areas as described in 909 Section 4. 911 7.2. Inter-area Segment routing in OSPFv2 913 In order to support SR in a multi-area environment, OSPFv2 MUST 914 propagate Prefix-SID information between areas. The following 915 procedure is used to propagate Prefix SIDs between areas. 917 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 918 prefix to all its connected areas, it will also originate an Extended 919 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 920 the Extended Prefix Opaque LSA type will be set to area-local scope. 921 The route-type in the OSPF Extended Prefix TLV is set to inter-area. 922 The Prefix-SID Sub-TLV will be included in this LSA and the Prefix- 923 SID value will be set as follows: 925 The ABR will look at its best path to the prefix in the source 926 area and find the advertising router associated with the best path 927 to that prefix. 929 The ABR will then determine if such router advertised a Prefix-SID 930 for the prefix and use it when advertising the Prefix-SID to other 931 connected areas. 933 If no Prefix-SID was advertised for the prefix in the source area 934 by the router that contributes to the best path to the prefix, the 935 originating ABR will use the Prefix-SID advertised by any other 936 router when propagating the Prefix-SID for the prefix to other 937 areas. 939 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 940 route to all its connected areas, it will also originate an Extended 941 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 942 the Extended Prefix Opaque LSA type will be set to area-local scope. 943 The route-type in OSPF Extended Prefix TLV is set to inter-area. The 944 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 945 will be set as follows: 947 The ABR will look at its best path to the prefix in the backbone 948 area and find the advertising router associated with the best path 949 to that prefix. 951 The ABR will then determine if such router advertised a Prefix-SID 952 for the prefix and use it when advertising the Prefix-SID to other 953 connected areas. 955 If no Prefix-SID was advertised for the prefix in the backbone 956 area by the ABR that contributes to the best path to the prefix, 957 the originating ABR will use the Prefix-SID advertised by any 958 other router when propagating the Prefix-SID for the prefix to 959 other areas. 961 7.3. Segment Routing for External Prefixes 963 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 964 SR, generates Type-5 LSAs, it SHOULD also originate Extended Prefix 965 Opaque LSAs, as described in [RFC7684]. The flooding scope of the 966 Extended Prefix Opaque LSA type is set to AS-wide scope. The route- 967 type in the OSPF Extended Prefix TLV is set to external. The Prefix- 968 SID Sub-TLV is included in this LSA and the Prefix-SID value will be 969 set to the SID that has been reserved for that prefix. 971 When an NSSA [RFC3101] ABR translates Type-7 LSAs into Type-5 LSAs, 972 it SHOULD also advertise the Prefix-SID for the prefix. The NSSA ABR 973 determines its best path to the prefix advertised in the translated 974 Type-7 LSA and finds the advertising router associated with that 975 path. If the advertising router has advertised a Prefix-SID for the 976 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 977 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 978 router will be used. 980 7.4. Advertisement of Adj-SID 982 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 983 using the Adj-SID Sub-TLV as described in Section 6. 985 7.4.1. Advertisement of Adj-SID on Point-to-Point Links 987 An Adj-SID MAY be advertised for any adjacency on a P2P link that is 988 in neighbor state 2-Way or higher. If the adjacency on a P2P link 989 transitions from the FULL state, then the Adj-SID for that adjacency 990 MAY be removed from the area. If the adjacency transitions to a 991 state lower then 2-Way, then the Adj-SID advertisement MUST be 992 withdrawn from the area. 994 7.4.2. Adjacency SID on Broadcast or NBMA Interfaces 996 Broadcast, NBMA, or hybrid [RFC6845] networks in OSPF are represented 997 by a star topology where the Designated Router (DR) is the central 998 point to which all other routers on the broadcast, NBMA, or hybrid 999 network connect. As a result, routers on the broadcast, NBMA, or 1000 hybrid network advertise only their adjacency to the DR. Routers 1001 that do not act as DR do not form or advertise adjacencies with each 1002 other. They do, however, maintain 2-Way adjacency state with each 1003 other and are directly reachable. 1005 When Segment Routing is used, each router on the broadcast, NBMA, or 1006 hybrid network MAY advertise the Adj-SID for its adjacency to the DR 1007 using the Adj-SID Sub-TLV as described in Section 6.1. 1009 SR capable routers MAY also advertise a LAN-Adj-SID for other 1010 neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid 1011 network using the LAN-ADJ-SID Sub-TLV as described in Section 6.2. 1013 8. IANA Considerations 1015 This specification updates several existing OSPF registries. 1017 8.1. OSPF Router Information (RI) TLVs Registry 1019 o 8 (IANA Preallocated) - SR-Algorithm TLV 1021 o 9 (IANA Preallocated) - SID/Label Range TLV 1023 o 14 - SR Local Block TLV 1025 o 15 - SRMS Preference TLV 1027 8.2. OSPFv2 Extended Prefix Opaque LSA TLVs Registry 1029 Following values are allocated: 1031 o 2 - OSPF Extended Prefix Range TLV 1033 8.3. OSPFv2 Extended Prefix TLV Sub-TLVs Registry 1035 Following values are allocated: 1037 o 1 - SID/Label Sub-TLV 1039 o 2 - Prefix SID Sub-TLV 1041 8.4. OSPFv2 Extended Link TLV Sub-TLVs Registry 1043 Following initial values are allocated: 1045 o 1 - SID/Label Sub-TLV 1047 o 2 - Adj-SID Sub-TLV 1049 o 3 - LAN Adj-SID/Label Sub-TLV 1051 8.5. IGP Algorithm Type Registry 1053 IANA is requested to set up a registry called "IGP Algorithm Type" 1054 under a new category of "Interior Gateway Protocol (IGP) Parameters" 1055 IANA registries. The registration policy for this registry is 1056 "Standards Action" ([RFC8126] and [RFC7120]). 1058 Values in this registry come from the range 0-255. 1060 The initial values in the IGP Algorithm Type registry are: 1062 0: Shortest Path First (SPF) algorithm based on link metric. This 1063 is the standard shortest path algorithm as computed by the IGP 1064 protocol. Consistent with the deployed practice for link-state 1065 protocols, Algorithm 0 permits any node to overwrite the SPF path 1066 with a different path based on its local policy. 1068 1: Strict Shortest Path First (SPF) algorithm based on link 1069 metric. The algorithm is identical to Algorithm 0 but Algorithm 1 1070 requires that all nodes along the path will honor the SPF routing 1071 decision. Local policy at the node claiming support for Algorithm 1072 1 MUST NOT alter the SPF paths computed by Algorithm 1. 1074 9. Implementation Status 1076 An implementation survey with seven questions related to the 1077 implementer's support of OSPFv2 Segment Routing was sent to the OSPF 1078 WG list and several known implementers. This section contains 1079 responses from three implementers who completed the survey. No 1080 external means were used to verify the accuracy of the information 1081 submitted by the respondents. The respondents are considered experts 1082 on the products they reported on. Additionally, responses were 1083 omitted from implementers who indicated that they have not 1084 implemented the function yet. 1086 This section will be removed before publication as an RFC. 1088 Responses from Nokia (former Alcatel-Lucent): 1090 Link to a web page describing the implementation: 1091 https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/ 1092 3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Un 1093 icast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf 1095 The implementation's level of maturity: Production. 1097 Coverage: We have implemented all sections and have support for the 1098 latest draft. 1100 Licensing: Part of the software package that needs to be purchased. 1102 Implementation experience: Great spec. We also performed inter- 1103 operability testing with Cisco's OSPF Segment Routing implementation. 1105 Contact information: wim.henderickx@nokia.com 1107 Responses from Cisco Systems: 1109 Link to a web page describing the implementation: 1111 http://www.segment-routing.net/home/tutorial 1112 The implementation's level of maturity: Production. 1114 Coverage: All sections have been implemented according to the latest 1115 draft. 1117 Licensing: Part of a commercial software package. 1119 Implementation experience: Many aspects of the draft are result of 1120 the actual implementation experience, as the draft evolved from its 1121 initial version to the current one. Interoperability testing with 1122 Alcatel-Lucent was performed, which confirmed the draft's ability to 1123 serve as a reference for the implementors. 1125 Contact information: ppsenak@cisco.com 1127 Responses from Juniper: 1129 The implementation's name and/or a link to a web page describing the 1130 implementation: 1132 Feature name is OSPF SPRING 1134 The implementation's level of maturity: To be released in 16.2 1135 (second half of 2016) 1137 Coverage: All sections implemented except Sections 4, and 6. 1139 Licensing: JUNOS Licensing needed. 1141 Implementation experience: NA 1143 Contact information: shraddha@juniper.net 1145 10. Security Considerations 1147 With the OSPFv2 segment routing extensions defined herein, OSPFv2 1148 will now program the MPLS data plane [RFC3031] in addition to the IP 1149 data plane. Previously, LDP [RFC5036] or another label distribution 1150 mechanism was required to advertise MPLS labels and program the MPLS 1151 data plane. 1153 In general, the same types of attacks that can be carried out on the 1154 IP control plane can be carried out on the MPLS control plane 1155 resulting in traffic being misrouted in the respective data planes. 1156 However, the latter can be more difficult to detect and isolate. 1158 Existing security extensions as described in [RFC2328] and [RFC7684] 1159 apply to these segment routing extensions. While OSPF is under a 1160 single administrative domain, there can be deployments where 1161 potential attackers have access to one or more networks in the OSPF 1162 routing domain. In these deployments, stronger authentication 1163 mechanisms such as those specified in [RFC7474] SHOULD be used. 1165 Implementations MUST assure that malformed TLV and Sub-TLV defined in 1166 this document are detected and do not provide a vulnerability for 1167 attackers to crash the OSPFv2 router or routing process. Reception 1168 of malformed TLV or Sub-TLV SHOULD be counted and/or logged for 1169 further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be 1170 rate-limited to prevent a Denial of Service (DoS) attack (distributed 1171 or otherwise) from overloading the OSPF control plane. 1173 11. Contributors 1175 The following people gave a substantial contribution to the content 1176 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1177 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1178 Saku Ytti. 1180 12. Acknowledgements 1182 We would like to thank Anton Smirnov for his contribution. 1184 Thanks to Acee Lindem for the detail review of the draft, 1185 corrections, as well as discussion about details of the encoding. 1187 13. References 1189 13.1. Normative References 1191 [I-D.ietf-spring-segment-routing] 1192 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1193 Litkowski, S., and R. Shakir, "Segment Routing 1194 Architecture", draft-ietf-spring-segment-routing-15 (work 1195 in progress), January 2018. 1197 [I-D.ietf-spring-segment-routing-ldp-interop] 1198 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and 1199 S. Litkowski, "Segment Routing interworking with LDP", 1200 draft-ietf-spring-segment-routing-ldp-interop-15 (work in 1201 progress), September 2018. 1203 [I-D.ietf-spring-segment-routing-mpls] 1204 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1205 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1206 data plane", draft-ietf-spring-segment-routing-mpls-15 1207 (work in progress), October 2018. 1209 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1210 Requirement Levels", BCP 14, RFC 2119, 1211 DOI 10.17487/RFC2119, March 1997, 1212 . 1214 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1215 DOI 10.17487/RFC2328, April 1998, 1216 . 1218 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1219 RFC 3101, DOI 10.17487/RFC3101, January 2003, 1220 . 1222 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1223 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1224 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1225 . 1227 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 1228 and Point-to-Multipoint Interface Type", RFC 6845, 1229 DOI 10.17487/RFC6845, January 2013, 1230 . 1232 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 1233 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 1234 2014, . 1236 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1237 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1238 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1239 2015, . 1241 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1242 S. Shaffer, "Extensions to OSPF for Advertising Optional 1243 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1244 February 2016, . 1246 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1247 Writing an IANA Considerations Section in RFCs", BCP 26, 1248 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1249 . 1251 13.2. Informative References 1253 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1254 Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment 1255 Routing", draft-ietf-ospf-ospfv3-segment-routing- 1256 extensions-18 (work in progress), November 2018. 1258 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 1259 "Security Extension for OSPFv2 When Using Manual Key 1260 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 1261 . 1263 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1264 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1265 Packet Routing in Networking (SPRING) Problem Statement 1266 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1267 2016, . 1269 Authors' Addresses 1271 Peter Psenak (editor) 1272 Cisco Systems, Inc. 1273 Apollo Business Center 1274 Mlynske nivy 43 1275 Bratislava 821 09 1276 Slovakia 1278 Email: ppsenak@cisco.com 1280 Stefano Previdi (editor) 1281 Cisco Systems, Inc. 1282 Via Del Serafico, 200 1283 Rome 00142 1284 Italy 1286 Email: stefano@previdi.net 1288 Clarence Filsfils 1289 Cisco Systems, Inc. 1290 Brussels 1291 Belgium 1293 Email: cfilsfil@cisco.com 1295 Hannes Gredler 1296 RtBrick Inc. 1298 Email: hannes@rtbrick.com 1299 Rob Shakir 1300 Google, Inc. 1301 1600 Amphitheatre Parkway 1302 Mountain View, CA 94043 1303 US 1305 Email: robjs@google.com 1307 Wim Henderickx 1308 Nokia 1309 Copernicuslaan 50 1310 Antwerp 2018 1311 BE 1313 Email: wim.henderickx@nokia.com 1315 Jeff Tantsura 1316 Apstra, Inc. 1318 Email: jefftant.ietf@gmail.com