idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-19.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 (August 25, 2017) is 2429 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 322 -- Looks like a reference, but probably isn't: '199' on line 322 -- Looks like a reference, but probably isn't: '1000' on line 323 -- Looks like a reference, but probably isn't: '1099' on line 323 -- Looks like a reference, but probably isn't: '500' on line 324 -- Looks like a reference, but probably isn't: '599' on line 324 == Missing Reference: 'RFC3031' is mentioned on line 1103, but not defined == Missing Reference: 'RFC5036' is mentioned on line 1104, 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-08 == 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: February 26, 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 August 25, 2017 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-19 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 http://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 February 26, 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 (http://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 . . . . . . . . . . . . . . . . . . . . 3 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 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 95 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 96 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 97 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 13.1. Normative References . . . . . . . . . . . . . . . . . . 25 99 13.2. Informative References . . . . . . . . . . . . . . . . . 26 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 102 1. Introduction 104 Segment Routing (SR) allows a flexible definition of end-to-end paths 105 within IGP topologies by encoding paths as sequences of topological 106 sub-paths, called "segments". These segments are advertised by the 107 link-state routing protocols (IS-IS and OSPF). Prefix segments 108 represent an ECMP-aware shortest-path to a prefix (or a node), as per 109 the state of the IGP topology. Adjacency segments represent a hop 110 over a specific adjacency between two nodes in the IGP. A prefix 111 segment is typically a multi-hop path while an adjacency segment, in 112 most cases, is a one-hop path. SR's control-plane can be applied to 113 both IPv6 and MPLS data-planes, and does not require any additional 114 signalling (other than IGP extensions). The IPv6 data plane is out 115 of the scope of this specification - it is not applicable to OSPFv2 116 which only supports the IPv4 address-family. For example, when used 117 in MPLS networks, SR paths do not require any LDP or RSVP-TE 118 signalling. However, SR can interoperate in the presence of LSPs 119 established with RSVP or LDP. 121 There are additional segment types, e.g., Binding SID defined in 122 [I-D.ietf-spring-segment-routing]. 124 This draft describes the OSPF extensions required for Segment 125 Routing. 127 Segment Routing architecture is described in 128 [I-D.ietf-spring-segment-routing]. 130 Segment Routing use cases are described in [RFC7855]. 132 2. Segment Routing Identifiers 134 Segment Routing defines various types of Segment Identifiers (SIDs): 135 Prefix-SID, Adjacency-SID, LAN Adjacency SID, and Binding SID. 137 Extended Prefix/Link Opaque LSAs defined in [RFC7684] are used for 138 advertisements of the various SID types. 140 2.1. SID/Label Sub-TLV 142 The SID/Label Sub-TLV appears in multiple TLVs or Sub-TLVs defined 143 later in this document. It is used to advertise the SID or label 144 associated with a prefix or adjacency. The SID/Label Sub-TLV has 145 following format: 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Type | Length | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | SID/Label (variable) | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 where: 157 Type: TBD, suggested value 1 159 Length: Variable, 3 or 4 octet 161 SID/Label: If length is set to 3, then the 20 rightmost bits 162 represent a label. If length is set to 4, then the value 163 represents a 32-bit SID. 165 The receiving router MUST ignore the SID/Label Sub-TLV if the 166 length is other then 3 or 4. 168 3. Segment Routing Capabilities 170 Segment Routing requires some additional router capabilities to be 171 advertised to other routers in the area. 173 These SR capabilities are advertised in the Router Information Opaque 174 LSA (defined in [RFC7770]). 176 3.1. SR-Algorithm TLV 178 The SR-Algorithm TLV is a top-level TLV of the Router Information 179 Opaque LSA (defined in [RFC7770]). 181 The SR-Algorithm TLV is optional. It SHOULD only be advertised once 182 in the Router Information Opaque LSA. If the SR-Algorithm TLV is not 183 advertised by the node, such node is considered as not being segment 184 routing capable. 186 An SR Router may use various algorithms when calculating reachability 187 to OSPF routers or prefixes in an OSPF area. Examples of these 188 algorithms are metric based Shortest Path First (SPF), various 189 flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a 190 router to advertise the algorithms currently used by the router to 191 other routers in an OSPF area. The SR-Algorithm TLV has following 192 format: 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Type | Length | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Algorithm 1 | Algorithm... | Algorithm n | | 200 +- -+ 201 | | 202 + + 204 where: 206 Type: TBD, suggested value 8 208 Length: Variable, dependent on number of algorithms advertised. 210 Algorithm: Single octet identifying the algorithm. The following 211 values are defined by this document: 213 0: Shortest Path First (SPF) algorithm based on link metric. 214 This is the standard shortest path algorithm as computed by the 215 OSPF protocol. Consistent with the deployed practice for link- 216 state protocols, Algorithm 0 permits any node to overwrite the 217 SPF path with a different path based on its local policy. If 218 the SR-Algorithm TLV is advertised, Algorithm 0 MUST be 219 included. 221 1: Strict Shortest Path First (SPF) algorithm based on link 222 metric. The algorithm is identical to Algorithm 0 but 223 Algorithm 1 requires that all nodes along the path will honor 224 the SPF routing decision. Local policy at the node claiming 225 support for Algorithm 1 MUST NOT alter the SPF paths computed 226 by Algorithm 1. 228 When multiple SR-Algorithm TLVs are received from a given router, the 229 receiver SHOULD use the first occurrence of the TLV in the Router 230 Information LSA. If the SR-Algorithm TLV appears in multiple Router 231 Information LSAs that have different flooding scopes, the SR- 232 Algorithm TLV in the Router Information LSA with the area-scoped 233 flooding scope SHOULD be used. If the SR-Algorithm TLV appears in 234 multiple Router Information LSAs that have the same flooding scope, 235 the SR-Algorithm TLV in the Router Information (RI) LSA with the 236 numerically smallest Instance ID SHOULD be used and subsequent 237 instances of the SR-Algorithm TLV SHOULD be ignored. 239 The RI LSA can be advertised at any of the defined opaque flooding 240 scopes (link, area, or Autonomous System (AS)). For the purpose of 241 SR-Algorithm TLV advertisement, area-scoped flooding is REQUIRED. 243 3.2. SID/Label Range TLV 245 Prefix SIDs MAY be advertised in a form of an index as described in 246 Section 5. Such index defines the offset in the SID/Label space 247 advertised by the router. The SID/Label Range TLV is used to 248 advertise such SID/Label space. 250 The SID/Label Range TLV is a top-level TLV of the Router Information 251 Opaque LSA (defined in [RFC7770]). 253 The SID/Label Range TLV MAY appear multiple times and has the 254 following format: 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Type | Length | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Range Size | Reserved | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Sub-TLVs (variable) | 264 +- -+ 265 | | 266 + + 268 where: 270 Type: TBD, suggested value 9 272 Length: Variable, dependent on Sub-TLVs. 274 Range Size: 3-octet SID/label range size (i.e., the number of SIDs 275 or labels in the range including the first SID/label). It MUST be 276 greater than 0. 278 Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as 279 defined in Section 2.1. The SID/Label Sub-TLV MUST be included in 280 the SID/Label Range TLV. The SID/Label advertised in the SID/Label 281 Sub-TLV represents the first SID/Label in the advertised range. 283 Only a single SID/Label Sub-TLV MAY be advertised in SID/Label Range 284 TLV. If more then one SID/Label Sub-TLVs are present, the SID/Label 285 Range TLV MUST be ignored. 287 Multiple occurrences of the SID/Label Range TLV MAY be advertised, in 288 order to advertise multiple ranges. In such case: 290 o The originating router MUST encode each range into a different 291 SID/Label Range TLV. 293 o The originating router decides the order in which the set of SID/ 294 Label Range TLVs are advertised inside the Router Information 295 Opaque LSA. The originating router MUST ensure the order is the 296 same after a graceful restart (using checkpointing, non-volatile 297 storage, or any other mechanism) in order to assure the SID/label 298 range and SID index correspondence is preserved across graceful 299 restarts. 301 o The receiving router MUST adhere to the order in which the ranges 302 are advertised when calculating a SID/label from a SID index. 304 o The originating router MUST NOT advertise overlapping ranges. 306 o When a router receives multiple overlapping ranges, it MUST 307 conform to the procedures defined in 308 [I-D.ietf-spring-conflict-resolution]. 310 The following example illustrates the advertisement of multiple 311 ranges: 313 The originating router advertises the following ranges: 315 Range 1: Range Size: 100 SID/Label Sub-TLV: 100 316 Range 1: Range Size: 100 SID/Label Sub-TLV: 1000 317 Range 1: Range Size: 100 SID/Label Sub-TLV: 500 319 The receiving routers concatenate the ranges and build the Segment 320 Routing Global Block (SRGB) as follows: 322 SRGB = [100, 199] 323 [1000, 1099] 324 [500, 599] 326 The indexes span multiple ranges: 328 index=0 means label 100 329 ... 330 index 99 means label 199 331 index 100 means label 1000 332 index 199 means label 1099 333 ... 334 index 200 means label 500 335 ... 337 The RI LSA can be advertised at any of the defined flooding scopes 338 (link, area, or autonomous system (AS)). For the purpose of SID/ 339 Label Range TLV advertisement, area-scoped flooding is REQUIRED. 341 3.3. SR Local Block TLV 343 The SR Local Block TLV (SRLB TLV) contains the range of labels the 344 node has reserved for local SIDs. SIDs from the SRLB MAY be used for 345 Adjacency-SIDs, but also by components other than the OSPF protocol. 346 As an example, an application or a controller may instruct the router 347 to allocate a specific local SID. Some controllers or applications 348 may use the control plane to discover the available set of local SIDs 349 on a particular router. In such cases, the SRLG is advertised in the 350 control plane. The requirement to advertise the SRLB is further 351 described in [I-D.ietf-spring-segment-routing-mpls]. The SRLB TLV is 352 used to advertise the SRLB. 354 The SRLB TLV is a top-level TLV of the Router Information Opaque LSA 355 (defined in [RFC7770]). 357 The SRLB TLV MAY appear multiple times in the Router Information 358 Opaque LSA and has the following format: 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type | Length | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Range Size | Reserved | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Sub-TLVs (variable) | 368 +- -+ 369 | | 370 + + 372 where: 374 Type: TBD, suggested value 12 376 Length: Variable, dependent on Sub-TLVs. 378 Range Size: 3-octet SID/label range size (i.e., the number of SIDs 379 or labels in the range including the first SID/label). It MUST be 380 greater than 0. 382 Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as 383 defined in Section 2.1. The SID/Label Sub-TLV MUST be included in 384 the SRLB TLV. The SID/Label advertised in the SID/Label Sub-TLV 385 represents the first SID/Label in the advertised range. 387 Only a single SID/Label Sub-TLV MAY be advertised in the SRLB TLV. 388 If more then one SID/Label Sub-TLVs are present, the SRLB TLV MUST be 389 ignored. 391 The originating router MUST NOT advertise overlapping ranges. 393 Each time a SID from the SRLB is allocated, it SHOULD also be 394 reported to all components (e.g., controller or applications) in 395 order for these components to have an up-to-date view of the current 396 SRLB allocation. This is required to avoid collisions between 397 allocation instructions. 399 Within the context of OSPF, the reporting of local SIDs is done 400 through OSPF Sub-TLVs such as the Adjacency-SID (Section 6). 401 However, the reporting of allocated local SIDs may also be done 402 through other means and protocols which are outside the scope of this 403 document. 405 A router advertising the SRLB TLV may also have other label ranges, 406 outside of the SRLB, used for its local allocation purposes which are 407 NOT advertised in the SRLB TLV. For example, it is possible that an 408 Adjacency-SID is allocated using a local label that is not part of 409 the SRLB. 411 The RI LSA can be advertised at any of the defined flooding scopes 412 (link, area, or autonomous system (AS)). For the purpose of SRLB TLV 413 advertisement, area-scoped flooding is REQUIRED. 415 3.4. SRMS Preference TLV 417 The Segment Routing Mapping Server Preference TLV (SRMS Preference 418 TLV) is used to advertise a preference associated with the node that 419 acts as an SR Mapping Server. The role of an SRMS is described in 420 [I-D.ietf-spring-segment-routing-ldp-interop]. SRMS preference is 421 defined in [I-D.ietf-spring-conflict-resolution]. 423 The SRMS Preference TLV is a top-level TLV of the Router Information 424 Opaque LSA (defined in [RFC7770]). 426 The SRMS Preference TLV MAY only be advertised once in the Router 427 Information Opaque LSA and has the following format: 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Type | Length | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Preference | Reserved | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 where: 439 Type: TBD, suggested value 13 441 Length: 4 octets 443 Preference: 1 octet. SRMS preference value from 0 to 255. 445 When multiple SRMS Preference TLVs are received from a given router, 446 the receiver SHOULD use the first occurrence of the TLV in the Router 447 Information LSA. If the SRMS Preference TLV appears in multiple 448 Router Information LSAs that have different flooding scopes, the SRMS 449 Preference TLV in the Router Information LSA with the narrowest 450 flooding scope SHOULD be used. If the SRMS Preference TLV appears in 451 multiple Router Information LSAs that have the same flooding scope, 452 the SRMS Preference TLV in the Router Information LSA with the 453 numerically smallest Instance ID SHOULD be used and subsequent 454 instances of the SRMS Preference TLV SHOULD be ignored. 456 The RI LSA can be advertised at any of the defined flooding scopes 457 (link, area, or autonomous system (AS)). For the purpose of the SRMS 458 Preference TLV advertisement, AS-scoped flooding SHOULD be used. 459 This is because SRMS servers can be located in a different area then 460 consumers of the SRMS advertisements. If the SRMS advertisements 461 from the SRMS server are only used inside the SRMS server's area, 462 area-scoped flooding MAY be used. 464 4. OSPF Extended Prefix Range TLV 466 In some cases it is useful to advertise attributes for a range of 467 prefixes. The Segment Routing Mapping Server, which is described in 468 [I-D.ietf-spring-segment-routing-ldp-interop], is an example where we 469 need a single advertisement to advertise SIDs for multiple prefixes 470 from a contiguous address range. 472 The OSPF Extended Prefix Range TLV, which is a top level TLV of the 473 Extended Prefix LSA described in [RFC7684] is defined for this 474 purpose. 476 Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each 477 OSPF Extended Prefix Opaque LSA, but all prefix ranges included in a 478 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 479 scope. The OSPF Extended Prefix Range TLV has the following format: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Type | Length | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Prefix Length | AF | Range Size | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Flags | Reserved | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Address Prefix (variable) | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Sub-TLVs (variable) | 493 +- -+ 494 | | 496 where: 498 Type: TBD, suggested value 2. 500 Length: Variable, dependent on Sub-TLVs. 502 Prefix length: Length of prefix in bits. 504 AF: Address family for the prefix. Currently, the only supported 505 value is 0 for IPv4 unicast. The inclusion of address family in 506 this TLV allows for future extension. 508 Range size: Represents the number of prefixes that are covered by 509 the advertisement. The Range Size MUST NOT exceed the number of 510 prefixes that could be satisfied by the prefix length without 511 including the IPv4 multicast address range (224.0.0.0/3). 513 Flags: Single octet field. The following flags are defined: 515 0 1 2 3 4 5 6 7 516 +--+--+--+--+--+--+--+--+ 517 |IA| | | | | | | | 518 +--+--+--+--+--+--+--+--+ 520 where: 522 IA-Flag: Inter-Area flag. If set, advertisement is of inter- 523 area type. An ABR that is advertising the OSPF Extended Prefix 524 Range TLV between areas MUST set this bit. 526 This bit is used to prevent redundant flooding of Prefix Range 527 TLVs between areas as follows: 529 An ABR only propagates an inter-area Prefix Range 530 advertisement from the backbone area to connected non- 531 backbone areas if the advertisement is considered to be the 532 best one. The following rules are used to select the best 533 range from the set of advertisements for the same Prefix 534 Range: 536 An ABR always prefers intra-area Prefix Range 537 advertisements over inter-area advertisements. 539 An ABR does not consider inter-area Prefix Range 540 advertisements coming from non-backbone areas. 542 Address Prefix: For the address family IPv4 unicast, the prefix 543 itself is encoded as a 32-bit value. The default route is 544 represented by a prefix of length 0. Prefix encoding for other 545 address families is beyond the scope of this specification. 547 5. Prefix SID Sub-TLV 549 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV 550 described in [RFC7684] and the OSPF Extended Prefix Range TLV 551 described in Section 4. It MAY appear more than once in the parent 552 TLV and has the following format: 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Type | Length | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Flags | Reserved | MT-ID | Algorithm | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | SID/Index/Label (variable) | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 where: 566 Type: TBD, suggested value 2. 568 Length: 7 or 8 octets, dependent on the V-flag 570 Flags: Single octet field. The following flags are defined: 572 0 1 2 3 4 5 6 7 573 +--+--+--+--+--+--+--+--+ 574 | |NP|M |E |V |L | | | 575 +--+--+--+--+--+--+--+--+ 577 where: 579 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 580 NOT pop the Prefix-SID before delivering packets to the node 581 that advertised the Prefix-SID. 583 M-Flag: Mapping Server Flag. If set, the SID was advertised by 584 a Segment Routing Mapping Server as described in 585 [I-D.ietf-spring-segment-routing-ldp-interop]. 587 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 588 the Prefix-SID originator MUST replace the Prefix-SID with the 589 Explicit-NULL label (0 for IPv4) before forwarding the packet. 591 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 592 an absolute value. If not set, then the Prefix-SID carries an 593 index. 595 L-Flag: Local/Global Flag. If set, then the value/index 596 carried by the Prefix-SID has local significance. If not set, 597 then the value/index carried by this Sub-TLV has global 598 significance. 600 Other bits: Reserved. These MUST be zero when sent and are 601 ignored when received. 603 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 605 Algorithm: Single octet identifying the algorithm the Prefix-SID 606 is associated with as defined in Section 3.1. 608 A router receiving a Prefix-SID from a remote node and with an 609 algorithm value that such remote node has not advertised in the 610 SR-Algorithm Sub-TLV (Section 3.1) MUST ignore the Prefix-SID Sub- 611 TLV. 613 SID/Index/Label: According to the V and L flags, it contains 614 either: 616 A 32-bit index defining the offset in the SID/Label space 617 advertised by this router. 619 A 24-bit label where the 20 rightmost bits are used for 620 encoding the label value. 622 If an OSPF router advertises multiple Prefix-SIDs for the same 623 prefix, topology and algorithm, all of them MUST be ignored. 625 When calculating the outgoing label for the prefix, the router MUST 626 take into account, as described below, the E, NP and M flags 627 advertised by the next-hop router if that router advertised the SID 628 for the prefix. This MUST be done regardless of whether the next-hop 629 router contributes to the best path to the prefix. 631 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 632 Prefix-SIDs allocated to inter-area prefixes that are originated by 633 the ABR based on intra-area or inter-area reachability between areas, 634 unless the advertised prefix is directly attached to the ABR. 636 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 637 Prefix-SIDs allocated to redistributed prefixes, unless the 638 redistributed prefix is directly attached to the ASBR. 640 If the NP-Flag is not set, then any upstream neighbor of the Prefix- 641 SID originator MUST pop the Prefix-SID. This is equivalent to the 642 penultimate hop popping mechanism used in the MPLS dataplane. If the 643 NP-flag is not set, then the received E-flag is ignored. 645 If the NP-flag is set then: 647 If the E-flag is not set, then any upstream neighbor of the 648 Prefix-SID originator MUST keep the Prefix-SID on top of the 649 stack. This is useful when the originator of the Prefix-SID must 650 stitch the incoming packet into a continuing MPLS LSP to the final 651 destination. This could occur at an Area Border Router (prefix 652 propagation from one area to another) or at an AS Boundary Router 653 (prefix propagation from one domain to another). 655 If the E-flag is set, then any upstream neighbor of the Prefix-SID 656 originator MUST replace the Prefix-SID with an Explicit-NULL 657 label. This is useful, e.g., when the originator of the Prefix- 658 SID is the final destination for the related prefix and the 659 originator wishes to receive the packet with the original EXP 660 bits. 662 When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at 663 reception. 665 As the Mapping Server does not specify the originator of a prefix 666 advertisement, it is not possible to determine PHP behavior solely 667 based on the Mapping Server advertisement. However, PHP behavior 668 SHOULD be done in following cases: 670 The Prefix is intra-area type and the downstream neighbor is the 671 originator of the prefix. 673 The Prefix is inter-area type and downstream neighbor is an ABR, 674 which is advertising prefix reachability and is also generating 675 the Extended Prefix TLV with the A-flag set for this prefix as 676 described in section 2.1 of [RFC7684]. 678 The Prefix is external type and downstream neighbor is an ASBR, 679 which is advertising prefix reachability and is also generating 680 the Extended Prefix TLV with the A-flag set for this prefix as 681 described in section 2.1 of [RFC7684]. 683 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 684 the value advertised in the Prefix SID Sub-TLV is interpreted as a 685 starting SID/Label value. 687 Example 1: If the following router addresses (loopback addresses) 688 need to be mapped into the corresponding Prefix SID indexes: 690 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 691 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 692 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 693 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 695 then the Prefix field in the Extended Prefix Range TLV would be set 696 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 697 set to 4, and the Index value in the Prefix-SID Sub-TLV would be set 698 to 1. 700 Example 2: If the following prefixes need to be mapped into the 701 corresponding Prefix-SID indexes: 703 192.0.2.0/30, Prefix-SID: Index 51 704 192.0.2.4/30, Prefix-SID: Index 52 705 192.0.2.8/30, Prefix-SID: Index 53 706 192.0.2.12/30, Prefix-SID: Index 54 707 192.0.2.16/30, Prefix-SID: Index 55 708 192.0.2.20/30, Prefix-SID: Index 56 709 192.0.2.24/30, Prefix-SID: Index 57 711 then the Prefix field in the Extended Prefix Range TLV would be set 712 to 192.0.2.0, Prefix Length would be set to 30, Range Size would be 713 7, and the Index value in the Prefix-SID Sub-TLV would be set to 51. 715 6. Adjacency Segment Identifier (Adj-SID) 717 An Adjacency Segment Identifier (Adj-SID) represents a router 718 adjacency in Segment Routing. 720 6.1. Adj-SID Sub-TLV 722 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 723 [RFC7684]. It MAY appear multiple times in the Extended Link TLV. 724 The Adj-SID Sub-TLV has the following format: 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Type | Length | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Flags | Reserved | MT-ID | Weight | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | SID/Label/Index (variable) | 734 +---------------------------------------------------------------+ 736 where: 738 Type: TBD, suggested value 2. 740 Length: 7 or 8 octets, dependent on the V flag. 742 Flags: Single octet field containing the following flags: 744 0 1 2 3 4 5 6 7 745 +-+-+-+-+-+-+-+-+ 746 |B|V|L|G|P| | 747 +-+-+-+-+-+-+-+-+ 749 where: 751 B-Flag: Backup Flag. If set, the Adj-SID refers to an 752 adjacency that is eligible for protection (e.g., using IPFRR or 753 MPLS-FRR) as described in section 3.5 of 754 [I-D.ietf-spring-segment-routing]. 756 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 757 an absolute value. If not set, then the Adj-SID carries an 758 index. 760 The L-Flag: Local/Global Flag. If set, then the value/index 761 carried by the Adj-SID has local significance. If not set, 762 then the value/index carried by this Sub-TLV has global 763 significance. 765 The G-Flag: Group Flag. When set, the G-Flag indicates that 766 the Adj-SID refers to a group of adjacencies (and therefore MAY 767 be assigned to other adjacencies as well). 769 P-Flag. Persistent flag. When set, the P-Flag indicates that 770 the Adj-SID is persistently allocated, i.e., the Adj-SID value 771 remains consistent across router restart and/or interface flap. 773 Other bits: Reserved. These MUST be zero when sent and are 774 ignored when received. 776 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 778 Weight: Weight used for load-balancing purposes. The use of the 779 weight is defined in [I-D.ietf-spring-segment-routing]. 781 SID/Index/Label: According to the V and L flags, it contains 782 either: 784 A 32-bit index defining the offset in the SID/Label space 785 advertised by this router. 787 A 24-bit label where the 20 rightmost bits are used for 788 encoding the label value. 790 An SR capable router MAY allocate an Adj-SID for each of its 791 adjacencies and set the B-Flag when the adjacency is eligible for 792 protection by an FRR mechanism (IP or MPLS) as described in section 793 3.5 of [I-D.ietf-spring-segment-routing]. 795 An SR capable router MAY allocate more than one Adj-SID to an 796 adjacency 798 An SR capable router MAY allocate the same Adj-SID to different 799 adjacencies 801 When the P-flag is not set, the Adj-SID MAY be persistent. When the 802 P-flag is set, the Adj-SID MUST be persistent. 804 6.2. LAN Adj-SID Sub-TLV 806 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 807 in [RFC7684]. It MAY appear multiple times in the Extended-Link TLV. 808 It is used to advertise a SID/Label for an adjacency to a non-DR 809 router on a broadcast, NBMA, or hybrid [RFC6845] network. 811 0 1 2 3 812 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 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Type | Length | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Flags | Reserved | MT-ID | Weight | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Neighbor ID | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | SID/Label/Index (variable) | 821 +---------------------------------------------------------------+ 823 where: 825 Type: TBD, suggested value 3. 827 Length: 11 or 12 octets, dependent on V-flag. 829 Flags: same as in Section 6.1 831 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 833 Weight: Weight used for load-balancing purposes. The use of the 834 weight is defined in [I-D.ietf-spring-segment-routing]. 836 Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- 837 SID is advertised. 839 SID/Index/Label: According to the V and L flags, it contains 840 either: 842 A 32-bit index defining the offset in the SID/Label space 843 advertised by this router. 845 A 24-bit label where the 20 rightmost bits are used for 846 encoding the label value. 848 When the P-flag is not set, the Adj-SID MAY be persistent. When 849 the P-flag is set, the Adj-SID MUST be persistent. 851 7. Elements of Procedure 853 7.1. Intra-area Segment routing in OSPFv2 855 An OSPFv2 router that supports segment routing MAY advertise Prefix- 856 SIDs for any prefix to which it is advertising reachability (e.g., a 857 loopback IP address as described in Section 5). 859 A Prefix-SID can also be advertised by the SR Mapping Servers (as 860 described in [I-D.ietf-spring-segment-routing-ldp-interop]). A 861 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 862 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 863 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 864 MUST be advertised by all of them. The flooding scope of the OSPF 865 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 866 could be either area-scoped or AS-scoped and is determined based on 867 the configuration of the SR Mapping Server. 869 An SR Mapping Server MUST use the OSPF Extended Prefix Range TLV when 870 advertising SIDs for prefixes. Prefixes of different route-types can 871 be combined in a single OSPF Extended Prefix Range TLV advertised by 872 an SR Mapping Server. Because the OSPF Extended Prefix Range TLV 873 doesn't include a Route-Type field, as in the OSPF Extended Prefix 874 TLV, it is possible to include adjacent prefixes from different 875 Route-Types in the OSPF Extended Prefix Range TLV. 877 Area-scoped OSPF Extended Prefix Range TLVs are propagated between 878 areas. Similar to propagation of prefixes between areas, an ABR only 879 propagates the OSPF Extended Prefix Range TLV that it considers to be 880 the best from the set it received. The rules used to pick the best 881 OSPF Extended Prefix Range TLV are described in Section 4. 883 When propagating an OSPF Extended Prefix Range TLV between areas, 884 ABRs MUST set the IA-Flag, that is used to prevent redundant flooding 885 of the OSPF Extended Prefix Range TLV between areas as described in 886 Section 4. 888 7.2. Inter-area Segment routing in OSPFv2 890 In order to support SR in a multi-area environment, OSPFv2 must 891 propagate Prefix-SID information between areas. The following 892 procedure is used to propagate Prefix SIDs between areas. 894 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 895 prefix to all its connected areas, it will also originate an Extended 896 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 897 the Extended Prefix Opaque LSA type will be set to area-local scope. 898 The route-type in the OSPF Extended Prefix TLV is set to inter-area. 899 The Prefix-SID Sub-TLV will be included in this LSA and the Prefix- 900 SID value will be set as follows: 902 The ABR will look at its best path to the prefix in the source 903 area and find the advertising router associated with the best path 904 to that prefix. 906 The ABR will then determine if such router advertised a Prefix-SID 907 for the prefix and use it when advertising the Prefix-SID to other 908 connected areas. 910 If no Prefix-SID was advertised for the prefix in the source area 911 by the router that contributes to the best path to the prefix, the 912 originating ABR will use the Prefix-SID advertised by any other 913 router when propagating the Prefix-SID for the prefix to other 914 areas. 916 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 917 route to all its connected areas, it will also originate an Extended 918 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 919 the Extended Prefix Opaque LSA type will be set to area-local scope. 920 The route-type in OSPF Extended Prefix TLV is set to inter-area. The 921 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 922 will be set as follows: 924 The ABR will look at its best path to the prefix in the backbone 925 area and find the advertising router associated with the best path 926 to that prefix. 928 The ABR will then determine if such router advertised a Prefix-SID 929 for the prefix and use it when advertising the Prefix-SID to other 930 connected areas. 932 If no Prefix-SID was advertised for the prefix in the backbone 933 area by the ABR that contributes to the best path to the prefix, 934 the originating ABR will use the Prefix-SID advertised by any 935 other router when propagating the Prefix-SID for the prefix to 936 other areas. 938 7.3. Segment Routing for External Prefixes 940 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 941 SR, generates Type-5 LSAs, it should also originate Extended Prefix 942 Opaque LSAs, as described in [RFC7684]. The flooding scope of the 943 Extended Prefix Opaque LSA type is set to AS-wide scope. The route- 944 type in the OSPF Extended Prefix TLV is set to external. The Prefix- 945 SID Sub-TLV is included in this LSA and the Prefix-SID value will be 946 set to the SID that has been reserved for that prefix. 948 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 949 also advertise the Prefix-SID for the prefix. The NSSA ABR 950 determines its best path to the prefix advertised in the translated 951 Type-7 LSA and finds the advertising router associated with that 952 path. If the advertising router has advertised a Prefix-SID for the 953 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 954 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 955 router will be used. 957 7.4. Advertisement of Adj-SID 959 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 960 using the Adj-SID Sub-TLV as described in Section 6. 962 7.4.1. Advertisement of Adj-SID on Point-to-Point Links 964 An Adj-SID MAY be advertised for any adjacency on a P2P link that is 965 in neighbor state 2-Way or higher. If the adjacency on a P2P link 966 transitions from the FULL state, then the Adj-SID for that adjacency 967 MAY be removed from the area. If the adjacency transitions to a 968 state lower then 2-Way, then the Adj-SID advertisement MUST be 969 withdrawn from the area. 971 7.4.2. Adjacency SID on Broadcast or NBMA Interfaces 973 Broadcast, NBMA, or hybrid [RFC6845] networks in OSPF are represented 974 by a star topology where the Designated Router (DR) is the central 975 point to which all other routers on the broadcast, NBMA, or hybrid 976 network connect. As a result, routers on the broadcast, NBMA, or 977 hybrid network advertise only their adjacency to the DR. Routers 978 that do not act as DR do not form or advertise adjacencies with each 979 other. They do, however, maintain 2-Way adjacency state with each 980 other and are directly reachable. 982 When Segment Routing is used, each router on the broadcast, NBMA, or 983 hybrid network MAY advertise the Adj-SID for its adjacency to the DR 984 using the Adj-SID Sub-TLV as described in Section 6.1. 986 SR capable routers MAY also advertise a LAN-Adj-SID for other 987 neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid 988 network using the LAN-ADJ-SID Sub-TLV as described in Section 6.2. 990 8. IANA Considerations 992 This specification updates several existing OSPF registries. 994 8.1. OSPF OSPF Router Information (RI) TLVs Registry 996 o 8 (IANA Preallocated) - SR-Algorithm TLV 998 o 9 (IANA Preallocated) - SID/Label Range TLV 1000 o 12 - SR Local Block TLV 1002 o 13 - SRMS Preference TLV 1004 8.2. OSPF Extended Prefix LSA TLV Registry 1006 Following values are allocated: 1008 o 2 - OSPF Extended Prefix Range TLV 1010 8.3. OSPF Extended Prefix LSA Sub-TLV Registry 1012 Following values are allocated: 1014 o 1 - SID/Label Sub-TLV 1016 o 2 - Prefix SID Sub-TLV 1018 8.4. OSPF Extended Link LSA Sub-TLV Registry 1020 Following initial values are allocated: 1022 o 1 - SID/Label Sub-TLV 1024 o 2 - Adj-SID Sub-TLV 1026 o 3 - LAN Adj-SID/Label Sub-TLV 1028 9. Implementation Status 1030 An implementation survey with seven questions related to the 1031 implementer's support of OSPFv2 Segment Routing was sent to the OSPF 1032 WG list and several known implementers. This section contains 1033 responses from three implementers who completed the survey. No 1034 external means were used to verify the accuracy of the information 1035 submitted by the respondents. The respondents are considered experts 1036 on the products they reported on. Additionally, responses were 1037 omitted from implementers who indicated that they have not 1038 implemented the function yet. 1040 This section will be removed before publication as an RFC. 1042 Responses from Nokia (former Alcatel-Lucent): 1044 Link to a web page describing the implementation: 1045 https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/ 1046 3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Un 1047 icast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf 1049 The implementation's level of maturity: Production. 1051 Coverage: We have implemented all sections and have support for the 1052 latest draft. 1054 Licensing: Part of the software package that needs to be purchased. 1056 Implementation experience: Great spec. We also performed inter- 1057 operability testing with Cisco's OSPF Segment Routing implementation. 1059 Contact information: wim.henderickx@nokia.com 1061 Responses from Cisco Systems: 1063 Link to a web page describing the implementation: 1065 http://www.segment-routing.net/home/tutorial 1067 The implementation's level of maturity: Production. 1069 Coverage: All sections have been implemented according to the latest 1070 draft. 1072 Licensing: Part of a commercial software package. 1074 Implementation experience: Many aspects of the draft are result of 1075 the actual implementation experience, as the draft evolved from its 1076 initial version to the current one. Interoperability testing with 1077 Alcatel-Lucent was performed, which confirmed the draft's ability to 1078 serve as a reference for the implementors. 1080 Contact information: ppsenak@cisco.com 1082 Responses from Juniper: 1084 The implementation's name and/or a link to a web page describing the 1085 implementation: 1087 Feature name is OSPF SPRING 1089 The implementation's level of maturity: To be released in 16.2 1090 (second half of 2016) 1092 Coverage: All sections implemented except Sections 4, and 6. 1094 Licensing: JUNOS Licensing needed. 1096 Implementation experience: NA 1098 Contact information: shraddha@juniper.net 1100 10. Security Considerations 1102 With the OSPFv2 segment routing extensions defined herein, OSPFv2 1103 will now program the MPLS data plane [RFC3031] in addition to the IP 1104 data plane. Previously, LDP [RFC5036] or another label distribution 1105 mechanism was required to advertise MPLS labels and program the MPLS 1106 data plane. 1108 In general, the same types of attacks that can be carried out on the 1109 IP control plane can be carried out on the MPLS control plane 1110 resulting in traffic being misrouted in the respective data planes. 1111 However, the latter may be more difficult to detect and isolate. 1113 Existing security extensions as described in [RFC2328] and [RFC7684] 1114 apply to these segment routing extensions. While OSPF is under a 1115 single administrative domain, there may be deployments where 1116 potential attackers have access to one or more networks in the OSPF 1117 routing domain. In these deployments, stronger authentication 1118 mechanisms such as those specified in [RFC7474] SHOULD be used. 1120 Implementations must assure that malformed TLV and Sub-TLV defined in 1121 this document are detected and do not provide a vulnerability for 1122 attackers to crash the OSPFv2 router or routing process. Reception 1123 of malformed TLV or Sub-TLV SHOULD be counted and/or logged for 1124 further analysis. 1126 11. Contributors 1128 The following people gave a substantial contribution to the content 1129 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1130 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1131 Saku Ytti. 1133 12. Acknowledgements 1135 We would like to thank Anton Smirnov for his contribution. 1137 Thanks to Acee Lindem for the detail review of the draft, 1138 corrections, as well as discussion about details of the encoding. 1140 13. References 1142 13.1. Normative References 1144 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1145 Requirement Levels", BCP 14, RFC 2119, 1146 DOI 10.17487/RFC2119, March 1997, . 1149 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1150 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1151 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1152 . 1154 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 1155 and Point-to-Multipoint Interface Type", RFC 6845, 1156 DOI 10.17487/RFC6845, January 2013, . 1159 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1160 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1161 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1162 2015, . 1164 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1165 S. Shaffer, "Extensions to OSPF for Advertising Optional 1166 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1167 February 2016, . 1169 13.2. Informative References 1171 [I-D.ietf-spring-conflict-resolution] 1172 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 1173 "Segment Routing MPLS Conflict Resolution", draft-ietf- 1174 spring-conflict-resolution-05 (work in progress), July 1175 2017. 1177 [I-D.ietf-spring-segment-routing] 1178 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1179 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1180 spring-segment-routing-12 (work in progress), June 2017. 1182 [I-D.ietf-spring-segment-routing-ldp-interop] 1183 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 1184 S. Litkowski, "Segment Routing interworking with LDP", 1185 draft-ietf-spring-segment-routing-ldp-interop-08 (work in 1186 progress), June 2017. 1188 [I-D.ietf-spring-segment-routing-mpls] 1189 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1190 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1191 data plane", draft-ietf-spring-segment-routing-mpls-10 1192 (work in progress), June 2017. 1194 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1195 DOI 10.17487/RFC2328, April 1998, . 1198 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 1199 "Security Extension for OSPFv2 When Using Manual Key 1200 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 1201 . 1203 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1204 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1205 Packet Routing in Networking (SPRING) Problem Statement 1206 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1207 2016, . 1209 Authors' Addresses 1210 Peter Psenak (editor) 1211 Cisco Systems, Inc. 1212 Apollo Business Center 1213 Mlynske nivy 43 1214 Bratislava 821 09 1215 Slovakia 1217 Email: ppsenak@cisco.com 1219 Stefano Previdi (editor) 1220 Cisco Systems, Inc. 1221 Via Del Serafico, 200 1222 Rome 00142 1223 Italy 1225 Email: stefano@previdi.net 1227 Clarence Filsfils 1228 Cisco Systems, Inc. 1229 Brussels 1230 Belgium 1232 Email: cfilsfil@cisco.com 1234 Hannes Gredler 1235 RtBrick Inc. 1237 Email: hannes@rtbrick.com 1239 Rob Shakir 1240 Google, Inc. 1241 1600 Amphitheatre Parkway 1242 Mountain View, CA 94043 1243 US 1245 Email: robjs@google.com 1246 Wim Henderickx 1247 Nokia 1248 Copernicuslaan 50 1249 Antwerp 2018 1250 BE 1252 Email: wim.henderickx@nokia.com 1254 Jeff Tantsura 1255 Individual 1256 US 1258 Email: jefftant.ietf@gmail.com