idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-20.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 (October 20, 2017) is 2379 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 323 -- Looks like a reference, but probably isn't: '199' on line 323 -- Looks like a reference, but probably isn't: '1000' on line 324 -- Looks like a reference, but probably isn't: '1099' on line 324 -- Looks like a reference, but probably isn't: '500' on line 325 -- Looks like a reference, but probably isn't: '599' on line 325 == Missing Reference: 'RFC3031' is mentioned on line 1126, but not defined == Missing Reference: 'RFC5036' is mentioned on line 1127, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 == 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-10 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: April 23, 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 October 20, 2017 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-20 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 OSPF 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 April 23, 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 . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 21 86 7.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 21 87 7.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 21 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 89 8.1. OSPF OSPF Router Information (RI) TLVs Registry . . . . . 22 90 8.2. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 22 91 8.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 22 92 8.4. OSPF Extended Link LSA Sub-TLV Registry . . . . . . . . . 22 93 8.5. SR-Algorithm Registry . . . . . . . . . . . . . . . . . . 23 94 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 95 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 96 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 97 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 98 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 99 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 100 13.2. Informative References . . . . . . . . . . . . . . . . . 26 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 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. For example, when used 118 in MPLS networks, SR paths do not require any LDP or RSVP-TE 119 signalling. However, SR can interoperate in the presence of LSPs 120 established with 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 may 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 SHOULD 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 SHOULD 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 SHOULD be used and subsequent 238 instances of the SR-Algorithm TLV SHOULD 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 Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as 280 defined in Section 2.1. The SID/Label Sub-TLV MUST be included in 281 the SID/Label Range TLV. The SID/Label advertised in the SID/Label 282 Sub-TLV represents the first SID/Label in the advertised range. 284 Only a single SID/Label Sub-TLV MAY be advertised in SID/Label Range 285 TLV. If more then one SID/Label Sub-TLVs are present, the SID/Label 286 Range TLV MUST be ignored. 288 Multiple occurrences of the SID/Label Range TLV MAY be advertised, in 289 order to advertise multiple ranges. In such case: 291 o The originating router MUST encode each range into a different 292 SID/Label Range TLV. 294 o The originating router decides the order in which the set of SID/ 295 Label Range TLVs are advertised inside the Router Information 296 Opaque LSA. The originating router MUST ensure the order is the 297 same after a graceful restart (using checkpointing, non-volatile 298 storage, or any other mechanism) in order to assure the SID/label 299 range and SID index correspondence is preserved across graceful 300 restarts. 302 o The receiving router MUST adhere to the order in which the ranges 303 are advertised when calculating a SID/label from a SID index. 305 o The originating router MUST NOT advertise overlapping ranges. 307 o When a router receives multiple overlapping ranges, it MUST 308 conform to the procedures defined in 309 [I-D.ietf-spring-conflict-resolution]. 311 The following example illustrates the advertisement of multiple 312 ranges: 314 The originating router advertises the following ranges: 316 Range 1: Range Size: 100 SID/Label Sub-TLV: 100 317 Range 1: Range Size: 100 SID/Label Sub-TLV: 1000 318 Range 1: Range Size: 100 SID/Label Sub-TLV: 500 320 The receiving routers concatenate the ranges and build the Segment 321 Routing Global Block (SRGB) as follows: 323 SRGB = [100, 199] 324 [1000, 1099] 325 [500, 599] 327 The indexes span multiple ranges: 329 index=0 means label 100 330 ... 331 index 99 means label 199 332 index 100 means label 1000 333 index 199 means label 1099 334 ... 335 index 200 means label 500 336 ... 338 The RI LSA can be advertised at any of the defined flooding scopes 339 (link, area, or autonomous system (AS)). For the purpose of SID/ 340 Label Range TLV advertisement, area-scoped flooding is REQUIRED. 342 3.3. SR Local Block TLV 344 The SR Local Block TLV (SRLB TLV) contains the range of labels the 345 node has reserved for local SIDs. SIDs from the SRLB MAY be used for 346 Adjacency-SIDs, but also by components other than the OSPF protocol. 347 As an example, an application or a controller may instruct the router 348 to allocate a specific local SID. Some controllers or applications 349 may use the control plane to discover the available set of local SIDs 350 on a particular router. In such cases, the SRLG is advertised in the 351 control plane. The requirement to advertise the SRLB is further 352 described in [I-D.ietf-spring-segment-routing-mpls]. The SRLB TLV is 353 used to advertise the SRLB. 355 The SRLB TLV is a top-level TLV of the Router Information Opaque LSA 356 (defined in [RFC7770]). 358 The SRLB TLV MAY appear multiple times in the Router Information 359 Opaque LSA and has the following format: 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Type | Length | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Range Size | Reserved | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Sub-TLVs (variable) | 369 +- -+ 370 | | 371 + + 373 where: 375 Type: 14 377 Length: Variable, in octets, dependent on Sub-TLVs. 379 Range Size: 3-octet SID/label range size (i.e., the number of SIDs 380 or labels in the range including the first SID/label). It MUST be 381 greater than 0. 383 Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as 384 defined in Section 2.1. The SID/Label Sub-TLV MUST be included in 385 the SRLB TLV. The SID/Label advertised in the SID/Label Sub-TLV 386 represents the first SID/Label in the advertised range. 388 Only a single SID/Label Sub-TLV MAY be advertised in the SRLB TLV. 389 If more then one SID/Label Sub-TLVs are present, the SRLB TLV MUST be 390 ignored. 392 The originating router MUST NOT advertise overlapping ranges. 394 Each time a SID from the SRLB is allocated, it SHOULD also be 395 reported to all components (e.g., controller or applications) in 396 order for these components to have an up-to-date view of the current 397 SRLB allocation. This is required to avoid collisions between 398 allocation instructions. 400 Within the context of OSPF, the reporting of local SIDs is done 401 through OSPF Sub-TLVs such as the Adjacency-SID (Section 6). 402 However, the reporting of allocated local SIDs may also be done 403 through other means and protocols which are outside the scope of this 404 document. 406 A router advertising the SRLB TLV may also have other label ranges, 407 outside of the SRLB, used for its local allocation purposes which are 408 NOT advertised in the SRLB TLV. For example, it is possible that an 409 Adjacency-SID is allocated using a local label that is not part of 410 the SRLB. 412 The RI LSA can be advertised at any of the defined flooding scopes 413 (link, area, or autonomous system (AS)). For the purpose of SRLB TLV 414 advertisement, area-scoped flooding is REQUIRED. 416 3.4. SRMS Preference TLV 418 The Segment Routing Mapping Server Preference TLV (SRMS Preference 419 TLV) is used to advertise a preference associated with the node that 420 acts as an SR Mapping Server. The role of an SRMS is described in 421 [I-D.ietf-spring-segment-routing-ldp-interop]. SRMS preference is 422 defined in [I-D.ietf-spring-conflict-resolution]. 424 The SRMS Preference TLV is a top-level TLV of the Router Information 425 Opaque LSA (defined in [RFC7770]). 427 The SRMS Preference TLV MAY only be advertised once in the Router 428 Information Opaque LSA and has the following format: 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Type | Length | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Preference | Reserved | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 where: 440 Type: 13 442 Length: 4 octets 444 Preference: 1 octet. SRMS preference value from 0 to 255. 446 When multiple SRMS Preference TLVs are received from a given router, 447 the receiver SHOULD use the first occurrence of the TLV in the Router 448 Information LSA. If the SRMS Preference TLV appears in multiple 449 Router Information LSAs that have different flooding scopes, the SRMS 450 Preference TLV in the Router Information LSA with the narrowest 451 flooding scope SHOULD be used. If the SRMS Preference TLV appears in 452 multiple Router Information LSAs that have the same flooding scope, 453 the SRMS Preference TLV in the Router Information LSA with the 454 numerically smallest Instance ID SHOULD be used and subsequent 455 instances of the SRMS Preference TLV SHOULD be ignored. 457 The RI LSA can be advertised at any of the defined flooding scopes 458 (link, area, or autonomous system (AS)). For the purpose of the SRMS 459 Preference TLV advertisement, AS-scoped flooding SHOULD be used. 460 This is because SRMS servers can be located in a different area then 461 consumers of the SRMS advertisements. If the SRMS advertisements 462 from the SRMS server are only used inside the SRMS server's area, 463 area-scoped flooding MAY be used. 465 4. OSPF Extended Prefix Range TLV 467 In some cases it is useful to advertise attributes for a range of 468 prefixes. The Segment Routing Mapping Server, which is described in 469 [I-D.ietf-spring-segment-routing-ldp-interop], is an example where we 470 need a single advertisement to advertise SIDs for multiple prefixes 471 from a contiguous address range. 473 The OSPF Extended Prefix Range TLV, which is a top level TLV of the 474 Extended Prefix LSA described in [RFC7684] is defined for this 475 purpose. 477 Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each 478 OSPF Extended Prefix Opaque LSA, but all prefix ranges included in a 479 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 480 scope. The OSPF Extended Prefix Range TLV has the following format: 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Type | Length | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Prefix Length | AF | Range Size | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Flags | Reserved | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Address Prefix (variable) | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Sub-TLVs (variable) | 494 +- -+ 495 | | 497 where: 499 Type: 2 501 Length: Variable, in octets, dependent on Sub-TLVs. 503 Prefix length: Length of prefix in bits. 505 AF: Address family for the prefix. Currently, the only supported 506 value is 0 for IPv4 unicast. The inclusion of address family in 507 this TLV allows for future extension. 509 Range size: Represents the number of prefixes that are covered by 510 the advertisement. The Range Size MUST NOT exceed the number of 511 prefixes that could be satisfied by the prefix length without 512 including the IPv4 multicast address range (224.0.0.0/3). 514 Flags: Single octet field. The following flags are defined: 516 0 1 2 3 4 5 6 7 517 +--+--+--+--+--+--+--+--+ 518 |IA| | | | | | | | 519 +--+--+--+--+--+--+--+--+ 521 where: 523 IA-Flag: Inter-Area flag. If set, advertisement is of inter- 524 area type. An ABR that is advertising the OSPF Extended Prefix 525 Range TLV between areas MUST set this bit. 527 This bit is used to prevent redundant flooding of Prefix Range 528 TLVs between areas as follows: 530 An ABR only propagates an inter-area Prefix Range 531 advertisement from the backbone area to connected non- 532 backbone areas if the advertisement is considered to be the 533 best one. The following rules are used to select the best 534 range from the set of advertisements for the same Prefix 535 Range: 537 An ABR always prefers intra-area Prefix Range 538 advertisements over inter-area advertisements. 540 An ABR does not consider inter-area Prefix Range 541 advertisements coming from non-backbone areas. 543 Address Prefix: For the address family IPv4 unicast, the prefix 544 itself is encoded as a 32-bit value. The default route is 545 represented by a prefix of length 0. Prefix encoding for other 546 address families is beyond the scope of this specification. 548 5. Prefix SID Sub-TLV 550 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV 551 described in [RFC7684] and the OSPF Extended Prefix Range TLV 552 described in Section 4. It MAY appear more than once in the parent 553 TLV and has the following format: 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Type | Length | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Flags | Reserved | MT-ID | Algorithm | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | SID/Index/Label (variable) | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 where: 567 Type: 2 569 Length: 7 or 8 octets, dependent on the V-flag 571 Flags: Single octet field. The following flags are defined: 573 0 1 2 3 4 5 6 7 574 +--+--+--+--+--+--+--+--+ 575 | |NP|M |E |V |L | | | 576 +--+--+--+--+--+--+--+--+ 578 where: 580 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 581 NOT pop the Prefix-SID before delivering packets to the node 582 that advertised the Prefix-SID. 584 M-Flag: Mapping Server Flag. If set, the SID was advertised by 585 a Segment Routing Mapping Server as described in 586 [I-D.ietf-spring-segment-routing-ldp-interop]. 588 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 589 the Prefix-SID originator MUST replace the Prefix-SID with the 590 Explicit-NULL label (0 for IPv4) before forwarding the packet. 592 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 593 an absolute value. If not set, then the Prefix-SID carries an 594 index. 596 L-Flag: Local/Global Flag. If set, then the value/index 597 carried by the Prefix-SID has local significance. If not set, 598 then the value/index carried by this Sub-TLV has global 599 significance. 601 Other bits: Reserved. These MUST be zero when sent and are 602 ignored when received. 604 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 606 Algorithm: Single octet identifying the algorithm the Prefix-SID 607 is associated with as defined in Section 3.1. 609 A router receiving a Prefix-SID from a remote node and with an 610 algorithm value that such remote node has not advertised in the 611 SR-Algorithm Sub-TLV (Section 3.1) MUST ignore the Prefix-SID Sub- 612 TLV. 614 SID/Index/Label: According to the V and L flags, it contains 615 either: 617 A 32-bit index defining the offset in the SID/Label space 618 advertised by this router. 620 A 24-bit label where the 20 rightmost bits are used for 621 encoding the label value. 623 If an OSPF router advertises multiple Prefix-SIDs for the same 624 prefix, topology and algorithm, all of them MUST be ignored. 626 When calculating the outgoing label for the prefix, the router MUST 627 take into account, as described below, the E, NP and M flags 628 advertised by the next-hop router if that router advertised the SID 629 for the prefix. This MUST be done regardless of whether the next-hop 630 router contributes to the best path to the prefix. 632 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 633 Prefix-SIDs allocated to inter-area prefixes that are originated by 634 the ABR based on intra-area or inter-area reachability between areas, 635 unless the advertised prefix is directly attached to the ABR. 637 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 638 Prefix-SIDs allocated to redistributed prefixes, unless the 639 redistributed prefix is directly attached to the ASBR. 641 If the NP-Flag is not set, then any upstream neighbor of the Prefix- 642 SID originator MUST pop the Prefix-SID. This is equivalent to the 643 penultimate hop popping mechanism used in the MPLS dataplane. If the 644 NP-flag is not set, then the received E-flag is ignored. 646 If the NP-flag is set then: 648 If the E-flag is not set, then any upstream neighbor of the 649 Prefix-SID originator MUST keep the Prefix-SID on top of the 650 stack. This is useful when the originator of the Prefix-SID must 651 stitch the incoming packet into a continuing MPLS LSP to the final 652 destination. This could occur at an Area Border Router (prefix 653 propagation from one area to another) or at an AS Boundary Router 654 (prefix propagation from one domain to another). 656 If the E-flag is set, then any upstream neighbor of the Prefix-SID 657 originator MUST replace the Prefix-SID with an Explicit-NULL 658 label. This is useful, e.g., when the originator of the Prefix- 659 SID is the final destination for the related prefix and the 660 originator wishes to receive the packet with the original EXP 661 bits. 663 When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at 664 reception. 666 As the Mapping Server does not specify the originator of a prefix 667 advertisement, it is not possible to determine PHP behavior solely 668 based on the Mapping Server advertisement. However, PHP behavior 669 SHOULD be done in following cases: 671 The Prefix is intra-area type and the downstream neighbor is the 672 originator of the prefix. 674 The Prefix is inter-area type and downstream neighbor is an ABR, 675 which is advertising prefix reachability and is also generating 676 the Extended Prefix TLV with the A-flag set for this prefix as 677 described in section 2.1 of [RFC7684]. 679 The Prefix is external type and downstream neighbor is an ASBR, 680 which is advertising prefix reachability and is also generating 681 the Extended Prefix TLV with the A-flag set for this prefix as 682 described in section 2.1 of [RFC7684]. 684 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 685 the value advertised in the Prefix SID Sub-TLV is interpreted as a 686 starting SID/Label value. 688 Example 1: If the following router addresses (loopback addresses) 689 need to be mapped into the corresponding Prefix SID indexes: 691 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 692 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 693 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 694 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 696 then the Prefix field in the Extended Prefix Range TLV would be set 697 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 698 set to 4, and the Index value in the Prefix-SID Sub-TLV would be set 699 to 1. 701 Example 2: If the following prefixes need to be mapped into the 702 corresponding Prefix-SID indexes: 704 192.0.2.0/30, Prefix-SID: Index 51 705 192.0.2.4/30, Prefix-SID: Index 52 706 192.0.2.8/30, Prefix-SID: Index 53 707 192.0.2.12/30, Prefix-SID: Index 54 708 192.0.2.16/30, Prefix-SID: Index 55 709 192.0.2.20/30, Prefix-SID: Index 56 710 192.0.2.24/30, Prefix-SID: Index 57 712 then the Prefix field in the Extended Prefix Range TLV would be set 713 to 192.0.2.0, Prefix Length would be set to 30, Range Size would be 714 7, and the Index value in the Prefix-SID Sub-TLV would be set to 51. 716 6. Adjacency Segment Identifier (Adj-SID) 718 An Adjacency Segment Identifier (Adj-SID) represents a router 719 adjacency in Segment Routing. 721 6.1. Adj-SID Sub-TLV 723 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 724 [RFC7684]. It MAY appear multiple times in the Extended Link TLV. 725 The Adj-SID Sub-TLV has the following format: 727 0 1 2 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Type | Length | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Flags | Reserved | MT-ID | Weight | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | SID/Label/Index (variable) | 735 +---------------------------------------------------------------+ 737 where: 739 Type: 2 741 Length: 7 or 8 octets, dependent on the V flag. 743 Flags: Single octet field containing the following flags: 745 0 1 2 3 4 5 6 7 746 +-+-+-+-+-+-+-+-+ 747 |B|V|L|G|P| | 748 +-+-+-+-+-+-+-+-+ 750 where: 752 B-Flag: Backup Flag. If set, the Adj-SID refers to an 753 adjacency that is eligible for protection (e.g., using IPFRR or 754 MPLS-FRR) as described in section 3.5 of 755 [I-D.ietf-spring-segment-routing]. 757 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 758 an absolute value. If not set, then the Adj-SID carries an 759 index. 761 The L-Flag: Local/Global Flag. If set, then the value/index 762 carried by the Adj-SID has local significance. If not set, 763 then the value/index carried by this Sub-TLV has global 764 significance. 766 The G-Flag: Group Flag. When set, the G-Flag indicates that 767 the Adj-SID refers to a group of adjacencies (and therefore MAY 768 be assigned to other adjacencies as well). 770 P-Flag. Persistent flag. When set, the P-Flag indicates that 771 the Adj-SID is persistently allocated, i.e., the Adj-SID value 772 remains consistent across router restart and/or interface flap. 774 Other bits: Reserved. These MUST be zero when sent and are 775 ignored when received. 777 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 779 Weight: Weight used for load-balancing purposes. The use of the 780 weight is defined in [I-D.ietf-spring-segment-routing]. 782 SID/Index/Label: According to the V and L flags, it contains 783 either: 785 A 32-bit index defining the offset in the SID/Label space 786 advertised by this router. 788 A 24-bit label where the 20 rightmost bits are used for 789 encoding the label value. 791 An SR capable router MAY allocate an Adj-SID for each of its 792 adjacencies and set the B-Flag when the adjacency is eligible for 793 protection by an FRR mechanism (IP or MPLS) as described in section 794 3.5 of [I-D.ietf-spring-segment-routing]. 796 An SR capable router MAY allocate more than one Adj-SID to an 797 adjacency 799 An SR capable router MAY allocate the same Adj-SID to different 800 adjacencies 802 When the P-flag is not set, the Adj-SID MAY be persistent. When the 803 P-flag is set, the Adj-SID MUST be persistent. 805 6.2. LAN Adj-SID Sub-TLV 807 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 808 in [RFC7684]. It MAY appear multiple times in the Extended-Link TLV. 809 It is used to advertise a SID/Label for an adjacency to a non-DR 810 router on a broadcast, NBMA, or hybrid [RFC6845] network. 812 0 1 2 3 813 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 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Type | Length | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Flags | Reserved | MT-ID | Weight | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Neighbor ID | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | SID/Label/Index (variable) | 822 +---------------------------------------------------------------+ 824 where: 826 Type: 3 828 Length: 11 or 12 octets, dependent on V-flag. 830 Flags: same as in Section 6.1 832 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 834 Weight: Weight used for load-balancing purposes. The use of the 835 weight is defined in [I-D.ietf-spring-segment-routing]. 837 Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- 838 SID is advertised. 840 SID/Index/Label: According to the V and L flags, it contains 841 either: 843 A 32-bit index defining the offset in the SID/Label space 844 advertised by this router. 846 A 24-bit label where the 20 rightmost bits are used for 847 encoding the label value. 849 When the P-flag is not set, the Adj-SID MAY be persistent. When 850 the P-flag is set, the Adj-SID MUST be persistent. 852 7. Elements of Procedure 854 7.1. Intra-area Segment routing in OSPFv2 856 An OSPFv2 router that supports segment routing MAY advertise Prefix- 857 SIDs for any prefix to which it is advertising reachability (e.g., a 858 loopback IP address as described in Section 5). 860 A Prefix-SID can also be advertised by the SR Mapping Servers (as 861 described in [I-D.ietf-spring-segment-routing-ldp-interop]). A 862 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 863 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 864 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 865 MUST be advertised by all of them. The flooding scope of the OSPF 866 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 867 could be either area-scoped or AS-scoped and is determined based on 868 the configuration of the SR Mapping Server. 870 An SR Mapping Server MUST use the OSPF Extended Prefix Range TLV when 871 advertising SIDs for prefixes. Prefixes of different route-types can 872 be combined in a single OSPF Extended Prefix Range TLV advertised by 873 an SR Mapping Server. Because the OSPF Extended Prefix Range TLV 874 doesn't include a Route-Type field, as in the OSPF Extended Prefix 875 TLV, it is possible to include adjacent prefixes from different 876 Route-Types in the OSPF Extended Prefix Range TLV. 878 Area-scoped OSPF Extended Prefix Range TLVs are propagated between 879 areas. Similar to propagation of prefixes between areas, an ABR only 880 propagates the OSPF Extended Prefix Range TLV that it considers to be 881 the best from the set it received. The rules used to pick the best 882 OSPF Extended Prefix Range TLV are described in Section 4. 884 When propagating an OSPF Extended Prefix Range TLV between areas, 885 ABRs MUST set the IA-Flag, that is used to prevent redundant flooding 886 of the OSPF Extended Prefix Range TLV between areas as described in 887 Section 4. 889 7.2. Inter-area Segment routing in OSPFv2 891 In order to support SR in a multi-area environment, OSPFv2 must 892 propagate Prefix-SID information between areas. The following 893 procedure is used to propagate Prefix SIDs between areas. 895 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 896 prefix to all its connected areas, it will also originate an Extended 897 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 898 the Extended Prefix Opaque LSA type will be set to area-local scope. 899 The route-type in the OSPF Extended Prefix TLV is set to inter-area. 900 The Prefix-SID Sub-TLV will be included in this LSA and the Prefix- 901 SID value will be set as follows: 903 The ABR will look at its best path to the prefix in the source 904 area and find the advertising router associated with the best path 905 to that prefix. 907 The ABR will then determine if such router advertised a Prefix-SID 908 for the prefix and use it when advertising the Prefix-SID to other 909 connected areas. 911 If no Prefix-SID was advertised for the prefix in the source area 912 by the router that contributes to the best path to the prefix, the 913 originating ABR will use the Prefix-SID advertised by any other 914 router when propagating the Prefix-SID for the prefix to other 915 areas. 917 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 918 route to all its connected areas, it will also originate an Extended 919 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 920 the Extended Prefix Opaque LSA type will be set to area-local scope. 921 The route-type in OSPF Extended Prefix TLV is set to inter-area. The 922 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 923 will be set as follows: 925 The ABR will look at its best path to the prefix in the backbone 926 area and find the advertising router associated with the best path 927 to that prefix. 929 The ABR will then determine if such router advertised a Prefix-SID 930 for the prefix and use it when advertising the Prefix-SID to other 931 connected areas. 933 If no Prefix-SID was advertised for the prefix in the backbone 934 area by the ABR that contributes to the best path to the prefix, 935 the originating ABR will use the Prefix-SID advertised by any 936 other router when propagating the Prefix-SID for the prefix to 937 other areas. 939 7.3. Segment Routing for External Prefixes 941 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 942 SR, generates Type-5 LSAs, it should also originate Extended Prefix 943 Opaque LSAs, as described in [RFC7684]. The flooding scope of the 944 Extended Prefix Opaque LSA type is set to AS-wide scope. The route- 945 type in the OSPF Extended Prefix TLV is set to external. The Prefix- 946 SID Sub-TLV is included in this LSA and the Prefix-SID value will be 947 set to the SID that has been reserved for that prefix. 949 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 950 also advertise the Prefix-SID for the prefix. The NSSA ABR 951 determines its best path to the prefix advertised in the translated 952 Type-7 LSA and finds the advertising router associated with that 953 path. If the advertising router has advertised a Prefix-SID for the 954 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 955 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 956 router will be used. 958 7.4. Advertisement of Adj-SID 960 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 961 using the Adj-SID Sub-TLV as described in Section 6. 963 7.4.1. Advertisement of Adj-SID on Point-to-Point Links 965 An Adj-SID MAY be advertised for any adjacency on a P2P link that is 966 in neighbor state 2-Way or higher. If the adjacency on a P2P link 967 transitions from the FULL state, then the Adj-SID for that adjacency 968 MAY be removed from the area. If the adjacency transitions to a 969 state lower then 2-Way, then the Adj-SID advertisement MUST be 970 withdrawn from the area. 972 7.4.2. Adjacency SID on Broadcast or NBMA Interfaces 974 Broadcast, NBMA, or hybrid [RFC6845] networks in OSPF are represented 975 by a star topology where the Designated Router (DR) is the central 976 point to which all other routers on the broadcast, NBMA, or hybrid 977 network connect. As a result, routers on the broadcast, NBMA, or 978 hybrid network advertise only their adjacency to the DR. Routers 979 that do not act as DR do not form or advertise adjacencies with each 980 other. They do, however, maintain 2-Way adjacency state with each 981 other and are directly reachable. 983 When Segment Routing is used, each router on the broadcast, NBMA, or 984 hybrid network MAY advertise the Adj-SID for its adjacency to the DR 985 using the Adj-SID Sub-TLV as described in Section 6.1. 987 SR capable routers MAY also advertise a LAN-Adj-SID for other 988 neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid 989 network using the LAN-ADJ-SID Sub-TLV as described in Section 6.2. 991 8. IANA Considerations 993 This specification updates several existing OSPF registries. 995 8.1. OSPF OSPF Router Information (RI) TLVs Registry 997 o 8 (IANA Preallocated) - SR-Algorithm TLV 999 o 9 (IANA Preallocated) - SID/Label Range TLV 1001 o 13 - SRMS Preference TLV 1003 o 14 - SR Local Block TLV 1005 8.2. OSPF Extended Prefix LSA TLV Registry 1007 Following values are allocated: 1009 o 2 - OSPF Extended Prefix Range TLV 1011 8.3. OSPF Extended Prefix LSA Sub-TLV Registry 1013 Following values are allocated: 1015 o 1 - SID/Label Sub-TLV 1017 o 2 - Prefix SID Sub-TLV 1019 8.4. OSPF Extended Link LSA Sub-TLV Registry 1021 Following initial values are allocated: 1023 o 1 - SID/Label Sub-TLV 1025 o 2 - Adj-SID Sub-TLV 1027 o 3 - LAN Adj-SID/Label Sub-TLV 1029 8.5. SR-Algorithm Registry 1031 IANA is requested to set up a registry called "SR-Algorithm Type". 1032 The registration policy for this registry is "Standards Action" 1033 ([RFC8126] and [RFC7120]). 1035 Values in this registry must come from the range 0-255. 1037 The initial values in the SR-Algorithm Type registry are: 1039 0: Shortest Path First (SPF) algorithm based on link metric. This 1040 is the standard shortest path algorithm as computed by the IGP 1041 protocol. Consistent with the deployed practice for link-state 1042 protocols, Algorithm 0 permits any node to overwrite the SPF path 1043 with a different path based on its local policy. 1045 1: Strict Shortest Path First (SPF) algorithm based on link 1046 metric. The algorithm is identical to Algorithm 0 but Algorithm 1 1047 requires that all nodes along the path will honor the SPF routing 1048 decision. Local policy at the node claiming support for Algorithm 1049 1 MUST NOT alter the SPF paths computed by Algorithm 1. 1051 9. Implementation Status 1053 An implementation survey with seven questions related to the 1054 implementer's support of OSPFv2 Segment Routing was sent to the OSPF 1055 WG list and several known implementers. This section contains 1056 responses from three implementers who completed the survey. No 1057 external means were used to verify the accuracy of the information 1058 submitted by the respondents. The respondents are considered experts 1059 on the products they reported on. Additionally, responses were 1060 omitted from implementers who indicated that they have not 1061 implemented the function yet. 1063 This section will be removed before publication as an RFC. 1065 Responses from Nokia (former Alcatel-Lucent): 1067 Link to a web page describing the implementation: 1068 https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/ 1069 3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Un 1070 icast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf 1072 The implementation's level of maturity: Production. 1074 Coverage: We have implemented all sections and have support for the 1075 latest draft. 1077 Licensing: Part of the software package that needs to be purchased. 1079 Implementation experience: Great spec. We also performed inter- 1080 operability testing with Cisco's OSPF Segment Routing implementation. 1082 Contact information: wim.henderickx@nokia.com 1084 Responses from Cisco Systems: 1086 Link to a web page describing the implementation: 1088 http://www.segment-routing.net/home/tutorial 1090 The implementation's level of maturity: Production. 1092 Coverage: All sections have been implemented according to the latest 1093 draft. 1095 Licensing: Part of a commercial software package. 1097 Implementation experience: Many aspects of the draft are result of 1098 the actual implementation experience, as the draft evolved from its 1099 initial version to the current one. Interoperability testing with 1100 Alcatel-Lucent was performed, which confirmed the draft's ability to 1101 serve as a reference for the implementors. 1103 Contact information: ppsenak@cisco.com 1105 Responses from Juniper: 1107 The implementation's name and/or a link to a web page describing the 1108 implementation: 1110 Feature name is OSPF SPRING 1112 The implementation's level of maturity: To be released in 16.2 1113 (second half of 2016) 1115 Coverage: All sections implemented except Sections 4, and 6. 1117 Licensing: JUNOS Licensing needed. 1119 Implementation experience: NA 1121 Contact information: shraddha@juniper.net 1123 10. Security Considerations 1125 With the OSPFv2 segment routing extensions defined herein, OSPFv2 1126 will now program the MPLS data plane [RFC3031] in addition to the IP 1127 data plane. Previously, LDP [RFC5036] or another label distribution 1128 mechanism was required to advertise MPLS labels and program the MPLS 1129 data plane. 1131 In general, the same types of attacks that can be carried out on the 1132 IP control plane can be carried out on the MPLS control plane 1133 resulting in traffic being misrouted in the respective data planes. 1134 However, the latter may be more difficult to detect and isolate. 1136 Existing security extensions as described in [RFC2328] and [RFC7684] 1137 apply to these segment routing extensions. While OSPF is under a 1138 single administrative domain, there may be deployments where 1139 potential attackers have access to one or more networks in the OSPF 1140 routing domain. In these deployments, stronger authentication 1141 mechanisms such as those specified in [RFC7474] SHOULD be used. 1143 Implementations must assure that malformed TLV and Sub-TLV defined in 1144 this document are detected and do not provide a vulnerability for 1145 attackers to crash the OSPFv2 router or routing process. Reception 1146 of malformed TLV or Sub-TLV SHOULD be counted and/or logged for 1147 further analysis. Logging of malformed TLVs and Sub-TLVs should be 1148 rate-limited to prevent a Denial of Service (DoS) attack (distributed 1149 or otherwise) from overloading the OSPF control plane. 1151 11. Contributors 1153 The following people gave a substantial contribution to the content 1154 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1155 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1156 Saku Ytti. 1158 12. Acknowledgements 1160 We would like to thank Anton Smirnov for his contribution. 1162 Thanks to Acee Lindem for the detail review of the draft, 1163 corrections, as well as discussion about details of the encoding. 1165 13. References 1166 13.1. Normative References 1168 [I-D.ietf-spring-segment-routing] 1169 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1170 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1171 spring-segment-routing-12 (work in progress), June 2017. 1173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1174 Requirement Levels", BCP 14, RFC 2119, 1175 DOI 10.17487/RFC2119, March 1997, 1176 . 1178 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1179 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1180 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1181 . 1183 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 1184 and Point-to-Multipoint Interface Type", RFC 6845, 1185 DOI 10.17487/RFC6845, January 2013, 1186 . 1188 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 1189 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 1190 2014, . 1192 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1193 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1194 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1195 2015, . 1197 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1198 S. Shaffer, "Extensions to OSPF for Advertising Optional 1199 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1200 February 2016, . 1202 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1203 Writing an IANA Considerations Section in RFCs", BCP 26, 1204 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1205 . 1207 13.2. Informative References 1209 [I-D.ietf-spring-conflict-resolution] 1210 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 1211 "Segment Routing MPLS Conflict Resolution", draft-ietf- 1212 spring-conflict-resolution-05 (work in progress), July 1213 2017. 1215 [I-D.ietf-spring-segment-routing-ldp-interop] 1216 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 1217 S. Litkowski, "Segment Routing interworking with LDP", 1218 draft-ietf-spring-segment-routing-ldp-interop-09 (work in 1219 progress), September 2017. 1221 [I-D.ietf-spring-segment-routing-mpls] 1222 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1223 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1224 data plane", draft-ietf-spring-segment-routing-mpls-10 1225 (work in progress), June 2017. 1227 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1228 DOI 10.17487/RFC2328, April 1998, 1229 . 1231 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 1232 "Security Extension for OSPFv2 When Using Manual Key 1233 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 1234 . 1236 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1237 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1238 Packet Routing in Networking (SPRING) Problem Statement 1239 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1240 2016, . 1242 Authors' Addresses 1244 Peter Psenak (editor) 1245 Cisco Systems, Inc. 1246 Apollo Business Center 1247 Mlynske nivy 43 1248 Bratislava 821 09 1249 Slovakia 1251 Email: ppsenak@cisco.com 1253 Stefano Previdi (editor) 1254 Cisco Systems, Inc. 1255 Via Del Serafico, 200 1256 Rome 00142 1257 Italy 1259 Email: stefano@previdi.net 1260 Clarence Filsfils 1261 Cisco Systems, Inc. 1262 Brussels 1263 Belgium 1265 Email: cfilsfil@cisco.com 1267 Hannes Gredler 1268 RtBrick Inc. 1270 Email: hannes@rtbrick.com 1272 Rob Shakir 1273 Google, Inc. 1274 1600 Amphitheatre Parkway 1275 Mountain View, CA 94043 1276 US 1278 Email: robjs@google.com 1280 Wim Henderickx 1281 Nokia 1282 Copernicuslaan 50 1283 Antwerp 2018 1284 BE 1286 Email: wim.henderickx@nokia.com 1288 Jeff Tantsura 1289 Individual 1290 US 1292 Email: jefftant.ietf@gmail.com