idnits 2.17.00 (12 Aug 2021) /tmp/idnits17445/draft-ietf-ospf-segment-routing-extensions-09.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- 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 (July 6, 2016) is 2145 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 300 -- Looks like a reference, but probably isn't: '199' on line 300 -- Looks like a reference, but probably isn't: '1000' on line 301 -- Looks like a reference, but probably isn't: '1099' on line 301 -- Looks like a reference, but probably isn't: '500' on line 302 -- Looks like a reference, but probably isn't: '599' on line 302 == Unused Reference: 'RFC2328' is defined on line 1329, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 1343, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-ldp-interop-02 == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 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: January 7, 2017 Cisco Systems, Inc. 6 H. Gredler 7 Individual 8 R. Shakir 9 Jive Communications, Inc. 10 W. Henderickx 11 Nokia 12 J. Tantsura 13 Individual 14 July 6, 2016 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-09 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 RFC 2119 [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 January 7, 2017. 51 Copyright Notice 53 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . 4 71 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4 72 3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4 73 3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 6 74 4. OSPF Extended Prefix Range TLV . . . . . . . . . . . . . . . 7 75 5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 9 76 6. SID/Label Binding Sub-TLV . . . . . . . . . . . . . . . . . . 13 77 6.1. ERO Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 14 78 6.2. ERO Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 15 79 6.2.1. IPv4 ERO Sub-TLV . . . . . . . . . . . . . . . . . . 15 80 6.2.2. Unnumbered Interface ID ERO Sub-TLV . . . . . . . . . 16 81 6.2.3. IPv4 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 17 82 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV . . . . . 18 83 7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 19 84 7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 20 85 7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 21 86 8. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 23 87 8.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 23 88 8.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 23 89 8.3. SID for External Prefixes . . . . . . . . . . . . . . . . 25 90 8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 25 91 8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 25 92 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 25 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 94 9.1. OSPF OSPF Router Information (RI) TLVs Registry . . . . . 26 95 9.2. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 26 96 9.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 26 97 9.4. OSPF Extended Link LSA Sub-TLV Registry . . . . . . . . . 26 98 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 99 11. Security Considerations . . . . . . . . . . . . . . . . . . . 28 100 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 101 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 102 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 103 14.1. Normative References . . . . . . . . . . . . . . . . . . 29 104 14.2. Informative References . . . . . . . . . . . . . . . . . 30 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 107 1. Introduction 109 Segment Routing (SR) allows a flexible definition of end-to-end paths 110 within IGP topologies by encoding paths as sequences of topological 111 sub-paths, called "segments". These segments are advertised by the 112 link-state routing protocols (IS-IS and OSPF). Prefix segments 113 represent an ECMP-aware shortest-path to a prefix (or a node), as per 114 the state of the IGP topology. Adjacency segments represent a hop 115 over a specific adjacency between two nodes in the IGP. A prefix 116 segment is typically a multi-hop path while an adjacency segment, in 117 most cases, is a one-hop path. SR's control-plane can be applied to 118 both IPv6 and MPLS data-planes, and does not require any additional 119 signalling (other than IGP extensions). The IPv6 data plane is out 120 of the scope of this specification - it is not applicable to OSPFv2 121 which only supports the IPv4 address-family. For example, when used 122 in MPLS networks, SR paths do not require any LDP or RSVP-TE 123 signalling. However, SR can interoperate in the presence of LSPs 124 established with RSVP or LDP. 126 This draft describes the OSPF extensions required for Segment 127 Routing. 129 Segment Routing architecture is described in 130 [I-D.ietf-spring-segment-routing]. 132 Segment Routing use cases are described in 133 [I-D.filsfils-spring-segment-routing-use-cases]. 135 2. Segment Routing Identifiers 137 Segment Routing defines various types of Segment Identifiers (SIDs): 138 Prefix-SID, Adjacency-SID, LAN Adjacency SID and Binding SID. 140 For the purpose of the advertisements of various SID values, new 141 Opaque LSAs [RFC5250] are defined in [RFC7684]. These LSAs are 142 generic containers that can be used to advertise any additional 143 attributes associated with a prefix or link. These Opaque LSAs are 144 complementary to the existing LSAs and are not aimed to replace any 145 of the existing LSAs. 147 2.1. SID/Label Sub-TLV 149 The SID/Label Sub-TLV appears in multiple TLVs or Sub-TLVs defined 150 later in this document. It is used to advertise the SID or label 151 associated with a prefix or adjacency. The SID/Label TLV has 152 following format: 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Type | Length | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | SID/Label (variable) | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 where: 164 Type: TBD, suggested value 1 166 Length: variable, 3 or 4 octet 168 SID/Label: If length is set to 3, then the 20 rightmost bits 169 represent a label. If length is set to 4, then the value 170 represents a 32-bit SID. 172 The receiving router MUST ignore SID/Label Sub-TLV if the length 173 is other then 3 or 4. 175 3. Segment Routing Capabilities 177 Segment Routing requires some additional router capabilities to be 178 advertised to other routers in the area. 180 These SR capabilities are advertised in the Router Information Opaque 181 LSA (defined in [RFC7770]). 183 3.1. SR-Algorithm TLV 185 The SR-Algorithm TLV is a top-level TLV of the Router Information 186 Opaque LSA (defined in [RFC7770]). 188 The SR-Algorithm Sub-TLV is optional. It MAY only be advertised once 189 in the Router Information Opaque LSA. If the SID/Label Range TLV, as 190 defined in Section 3.2, is advertised, then the SR-Algorithm TLV MUST 191 also be advertised. If the SR-Algorithm TLV is not advertised by the 192 node, such node is considered as not being segment routing capable. 194 An SR Router may use various algorithms when calculating reachability 195 to OSPF routers or prefixes in an OSPF area. Examples of these 196 algorithms are metric based Shortest Path First (SPF), various 197 flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a 198 router to advertise the algorithms currently used by the router to 199 other routers in an OSPF area. The SR-Algorithm TLV has following 200 format: 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type | Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Algorithm 1 | Algorithm... | Algorithm n | | 208 +- -+ 209 | | 210 + + 212 where: 214 Type: TBD, suggested value 8 216 Length: variable 218 Algorithm: Single octet identifying the algorithm. The following 219 values are defined by this document: 221 0: Shortest Path First (SPF) algorithm based on link metric. 222 This is the standard shortest path algorithm as computed by the 223 OSPF protocol. Consistent with the deployed practice for link- 224 state protocols, Algorithm 0 permits any node to overwrite the 225 SPF path with a different path based on its local policy. If 226 the SR-Algorithm Sub-TLV is advertised, Algorithm 0 MUST be 227 included. 229 1: Strict Shortest Path First (SPF) algorithm based on link 230 metric. The algorithm is identical to Algorithm 0 but 231 Algorithm 1 requires that all nodes along the path will honor 232 the SPF routing decision. Local policy at the node claiming 233 support for Algorithm 1 MUST NOT alter the SPF paths computed 234 by Algorithm 1. 236 The RI LSA can be advertised at any of the defined opaque flooding 237 scopes (link, area, or Autonomous System (AS)). For the purpose of 238 SR-Algorithm TLV advertisement, area scope flooding is required. 240 3.2. SID/Label Range TLV 242 The SID/Label Range TLV is a top-level TLV of the Router Information 243 Opaque LSA (defined in [RFC7770]). 245 The SID/Label Range TLV MAY appear multiple times and has the 246 following format: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type | Length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Range Size | Reserved | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Sub-TLVs (variable) | 256 +- -+ 257 | | 258 + + 260 where: 262 Type: TBD, suggested value 9 264 Length: variable 266 Range Size: 3 octets of the SID/label range 268 Initially, the only supported Sub-TLV is the SID/Label TLV as defined 269 in Section 2.1. The SID/Label advertised in the SID/Label TLV 270 represents the first SID/Label in the advertised range. 272 Multiple occurrences of the SID/Label Range TLV MAY be advertised, in 273 order to advertise multiple ranges. In such case: 275 o The originating router MUST encode each range into a different 276 SID/Label Range TLV. 278 o The originating router decides the order in which the set of SID/ 279 Label Range TLVs are advertised inside the Router Information 280 Opaque LSA. The originating router MUST ensure the order is the 281 same after a graceful restart (using checkpointing, non-volatile 282 storage or any other mechanism) in order to assure the SID/label 283 range and SID index correspondence is preserved across graceful 284 restarts. 286 o The receiving router must adhere to the order in which the ranges 287 are advertised when calculating a SID/label from a SID index. 289 The following example illustrates the advertisement of multiple 290 ranges: 292 The originating router advertises following ranges: 293 Range 1: [100, 199] 294 Range 2: [1000, 1099] 295 Range 3: [500, 599] 297 The receiving routers concatenate the ranges and build the Segment 298 Routing Global Block (SRGB) as follows: 300 SRGB = [100, 199] 301 [1000, 1099] 302 [500, 599] 304 The indexes span multiple ranges: 306 index=0 means label 100 307 ... 308 index 99 means label 199 309 index 100 means label 1000 310 index 199 means label 1099 311 ... 312 index 200 means label 500 313 ... 315 The RI LSA can be advertised at any of the defined flooding scopes 316 (link, area, or autonomous system (AS)). For the purpose of SID/ 317 Label Range TLV advertisement, area scope flooding is required. 319 4. OSPF Extended Prefix Range TLV 321 In some cases it is useful to advertise attributes for a range of 322 prefixes. The Segment Routing Mapping Server, which is described in 323 [I-D.filsfils-spring-segment-routing-ldp-interop], is an example 324 where we need a single advertisement to advertise SIDs for multiple 325 prefixes from a contiguous address range. 327 The OSPF Extended Prefix Range TLV, which is a new top level TLV of 328 the Extended Prefix LSA described in [RFC7684] is defined for this 329 purpose. 331 Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each 332 OSPF Extended Prefix Opaque LSA, but all prefix ranges included in a 333 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 334 scope. The OSPF Extended Prefix Range TLV has the following format: 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Prefix Length | AF | Range Size | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Flags | Reserved | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Address Prefix (variable) | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Sub-TLVs (variable) | 348 +- -+ 349 | | 351 where: 353 Type: TBD, suggested value 2. 355 Length: Variable 357 Prefix length: Length of the prefix 359 AF: 0 - IPv4 unicast 361 Range size: Represents the number of prefixes that are covered by 362 the advertisement. The Range Size MUST NOT exceed the number of 363 prefixes that could be satisfied by the prefix length without 364 including the IPv4 multicast address range (224.0.0.0/3). 366 Flags: Single octet field. The following flags are defined: 368 0 1 2 3 4 5 6 7 369 +--+--+--+--+--+--+--+--+ 370 |IA| | | | | | | | 371 +--+--+--+--+--+--+--+--+ 373 where: 375 IA-Flag: Inter-Area flag. If set, advertisement is of inter- 376 area type. The ABR that is advertising the OSPF Extended 377 Prefix Range TLV between areas MUST set this bit. 379 This bit is used to prevent redundant flooding of Prefix Range 380 TLVs between areas as follows: 382 An ABR always prefers intra-area Prefix Range advertisements 383 over inter-area advertisements. 385 An ABR does not consider inter-area Prefix Range 386 advertisements coming from non-backbone areas. 388 An ABR only propagates an inter-area Prefix Range 389 advertisement from the backbone area to connected non- 390 backbone areas if the advertisement is considered to be the 391 best one. 393 Address Prefix: The prefix, encoded as an even multiple of 32-bit 394 words, padded with zero bits as necessary. This encoding consumes 395 ((PrefixLength + 31) / 32) 32-bit words. The Address Prefix 396 represents the first prefix in the prefix range. 398 5. Prefix SID Sub-TLV 400 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV 401 described in [RFC7684] and the OSPF Extended Prefix Range TLV 402 described in Section 4. It MAY appear more than once in the parent 403 TLV and has the following format: 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Type | Length | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Flags | Reserved | MT-ID | Algorithm | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | SID/Index/Label (variable) | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 where: 417 Type: TBD, suggested value 2. 419 Length: Variable 421 Flags: Single octet field. The following flags are defined: 423 0 1 2 3 4 5 6 7 424 +--+--+--+--+--+--+--+--+ 425 | |NP|M |E |V |L | | | 426 +--+--+--+--+--+--+--+--+ 428 where: 430 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 431 NOT pop the Prefix-SID before delivering packets to the node 432 that advertised the Prefix-SID. 434 M-Flag: Mapping Server Flag. If set, the SID was advertised by 435 a Segment Routing Mapping Server as described in 436 [I-D.filsfils-spring-segment-routing-ldp-interop]. 438 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 439 the Prefix-SID originator MUST replace the Prefix-SID with the 440 Explicit-NULL label (0 for IPv4) before forwarding the packet. 442 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 443 an absolute value. If not set, then the Prefix-SID carries an 444 index. 446 L-Flag: Local/Global Flag. If set, then the value/index 447 carried by the Prefix-SID has local significance. If not set, 448 then the value/index carried by this Sub-TLV has global 449 significance. 451 Other bits: Reserved. These MUST be zero when sent and are 452 ignored when received. 454 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 456 Algorithm: Single octet identifying the algorithm the Prefix-SID 457 is associated with as defined in Section 3.1. 459 SID/Index/Label: According to the V and L flags, it contains 460 either: 462 A 32-bit index defining the offset in the SID/Label space 463 advertised by this router. 465 A 24-bit label where the 20 rightmost bits are used for 466 encoding the label value. 468 If multiple Prefix-SIDs are advertised for the same prefix, the 469 receiving router MUST use the first encoded SID and MAY use the 470 subsequent SIDs. 472 When propagating Prefix-SIDs between areas, if multiple prefix-SIDs 473 are advertised for a prefix, an implementation SHOULD preserve the 474 original order when advertising prefix-SIDs to other areas. This 475 allows implementations that only support a single Prefix-SID to have 476 a consistent view across areas. 478 When calculating the outgoing label for the prefix, the router MUST 479 take into account the E and P flags advertised by the next-hop router 480 if that router advertised the SID for the prefix. This MUST be done 481 regardless of whether the next-hop router contributes to the best 482 path to the prefix. 484 The NP-Flag (No-PHP) MUST be set for Prefix-SIDs allocated to inter- 485 area prefixes that are originated by the ABR based on intra-area or 486 inter-area reachability between areas. When the inter-area prefix is 487 generated based on a prefix which is directly attached to the ABR, 488 the NP-Flag SHOULD NOT be set. 490 The NP-Flag (No-PHP) MUST be be set for the Prefix-SIDs allocated to 491 redistributed prefixes, unless the redistributed prefix is directly 492 attached to the ASBR, in which case the NP-flag SHOULD NOT be set. 494 If the NP-Flag is not set, then any upstream neighbor of the Prefix- 495 SID originator MUST pop the Prefix-SID. This is equivalent to the 496 penultimate hop popping mechanism used in the MPLS dataplane. In 497 such case, MPLS EXP bits of the Prefix-SID are not preserved for the 498 final destination (the Prefix-SID being removed). If the NP-flag is 499 not set then the received E-flag is ignored. 501 If the NP-flag is set then: 503 If the E-flag is not set, then any upstream neighbor of the 504 Prefix-SID originator MUST keep the Prefix-SID on top of the 505 stack. This is useful when the originator of the Prefix-SID must 506 stitch the incoming packet into a continuing MPLS LSP to the final 507 destination. This could occur at an Area Border Router (prefix 508 propagation from one area to another) or at an AS Boundary Router 509 (prefix propagation from one domain to another). 511 If the E-flag is set, then any upstream neighbor of the Prefix-SID 512 originator MUST replace the Prefix-SID with an Explicit-NULL 513 label. This is useful, e.g., when the originator of the Prefix- 514 SID is the final destination for the related prefix and the 515 originator wishes to receive the packet with the original EXP 516 bits. 518 When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at 519 reception. 521 As the Mapping Server does not specify the originator of a prefix 522 advertisement, it is not possible to determine PHP behavior solely 523 based on the Mapping Server advertisement. However, PHP behavior may 524 safely be done in following cases: 526 The Prefix is intra-area type and the downstream neighbor is the 527 originator of the prefix. 529 The Prefix is inter-area type and downstream neighbor is an ABR, 530 which is advertising the prefix reachability and is also 531 generating the Extended Prefix TLV with the A-flag set for this 532 prefix as described in section 2.1 of [RFC7684]. 534 The Prefix is external type and downstream neighbor is an ASBR, 535 which is advertising the prefix reachability and is also 536 generating the Extended Prefix TLV with the A-flag set for this 537 prefix as described in section 2.1 of [RFC7684]. 539 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 540 the value advertised in Prefix SID Sub-TLV is interpreted as a 541 starting SID value. 543 Example 1: If the following router addresses (loopback addresses) 544 need to be mapped into the corresponding Prefix SID indexes: 546 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 547 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 548 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 549 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 551 then the Prefix field in the Extended Prefix Range TLV would be set 552 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 553 set to 4, and the Index value in the Prefix-SID Sub-TLV would be set 554 to 1. 556 Example 2: If the following prefixes need to be mapped into the 557 corresponding Prefix-SID indexes: 559 10.1.1/24, Prefix-SID: Index 51 560 10.1.2/24, Prefix-SID: Index 52 561 10.1.3/24, Prefix-SID: Index 53 562 10.1.4/24, Prefix-SID: Index 54 563 10.1.5/24, Prefix-SID: Index 55 564 10.1.6/24, Prefix-SID: Index 56 565 10.1.7/24, Prefix-SID: Index 57 567 then the Prefix field in the Extended Prefix Range TLV would be set 568 to 10.1.1.0, Prefix Length would be set to 24, Range Size would be 7, 569 and the Index value in the Prefix-SID Sub-TLV would be set to 51. 571 6. SID/Label Binding Sub-TLV 573 The SID/Label Binding Sub-TLV is used to advertise a SID/Label 574 mapping for a path to the prefix. 576 The SID/Label Binding Sub-TLV MAY be originated by any router in an 577 OSPF domain. The router may advertise a SID/Label binding to a FEC 578 along with at least a single 'nexthop style' anchor. The protocol 579 supports more than one 'nexthop style' anchor to be attached to a 580 SID/Label binding, which results in a simple path description 581 language. In analogy to RSVP, the terminology for this is called an 582 'Explicit Route Object' (ERO). Since ERO style path notation allows 583 anchoring SID/label bindings to both link and node IP addresses, any 584 Label Switched Path (LSP) can be described. Additionally, SID/Label 585 Bindings from external protocols can be easily re-advertised. 587 The SID/Label Binding Sub-TLV may be used for advertising SID/Label 588 Bindings and their associated Primary and Backup paths. In a single 589 TLV, a primary ERO Path, backup ERO Path, or both can be advertised. 590 If a router wants to advertise multiple parallel paths, then it can 591 generate several TLVs for the same Prefix/FEC. Each occurrence of a 592 Binding TLV for a given FEC Prefix will add a new path. 594 The SID/Label Binding Sub-TLV is a Sub-TLV of the OSPF Extended 595 Prefix TLV described in [RFC7684] and the OSPF Extended Prefix Range 596 TLV described in Section 4. Multiple SID/Label Binding TLVs can be 597 present in their parent TLV. The SID/Label Binding Sub-TLV has 598 following format: 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type | Length | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Flags | Reserved | MT-ID | Weight | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Sub-TLVs (variable) | 608 +- -+ 609 | | 611 where: 613 Type: TBD, suggested value 3 615 Length: Variable 617 Flags: Single octet field containing the following flags: 619 0 1 2 3 4 5 6 7 620 +-+-+-+-+-+-+-+-+ 621 |M| | 622 +-+-+-+-+-+-+-+-+ 624 where: 626 M-bit - When the bit is set, the binding represents a mirroring 627 context as defined in 628 [I-D.minto-rsvp-lsp-egress-fast-protection]. 630 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 632 Weight: Weight used for load-balancing purposes. The use of the 633 weight is defined in [I-D.ietf-spring-segment-routing]. 635 The SID/Label Binding Sub-TLV supports the following Sub-TLVs: 637 SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST 638 appear in the SID/Label Binding Sub-TLV and it SHOULD only appear 639 once. If the SID/Label Sub-TLV is not included in the SID/Label 640 Binding Sub-TLV, the SID/Label Binding Sub-TLV MUST be ignored. 641 If the SID/Label Sub-TLV appears in the SID/Label Binding Sub-TLV 642 more than once, instances other than the first will be ignored and 643 the condition SHOULD be logged for possible action by the network 644 operator. 646 ERO Metric Sub-TLV as defined in Section 6.1. 648 ERO Sub-TLVs as defined in Section 6.2. 650 6.1. ERO Metric Sub-TLV 652 The ERO Metric Sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 654 The ERO Metric Sub-TLV advertises the cost of an ERO path. It is 655 used to compare the cost of a given source/destination path. A 656 router SHOULD advertise the ERO Metric Sub-TLV in an advertised ERO 657 TLV. The cost of the ERO Metric Sub-TLV SHOULD be set to the 658 cumulative IGP or TE path cost of the advertised ERO. Since 659 manipulation of the Metric field may attract or repel traffic to and 660 from the advertised segment, it MAY be manually overridden. 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Type | Length | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Metric (4 octets) | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 ERO Metric Sub-TLV format 672 where: 674 Type: TBD, suggested value 8 676 Length: Always 4 678 Metric: A 4-octet metric representing the aggregate IGP or TE path 679 cost. 681 6.2. ERO Sub-TLVs 683 All ERO information represents an ordered set which describes the 684 segments of a path. The first ERO Sub-TLV describes the first 685 segment of a path. Similiarly, the last ERO Sub-TLV describes the 686 segment closest to the egress point. If a router extends or stitches 687 a path, it MUST prepend the new segment's path information to the ERO 688 list. This applies equally to advertised backup EROs. 690 All ERO Sub-TLVs must immediately follow the SID/Label Sub-TLV. 692 All Backup ERO Sub-TLVs must immediately follow the last ERO Sub-TLV. 694 6.2.1. IPv4 ERO Sub-TLV 696 The IPv4 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 698 The IPv4 ERO Sub-TLV describes a path segment using IPv4 Address 699 style encoding. Its semantics have been borrowed from [RFC3209]. 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Type | Length | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Flags | Reserved | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | IPv4 Address (4 octets) | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 IPv4 ERO Sub-TLV format 713 where: 715 Type: TBD, suggested value 4 717 Length: 8 octets 719 Flags: Single octet field containing the following flags: 721 0 1 2 3 4 5 6 7 722 +-+-+-+-+-+-+-+-+ 723 |L| | 724 +-+-+-+-+-+-+-+-+ 726 where: 728 L-bit - If the L-bit is set, then the segment path is 729 designated as 'loose'. Otherwise, the segment path is 730 designated as 'strict'. The terms 'loose' and 'strict' are 731 defined for RSVP subobjects in [RFC3209]. 733 IPv4 Address - The address of the explicit route hop. 735 6.2.2. Unnumbered Interface ID ERO Sub-TLV 737 The Unnumbered Interface ID ERO Sub-TLV is a Sub-TLV of the SID/Label 738 Binding Sub-TLV. 740 The appearance and semantics of the 'Unnumbered Interface ID' have 741 been borrowed from [RFC3477]. 743 The Unnumbered Interface-ID ERO Sub-TLV describes a path segment that 744 includes an unnumbered interface. Unnumbered interfaces are 745 referenced using the interface index. Interface indices are assigned 746 local to the router and therefore are not unique within a domain. 747 All elements in an ERO path need to be unique within a domain and 748 hence need to be disambiguated using a domain unique Router-ID. 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Type | Length | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Flags | Reserved | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Router ID | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Interface ID | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 where: 764 Unnumbered Interface ID ERO Sub-TLV format 766 Type: TBD, suggested value 5 768 Length: 12 octets 770 Flags: Single octet field containing the following flags: 772 0 1 2 3 4 5 6 7 773 +-+-+-+-+-+-+-+-+ 774 |L| | 775 +-+-+-+-+-+-+-+-+ 777 where: 779 L-bit - If the L-bit is set, then the segment path is 780 designated as 'loose'. Otherwise, the segment path is 781 designated as 'strict'. The terms 'loose' and 'strict' are 782 defined for RSVP subobjects in [RFC3209] 784 Router-ID: Router-ID of the next-hop. 786 Interface ID: The identifier assigned to the link by the router 787 specified by the Router-ID. 789 6.2.3. IPv4 Backup ERO Sub-TLV 791 IPv4 Prefix Backup ERO Sub-TLV is a Sub-TLV of the SID/Label Binding 792 Sub-TLV. 794 The IPv4 Backup ERO Sub-TLV describes a path segment using IPv4 795 Address style of encoding. Its semantics have been borrowed from 796 [RFC3209]. 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Type | Length | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Flags | Reserved | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | IPv4 Address (4 octets) | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 IPv4 Backup ERO Sub-TLV format 810 where: 812 Type: TBD, suggested value 6 814 Length: 8 octets 816 Flags: Single octet field containing the following flags: 818 0 1 2 3 4 5 6 7 819 +-+-+-+-+-+-+-+-+ 820 |L| | 821 +-+-+-+-+-+-+-+-+ 823 where: 825 L-bit - If the L-bit is set, then the segment path is 826 designated as 'loose'. Otherwise, the segment path is 827 designated as 'strict'. The terms 'loose' and 'strict' are 828 defined for RSVP subobjects in [RFC3209] 830 IPv4 Address - The address of the explicit route hop. 832 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV 834 The Unnumbered Interface ID Backup ERO Sub-TLV is a Sub-TLV of the 835 SID/Label Binding Sub-TLV. 837 The appearance and semantics of the 'Unnumbered Interface ID' have 838 been borrowed from [RFC3477]. 840 The Unnumbered Interface-ID Backup ERO Sub-TLV describes a path 841 segment that includes an unnumbered interface. Unnumbered interfaces 842 are referenced using the interface index. Interface indices are 843 assigned local to the router and are therefore not unique within a 844 domain. All elements in an ERO path need to be unique within a 845 domain and hence need to be disambiguated with specification of the 846 domain unique Router-ID. 848 0 1 2 3 849 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 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Type | Length | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Flags | Reserved | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Router ID | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Interface ID | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Unnumbered Interface ID Backup ERO Sub-TLV format 862 where: 864 Type: TBD, suggested value 7 866 Length: 12 octets 868 Flags: Single octet field containing the following flags: 870 0 1 2 3 4 5 6 7 871 +-+-+-+-+-+-+-+-+ 872 |L| | 873 +-+-+-+-+-+-+-+-+ 875 where: 877 L-bit - If the L-bit is set, then the segment path is 878 designated as 'loose'. Otherwise, the segment path is 879 designated as 'strict'. 881 Router-ID: Router-ID of the next-hop. 883 Interface ID: The identifier assigned to the link by the router 884 specified by the Router-ID. 886 7. Adjacency Segment Identifier (Adj-SID) 888 An Adjacency Segment Identifier (Adj-SID) represents a router 889 adjacency in Segment Routing. 891 7.1. Adj-SID Sub-TLV 893 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 894 [RFC7684]. It MAY appear multiple times in the Extended Link TLV. 895 Examples where more than one Adj-SID may be used per neighbor are 896 described in section 4 of 897 [I-D.filsfils-spring-segment-routing-use-cases]. The Adj-SID Sub-TLV 898 has the following format: 900 0 1 2 3 901 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 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Type | Length | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Flags | Reserved | MT-ID | Weight | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | SID/Label/Index (variable) | 908 +---------------------------------------------------------------+ 910 where: 912 Type: TBD, suggested value 2. 914 Length: Variable. 916 Flags: Single octet field containing the following flags: 918 0 1 2 3 4 5 6 7 919 +-+-+-+-+-+-+-+-+ 920 |B|V|L|G| | 921 +-+-+-+-+-+-+-+-+ 923 where: 925 B-Flag: Backup Flag. If set, the Adj-SID refers to an 926 adjacency that is eligible for protection (e.g.: using IPFRR or 927 MPLS-FRR) as described in section 3.5 of 928 [I-D.ietf-spring-segment-routing]. 930 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 931 an absolute value. If not set, then the Adj-SID carries an 932 index. 934 The L-Flag: Local/Global Flag. If set, then the value/index 935 carried by the Adj-SID has local significance. If not set, 936 then the value/index carried by this Sub-TLV has global 937 significance. 939 The G-Flag: Group Flag. When set, the G-Flag indicates that 940 the Adj-SID refers to a group of adjacencies (and therefore MAY 941 be assigned to other adjacencies as well). 943 Other bits: Reserved. These MUST be zero when sent and are 944 ignored when received. 946 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 948 Weight: Weight used for load-balancing purposes. The use of the 949 weight is defined in [I-D.ietf-spring-segment-routing]. 951 SID/Index/Label: According to the V and L flags, it contains 952 either: 954 A 32-bit index defining the offset in the SID/Label space 955 advertised by this router. 957 A 24-bit label where the 20 rightmost bits are used for 958 encoding the label value. 960 An SR capable router MAY allocate an Adj-SID for each of its 961 adjacencies and set the B-Flag when the adjacency is eligible for 962 protection by an FRR mechanism (IP or MPLS) as described in section 963 3.5 of [I-D.ietf-spring-segment-routing]. 965 7.2. LAN Adj-SID Sub-TLV 967 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 968 in [RFC7684]. It MAY appear multiple times in the Extended-Link TLV. 969 It is used to advertise a SID/Label for an adjacency to a non-DR 970 router on a broadcast, NBMA, or hybrid [RFC6845] network. 972 0 1 2 3 973 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 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Type | Length | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Flags | Reserved | MT-ID | Weight | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Neighbor ID | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | SID/Label/Index (variable) | 982 +---------------------------------------------------------------+ 984 where: 986 Type: TBD, suggested value 3. 988 Length: Variable. 990 Flags: Single octet field containing the following flags: 992 0 1 2 3 4 5 6 7 993 +-+-+-+-+-+-+-+-+ 994 |B|V|L|G| | 995 +-+-+-+-+-+-+-+-+ 997 where: 999 B-Flag: Backup-flag. If set, the LAN-Adj-SID refers to an 1000 adjacency that is eligible for protection (e.g.: using IPFRR or 1001 MPLS-FRR) as described in section 3.5 of 1002 [I-D.ietf-spring-segment-routing]. 1004 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 1005 carries an absolute value. If not set, then the Prefix-SID 1006 carries an index. 1008 The L-Flag: Local/Global Flag. If set, then the value/index 1009 carried by the Prefix-SID has local significance. If not set, 1010 then the value/index carried by this Sub-TLV has global 1011 significance. 1013 The G-Flag: Group Flag. When set, the G-Flag indicates that 1014 the LAN-Adj-SID refers to a group of adjacencies (and therefore 1015 MAY be assigned to other adjacencies as well). 1017 Other bits: Reserved. These MUST be zero when sent and are 1018 ignored when received. 1020 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1022 Weight: Weight used for load-balancing purposes. The use of the 1023 weight is defined in [I-D.ietf-spring-segment-routing]. 1025 Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- 1026 SID is advertised. 1028 SID/Index/Label: According to the V and L flags, it contains 1029 either: 1031 A 32-bit index defining the offset in the SID/Label space 1032 advertised by this router. 1034 A 24-bit label where the 20 rightmost bits are used for 1035 encoding the label value. 1037 8. Elements of Procedure 1039 8.1. Intra-area Segment routing in OSPFv2 1041 An OSPFv2 router that supports segment routing MAY advertise Prefix- 1042 SIDs for any prefix to which it is advertising reachability (e.g., a 1043 loopback IP address as described in Section 5). 1045 If multiple routers advertise a Prefix-SID for the same prefix, then 1046 the Prefix-SID MUST be the same. This is required in order to allow 1047 traffic load-balancing when multiple equal cost paths to the 1048 destination exist in the OSPFv2 routing domain. 1050 Prefix-SID can also be advertised by the SR Mapping Servers (as 1051 described in [I-D.filsfils-spring-segment-routing-ldp-interop]). The 1052 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 1053 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 1054 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 1055 MUST be advertised by all of them. The flooding scope of the OSPF 1056 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 1057 could be either area scoped or AS scoped and is determined based on 1058 the configuration of the SR Mapping Server. 1060 The SR Mapping Server MUST use OSPF Extended Prefix Range TLV when 1061 advertising SIDs for prefixes. Prefixes of different route-types can 1062 be combined in a single OSPF Extended Prefix Range TLV advertised by 1063 the SR Mapping Server. 1065 Area-scoped OSPF Extended Prefix Range TLV are propagated between 1066 areas. Similar to propagation of prefixes between areas, an ABR only 1067 propagates the OSPF Extended Prefix Range TLV that it considers to be 1068 the best from the set it received. The rules used to pick the best 1069 OSPF Extended Prefix Range TLV are described in Section 4. 1071 When propagating an OSPF Extended Prefix Range TLV between areas, 1072 ABRs MUST set the IA-Flag, that is used to prevent redundant flooding 1073 of the OSPF Extended Prefix Range TLV between areas as described in 1074 Section 4. 1076 If the Prefix-SID that is advertised in a Prefix SID Sub-TLV is also 1077 covered by the OSPF Extended Prefix Range TLV, the Prefix-SID 1078 advertised in Prefix SID Sub-TLV MUST be preferred. 1080 8.2. Inter-area Segment routing in OSPFv2 1082 In order to support SR in a multi-area environment, OSPFv2 must 1083 propagate Prefix-SID information between areas. The following 1084 procedure is used to propagate Prefix SIDs between areas. 1086 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 1087 prefix to all its connected areas, it will also originate an Extended 1088 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 1089 the Extended Prefix Opaque LSA type will be set to area-scope. The 1090 route-type in the OSPF Extended Prefix TLV is set to inter-area. The 1091 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1092 value will be set as follows: 1094 The ABR will look at its best path to the prefix in the source 1095 area and find the advertising router associated with the best path 1096 to that prefix. 1098 The ABR will then determine if such router advertised a Prefix-SID 1099 for the prefix and use it when advertising the Prefix-SID to other 1100 connected areas. 1102 If no Prefix-SID was advertised for the prefix in the source area 1103 by the router that contributes to the best path to the prefix, the 1104 originating ABR will use the Prefix-SID advertised by any other 1105 router when propagating the Prefix-SID for the prefix to other 1106 areas. 1108 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 1109 route to all its connected areas, it will also originate an Extended 1110 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 1111 the Extended Prefix Opaque LSA type will be set to area-scope. The 1112 route-type in OSPF Extended Prefix TLV is set to inter-area. The 1113 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1114 will be set as follows: 1116 The ABR will look at its best path to the prefix in the backbone 1117 area and find the advertising router associated with the best path 1118 to that prefix. 1120 The ABR will then determine if such router advertised a Prefix-SID 1121 for the prefix and use it when advertising the Prefix-SID to other 1122 connected areas. 1124 If no Prefix-SID was advertised for the prefix in the backbone 1125 area by the ABR that contributes to the best path to the prefix, 1126 the originating ABR will use the Prefix-SID advertised by any 1127 other router when propagating the Prefix-SID for the prefix to 1128 other areas. 1130 8.3. SID for External Prefixes 1132 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1133 SR, generates Type-5 LSAs, it should also originate Extended Prefix 1134 Opaque LSAs, as described in [RFC7684]. The flooding scope of the 1135 Extended Prefix Opaque LSA type is set to AS-scope. The route-type 1136 in the OSPF Extended Prefix TLV is set to external. The Prefix-SID 1137 Sub-TLV is included in this LSA and the Prefix-SID value will be set 1138 to the SID that has been reserved for that prefix. 1140 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 1141 also advertise the Prefix-SID for the prefix. The NSSA ABR 1142 determines its best path to the prefix advertised in the translated 1143 Type-7 LSA and finds the advertising router associated with that 1144 path. If the advertising router has advertised a Prefix-SID for the 1145 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 1146 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 1147 router will be used. 1149 8.4. Advertisement of Adj-SID 1151 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1152 using the Adj-SID Sub-TLV as described in Section 7. 1154 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 1156 An Adj-SID MAY be advertised for any adjacency on a P2P link that is 1157 in neighbor state 2-Way or higher. If the adjacency on a P2P link 1158 transitions from the FULL state, then the Adj-SID for that adjacency 1159 MAY be removed from the area. If the adjacency transitions to a 1160 state lower then 2-Way, then the Adj-SID advertisement MUST be 1161 removed from the area. 1163 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1165 Broadcast, NBMA or or hybrid [RFC6845] networks in OSPF are 1166 represented by a star topology where the Designated Router (DR) is 1167 the central point to which all other routers on the broadcast, NBMA, 1168 or hybrid network connect. As a result, routers on the broadcast, 1169 NBMA, or hybrid network advertise only their adjacency to the DR. 1170 Routers that do not act as DR do not form or advertise adjacencies 1171 with each other. They do, however, maintain 2-Way adjacency state 1172 with each other and are directly reachable. 1174 When Segment Routing is used, each router on the broadcast or NBMA 1175 network MAY advertise the Adj-SID for its adjacency to the DR using 1176 the Adj-SID Sub-TLV as described in Section 7.1. 1178 SR capable routers MAY also advertise an LAN-Adj-SID for other 1179 neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA or hybrid 1180 network using the LAN-ADJ-SID Sub-TLV as described in Section 7.2. 1182 9. IANA Considerations 1184 This specification updates several existing OSPF registries. 1186 9.1. OSPF OSPF Router Information (RI) TLVs Registry 1188 o 8 (IANA Preallocated) - SR-Algorithm TLV 1190 o 9 (IANA Preallocated) - SID/Label Range TLV 1192 9.2. OSPF Extended Prefix LSA TLV Registry 1194 Following values are allocated: 1196 o 2 - OSPF Extended Prefix Range TLV 1198 9.3. OSPF Extended Prefix LSA Sub-TLV Registry 1200 Following values are allocated: 1202 o 1 - SID/Label Sub-TLV 1204 o 2 - Prefix SID Sub-TLV 1206 o 3 - SID/Label Binding Sub-TLV 1208 o 4 - IPv4 ERO Sub-TLV 1210 o 5 - Unnumbered Interface ID ERO Sub-TLV 1212 o 6 - IPv4 Backup ERO Sub-TLV 1214 o 7 - Unnumbered Interface ID Backup ERO Sub-TLV 1216 o 8 - ERO Metric Sub-TLV 1218 9.4. OSPF Extended Link LSA Sub-TLV Registry 1220 Following initial values are allocated: 1222 o 1 - SID/Label Sub-TLV 1224 o 2 - Adj-SID Sub-TLV 1225 o 3 - LAN Adj-SID/Label Sub-TLV 1227 10. Implementation Status 1229 An implementation survey with seven questions related to the 1230 implementer's support of OSPFv2 Segment Routing was sent to the OSPF 1231 WG list and several known implementers. This section contains 1232 responses from two implementers who completed the survey. No 1233 external means were used to verify the accuracy of the information 1234 submitted by the respondents. The respondents are considered experts 1235 on the products they reported on. Additionally, responses were 1236 omitted from implementers who indicated that they have not 1237 implemented the function yet. 1239 Responses from Nokia (former Alcatel-Lucent): 1241 Link to a web page describing the implementation: 1242 https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/ 1243 3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Un 1244 icast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf 1246 The implementation's level of maturity: Production. 1248 Coverage: We have implemented all sections and have support for the 1249 latest draft. 1251 Licensing: Part of the software package that needs to be purchased. 1253 Implementation experience: Great spec. We also performed inter- 1254 operability testing with Cisco's OSPF Segment Routing implementation. 1256 Contact information: wim.henderickx@nokia.com 1258 Responses from Cisco Systems: 1260 Link to a web page describing the implementation: 1262 www.segment-routing.net/home/tutorial 1264 The implementation's level of maturity: Production. 1266 Coverage: All sections, except the section 6 (SID/Label Binding Sub- 1267 TLV) have been implemented according to the latest draft. 1269 Licensing: Part of a commercial software package. 1271 Implementation experience: Many aspects of the draft are result of 1272 the actual implementation experience, as the draft evolved from its 1273 initial version to the current one. Interoperability testing with 1274 Alcatel-Lucent was performed, which confirmed the draft's ability to 1275 serve as a reference for the implementors. 1277 Contact information: ppsenak@cisco.com 1279 Responses from Juniper: 1281 The implementation's name and/or a link to a web page describing the 1282 implementation: 1284 Feature name is OSPF SPRING 1286 The implementation's level of maturity: To be released in 16.2 1287 (second half of 2016) 1289 Coverage: All sections implemented except Sections 4, and 6. 1291 Licensing: JUNOS Licensing needed. 1293 Implementation experience: NA 1295 Contact information: shraddha@juniper.net 1297 11. Security Considerations 1299 Implementations must assure that malformed TLV and Sub-TLV 1300 permutations do not result in errors which cause hard OSPF failures. 1302 12. Contributors 1304 The following people gave a substantial contribution to the content 1305 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1306 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1307 Saku Ytti. 1309 13. Acknowledgements 1311 We would like to thank Anton Smirnov for his contribution. 1313 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1314 contribution on earlier incarnations of the "Binding / MPLS Label 1315 TLV" in [I-D.gredler-ospf-label-advertisement]. 1317 Thanks to Acee Lindem for the detail review of the draft, 1318 corrections, as well as discussion about details of the encoding. 1320 14. References 1322 14.1. Normative References 1324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1325 Requirement Levels", BCP 14, RFC 2119, 1326 DOI 10.17487/RFC2119, March 1997, 1327 . 1329 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1330 DOI 10.17487/RFC2328, April 1998, 1331 . 1333 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1334 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1335 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1336 . 1338 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1339 in Resource ReSerVation Protocol - Traffic Engineering 1340 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1341 . 1343 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1344 (TE) Extensions to OSPF Version 2", RFC 3630, 1345 DOI 10.17487/RFC3630, September 2003, 1346 . 1348 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1349 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1350 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1351 . 1353 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1354 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 1355 July 2008, . 1357 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 1358 and Point-to-Multipoint Interface Type", RFC 6845, 1359 DOI 10.17487/RFC6845, January 2013, 1360 . 1362 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1363 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1364 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1365 2015, . 1367 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1368 S. Shaffer, "Extensions to OSPF for Advertising Optional 1369 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1370 February 2016, . 1372 14.2. Informative References 1374 [I-D.filsfils-spring-segment-routing-ldp-interop] 1375 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1376 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1377 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1378 "Segment Routing interoperability with LDP", draft- 1379 filsfils-spring-segment-routing-ldp-interop-02 (work in 1380 progress), September 2014. 1382 [I-D.filsfils-spring-segment-routing-use-cases] 1383 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1384 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1385 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1386 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1387 spring-segment-routing-use-cases-01 (work in progress), 1388 October 2014. 1390 [I-D.gredler-ospf-label-advertisement] 1391 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1392 "Advertising MPLS labels in OSPF", draft-gredler-ospf- 1393 label-advertisement-03 (work in progress), May 2013. 1395 [I-D.ietf-spring-segment-routing] 1396 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1397 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1398 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 1399 spring-segment-routing-00 (work in progress), December 1400 2014. 1402 [I-D.minto-rsvp-lsp-egress-fast-protection] 1403 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1404 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1405 protection-03 (work in progress), November 2013. 1407 Authors' Addresses 1408 Peter Psenak (editor) 1409 Cisco Systems, Inc. 1410 Apollo Business Center 1411 Mlynske nivy 43 1412 Bratislava 821 09 1413 Slovakia 1415 Email: ppsenak@cisco.com 1417 Stefano Previdi (editor) 1418 Cisco Systems, Inc. 1419 Via Del Serafico, 200 1420 Rome 00142 1421 Italy 1423 Email: sprevidi@cisco.com 1425 Clarence Filsfils 1426 Cisco Systems, Inc. 1427 Brussels 1428 Belgium 1430 Email: cfilsfil@cisco.com 1432 Hannes Gredler 1433 Individual 1434 Austria 1436 Email: hannes@gredler.at 1438 Rob Shakir 1439 Jive Communications, Inc. 1440 1275 West 1600 North, Suite 100 1441 Orem, UT 84057 1442 US 1444 Email: rrjs@rob.sh 1445 Wim Henderickx 1446 Nokia 1447 Copernicuslaan 50 1448 Antwerp 2018 1449 BE 1451 Email: wim.henderickx@nokia.com 1453 Jeff Tantsura 1454 Individual 1455 US 1457 Email: jefftant.ietf@gmail.com