idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-24.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 14, 2017) is 2297 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 326 -- Looks like a reference, but probably isn't: '199' on line 326 -- Looks like a reference, but probably isn't: '1000' on line 327 -- Looks like a reference, but probably isn't: '1099' on line 327 -- Looks like a reference, but probably isn't: '500' on line 328 -- Looks like a reference, but probably isn't: '599' on line 328 == Missing Reference: 'RFC3031' is mentioned on line 1146, but not defined == Missing Reference: 'RFC5036' is mentioned on line 1147, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-13 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-11 Summary: 0 errors (**), 0 flaws (~~), 6 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 17, 2018 Cisco Systems, Inc. 6 H. Gredler 7 RtBrick Inc. 8 R. Shakir 9 Google, Inc. 10 W. Henderickx 11 Nokia 12 J. Tantsura 13 Individual 14 December 14, 2017 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-24 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 17, 2018. 51 Copyright Notice 53 Copyright (c) 2017 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]). 177 3.1. SR-Algorithm TLV 179 The SR-Algorithm TLV is a top-level TLV of the Router Information 180 Opaque LSA (defined in [RFC7770]). 182 The SR-Algorithm TLV is optional. It SHOULD only be advertised once 183 in the Router Information Opaque LSA. If the SR-Algorithm TLV is not 184 advertised by the node, such node is considered as not being segment 185 routing capable. 187 An SR Router can use various algorithms when calculating reachability 188 to OSPF routers or prefixes in an OSPF area. Examples of these 189 algorithms are metric based Shortest Path First (SPF), various 190 flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a 191 router to advertise the algorithms currently used by the router to 192 other routers in an OSPF area. The SR-Algorithm TLV has following 193 format: 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Type | Length | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Algorithm 1 | Algorithm... | Algorithm n | | 201 +- -+ 202 | | 203 + + 205 where: 207 Type: 8 209 Variable, in octets, dependent on number of algorithms advertised. 211 Algorithm: Single octet identifying the algorithm. The following 212 values are defined by this document: 214 0: Shortest Path First (SPF) algorithm based on link metric. 215 This is the standard shortest path algorithm as computed by the 216 OSPF protocol. Consistent with the deployed practice for link- 217 state protocols, Algorithm 0 permits any node to overwrite the 218 SPF path with a different path based on its local policy. If 219 the SR-Algorithm TLV is advertised, Algorithm 0 MUST be 220 included. 222 1: Strict Shortest Path First (SPF) algorithm based on link 223 metric. The algorithm is identical to Algorithm 0 but 224 Algorithm 1 requires that all nodes along the path will honor 225 the SPF routing decision. Local policy at the node claiming 226 support for Algorithm 1 MUST NOT alter the SPF paths computed 227 by Algorithm 1. 229 When multiple SR-Algorithm TLVs are received from a given router, the 230 receiver MUST use the first occurrence of the TLV in the Router 231 Information LSA. If the SR-Algorithm TLV appears in multiple Router 232 Information LSAs that have different flooding scopes, the SR- 233 Algorithm TLV in the Router Information LSA with the area-scoped 234 flooding scope MUST be used. If the SR-Algorithm TLV appears in 235 multiple Router Information LSAs that have the same flooding scope, 236 the SR-Algorithm TLV in the Router Information (RI) LSA with the 237 numerically smallest Instance ID MUST be used and subsequent 238 instances of the SR-Algorithm TLV MUST be ignored. 240 The RI LSA can be advertised at any of the defined opaque flooding 241 scopes (link, area, or Autonomous System (AS)). For the purpose of 242 SR-Algorithm TLV advertisement, area-scoped flooding is REQUIRED. 244 3.2. SID/Label Range TLV 246 Prefix SIDs MAY be advertised in a form of an index as described in 247 Section 5. Such index defines the offset in the SID/Label space 248 advertised by the router. The SID/Label Range TLV is used to 249 advertise such SID/Label space. 251 The SID/Label Range TLV is a top-level TLV of the Router Information 252 Opaque LSA (defined in [RFC7770]). 254 The SID/Label Range TLV MAY appear multiple times and has the 255 following format: 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type | Length | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Range Size | Reserved | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Sub-TLVs (variable) | 265 +- -+ 266 | | 267 + + 269 where: 271 Type: 9 273 Length: Variable, in octets, dependent on Sub-TLVs. 275 Range Size: 3-octet SID/label range size (i.e., the number of SIDs 276 or labels in the range including the first SID/label). It MUST be 277 greater than 0. 279 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 280 on reception. 282 Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as 283 defined in Section 2.1. The SID/Label Sub-TLV MUST be included in 284 the SID/Label Range TLV. The SID/Label advertised in the SID/Label 285 Sub-TLV represents the first SID/Label in the advertised range. 287 Only a single SID/Label Sub-TLV MAY be advertised in SID/Label Range 288 TLV. If more then one SID/Label Sub-TLVs are present, the SID/Label 289 Range TLV MUST be ignored. 291 Multiple occurrences of the SID/Label Range TLV MAY be advertised, in 292 order to advertise multiple ranges. In such case: 294 o The originating router MUST encode each range into a different 295 SID/Label Range TLV. 297 o The originating router decides the order in which the set of SID/ 298 Label Range TLVs are advertised inside the Router Information 299 Opaque LSA. The originating router MUST ensure the order is the 300 same after a graceful restart (using checkpointing, non-volatile 301 storage, or any other mechanism) in order to assure the SID/label 302 range and SID index correspondence is preserved across graceful 303 restarts. 305 o The receiving router MUST adhere to the order in which the ranges 306 are advertised when calculating a SID/label from a SID index. 308 o The originating router MUST NOT advertise overlapping ranges. 310 o When a router receives multiple overlapping ranges, it MUST 311 conform to the procedures defined in 312 [I-D.ietf-spring-conflict-resolution]. 314 The following example illustrates the advertisement of multiple 315 ranges: 317 The originating router advertises the following ranges: 319 Range 1: Range Size: 100 SID/Label Sub-TLV: 100 320 Range 1: Range Size: 100 SID/Label Sub-TLV: 1000 321 Range 1: Range Size: 100 SID/Label Sub-TLV: 500 323 The receiving routers concatenate the ranges and build the Segment 324 Routing Global Block (SRGB) as follows: 326 SRGB = [100, 199] 327 [1000, 1099] 328 [500, 599] 330 The indexes span multiple ranges: 332 index=0 means label 100 333 ... 334 index 99 means label 199 335 index 100 means label 1000 336 index 199 means label 1099 337 ... 338 index 200 means label 500 339 ... 341 The RI LSA can be advertised at any of the defined flooding scopes 342 (link, area, or autonomous system (AS)). For the purpose of SID/ 343 Label Range TLV advertisement, area-scoped flooding is REQUIRED. 345 3.3. SR Local Block TLV 347 The SR Local Block TLV (SRLB TLV) contains the range of labels the 348 node has reserved for local SIDs. SIDs from the SRLB MAY be used for 349 Adjacency-SIDs, but also by components other than the OSPF protocol. 350 As an example, an application or a controller can instruct the router 351 to allocate a specific local SID. Some controllers or applications 352 can use the control plane to discover the available set of local SIDs 353 on a particular router. In such cases, the SRLB is advertised in the 354 control plane. The requirement to advertise the SRLB is further 355 described in [I-D.ietf-spring-segment-routing-mpls]. The SRLB TLV is 356 used to advertise the SRLB. 358 The SRLB TLV is a top-level TLV of the Router Information Opaque LSA 359 (defined in [RFC7770]). 361 The SRLB TLV MAY appear multiple times in the Router Information 362 Opaque LSA and has the following format: 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type | Length | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Range Size | Reserved | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Sub-TLVs (variable) | 372 +- -+ 373 | | 374 + + 376 where: 378 Type: 14 380 Length: Variable, in octets, dependent on Sub-TLVs. 382 Range Size: 3-octet SID/label range size (i.e., the number of SIDs 383 or labels in the range including the first SID/label). It MUST be 384 greater than 0. 386 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 387 on reception. 389 Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as 390 defined in Section 2.1. The SID/Label Sub-TLV MUST be included in 391 the SRLB TLV. The SID/Label advertised in the SID/Label Sub-TLV 392 represents the first SID/Label in the advertised range. 394 Only a single SID/Label Sub-TLV MAY be advertised in the SRLB TLV. 395 If more then one SID/Label Sub-TLVs are present, the SRLB TLV MUST be 396 ignored. 398 The originating router MUST NOT advertise overlapping ranges. 400 Each time a SID from the SRLB is allocated, it SHOULD also be 401 reported to all components (e.g., controller or applications) in 402 order for these components to have an up-to-date view of the current 403 SRLB allocation. This is required to avoid collisions between 404 allocation instructions. 406 Within the context of OSPF, the reporting of local SIDs is done 407 through OSPF Sub-TLVs such as the Adjacency-SID (Section 6). 408 However, the reporting of allocated local SIDs can also be done 409 through other means and protocols which are outside the scope of this 410 document. 412 A router advertising the SRLB TLV MAY also have other label ranges, 413 outside of the SRLB, used for its local allocation purposes which are 414 not advertised in the SRLB TLV. For example, it is possible that an 415 Adjacency-SID is allocated using a local label that is not part of 416 the SRLB. 418 The RI LSA can be advertised at any of the defined flooding scopes 419 (link, area, or autonomous system (AS)). For the purpose of SRLB TLV 420 advertisement, area-scoped flooding is REQUIRED. 422 3.4. SRMS Preference TLV 424 The Segment Routing Mapping Server Preference TLV (SRMS Preference 425 TLV) is used to advertise a preference associated with the node that 426 acts as an SR Mapping Server. The role of an SRMS is described in 427 [I-D.ietf-spring-segment-routing-ldp-interop]. SRMS preference is 428 defined in [I-D.ietf-spring-conflict-resolution]. 430 The SRMS Preference TLV is a top-level TLV of the Router Information 431 Opaque LSA (defined in [RFC7770]). 433 The SRMS Preference TLV MAY only be advertised once in the Router 434 Information Opaque LSA and has the following format: 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type | Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Preference | Reserved | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 where: 446 Type: 15 448 Length: 4 octets 450 Preference: 1 octet. SRMS preference value from 0 to 255. 452 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 453 on reception. 455 When multiple SRMS Preference TLVs are received from a given router, 456 the receiver MUST use the first occurrence of the TLV in the Router 457 Information LSA. If the SRMS Preference TLV appears in multiple 458 Router Information LSAs that have different flooding scopes, the SRMS 459 Preference TLV in the Router Information LSA with the narrowest 460 flooding scope MUST be used. If the SRMS Preference TLV appears in 461 multiple Router Information LSAs that have the same flooding scope, 462 the SRMS Preference TLV in the Router Information LSA with the 463 numerically smallest Instance ID MUST be used and subsequent 464 instances of the SRMS Preference TLV MUST be ignored. 466 The RI LSA can be advertised at any of the defined flooding scopes 467 (link, area, or autonomous system (AS)). For the purpose of the SRMS 468 Preference TLV advertisement, AS-scoped flooding SHOULD be used. 469 This is because SRMS servers can be located in a different area then 470 consumers of the SRMS advertisements. If the SRMS advertisements 471 from the SRMS server are only used inside the SRMS server's area, 472 area-scoped flooding MAY be used. 474 4. OSPF Extended Prefix Range TLV 476 In some cases it is useful to advertise attributes for a range of 477 prefixes. The Segment Routing Mapping Server, which is described in 478 [I-D.ietf-spring-segment-routing-ldp-interop], is an example where we 479 need a single advertisement to advertise SIDs for multiple prefixes 480 from a contiguous address range. 482 The OSPF Extended Prefix Range TLV, which is a top level TLV of the 483 Extended Prefix LSA described in [RFC7684] is defined for this 484 purpose. 486 Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each 487 OSPF Extended Prefix Opaque LSA, but all prefix ranges included in a 488 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 489 scope. The OSPF Extended Prefix Range TLV has the following format: 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type | Length | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Prefix Length | AF | Range Size | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Flags | Reserved | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Address Prefix (variable) | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Sub-TLVs (variable) | 503 +- -+ 504 | | 506 where: 508 Type: 2 510 Length: Variable, in octets, dependent on Sub-TLVs. 512 Prefix length: Length of prefix in bits. 514 AF: Address family for the prefix. Currently, the only supported 515 value is 0 for IPv4 unicast. The inclusion of address family in 516 this TLV allows for future extension. 518 Range size: Represents the number of prefixes that are covered by 519 the advertisement. The Range Size MUST NOT exceed the number of 520 prefixes that could be satisfied by the prefix length without 521 including the IPv4 multicast address range (224.0.0.0/3). 523 Flags: Single octet field. The following flags are defined: 525 0 1 2 3 4 5 6 7 526 +--+--+--+--+--+--+--+--+ 527 |IA| | | | | | | | 528 +--+--+--+--+--+--+--+--+ 530 where: 532 IA-Flag: Inter-Area flag. If set, advertisement is of inter- 533 area type. An ABR that is advertising the OSPF Extended Prefix 534 Range TLV between areas MUST set this bit. 536 This bit is used to prevent redundant flooding of Prefix Range 537 TLVs between areas as follows: 539 An ABR only propagates an inter-area Prefix Range 540 advertisement from the backbone area to connected non- 541 backbone areas if the advertisement is considered to be the 542 best one. The following rules are used to select the best 543 range from the set of advertisements for the same Prefix 544 Range: 546 An ABR always prefers intra-area Prefix Range 547 advertisements over inter-area advertisements. 549 An ABR does not consider inter-area Prefix Range 550 advertisements coming from non-backbone areas. 552 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 553 on reception. 555 Address Prefix: For the address family IPv4 unicast, the prefix 556 itself is encoded as a 32-bit value. The default route is 557 represented by a prefix of length 0. Prefix encoding for other 558 address families is beyond the scope of this specification. 560 5. Prefix SID Sub-TLV 562 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV 563 described in [RFC7684] and the OSPF Extended Prefix Range TLV 564 described in Section 4. It MAY appear more than once in the parent 565 TLV and has the following format: 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Type | Length | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Flags | Reserved | MT-ID | Algorithm | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | SID/Index/Label (variable) | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 where: 579 Type: 2 581 Length: 7 or 8 octets, dependent on the V-flag 583 Flags: Single octet field. The following flags are defined: 585 0 1 2 3 4 5 6 7 586 +--+--+--+--+--+--+--+--+ 587 | |NP|M |E |V |L | | | 588 +--+--+--+--+--+--+--+--+ 590 where: 592 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 593 NOT pop the Prefix-SID before delivering packets to the node 594 that advertised the Prefix-SID. 596 M-Flag: Mapping Server Flag. If set, the SID was advertised by 597 a Segment Routing Mapping Server as described in 598 [I-D.ietf-spring-segment-routing-ldp-interop]. 600 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 601 the Prefix-SID originator MUST replace the Prefix-SID with the 602 Explicit-NULL label (0 for IPv4) before forwarding the packet. 604 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 605 an absolute value. If not set, then the Prefix-SID carries an 606 index. 608 L-Flag: Local/Global Flag. If set, then the value/index 609 carried by the Prefix-SID has local significance. If not set, 610 then the value/index carried by this Sub-TLV has global 611 significance. 613 Other bits: Reserved. These MUST be zero when sent and are 614 ignored when received. 616 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 617 on reception. 619 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 621 Algorithm: Single octet identifying the algorithm the Prefix-SID 622 is associated with as defined in Section 3.1. 624 A router receiving a Prefix-SID from a remote node and with an 625 algorithm value that such remote node has not advertised in the 626 SR-Algorithm Sub-TLV (Section 3.1) MUST ignore the Prefix-SID Sub- 627 TLV. 629 SID/Index/Label: According to the V and L flags, it contains 630 either: 632 A 32-bit index defining the offset in the SID/Label space 633 advertised by this router. 635 A 24-bit label where the 20 rightmost bits are used for 636 encoding the label value. 638 If an OSPF router advertises multiple Prefix-SIDs for the same 639 prefix, topology and algorithm, all of them MUST be ignored. 641 When calculating the outgoing label for the prefix, the router MUST 642 take into account, as described below, the E, NP and M flags 643 advertised by the next-hop router if that router advertised the SID 644 for the prefix. This MUST be done regardless of whether the next-hop 645 router contributes to the best path to the prefix. 647 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 648 Prefix-SIDs allocated to inter-area prefixes that are originated by 649 the ABR based on intra-area or inter-area reachability between areas, 650 unless the advertised prefix is directly attached to the ABR. 652 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 653 Prefix-SIDs allocated to redistributed prefixes, unless the 654 redistributed prefix is directly attached to the ASBR. 656 If the NP-Flag is not set, then any upstream neighbor of the Prefix- 657 SID originator MUST pop the Prefix-SID. This is equivalent to the 658 penultimate hop popping mechanism used in the MPLS dataplane. If the 659 NP-flag is not set, then the received E-flag is ignored. 661 If the NP-flag is set then: 663 If the E-flag is not set, then any upstream neighbor of the 664 Prefix-SID originator MUST keep the Prefix-SID on top of the 665 stack. This is useful when the originator of the Prefix-SID need 666 to stitch the incoming packet into a continuing MPLS LSP to the 667 final destination. This could occur at an Area Border Router 668 (prefix propagation from one area to another) or at an AS Boundary 669 Router (prefix propagation from one domain to another). 671 If the E-flag is set, then any upstream neighbor of the Prefix-SID 672 originator MUST replace the Prefix-SID with an Explicit-NULL 673 label. This is useful, e.g., when the originator of the Prefix- 674 SID is the final destination for the related prefix and the 675 originator wishes to receive the packet with the original EXP 676 bits. 678 When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at 679 reception. 681 As the Mapping Server does not specify the originator of a prefix 682 advertisement, it is not possible to determine PHP behavior solely 683 based on the Mapping Server advertisement. However, PHP behavior 684 SHOULD be done in following cases: 686 The Prefix is intra-area type and the downstream neighbor is the 687 originator of the prefix. 689 The Prefix is inter-area type and downstream neighbor is an ABR, 690 which is advertising prefix reachability and is also generating 691 the Extended Prefix TLV with the A-flag set for this prefix as 692 described in section 2.1 of [RFC7684]. 694 The Prefix is external type and downstream neighbor is an ASBR, 695 which is advertising prefix reachability and is also generating 696 the Extended Prefix TLV with the A-flag set for this prefix as 697 described in section 2.1 of [RFC7684]. 699 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 700 the value advertised in the Prefix SID Sub-TLV is interpreted as a 701 starting SID/Label value. 703 Example 1: If the following router addresses (loopback addresses) 704 need to be mapped into the corresponding Prefix SID indexes: 706 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 707 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 708 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 709 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 711 then the Prefix field in the Extended Prefix Range TLV would be set 712 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 713 set to 4, and the Index value in the Prefix-SID Sub-TLV would be set 714 to 1. 716 Example 2: If the following prefixes need to be mapped into the 717 corresponding Prefix-SID indexes: 719 192.0.2.0/30, Prefix-SID: Index 51 720 192.0.2.4/30, Prefix-SID: Index 52 721 192.0.2.8/30, Prefix-SID: Index 53 722 192.0.2.12/30, Prefix-SID: Index 54 723 192.0.2.16/30, Prefix-SID: Index 55 724 192.0.2.20/30, Prefix-SID: Index 56 725 192.0.2.24/30, Prefix-SID: Index 57 727 then the Prefix field in the Extended Prefix Range TLV would be set 728 to 192.0.2.0, Prefix Length would be set to 30, Range Size would be 729 7, and the Index value in the Prefix-SID Sub-TLV would be set to 51. 731 6. Adjacency Segment Identifier (Adj-SID) 733 An Adjacency Segment Identifier (Adj-SID) represents a router 734 adjacency in Segment Routing. 736 6.1. Adj-SID Sub-TLV 738 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 739 [RFC7684]. It MAY appear multiple times in the Extended Link TLV. 740 The Adj-SID Sub-TLV has the following format: 742 0 1 2 3 743 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 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Type | Length | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Flags | Reserved | MT-ID | Weight | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | SID/Label/Index (variable) | 750 +---------------------------------------------------------------+ 752 where: 754 Type: 2 756 Length: 7 or 8 octets, dependent on the V flag. 758 Flags: Single octet field containing the following flags: 760 0 1 2 3 4 5 6 7 761 +-+-+-+-+-+-+-+-+ 762 |B|V|L|G|P| | 763 +-+-+-+-+-+-+-+-+ 765 where: 767 B-Flag: Backup Flag. If set, the Adj-SID refers to an 768 adjacency that is eligible for protection (e.g., using IPFRR or 769 MPLS-FRR) as described in section 3.5 of 770 [I-D.ietf-spring-segment-routing]. 772 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 773 an absolute value. If not set, then the Adj-SID carries an 774 index. 776 The L-Flag: Local/Global Flag. If set, then the value/index 777 carried by the Adj-SID has local significance. If not set, 778 then the value/index carried by this Sub-TLV has global 779 significance. 781 The G-Flag: Group Flag. When set, the G-Flag indicates that 782 the Adj-SID refers to a group of adjacencies (and therefore MAY 783 be assigned to other adjacencies as well). 785 P-Flag. Persistent flag. When set, the P-Flag indicates that 786 the Adj-SID is persistently allocated, i.e., the Adj-SID value 787 remains consistent across router restart and/or interface flap. 789 Other bits: Reserved. These MUST be zero when sent and are 790 ignored when received. 792 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 793 on reception. 795 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 797 Weight: Weight used for load-balancing purposes. The use of the 798 weight is defined in [I-D.ietf-spring-segment-routing]. 800 SID/Index/Label: According to the V and L flags, it contains 801 either: 803 A 32-bit index defining the offset in the SID/Label space 804 advertised by this router. 806 A 24-bit label where the 20 rightmost bits are used for 807 encoding the label value. 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: According to the V and L flags, it contains 862 either: 864 A 32-bit index defining the offset in the SID/Label space 865 advertised by this router. 867 A 24-bit label where the 20 rightmost bits are used for 868 encoding the label value. 870 When the P-flag is not set, the Adj-SID MAY be persistent. When 871 the P-flag is set, the Adj-SID MUST be persistent. 873 7. Elements of Procedure 874 7.1. Intra-area Segment routing in OSPFv2 876 An OSPFv2 router that supports segment routing MAY advertise Prefix- 877 SIDs for any prefix to which it is advertising reachability (e.g., a 878 loopback IP address as described in Section 5). 880 A Prefix-SID can also be advertised by the SR Mapping Servers (as 881 described in [I-D.ietf-spring-segment-routing-ldp-interop]). A 882 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 883 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 884 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 885 MUST be advertised by all of them. The flooding scope of the OSPF 886 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 887 could be either area-scoped or AS-scoped and is determined based on 888 the configuration of the SR Mapping Server. 890 An SR Mapping Server MUST use the OSPF Extended Prefix Range TLV when 891 advertising SIDs for prefixes. Prefixes of different route-types can 892 be combined in a single OSPF Extended Prefix Range TLV advertised by 893 an SR Mapping Server. Because the OSPF Extended Prefix Range TLV 894 doesn't include a Route-Type field, as in the OSPF Extended Prefix 895 TLV, it is possible to include adjacent prefixes from different 896 Route-Types in the OSPF Extended Prefix Range TLV. 898 Area-scoped OSPF Extended Prefix Range TLVs are propagated between 899 areas. Similar to propagation of prefixes between areas, an ABR only 900 propagates the OSPF Extended Prefix Range TLV that it considers to be 901 the best from the set it received. The rules used to pick the best 902 OSPF Extended Prefix Range TLV are described in Section 4. 904 When propagating an OSPF Extended Prefix Range TLV between areas, 905 ABRs MUST set the IA-Flag, that is used to prevent redundant flooding 906 of the OSPF Extended Prefix Range TLV between areas as described in 907 Section 4. 909 7.2. Inter-area Segment routing in OSPFv2 911 In order to support SR in a multi-area environment, OSPFv2 MUST 912 propagate Prefix-SID information between areas. The following 913 procedure is used to propagate Prefix SIDs between areas. 915 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 916 prefix to all its connected areas, it will also originate an Extended 917 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 918 the Extended Prefix Opaque LSA type will be set to area-local scope. 919 The route-type in the OSPF Extended Prefix TLV is set to inter-area. 920 The Prefix-SID Sub-TLV will be included in this LSA and the Prefix- 921 SID value will be set as follows: 923 The ABR will look at its best path to the prefix in the source 924 area and find the advertising router associated with the best path 925 to that prefix. 927 The ABR will then determine if such router advertised a Prefix-SID 928 for the prefix and use it when advertising the Prefix-SID to other 929 connected areas. 931 If no Prefix-SID was advertised for the prefix in the source area 932 by the router that contributes to the best path to the prefix, the 933 originating ABR will use the Prefix-SID advertised by any other 934 router when propagating the Prefix-SID for the prefix to other 935 areas. 937 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 938 route to all its connected areas, it will also originate an Extended 939 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 940 the Extended Prefix Opaque LSA type will be set to area-local scope. 941 The route-type in OSPF Extended Prefix TLV is set to inter-area. The 942 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 943 will be set as follows: 945 The ABR will look at its best path to the prefix in the backbone 946 area and find the advertising router associated with the best path 947 to that prefix. 949 The ABR will then determine if such router advertised a Prefix-SID 950 for the prefix and use it when advertising the Prefix-SID to other 951 connected areas. 953 If no Prefix-SID was advertised for the prefix in the backbone 954 area by the ABR that contributes to the best path to the prefix, 955 the originating ABR will use the Prefix-SID advertised by any 956 other router when propagating the Prefix-SID for the prefix to 957 other areas. 959 7.3. Segment Routing for External Prefixes 961 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 962 SR, generates Type-5 LSAs, it SHOULD also originate Extended Prefix 963 Opaque LSAs, as described in [RFC7684]. The flooding scope of the 964 Extended Prefix Opaque LSA type is set to AS-wide scope. The route- 965 type in the OSPF Extended Prefix TLV is set to external. The Prefix- 966 SID Sub-TLV is included in this LSA and the Prefix-SID value will be 967 set to the SID that has been reserved for that prefix. 969 When an NSSA [RFC3101] ABR translates Type-7 LSAs into Type-5 LSAs, 970 it SHOULD also advertise the Prefix-SID for the prefix. The NSSA ABR 971 determines its best path to the prefix advertised in the translated 972 Type-7 LSA and finds the advertising router associated with that 973 path. If the advertising router has advertised a Prefix-SID for the 974 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 975 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 976 router will be used. 978 7.4. Advertisement of Adj-SID 980 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 981 using the Adj-SID Sub-TLV as described in Section 6. 983 7.4.1. Advertisement of Adj-SID on Point-to-Point Links 985 An Adj-SID MAY be advertised for any adjacency on a P2P link that is 986 in neighbor state 2-Way or higher. If the adjacency on a P2P link 987 transitions from the FULL state, then the Adj-SID for that adjacency 988 MAY be removed from the area. If the adjacency transitions to a 989 state lower then 2-Way, then the Adj-SID advertisement MUST be 990 withdrawn from the area. 992 7.4.2. Adjacency SID on Broadcast or NBMA Interfaces 994 Broadcast, NBMA, or hybrid [RFC6845] networks in OSPF are represented 995 by a star topology where the Designated Router (DR) is the central 996 point to which all other routers on the broadcast, NBMA, or hybrid 997 network connect. As a result, routers on the broadcast, NBMA, or 998 hybrid network advertise only their adjacency to the DR. Routers 999 that do not act as DR do not form or advertise adjacencies with each 1000 other. They do, however, maintain 2-Way adjacency state with each 1001 other and are directly reachable. 1003 When Segment Routing is used, each router on the broadcast, NBMA, or 1004 hybrid network MAY advertise the Adj-SID for its adjacency to the DR 1005 using the Adj-SID Sub-TLV as described in Section 6.1. 1007 SR capable routers MAY also advertise a LAN-Adj-SID for other 1008 neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid 1009 network using the LAN-ADJ-SID Sub-TLV as described in Section 6.2. 1011 8. IANA Considerations 1013 This specification updates several existing OSPF registries. 1015 8.1. OSPF Router Information (RI) TLVs Registry 1017 o 8 (IANA Preallocated) - SR-Algorithm TLV 1019 o 9 (IANA Preallocated) - SID/Label Range TLV 1021 o 14 - SR Local Block TLV 1023 o 15 - SRMS Preference TLV 1025 8.2. OSPFv2 Extended Prefix Opaque LSA TLVs Registry 1027 Following values are allocated: 1029 o 2 - OSPF Extended Prefix Range TLV 1031 8.3. OSPFv2 Extended Prefix TLV Sub-TLVs Registry 1033 Following values are allocated: 1035 o 1 - SID/Label Sub-TLV 1037 o 2 - Prefix SID Sub-TLV 1039 8.4. OSPFv2 Extended Link TLV Sub-TLVs Registry 1041 Following initial values are allocated: 1043 o 1 - SID/Label Sub-TLV 1045 o 2 - Adj-SID Sub-TLV 1047 o 3 - LAN Adj-SID/Label Sub-TLV 1049 8.5. IGP Algorithm Type Registry 1051 IANA is requested to set up a registry called "IGP Algorithm Type" 1052 under a new category of "Interior Gateway Protocol (IGP) Parameters" 1053 IANA registries. The registration policy for this registry is 1054 "Standards Action" ([RFC8126] and [RFC7120]). 1056 Values in this registry come from the range 0-255. 1058 The initial values in the IGP Algorithm Type registry are: 1060 0: Shortest Path First (SPF) algorithm based on link metric. This 1061 is the standard shortest path algorithm as computed by the IGP 1062 protocol. Consistent with the deployed practice for link-state 1063 protocols, Algorithm 0 permits any node to overwrite the SPF path 1064 with a different path based on its local policy. 1066 1: Strict Shortest Path First (SPF) algorithm based on link 1067 metric. The algorithm is identical to Algorithm 0 but Algorithm 1 1068 requires that all nodes along the path will honor the SPF routing 1069 decision. Local policy at the node claiming support for Algorithm 1070 1 MUST NOT alter the SPF paths computed by Algorithm 1. 1072 9. Implementation Status 1074 An implementation survey with seven questions related to the 1075 implementer's support of OSPFv2 Segment Routing was sent to the OSPF 1076 WG list and several known implementers. This section contains 1077 responses from three implementers who completed the survey. No 1078 external means were used to verify the accuracy of the information 1079 submitted by the respondents. The respondents are considered experts 1080 on the products they reported on. Additionally, responses were 1081 omitted from implementers who indicated that they have not 1082 implemented the function yet. 1084 This section will be removed before publication as an RFC. 1086 Responses from Nokia (former Alcatel-Lucent): 1088 Link to a web page describing the implementation: 1089 https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/ 1090 3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Un 1091 icast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf 1093 The implementation's level of maturity: Production. 1095 Coverage: We have implemented all sections and have support for the 1096 latest draft. 1098 Licensing: Part of the software package that needs to be purchased. 1100 Implementation experience: Great spec. We also performed inter- 1101 operability testing with Cisco's OSPF Segment Routing implementation. 1103 Contact information: wim.henderickx@nokia.com 1105 Responses from Cisco Systems: 1107 Link to a web page describing the implementation: 1109 http://www.segment-routing.net/home/tutorial 1110 The implementation's level of maturity: Production. 1112 Coverage: All sections have been implemented according to the latest 1113 draft. 1115 Licensing: Part of a commercial software package. 1117 Implementation experience: Many aspects of the draft are result of 1118 the actual implementation experience, as the draft evolved from its 1119 initial version to the current one. Interoperability testing with 1120 Alcatel-Lucent was performed, which confirmed the draft's ability to 1121 serve as a reference for the implementors. 1123 Contact information: ppsenak@cisco.com 1125 Responses from Juniper: 1127 The implementation's name and/or a link to a web page describing the 1128 implementation: 1130 Feature name is OSPF SPRING 1132 The implementation's level of maturity: To be released in 16.2 1133 (second half of 2016) 1135 Coverage: All sections implemented except Sections 4, and 6. 1137 Licensing: JUNOS Licensing needed. 1139 Implementation experience: NA 1141 Contact information: shraddha@juniper.net 1143 10. Security Considerations 1145 With the OSPFv2 segment routing extensions defined herein, OSPFv2 1146 will now program the MPLS data plane [RFC3031] in addition to the IP 1147 data plane. Previously, LDP [RFC5036] or another label distribution 1148 mechanism was required to advertise MPLS labels and program the MPLS 1149 data plane. 1151 In general, the same types of attacks that can be carried out on the 1152 IP control plane can be carried out on the MPLS control plane 1153 resulting in traffic being misrouted in the respective data planes. 1154 However, the latter can be more difficult to detect and isolate. 1156 Existing security extensions as described in [RFC2328] and [RFC7684] 1157 apply to these segment routing extensions. While OSPF is under a 1158 single administrative domain, there can be deployments where 1159 potential attackers have access to one or more networks in the OSPF 1160 routing domain. In these deployments, stronger authentication 1161 mechanisms such as those specified in [RFC7474] SHOULD be used. 1163 Implementations MUST assure that malformed TLV and Sub-TLV defined in 1164 this document are detected and do not provide a vulnerability for 1165 attackers to crash the OSPFv2 router or routing process. Reception 1166 of malformed TLV or Sub-TLV SHOULD be counted and/or logged for 1167 further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be 1168 rate-limited to prevent a Denial of Service (DoS) attack (distributed 1169 or otherwise) from overloading the OSPF control plane. 1171 11. Contributors 1173 The following people gave a substantial contribution to the content 1174 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1175 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1176 Saku Ytti. 1178 12. Acknowledgements 1180 We would like to thank Anton Smirnov for his contribution. 1182 Thanks to Acee Lindem for the detail review of the draft, 1183 corrections, as well as discussion about details of the encoding. 1185 13. References 1187 13.1. Normative References 1189 [I-D.ietf-spring-conflict-resolution] 1190 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 1191 "Segment Routing MPLS Conflict Resolution", draft-ietf- 1192 spring-conflict-resolution-05 (work in progress), July 1193 2017. 1195 [I-D.ietf-spring-segment-routing] 1196 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1197 Litkowski, S., and R. Shakir, "Segment Routing 1198 Architecture", draft-ietf-spring-segment-routing-13 (work 1199 in progress), October 2017. 1201 [I-D.ietf-spring-segment-routing-ldp-interop] 1202 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 1203 S. Litkowski, "Segment Routing interworking with LDP", 1204 draft-ietf-spring-segment-routing-ldp-interop-09 (work in 1205 progress), September 2017. 1207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1208 Requirement Levels", BCP 14, RFC 2119, 1209 DOI 10.17487/RFC2119, March 1997, 1210 . 1212 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1213 DOI 10.17487/RFC2328, April 1998, 1214 . 1216 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1217 RFC 3101, DOI 10.17487/RFC3101, January 2003, 1218 . 1220 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1221 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1222 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1223 . 1225 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 1226 and Point-to-Multipoint Interface Type", RFC 6845, 1227 DOI 10.17487/RFC6845, January 2013, 1228 . 1230 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 1231 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 1232 2014, . 1234 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1235 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1236 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1237 2015, . 1239 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1240 S. Shaffer, "Extensions to OSPF for Advertising Optional 1241 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1242 February 2016, . 1244 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1245 Writing an IANA Considerations Section in RFCs", BCP 26, 1246 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1247 . 1249 13.2. Informative References 1251 [I-D.ietf-spring-segment-routing-mpls] 1252 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1253 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1254 data plane", draft-ietf-spring-segment-routing-mpls-11 1255 (work in progress), October 2017. 1257 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 1258 "Security Extension for OSPFv2 When Using Manual Key 1259 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 1260 . 1262 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1263 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1264 Packet Routing in Networking (SPRING) Problem Statement 1265 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1266 2016, . 1268 Authors' Addresses 1270 Peter Psenak (editor) 1271 Cisco Systems, Inc. 1272 Apollo Business Center 1273 Mlynske nivy 43 1274 Bratislava 821 09 1275 Slovakia 1277 Email: ppsenak@cisco.com 1279 Stefano Previdi (editor) 1280 Cisco Systems, Inc. 1281 Via Del Serafico, 200 1282 Rome 00142 1283 Italy 1285 Email: stefano@previdi.net 1287 Clarence Filsfils 1288 Cisco Systems, Inc. 1289 Brussels 1290 Belgium 1292 Email: cfilsfil@cisco.com 1293 Hannes Gredler 1294 RtBrick Inc. 1296 Email: hannes@rtbrick.com 1298 Rob Shakir 1299 Google, Inc. 1300 1600 Amphitheatre Parkway 1301 Mountain View, CA 94043 1302 US 1304 Email: robjs@google.com 1306 Wim Henderickx 1307 Nokia 1308 Copernicuslaan 50 1309 Antwerp 2018 1310 BE 1312 Email: wim.henderickx@nokia.com 1314 Jeff Tantsura 1315 Individual 1316 US 1318 Email: jefftant.ietf@gmail.com