idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-27.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 (December 3, 2018) is 1964 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 1141, but not defined == Missing Reference: 'RFC5036' is mentioned on line 1142, 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: June 6, 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 December 3, 2018 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-27 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 June 6, 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 . . . . . . . . . . . . . . . . . . . . . 17 80 6.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 18 81 7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19 82 7.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 19 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 . . . . . . . 22 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: 633 V-flag is set to 0 and L-flag is set to 0: The SID/Index/Label 634 field is a 4 octet index defining the offset in the SID/Label 635 space advertised by this router 637 V-flag is set to 1 and L-flag is set to 1: The SID/Index/Label 638 field is a 3 octet local label where the 20 rightmost bits are 639 used for encoding the label value. 641 All other combinations of V-flag and L-flag are invalid and any 642 SID advertisement received with an invalid setting for V and L 643 flags MUST be ignored. 645 If an OSPF router advertises multiple Prefix-SIDs for the same 646 prefix, topology and algorithm, all of them MUST be ignored. 648 When calculating the outgoing label for the prefix, the router MUST 649 take into account, as described below, the E, NP and M flags 650 advertised by the next-hop router if that router advertised the SID 651 for the prefix. This MUST be done regardless of whether the next-hop 652 router contributes to the best path to the prefix. 654 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 655 Prefix-SIDs allocated to inter-area prefixes that are originated by 656 the ABR based on intra-area or inter-area reachability between areas, 657 unless the advertised prefix is directly attached to the ABR. 659 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 660 Prefix-SIDs allocated to redistributed prefixes, unless the 661 redistributed prefix is directly attached to the ASBR. 663 If the NP-Flag is not set, then any upstream neighbor of the Prefix- 664 SID originator MUST pop the Prefix-SID. This is equivalent to the 665 penultimate hop popping mechanism used in the MPLS dataplane. If the 666 NP-flag is not set, then the received E-flag is ignored. 668 If the NP-flag is set then: 670 If the E-flag is not set, then any upstream neighbor of the 671 Prefix-SID originator MUST keep the Prefix-SID on top of the 672 stack. This is useful when the originator of the Prefix-SID need 673 to stitch the incoming packet into a continuing MPLS LSP to the 674 final destination. This could occur at an Area Border Router 675 (prefix propagation from one area to another) or at an AS Boundary 676 Router (prefix propagation from one domain to another). 678 If the E-flag is set, then any upstream neighbor of the Prefix-SID 679 originator MUST replace the Prefix-SID with an Explicit-NULL 680 label. This is useful, e.g., when the originator of the Prefix- 681 SID is the final destination for the related prefix and the 682 originator wishes to receive the packet with the original EXP 683 bits. 685 When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at 686 reception. 688 As the Mapping Server does not specify the originator of a prefix 689 advertisement, it is not possible to determine PHP behavior solely 690 based on the Mapping Server advertisement. However, PHP behavior 691 SHOULD be done in following cases: 693 The Prefix is intra-area type and the downstream neighbor is the 694 originator of the prefix. 696 The Prefix is inter-area type and downstream neighbor is an ABR, 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 The Prefix is external type and downstream neighbor is an ASBR, 702 which is advertising prefix reachability and is also generating 703 the Extended Prefix TLV with the A-flag set for this prefix as 704 described in section 2.1 of [RFC7684]. 706 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 707 the value advertised in the Prefix SID Sub-TLV is interpreted as a 708 starting SID/Label value. 710 Example 1: If the following router addresses (loopback addresses) 711 need to be mapped into the corresponding Prefix SID indexes: 713 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 714 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 715 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 716 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 718 then the Prefix field in the Extended Prefix Range TLV would be set 719 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 720 set to 4, and the Index value in the Prefix-SID Sub-TLV would be set 721 to 1. 723 Example 2: If the following prefixes need to be mapped into the 724 corresponding Prefix-SID indexes: 726 192.0.2.0/30, Prefix-SID: Index 51 727 192.0.2.4/30, Prefix-SID: Index 52 728 192.0.2.8/30, Prefix-SID: Index 53 729 192.0.2.12/30, Prefix-SID: Index 54 730 192.0.2.16/30, Prefix-SID: Index 55 731 192.0.2.20/30, Prefix-SID: Index 56 732 192.0.2.24/30, Prefix-SID: Index 57 734 then the Prefix field in the Extended Prefix Range TLV would be set 735 to 192.0.2.0, Prefix Length would be set to 30, Range Size would be 736 7, and the Index value in the Prefix-SID Sub-TLV would be set to 51. 738 6. Adjacency Segment Identifier (Adj-SID) 740 An Adjacency Segment Identifier (Adj-SID) represents a router 741 adjacency in Segment Routing. 743 6.1. Adj-SID Sub-TLV 745 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 746 [RFC7684]. It MAY appear multiple times in the Extended Link TLV. 747 The Adj-SID Sub-TLV has the following format: 749 0 1 2 3 750 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 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Type | Length | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Flags | Reserved | MT-ID | Weight | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | SID/Label/Index (variable) | 757 +---------------------------------------------------------------+ 759 where: 761 Type: 2 763 Length: 7 or 8 octets, dependent on the V flag. 765 Flags: Single octet field containing the following flags: 767 0 1 2 3 4 5 6 7 768 +-+-+-+-+-+-+-+-+ 769 |B|V|L|G|P| | 770 +-+-+-+-+-+-+-+-+ 772 where: 774 B-Flag: Backup Flag. If set, the Adj-SID refers to an 775 adjacency that is eligible for protection (e.g., using IPFRR or 776 MPLS-FRR) as described in section 3.5 of 777 [I-D.ietf-spring-segment-routing]. 779 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 780 an absolute value. If not set, then the Adj-SID carries an 781 index. 783 The L-Flag: Local/Global Flag. If set, then the value/index 784 carried by the Adj-SID has local significance. If not set, 785 then the value/index carried by this Sub-TLV has global 786 significance. 788 The G-Flag: Group Flag. When set, the G-Flag indicates that 789 the Adj-SID refers to a group of adjacencies (and therefore MAY 790 be assigned to other adjacencies as well). 792 P-Flag. Persistent flag. When set, the P-Flag indicates that 793 the Adj-SID is persistently allocated, i.e., the Adj-SID value 794 remains consistent across router restart and/or interface flap. 796 Other bits: Reserved. These MUST be zero when sent and are 797 ignored when received. 799 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 800 on reception. 802 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 804 Weight: Weight used for load-balancing purposes. The use of the 805 weight is defined in [I-D.ietf-spring-segment-routing]. 807 SID/Index/Label: as described in Section 5. 809 An SR capable router MAY allocate an Adj-SID for each of its 810 adjacencies and set the B-Flag when the adjacency is eligible for 811 protection by an FRR mechanism (IP or MPLS) as described in section 812 3.5 of [I-D.ietf-spring-segment-routing]. 814 An SR capable router MAY allocate more than one Adj-SID to an 815 adjacency 817 An SR capable router MAY allocate the same Adj-SID to different 818 adjacencies 820 When the P-flag is not set, the Adj-SID MAY be persistent. When the 821 P-flag is set, the Adj-SID MUST be persistent. 823 6.2. LAN Adj-SID Sub-TLV 825 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 826 in [RFC7684]. It MAY appear multiple times in the Extended-Link TLV. 827 It is used to advertise a SID/Label for an adjacency to a non-DR 828 router on a broadcast, NBMA, or hybrid [RFC6845] network. 830 0 1 2 3 831 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 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Type | Length | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Flags | Reserved | MT-ID | Weight | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Neighbor ID | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | SID/Label/Index (variable) | 840 +---------------------------------------------------------------+ 842 where: 844 Type: 3 846 Length: 11 or 12 octets, dependent on V-flag. 848 Flags: same as in Section 6.1 850 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 851 on reception. 853 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 855 Weight: Weight used for load-balancing purposes. The use of the 856 weight is defined in [I-D.ietf-spring-segment-routing]. 858 Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- 859 SID is advertised. 861 SID/Index/Label: as described in Section 5. 863 When the P-flag is not set, the Adj-SID MAY be persistent. When 864 the P-flag is set, the Adj-SID MUST be persistent. 866 7. Elements of Procedure 868 7.1. Intra-area Segment routing in OSPFv2 870 An OSPFv2 router that supports segment routing MAY advertise Prefix- 871 SIDs for any prefix to which it is advertising reachability (e.g., a 872 loopback IP address as described in Section 5). 874 A Prefix-SID can also be advertised by the SR Mapping Servers (as 875 described in [I-D.ietf-spring-segment-routing-ldp-interop]). A 876 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 877 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 878 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 879 MUST be advertised by all of them. The flooding scope of the OSPF 880 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 881 could be either area-scoped or AS-scoped and is determined based on 882 the configuration of the SR Mapping Server. 884 An SR Mapping Server MUST use the OSPF Extended Prefix Range TLV when 885 advertising SIDs for prefixes. Prefixes of different route-types can 886 be combined in a single OSPF Extended Prefix Range TLV advertised by 887 an SR Mapping Server. Because the OSPF Extended Prefix Range TLV 888 doesn't include a Route-Type field, as in the OSPF Extended Prefix 889 TLV, it is possible to include adjacent prefixes from different 890 Route-Types in the OSPF Extended Prefix Range TLV. 892 Area-scoped OSPF Extended Prefix Range TLVs are propagated between 893 areas. Similar to propagation of prefixes between areas, an ABR only 894 propagates the OSPF Extended Prefix Range TLV that it considers to be 895 the best from the set it received. The rules used to pick the best 896 OSPF Extended Prefix Range TLV are described in Section 4. 898 When propagating an OSPF Extended Prefix Range TLV between areas, 899 ABRs MUST set the IA-Flag, that is used to prevent redundant flooding 900 of the OSPF Extended Prefix Range TLV between areas as described in 901 Section 4. 903 7.2. Inter-area Segment routing in OSPFv2 905 In order to support SR in a multi-area environment, OSPFv2 MUST 906 propagate Prefix-SID information between areas. The following 907 procedure is used to propagate Prefix SIDs between areas. 909 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 910 prefix to all its connected areas, it will also originate an Extended 911 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 912 the Extended Prefix Opaque LSA type will be set to area-local scope. 913 The route-type in the OSPF Extended Prefix TLV is set to inter-area. 914 The Prefix-SID Sub-TLV will be included in this LSA and the Prefix- 915 SID value will be set as follows: 917 The ABR will look at its best path to the prefix in the source 918 area and find the advertising router associated with the best path 919 to that prefix. 921 The ABR will then determine if such router advertised a Prefix-SID 922 for the prefix and use it when advertising the Prefix-SID to other 923 connected areas. 925 If no Prefix-SID was advertised for the prefix in the source area 926 by the router that contributes to the best path to the prefix, the 927 originating ABR will use the Prefix-SID advertised by any other 928 router when propagating the Prefix-SID for the prefix to other 929 areas. 931 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 932 route to all its connected areas, it will also originate an Extended 933 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 934 the Extended Prefix Opaque LSA type will be set to area-local scope. 935 The route-type in OSPF Extended Prefix TLV is set to inter-area. The 936 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 937 will be set as follows: 939 The ABR will look at its best path to the prefix in the backbone 940 area and find the advertising router associated with the best path 941 to that prefix. 943 The ABR will then determine if such router advertised a Prefix-SID 944 for the prefix and use it when advertising the Prefix-SID to other 945 connected areas. 947 If no Prefix-SID was advertised for the prefix in the backbone 948 area by the ABR that contributes to the best path to the prefix, 949 the originating ABR will use the Prefix-SID advertised by any 950 other router when propagating the Prefix-SID for the prefix to 951 other areas. 953 7.3. Segment Routing for External Prefixes 955 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 956 SR, generates Type-5 LSAs, it SHOULD also originate Extended Prefix 957 Opaque LSAs, as described in [RFC7684]. The flooding scope of the 958 Extended Prefix Opaque LSA type is set to AS-wide scope. The route- 959 type in the OSPF Extended Prefix TLV is set to external. The Prefix- 960 SID Sub-TLV is included in this LSA and the Prefix-SID value will be 961 set to the SID that has been reserved for that prefix. 963 When an NSSA [RFC3101] ABR translates Type-7 LSAs into Type-5 LSAs, 964 it SHOULD also advertise the Prefix-SID for the prefix. The NSSA ABR 965 determines its best path to the prefix advertised in the translated 966 Type-7 LSA and finds the advertising router associated with that 967 path. If the advertising router has advertised a Prefix-SID for the 968 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 969 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 970 router will be used. 972 7.4. Advertisement of Adj-SID 974 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 975 using the Adj-SID Sub-TLV as described in Section 6. 977 7.4.1. Advertisement of Adj-SID on Point-to-Point Links 979 An Adj-SID MAY be advertised for any adjacency on a P2P link that is 980 in neighbor state 2-Way or higher. If the adjacency on a P2P link 981 transitions from the FULL state, then the Adj-SID for that adjacency 982 MAY be removed from the area. If the adjacency transitions to a 983 state lower then 2-Way, then the Adj-SID advertisement MUST be 984 withdrawn from the area. 986 7.4.2. Adjacency SID on Broadcast or NBMA Interfaces 988 Broadcast, NBMA, or hybrid [RFC6845] networks in OSPF are represented 989 by a star topology where the Designated Router (DR) is the central 990 point to which all other routers on the broadcast, NBMA, or hybrid 991 network connect. As a result, routers on the broadcast, NBMA, or 992 hybrid network advertise only their adjacency to the DR. Routers 993 that do not act as DR do not form or advertise adjacencies with each 994 other. They do, however, maintain 2-Way adjacency state with each 995 other and are directly reachable. 997 When Segment Routing is used, each router on the broadcast, NBMA, or 998 hybrid network MAY advertise the Adj-SID for its adjacency to the DR 999 using the Adj-SID Sub-TLV as described in Section 6.1. 1001 SR capable routers MAY also advertise a LAN-Adj-SID for other 1002 neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid 1003 network using the LAN-ADJ-SID Sub-TLV as described in Section 6.2. 1005 8. IANA Considerations 1007 This specification updates several existing OSPF registries. 1009 8.1. OSPF Router Information (RI) TLVs Registry 1011 o 8 (IANA Preallocated) - SR-Algorithm TLV 1013 o 9 (IANA Preallocated) - SID/Label Range TLV 1015 o 14 - SR Local Block TLV 1017 o 15 - SRMS Preference TLV 1019 8.2. OSPFv2 Extended Prefix Opaque LSA TLVs Registry 1021 Following values are allocated: 1023 o 2 - OSPF Extended Prefix Range TLV 1025 8.3. OSPFv2 Extended Prefix TLV Sub-TLVs Registry 1027 Following values are allocated: 1029 o 1 - SID/Label Sub-TLV 1031 o 2 - Prefix SID Sub-TLV 1033 8.4. OSPFv2 Extended Link TLV Sub-TLVs Registry 1035 Following initial values are allocated: 1037 o 1 - SID/Label Sub-TLV 1039 o 2 - Adj-SID Sub-TLV 1041 o 3 - LAN Adj-SID/Label Sub-TLV 1043 8.5. IGP Algorithm Type Registry 1045 IANA is requested to set up a registry called "IGP Algorithm Type" 1046 under a new category of "Interior Gateway Protocol (IGP) Parameters" 1047 IANA registries. The registration policy for this registry is 1048 "Standards Action" ([RFC8126] and [RFC7120]). 1050 Values in this registry come from the range 0-255. 1052 The initial values in the IGP Algorithm Type registry are: 1054 0: Shortest Path First (SPF) algorithm based on link metric. This 1055 is the standard shortest path algorithm as computed by the IGP 1056 protocol. Consistent with the deployed practice for link-state 1057 protocols, Algorithm 0 permits any node to overwrite the SPF path 1058 with a different path based on its local policy. 1060 1: Strict Shortest Path First (SPF) algorithm based on link 1061 metric. The algorithm is identical to Algorithm 0 but Algorithm 1 1062 requires that all nodes along the path will honor the SPF routing 1063 decision. Local policy at the node claiming support for Algorithm 1064 1 MUST NOT alter the SPF paths computed by Algorithm 1. 1066 9. Implementation Status 1068 An implementation survey with seven questions related to the 1069 implementer's support of OSPFv2 Segment Routing was sent to the OSPF 1070 WG list and several known implementers. This section contains 1071 responses from three implementers who completed the survey. No 1072 external means were used to verify the accuracy of the information 1073 submitted by the respondents. The respondents are considered experts 1074 on the products they reported on. Additionally, responses were 1075 omitted from implementers who indicated that they have not 1076 implemented the function yet. 1078 This section will be removed before publication as an RFC. 1080 Responses from Nokia (former Alcatel-Lucent): 1082 Link to a web page describing the implementation: 1083 https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/ 1084 3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Un 1085 icast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf 1087 The implementation's level of maturity: Production. 1089 Coverage: We have implemented all sections and have support for the 1090 latest draft. 1092 Licensing: Part of the software package that needs to be purchased. 1094 Implementation experience: Great spec. We also performed inter- 1095 operability testing with Cisco's OSPF Segment Routing implementation. 1097 Contact information: wim.henderickx@nokia.com 1099 Responses from Cisco Systems: 1101 Link to a web page describing the implementation: 1103 http://www.segment-routing.net/home/tutorial 1105 The implementation's level of maturity: Production. 1107 Coverage: All sections have been implemented according to the latest 1108 draft. 1110 Licensing: Part of a commercial software package. 1112 Implementation experience: Many aspects of the draft are result of 1113 the actual implementation experience, as the draft evolved from its 1114 initial version to the current one. Interoperability testing with 1115 Alcatel-Lucent was performed, which confirmed the draft's ability to 1116 serve as a reference for the implementors. 1118 Contact information: ppsenak@cisco.com 1120 Responses from Juniper: 1122 The implementation's name and/or a link to a web page describing the 1123 implementation: 1125 Feature name is OSPF SPRING 1127 The implementation's level of maturity: To be released in 16.2 1128 (second half of 2016) 1130 Coverage: All sections implemented except Sections 4, and 6. 1132 Licensing: JUNOS Licensing needed. 1134 Implementation experience: NA 1136 Contact information: shraddha@juniper.net 1138 10. Security Considerations 1140 With the OSPFv2 segment routing extensions defined herein, OSPFv2 1141 will now program the MPLS data plane [RFC3031] in addition to the IP 1142 data plane. Previously, LDP [RFC5036] or another label distribution 1143 mechanism was required to advertise MPLS labels and program the MPLS 1144 data plane. 1146 In general, the same types of attacks that can be carried out on the 1147 IP control plane can be carried out on the MPLS control plane 1148 resulting in traffic being misrouted in the respective data planes. 1149 However, the latter can be more difficult to detect and isolate. 1151 Existing security extensions as described in [RFC2328] and [RFC7684] 1152 apply to these segment routing extensions. While OSPF is under a 1153 single administrative domain, there can be deployments where 1154 potential attackers have access to one or more networks in the OSPF 1155 routing domain. In these deployments, stronger authentication 1156 mechanisms such as those specified in [RFC7474] SHOULD be used. 1158 Implementations MUST assure that malformed TLV and Sub-TLV defined in 1159 this document are detected and do not provide a vulnerability for 1160 attackers to crash the OSPFv2 router or routing process. Reception 1161 of malformed TLV or Sub-TLV SHOULD be counted and/or logged for 1162 further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be 1163 rate-limited to prevent a Denial of Service (DoS) attack (distributed 1164 or otherwise) from overloading the OSPF control plane. 1166 11. Contributors 1168 The following people gave a substantial contribution to the content 1169 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1170 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1171 Saku Ytti. 1173 12. Acknowledgements 1175 We would like to thank Anton Smirnov for his contribution. 1177 Thanks to Acee Lindem for the detail review of the draft, 1178 corrections, as well as discussion about details of the encoding. 1180 13. References 1182 13.1. Normative References 1184 [I-D.ietf-spring-segment-routing] 1185 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1186 Litkowski, S., and R. Shakir, "Segment Routing 1187 Architecture", draft-ietf-spring-segment-routing-15 (work 1188 in progress), January 2018. 1190 [I-D.ietf-spring-segment-routing-ldp-interop] 1191 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and 1192 S. Litkowski, "Segment Routing interworking with LDP", 1193 draft-ietf-spring-segment-routing-ldp-interop-15 (work in 1194 progress), September 2018. 1196 [I-D.ietf-spring-segment-routing-mpls] 1197 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1198 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1199 data plane", draft-ietf-spring-segment-routing-mpls-15 1200 (work in progress), October 2018. 1202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1203 Requirement Levels", BCP 14, RFC 2119, 1204 DOI 10.17487/RFC2119, March 1997, 1205 . 1207 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1208 DOI 10.17487/RFC2328, April 1998, 1209 . 1211 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1212 RFC 3101, DOI 10.17487/RFC3101, January 2003, 1213 . 1215 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1216 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1217 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1218 . 1220 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 1221 and Point-to-Multipoint Interface Type", RFC 6845, 1222 DOI 10.17487/RFC6845, January 2013, 1223 . 1225 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 1226 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 1227 2014, . 1229 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1230 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1231 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1232 2015, . 1234 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1235 S. Shaffer, "Extensions to OSPF for Advertising Optional 1236 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1237 February 2016, . 1239 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1240 Writing an IANA Considerations Section in RFCs", BCP 26, 1241 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1242 . 1244 13.2. Informative References 1246 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1247 Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment 1248 Routing", draft-ietf-ospf-ospfv3-segment-routing- 1249 extensions-18 (work in progress), November 2018. 1251 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 1252 "Security Extension for OSPFv2 When Using Manual Key 1253 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 1254 . 1256 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1257 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1258 Packet Routing in Networking (SPRING) Problem Statement 1259 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1260 2016, . 1262 Authors' Addresses 1264 Peter Psenak (editor) 1265 Cisco Systems, Inc. 1266 Apollo Business Center 1267 Mlynske nivy 43 1268 Bratislava 821 09 1269 Slovakia 1271 Email: ppsenak@cisco.com 1273 Stefano Previdi (editor) 1274 Cisco Systems, Inc. 1275 Via Del Serafico, 200 1276 Rome 00142 1277 Italy 1279 Email: stefano@previdi.net 1281 Clarence Filsfils 1282 Cisco Systems, Inc. 1283 Brussels 1284 Belgium 1286 Email: cfilsfil@cisco.com 1288 Hannes Gredler 1289 RtBrick Inc. 1291 Email: hannes@rtbrick.com 1293 Rob Shakir 1294 Google, Inc. 1295 1600 Amphitheatre Parkway 1296 Mountain View, CA 94043 1297 US 1299 Email: robjs@google.com 1300 Wim Henderickx 1301 Nokia 1302 Copernicuslaan 50 1303 Antwerp 2018 1304 BE 1306 Email: wim.henderickx@nokia.com 1308 Jeff Tantsura 1309 Apstra, Inc. 1311 Email: jefftant.ietf@gmail.com