idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-17.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 (June 23, 2017) is 2497 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 1101, but not defined == Missing Reference: 'RFC5036' is mentioned on line 1102, but not defined == Outdated reference: A later version (-05) exists of draft-ietf-spring-conflict-resolution-04 == 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 (~~), 7 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: December 25, 2017 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 June 23, 2017 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-17 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 December 25, 2017. 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 . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . 25 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 narrowest 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 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: 199 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 is REQUIRED. This 459 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 always prefers intra-area Prefix Range advertisements 530 over inter-area advertisements. 532 An ABR does not consider inter-area Prefix Range 533 advertisements coming from non-backbone areas. 535 An ABR only propagates an inter-area Prefix Range 536 advertisement from the backbone area to connected non- 537 backbone areas if the advertisement is considered to be the 538 best one. 540 Address Prefix: For the address family IPv4 unicast, the prefix 541 itself is encoded as a 32-bit value. The default route is 542 represented by a prefix of length 0. Prefix encoding for other 543 address families is beyond the scope of this specification. 545 5. Prefix SID Sub-TLV 547 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV 548 described in [RFC7684] and the OSPF Extended Prefix Range TLV 549 described in Section 4. It MAY appear more than once in the parent 550 TLV and has the following format: 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Type | Length | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Flags | Reserved | MT-ID | Algorithm | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | SID/Index/Label (variable) | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 where: 564 Type: TBD, suggested value 2. 566 Length: 7 or 8 octets, dependent on the V-flag 568 Flags: Single octet field. The following flags are defined: 570 0 1 2 3 4 5 6 7 571 +--+--+--+--+--+--+--+--+ 572 | |NP|M |E |V |L | | | 573 +--+--+--+--+--+--+--+--+ 575 where: 577 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 578 NOT pop the Prefix-SID before delivering packets to the node 579 that advertised the Prefix-SID. 581 M-Flag: Mapping Server Flag. If set, the SID was advertised by 582 a Segment Routing Mapping Server as described in 583 [I-D.ietf-spring-segment-routing-ldp-interop]. 585 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 586 the Prefix-SID originator MUST replace the Prefix-SID with the 587 Explicit-NULL label (0 for IPv4) before forwarding the packet. 589 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 590 an absolute value. If not set, then the Prefix-SID carries an 591 index. 593 L-Flag: Local/Global Flag. If set, then the value/index 594 carried by the Prefix-SID has local significance. If not set, 595 then the value/index carried by this Sub-TLV has global 596 significance. 598 Other bits: Reserved. These MUST be zero when sent and are 599 ignored when received. 601 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 603 Algorithm: Single octet identifying the algorithm the Prefix-SID 604 is associated with as defined in Section 3.1. 606 A router receiving a Prefix-SID from a remote node and with an 607 algorithm value that such remote node has not advertised in the 608 SR-Algorithm Sub-TLV (Section 3.1) MUST ignore the Prefix-SID Sub- 609 TLV. 611 SID/Index/Label: According to the V and L flags, it contains 612 either: 614 A 32-bit index defining the offset in the SID/Label space 615 advertised by this router. 617 A 24-bit label where the 20 rightmost bits are used for 618 encoding the label value. 620 If an OSPF router advertises multiple Prefix-SIDs for the same 621 prefix, topology and algorithm, all of them MUST be ignored. 623 When calculating the outgoing label for the prefix, the router MUST 624 take into account, as described below, the E, NP and M flags 625 advertised by the next-hop router if that router advertised the SID 626 for the prefix. This MUST be done regardless of whether the next-hop 627 router contributes to the best path to the prefix. 629 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 630 Prefix-SIDs allocated to inter-area prefixes that are originated by 631 the ABR based on intra-area or inter-area reachability between areas, 632 unless the advertised prefix is directly attached to the ABR. 634 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 635 Prefix-SIDs allocated to redistributed prefixes, unless the 636 redistributed prefix is directly attached to the ASBR. 638 If the NP-Flag is not set, then any upstream neighbor of the Prefix- 639 SID originator MUST pop the Prefix-SID. This is equivalent to the 640 penultimate hop popping mechanism used in the MPLS dataplane. If the 641 NP-flag is not set, then the received E-flag is ignored. 643 If the NP-flag is set then: 645 If the E-flag is not set, then any upstream neighbor of the 646 Prefix-SID originator MUST keep the Prefix-SID on top of the 647 stack. This is useful when the originator of the Prefix-SID must 648 stitch the incoming packet into a continuing MPLS LSP to the final 649 destination. This could occur at an Area Border Router (prefix 650 propagation from one area to another) or at an AS Boundary Router 651 (prefix propagation from one domain to another). 653 If the E-flag is set, then any upstream neighbor of the Prefix-SID 654 originator MUST replace the Prefix-SID with an Explicit-NULL 655 label. This is useful, e.g., when the originator of the Prefix- 656 SID is the final destination for the related prefix and the 657 originator wishes to receive the packet with the original EXP 658 bits. 660 When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at 661 reception. 663 As the Mapping Server does not specify the originator of a prefix 664 advertisement, it is not possible to determine PHP behavior solely 665 based on the Mapping Server advertisement. However, PHP behavior 666 SHOULD be done in following cases: 668 The Prefix is intra-area type and the downstream neighbor is the 669 originator of the prefix. 671 The Prefix is inter-area type and downstream neighbor is an ABR, 672 which is advertising prefix reachability and is also generating 673 the Extended Prefix TLV with the A-flag set for this prefix as 674 described in section 2.1 of [RFC7684]. 676 The Prefix is external type and downstream neighbor is an ASBR, 677 which is advertising prefix reachability and is also generating 678 the Extended Prefix TLV with the A-flag set for this prefix as 679 described in section 2.1 of [RFC7684]. 681 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 682 the value advertised in the Prefix SID Sub-TLV is interpreted as a 683 starting SID/Label value. 685 Example 1: If the following router addresses (loopback addresses) 686 need to be mapped into the corresponding Prefix SID indexes: 688 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 689 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 690 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 691 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 693 then the Prefix field in the Extended Prefix Range TLV would be set 694 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 695 set to 4, and the Index value in the Prefix-SID Sub-TLV would be set 696 to 1. 698 Example 2: If the following prefixes need to be mapped into the 699 corresponding Prefix-SID indexes: 701 192.0.2.0/30, Prefix-SID: Index 51 702 192.0.2.4/30, Prefix-SID: Index 52 703 192.0.2.8/30, Prefix-SID: Index 53 704 192.0.2.12/30, Prefix-SID: Index 54 705 192.0.2.16/30, Prefix-SID: Index 55 706 192.0.2.20/30, Prefix-SID: Index 56 707 192.0.2.24/30, Prefix-SID: Index 57 709 then the Prefix field in the Extended Prefix Range TLV would be set 710 to 192.0.2.0, Prefix Length would be set to 30, Range Size would be 711 7, and the Index value in the Prefix-SID Sub-TLV would be set to 51. 713 6. Adjacency Segment Identifier (Adj-SID) 715 An Adjacency Segment Identifier (Adj-SID) represents a router 716 adjacency in Segment Routing. 718 6.1. Adj-SID Sub-TLV 720 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 721 [RFC7684]. It MAY appear multiple times in the Extended Link TLV. 722 The Adj-SID Sub-TLV has the following format: 724 0 1 2 3 725 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 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Type | Length | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Flags | Reserved | MT-ID | Weight | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | SID/Label/Index (variable) | 732 +---------------------------------------------------------------+ 734 where: 736 Type: TBD, suggested value 2. 738 Length: 7 or 8 octets, dependent on the V flag. 740 Flags: Single octet field containing the following flags: 742 0 1 2 3 4 5 6 7 743 +-+-+-+-+-+-+-+-+ 744 |B|V|L|G|P| | 745 +-+-+-+-+-+-+-+-+ 747 where: 749 B-Flag: Backup Flag. If set, the Adj-SID refers to an 750 adjacency that is eligible for protection (e.g., using IPFRR or 751 MPLS-FRR) as described in section 3.5 of 752 [I-D.ietf-spring-segment-routing]. 754 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 755 an absolute value. If not set, then the Adj-SID carries an 756 index. 758 The L-Flag: Local/Global Flag. If set, then the value/index 759 carried by the Adj-SID has local significance. If not set, 760 then the value/index carried by this Sub-TLV has global 761 significance. 763 The G-Flag: Group Flag. When set, the G-Flag indicates that 764 the Adj-SID refers to a group of adjacencies (and therefore MAY 765 be assigned to other adjacencies as well). 767 P-Flag. Persistent flag. When set, the P-Flag indicates that 768 the Adj-SID is persistently allocated, i.e., the Adj-SID value 769 remains consistent across router restart and/or interface flap. 771 Other bits: Reserved. These MUST be zero when sent and are 772 ignored when received. 774 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 776 Weight: Weight used for load-balancing purposes. The use of the 777 weight is defined in [I-D.ietf-spring-segment-routing]. 779 SID/Index/Label: According to the V and L flags, it contains 780 either: 782 A 32-bit index defining the offset in the SID/Label space 783 advertised by this router. 785 A 24-bit label where the 20 rightmost bits are used for 786 encoding the label value. 788 An SR capable router MAY allocate an Adj-SID for each of its 789 adjacencies and set the B-Flag when the adjacency is eligible for 790 protection by an FRR mechanism (IP or MPLS) as described in section 791 3.5 of [I-D.ietf-spring-segment-routing]. 793 An SR capable router MAY allocate more than one Adj-SID to an 794 adjacency 796 An SR capable router MAY allocate the same Adj-SID to different 797 adjacencies 799 When the P-flag is not set, the Adj-SID MAY be persistent. When the 800 P-flag is set, the Adj-SID MUST be persistent. 802 6.2. LAN Adj-SID Sub-TLV 804 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 805 in [RFC7684]. It MAY appear multiple times in the Extended-Link TLV. 806 It is used to advertise a SID/Label for an adjacency to a non-DR 807 router on a broadcast, NBMA, or hybrid [RFC6845] network. 809 0 1 2 3 810 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 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Type | Length | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Flags | Reserved | MT-ID | Weight | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Neighbor ID | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | SID/Label/Index (variable) | 819 +---------------------------------------------------------------+ 821 where: 823 Type: TBD, suggested value 3. 825 Length: 11 or 12 octets, dependent on V-flag. 827 Flags: same as in Section 6.1 829 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 831 Weight: Weight used for load-balancing purposes. The use of the 832 weight is defined in [I-D.ietf-spring-segment-routing]. 834 Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- 835 SID is advertised. 837 SID/Index/Label: According to the V and L flags, it contains 838 either: 840 A 32-bit index defining the offset in the SID/Label space 841 advertised by this router. 843 A 24-bit label where the 20 rightmost bits are used for 844 encoding the label value. 846 When the P-flag is not set, the Adj-SID MAY be persistent. When 847 the P-flag is set, the Adj-SID MUST be persistent. 849 7. Elements of Procedure 851 7.1. Intra-area Segment routing in OSPFv2 853 An OSPFv2 router that supports segment routing MAY advertise Prefix- 854 SIDs for any prefix to which it is advertising reachability (e.g., a 855 loopback IP address as described in Section 5). 857 A Prefix-SID can also be advertised by the SR Mapping Servers (as 858 described in [I-D.ietf-spring-segment-routing-ldp-interop]). A 859 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 860 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 861 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 862 MUST be advertised by all of them. The flooding scope of the OSPF 863 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 864 could be either area-scoped or AS-scoped and is determined based on 865 the configuration of the SR Mapping Server. 867 An SR Mapping Server MUST use the OSPF Extended Prefix Range TLV when 868 advertising SIDs for prefixes. Prefixes of different route-types can 869 be combined in a single OSPF Extended Prefix Range TLV advertised by 870 an SR Mapping Server. Because the OSPF Extended Prefix Range TLV 871 doesn't include a Route-Type field, as in the OSPF Extended Prefix 872 TLV, it is possible to include adjacent prefixes from different 873 Route-Types in the OSPF Extended Prefix Range TLV. 875 Area-scoped OSPF Extended Prefix Range TLVs are propagated between 876 areas. Similar to propagation of prefixes between areas, an ABR only 877 propagates the OSPF Extended Prefix Range TLV that it considers to be 878 the best from the set it received. The rules used to pick the best 879 OSPF Extended Prefix Range TLV are described in Section 4. 881 When propagating an OSPF Extended Prefix Range TLV between areas, 882 ABRs MUST set the IA-Flag, that is used to prevent redundant flooding 883 of the OSPF Extended Prefix Range TLV between areas as described in 884 Section 4. 886 7.2. Inter-area Segment routing in OSPFv2 888 In order to support SR in a multi-area environment, OSPFv2 must 889 propagate Prefix-SID information between areas. The following 890 procedure is used to propagate Prefix SIDs between areas. 892 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 893 prefix to all its connected areas, it will also originate an Extended 894 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 895 the Extended Prefix Opaque LSA type will be set to area-local scope. 896 The route-type in the OSPF Extended Prefix TLV is set to inter-area. 897 The Prefix-SID Sub-TLV will be included in this LSA and the Prefix- 898 SID value will be set as follows: 900 The ABR will look at its best path to the prefix in the source 901 area and find the advertising router associated with the best path 902 to that prefix. 904 The ABR will then determine if such router advertised a Prefix-SID 905 for the prefix and use it when advertising the Prefix-SID to other 906 connected areas. 908 If no Prefix-SID was advertised for the prefix in the source area 909 by the router that contributes to the best path to the prefix, the 910 originating ABR will use the Prefix-SID advertised by any other 911 router when propagating the Prefix-SID for the prefix to other 912 areas. 914 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 915 route to all its connected areas, it will also originate an Extended 916 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 917 the Extended Prefix Opaque LSA type will be set to area-local scope. 918 The route-type in OSPF Extended Prefix TLV is set to inter-area. The 919 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 920 will be set as follows: 922 The ABR will look at its best path to the prefix in the backbone 923 area and find the advertising router associated with the best path 924 to that prefix. 926 The ABR will then determine if such router advertised a Prefix-SID 927 for the prefix and use it when advertising the Prefix-SID to other 928 connected areas. 930 If no Prefix-SID was advertised for the prefix in the backbone 931 area by the ABR that contributes to the best path to the prefix, 932 the originating ABR will use the Prefix-SID advertised by any 933 other router when propagating the Prefix-SID for the prefix to 934 other areas. 936 7.3. Segment Routing for External Prefixes 938 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 939 SR, generates Type-5 LSAs, it should also originate Extended Prefix 940 Opaque LSAs, as described in [RFC7684]. The flooding scope of the 941 Extended Prefix Opaque LSA type is set to AS-wide scope. The route- 942 type in the OSPF Extended Prefix TLV is set to external. The Prefix- 943 SID Sub-TLV is included in this LSA and the Prefix-SID value will be 944 set to the SID that has been reserved for that prefix. 946 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 947 also advertise the Prefix-SID for the prefix. The NSSA ABR 948 determines its best path to the prefix advertised in the translated 949 Type-7 LSA and finds the advertising router associated with that 950 path. If the advertising router has advertised a Prefix-SID for the 951 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 952 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 953 router will be used. 955 7.4. Advertisement of Adj-SID 957 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 958 using the Adj-SID Sub-TLV as described in Section 6. 960 7.4.1. Advertisement of Adj-SID on Point-to-Point Links 962 An Adj-SID MAY be advertised for any adjacency on a P2P link that is 963 in neighbor state 2-Way or higher. If the adjacency on a P2P link 964 transitions from the FULL state, then the Adj-SID for that adjacency 965 MAY be removed from the area. If the adjacency transitions to a 966 state lower then 2-Way, then the Adj-SID advertisement MUST be 967 withdrawn from the area. 969 7.4.2. Adjacency SID on Broadcast or NBMA Interfaces 971 Broadcast, NBMA, or hybrid [RFC6845] networks in OSPF are represented 972 by a star topology where the Designated Router (DR) is the central 973 point to which all other routers on the broadcast, NBMA, or hybrid 974 network connect. As a result, routers on the broadcast, NBMA, or 975 hybrid network advertise only their adjacency to the DR. Routers 976 that do not act as DR do not form or advertise adjacencies with each 977 other. They do, however, maintain 2-Way adjacency state with each 978 other and are directly reachable. 980 When Segment Routing is used, each router on the broadcast, NBMA, or 981 hybrid network MAY advertise the Adj-SID for its adjacency to the DR 982 using the Adj-SID Sub-TLV as described in Section 6.1. 984 SR capable routers MAY also advertise a LAN-Adj-SID for other 985 neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid 986 network using the LAN-ADJ-SID Sub-TLV as described in Section 6.2. 988 8. IANA Considerations 990 This specification updates several existing OSPF registries. 992 8.1. OSPF OSPF Router Information (RI) TLVs Registry 994 o 8 (IANA Preallocated) - SR-Algorithm TLV 996 o 9 (IANA Preallocated) - SID/Label Range TLV 998 o 12 - SR Local Block TLV 1000 o 13 - SRMS Preference TLV 1002 8.2. OSPF Extended Prefix LSA TLV Registry 1004 Following values are allocated: 1006 o 2 - OSPF Extended Prefix Range TLV 1008 8.3. OSPF Extended Prefix LSA Sub-TLV Registry 1010 Following values are allocated: 1012 o 1 - SID/Label Sub-TLV 1014 o 2 - Prefix SID Sub-TLV 1016 8.4. OSPF Extended Link LSA Sub-TLV Registry 1018 Following initial values are allocated: 1020 o 1 - SID/Label Sub-TLV 1022 o 2 - Adj-SID Sub-TLV 1024 o 3 - LAN Adj-SID/Label Sub-TLV 1026 9. Implementation Status 1028 An implementation survey with seven questions related to the 1029 implementer's support of OSPFv2 Segment Routing was sent to the OSPF 1030 WG list and several known implementers. This section contains 1031 responses from three implementers who completed the survey. No 1032 external means were used to verify the accuracy of the information 1033 submitted by the respondents. The respondents are considered experts 1034 on the products they reported on. Additionally, responses were 1035 omitted from implementers who indicated that they have not 1036 implemented the function yet. 1038 This section will be removed before publication as an RFC. 1040 Responses from Nokia (former Alcatel-Lucent): 1042 Link to a web page describing the implementation: 1043 https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/ 1044 3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Un 1045 icast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf 1047 The implementation's level of maturity: Production. 1049 Coverage: We have implemented all sections and have support for the 1050 latest draft. 1052 Licensing: Part of the software package that needs to be purchased. 1054 Implementation experience: Great spec. We also performed inter- 1055 operability testing with Cisco's OSPF Segment Routing implementation. 1057 Contact information: wim.henderickx@nokia.com 1059 Responses from Cisco Systems: 1061 Link to a web page describing the implementation: 1063 http://www.segment-routing.net/home/tutorial 1065 The implementation's level of maturity: Production. 1067 Coverage: All sections have been implemented according to the latest 1068 draft. 1070 Licensing: Part of a commercial software package. 1072 Implementation experience: Many aspects of the draft are result of 1073 the actual implementation experience, as the draft evolved from its 1074 initial version to the current one. Interoperability testing with 1075 Alcatel-Lucent was performed, which confirmed the draft's ability to 1076 serve as a reference for the implementors. 1078 Contact information: ppsenak@cisco.com 1080 Responses from Juniper: 1082 The implementation's name and/or a link to a web page describing the 1083 implementation: 1085 Feature name is OSPF SPRING 1087 The implementation's level of maturity: To be released in 16.2 1088 (second half of 2016) 1090 Coverage: All sections implemented except Sections 4, and 6. 1092 Licensing: JUNOS Licensing needed. 1094 Implementation experience: NA 1096 Contact information: shraddha@juniper.net 1098 10. Security Considerations 1100 With the OSPFv2 segment routing extensions defined herein, OSPFv2 1101 will now program the MPLS data plane [RFC3031] in addition to the IP 1102 data plane. Previously, LDP [RFC5036] or another label distribution 1103 mechanism was required to advertise MPLS labels and program the MPLS 1104 data plane. 1106 In general, the same types of attacks that can be carried out on the 1107 IP control plane can be carried out on the MPLS control plane 1108 resulting in traffic being misrouted in the respective data planes. 1109 However, the latter may be more difficult to detect and isolate. 1111 Existing security extensions as described in [RFC2328] and [RFC7684] 1112 apply to these segment routing extensions. While OSPF is under a 1113 single administrative domain, there may be deployments where 1114 potential attackers have access to one or more networks in the OSPF 1115 routing domain. In these deployments, stronger authentication 1116 mechanisms such as those specified in [RFC7474] SHOULD be used. 1118 Implementations must assure that malformed TLV and Sub-TLV defined in 1119 this document are detected and do not provide a vulnerability for 1120 attackers to crash the OSPFv2 router or routing process. 1122 11. Contributors 1124 The following people gave a substantial contribution to the content 1125 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1126 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1127 Saku Ytti. 1129 12. Acknowledgements 1131 We would like to thank Anton Smirnov for his contribution. 1133 Thanks to Acee Lindem for the detail review of the draft, 1134 corrections, as well as discussion about details of the encoding. 1136 13. References 1138 13.1. Normative References 1140 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1141 Requirement Levels", BCP 14, RFC 2119, 1142 DOI 10.17487/RFC2119, March 1997, 1143 . 1145 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1146 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1147 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1148 . 1150 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 1151 and Point-to-Multipoint Interface Type", RFC 6845, 1152 DOI 10.17487/RFC6845, January 2013, 1153 . 1155 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1156 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1157 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1158 2015, . 1160 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1161 S. Shaffer, "Extensions to OSPF for Advertising Optional 1162 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1163 February 2016, . 1165 13.2. Informative References 1167 [I-D.ietf-spring-conflict-resolution] 1168 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 1169 "Segment Routing MPLS Conflict Resolution", draft-ietf- 1170 spring-conflict-resolution-04 (work in progress), May 1171 2017. 1173 [I-D.ietf-spring-segment-routing] 1174 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1175 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1176 spring-segment-routing-12 (work in progress), June 2017. 1178 [I-D.ietf-spring-segment-routing-ldp-interop] 1179 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 1180 S. Litkowski, "Segment Routing interworking with LDP", 1181 draft-ietf-spring-segment-routing-ldp-interop-08 (work in 1182 progress), June 2017. 1184 [I-D.ietf-spring-segment-routing-mpls] 1185 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1186 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1187 data plane", draft-ietf-spring-segment-routing-mpls-10 1188 (work in progress), June 2017. 1190 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1191 DOI 10.17487/RFC2328, April 1998, 1192 . 1194 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 1195 "Security Extension for OSPFv2 When Using Manual Key 1196 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 1197 . 1199 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1200 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1201 Packet Routing in Networking (SPRING) Problem Statement 1202 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1203 2016, . 1205 Authors' Addresses 1207 Peter Psenak (editor) 1208 Cisco Systems, Inc. 1209 Apollo Business Center 1210 Mlynske nivy 43 1211 Bratislava 821 09 1212 Slovakia 1214 Email: ppsenak@cisco.com 1215 Stefano Previdi (editor) 1216 Cisco Systems, Inc. 1217 Via Del Serafico, 200 1218 Rome 00142 1219 Italy 1221 Email: stefano@previdi.net 1223 Clarence Filsfils 1224 Cisco Systems, Inc. 1225 Brussels 1226 Belgium 1228 Email: cfilsfil@cisco.com 1230 Hannes Gredler 1231 RtBrick Inc. 1233 Email: hannes@rtbrick.com 1235 Rob Shakir 1236 Google, Inc. 1237 1600 Amphitheatre Parkway 1238 Mountain View, CA 94043 1239 US 1241 Email: robjs@google.com 1243 Wim Henderickx 1244 Nokia 1245 Copernicuslaan 50 1246 Antwerp 2018 1247 BE 1249 Email: wim.henderickx@nokia.com 1251 Jeff Tantsura 1252 Individual 1253 US 1255 Email: jefftant.ietf@gmail.com