idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-08.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 (April 27, 2016) is 2920 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 299 -- Looks like a reference, but probably isn't: '199' on line 299 -- Looks like a reference, but probably isn't: '1000' on line 300 -- Looks like a reference, but probably isn't: '1099' on line 300 -- Looks like a reference, but probably isn't: '500' on line 301 -- Looks like a reference, but probably isn't: '599' on line 301 == Unused Reference: 'RFC2328' is defined on line 1328, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 1342, 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: A later version (-15) exists of draft-ietf-spring-segment-routing-00 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: October 29, 2016 Cisco Systems, Inc. 6 H. Gredler 7 Individual 8 R. Shakir 9 Jive Communications, Inc. 10 W. Henderickx 11 Alcatel-Lucent 12 J. Tantsura 13 Individual 14 April 27, 2016 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-08 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 October 29, 2016. 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. 193 An SR Router may use various algorithms when calculating reachability 194 to OSPF routers or prefixes in an OSPF area. Examples of these 195 algorithms are metric based Shortest Path First (SPF), various 196 flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a 197 router to advertise the algorithms currently used by the router to 198 other routers in an OSPF area. The SR-Algorithm TLV has following 199 format: 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Type | Length | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Algorithm 1 | Algorithm... | Algorithm n | | 207 +- -+ 208 | | 209 + + 211 where: 213 Type: TBD, suggested value 8 215 Length: variable 217 Algorithm: Single octet identifying the algorithm. The following 218 values are defined by this document: 220 0: Shortest Path First (SPF) algorithm based on link metric. 221 This is the standard shortest path algorithm as computed by the 222 OSPF protocol. Consistent with the deployed practice for link- 223 state protocols, Algorithm 0 permits any node to overwrite the 224 SPF path with a different path based on its local policy. If 225 the SR-Algorithm Sub-TLV is advertised, Algorithm 0 MUST be 226 included. 228 1: Strict Shortest Path First (SPF) algorithm based on link 229 metric. The algorithm is identical to Algorithm 0 but 230 Algorithm 1 requires that all nodes along the path will honor 231 the SPF routing decision. Local policy at the node claiming 232 support for Algorithm 1 MUST NOT alter the SPF paths computed 233 by Algorithm 1. 235 The RI LSA can be advertised at any of the defined opaque flooding 236 scopes (link, area, or Autonomous System (AS)). For the purpose of 237 SR-Algorithm TLV advertisement, area scope flooding is required. 239 3.2. SID/Label Range TLV 241 The SID/Label Range TLV is a top-level TLV of the Router Information 242 Opaque LSA (defined in [RFC7770]). 244 The SID/Label Range TLV MAY appear multiple times and has the 245 following format: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type | Length | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Range Size | Reserved | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Sub-TLVs (variable) | 255 +- -+ 256 | | 257 + + 259 where: 261 Type: TBD, suggested value 9 263 Length: variable 265 Range Size: 3 octets of the SID/label range 267 Initially, the only supported Sub-TLV is the SID/Label TLV as defined 268 in Section 2.1. The SID/Label advertised in the SID/Label TLV 269 represents the first SID/Label in the advertised range. 271 Multiple occurrences of the SID/Label Range TLV MAY be advertised, in 272 order to advertise multiple ranges. In such case: 274 o The originating router MUST encode each range into a different 275 SID/Label Range TLV. 277 o The originating router decides the order in which the set of SID/ 278 Label Range TLVs are advertised inside the Router Information 279 Opaque LSA. The originating router MUST ensure the order is the 280 same after a graceful restart (using checkpointing, non-volatile 281 storage or any other mechanism) in order to assure the SID/label 282 range and SID index correspondence is preserved across graceful 283 restarts. 285 o The receiving router must adhere to the order in which the ranges 286 are advertised when calculating a SID/label from a SID index. 288 The following example illustrates the advertisement of multiple 289 ranges: 291 The originating router advertises following ranges: 292 Range 1: [100, 199] 293 Range 2: [1000, 1099] 294 Range 3: [500, 599] 296 The receiving routers concatenate the ranges and build the Segment 297 Routing Global Block (SRGB) as follows: 299 SRGB = [100, 199] 300 [1000, 1099] 301 [500, 599] 303 The indexes span multiple ranges: 305 index=0 means label 100 306 ... 307 index 99 means label 199 308 index 100 means label 1000 309 index 199 means label 1099 310 ... 311 index 200 means label 500 312 ... 314 The RI LSA can be advertised at any of the defined flooding scopes 315 (link, area, or autonomous system (AS)). For the purpose of SID/ 316 Label Range TLV advertisement, area scope flooding is required. 318 4. OSPF Extended Prefix Range TLV 320 In some cases it is useful to advertise attributes for a range of 321 prefixes. The Segment Routing Mapping Server, which is described in 322 [I-D.filsfils-spring-segment-routing-ldp-interop], is an example 323 where we need a single advertisement to advertise SIDs for multiple 324 prefixes from a contiguous address range. 326 The OSPF Extended Prefix Range TLV, which is a new top level TLV of 327 the Extended Prefix LSA described in [RFC7684] is defined for this 328 purpose. 330 Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each 331 OSPF Extended Prefix Opaque LSA, but all prefix ranges included in a 332 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 333 scope. The OSPF Extended Prefix Range TLV has the following format: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Type | Length | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Prefix Length | AF | Range Size | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Flags | Reserved | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Address Prefix (variable) | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Sub-TLVs (variable) | 347 +- -+ 348 | | 350 where: 352 Type: TBD, suggested value 2. 354 Length: Variable 356 Prefix length: Length of the prefix 358 AF: 0 - IPv4 unicast 360 Range size: Represents the number of prefixes that are covered by 361 the advertisement. The Range Size MUST NOT exceed the number of 362 prefixes that could be satisfied by the prefix length without 363 including the IPv4 multicast address range (224.0.0.0/3). 365 Flags: Single octet field. The following flags are defined: 367 0 1 2 3 4 5 6 7 368 +--+--+--+--+--+--+--+--+ 369 |IA| | | | | | | | 370 +--+--+--+--+--+--+--+--+ 372 where: 374 IA-Flag: Inter-Area flag. If set, advertisement is of inter- 375 area type. The ABR that is advertising the OSPF Extended 376 Prefix Range TLV between areas MUST set this bit. 378 This bit is used to prevent redundant flooding of Prefix Range 379 TLVs between areas as follows: 381 An ABR always prefers intra-area Prefix Range advertisements 382 over inter-area advertisements. 384 An ABR does not consider inter-area Prefix Range 385 advertisements coming from non-backbone areas. 387 An ABR only propagates an inter-area Prefix Range 388 advertisement from the backbone area to connected non- 389 backbone areas if the advertisement is considered to be the 390 best one. 392 Address Prefix: The prefix, encoded as an even multiple of 32-bit 393 words, padded with zero bits as necessary. This encoding consumes 394 ((PrefixLength + 31) / 32) 32-bit words. The Address Prefix 395 represents the first prefix in the prefix range. 397 5. Prefix SID Sub-TLV 399 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV 400 described in [RFC7684] and the OSPF Extended Prefix Range TLV 401 described in Section 4. It MAY appear more than once in the parent 402 TLV and has the following format: 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type | Length | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Flags | Reserved | MT-ID | Algorithm | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | SID/Index/Label (variable) | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 where: 416 Type: TBD, suggested value 2. 418 Length: Variable 420 Flags: Single octet field. The following flags are defined: 422 0 1 2 3 4 5 6 7 423 +--+--+--+--+--+--+--+--+ 424 | |NP|M |E |V |L | | | 425 +--+--+--+--+--+--+--+--+ 427 where: 429 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 430 NOT pop the Prefix-SID before delivering packets to the node 431 that advertised the Prefix-SID. 433 M-Flag: Mapping Server Flag. If set, the SID was advertised by 434 a Segment Routing Mapping Server as described in 435 [I-D.filsfils-spring-segment-routing-ldp-interop]. 437 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 438 the Prefix-SID originator MUST replace the Prefix-SID with the 439 Explicit-NULL label (0 for IPv4) before forwarding the packet. 441 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 442 an absolute value. If not set, then the Prefix-SID carries an 443 index. 445 L-Flag: Local/Global Flag. If set, then the value/index 446 carried by the Prefix-SID has local significance. If not set, 447 then the value/index carried by this Sub-TLV has global 448 significance. 450 Other bits: Reserved. These MUST be zero when sent and are 451 ignored when received. 453 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 455 Algorithm: Single octet identifying the algorithm the Prefix-SID 456 is associated with as defined in Section 3.1. 458 SID/Index/Label: According to the V and L flags, it contains 459 either: 461 A 32-bit index defining the offset in the SID/Label space 462 advertised by this router. 464 A 24-bit label where the 20 rightmost bits are used for 465 encoding the label value. 467 If multiple Prefix-SIDs are advertised for the same prefix, the 468 receiving router MUST use the first encoded SID and MAY use the 469 subsequent SIDs. 471 When propagating Prefix-SIDs between areas, if multiple prefix-SIDs 472 are advertised for a prefix, an implementation SHOULD preserve the 473 original order when advertising prefix-SIDs to other areas. This 474 allows implementations that only support a single Prefix-SID to have 475 a consistent view across areas. 477 When calculating the outgoing label for the prefix, the router MUST 478 take into account the E and P flags advertised by the next-hop router 479 if that router advertised the SID for the prefix. This MUST be done 480 regardless of whether the next-hop router contributes to the best 481 path to the prefix. 483 The NP-Flag (No-PHP) MUST be set for Prefix-SIDs allocated to inter- 484 area prefixes that are originated by the ABR based on intra-area or 485 inter-area reachability between areas. When the inter-area prefix is 486 generated based on a prefix which is directly attached to the ABR, 487 the NP-Flag SHOULD NOT be set. 489 The NP-Flag (No-PHP) MUST be be set for the Prefix-SIDs allocated to 490 redistributed prefixes, unless the redistributed prefix is directly 491 attached to the ASBR, in which case the NP-flag SHOULD NOT be set. 493 If the NP-Flag is not set, then any upstream neighbor of the Prefix- 494 SID originator MUST pop the Prefix-SID. This is equivalent to the 495 penultimate hop popping mechanism used in the MPLS dataplane. In 496 such case, MPLS EXP bits of the Prefix-SID are not preserved for the 497 final destination (the Prefix-SID being removed). If the NP-flag is 498 not set then the received E-flag is ignored. 500 If the NP-flag is set then: 502 If the E-flag is not set, then any upstream neighbor of the 503 Prefix-SID originator MUST keep the Prefix-SID on top of the 504 stack. This is useful when the originator of the Prefix-SID must 505 stitch the incoming packet into a continuing MPLS LSP to the final 506 destination. This could occur at an Area Border Router (prefix 507 propagation from one area to another) or at an AS Boundary Router 508 (prefix propagation from one domain to another). 510 If the E-flag is set, then any upstream neighbor of the Prefix-SID 511 originator MUST replace the Prefix-SID with an Explicit-NULL 512 label. This is useful, e.g., when the originator of the Prefix- 513 SID is the final destination for the related prefix and the 514 originator wishes to receive the packet with the original EXP 515 bits. 517 When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at 518 reception. 520 As the Mapping Server does not specify the originator of a prefix 521 advertisement, it is not possible to determine PHP behavior solely 522 based on the Mapping Server advertisement. However, PHP behavior may 523 safely be done in following cases: 525 The Prefix is intra-area type and the downstream neighbor is the 526 originator of the prefix. 528 The Prefix is inter-area type and downstream neighbor is an ABR, 529 which is advertising the prefix reachability and is also 530 generating the Extended Prefix TLV with the A-flag set for this 531 prefix as described in section 2.1 of [RFC7684]. 533 The Prefix is external type and downstream neighbor is an ASBR, 534 which is advertising the prefix reachability and is also 535 generating the Extended Prefix TLV with the A-flag set for this 536 prefix as described in section 2.1 of [RFC7684]. 538 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 539 the value advertised in Prefix SID Sub-TLV is interpreted as a 540 starting SID value. 542 Example 1: If the following router addresses (loopback addresses) 543 need to be mapped into the corresponding Prefix SID indexes: 545 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 546 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 547 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 548 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 550 then the Prefix field in the Extended Prefix Range TLV would be set 551 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 552 set to 4, and the Index value in the Prefix-SID Sub-TLV would be set 553 to 1. 555 Example 2: If the following prefixes need to be mapped into the 556 corresponding Prefix-SID indexes: 558 10.1.1/24, Prefix-SID: Index 51 559 10.1.2/24, Prefix-SID: Index 52 560 10.1.3/24, Prefix-SID: Index 53 561 10.1.4/24, Prefix-SID: Index 54 562 10.1.5/24, Prefix-SID: Index 55 563 10.1.6/24, Prefix-SID: Index 56 564 10.1.7/24, Prefix-SID: Index 57 566 then the Prefix field in the Extended Prefix Range TLV would be set 567 to 10.1.1.0, Prefix Length would be set to 24, Range Size would be 7, 568 and the Index value in the Prefix-SID Sub-TLV would be set to 51. 570 6. SID/Label Binding Sub-TLV 572 The SID/Label Binding Sub-TLV is used to advertise a SID/Label 573 mapping for a path to the prefix. 575 The SID/Label Binding Sub-TLV MAY be originated by any router in an 576 OSPF domain. The router may advertise a SID/Label binding to a FEC 577 along with at least a single 'nexthop style' anchor. The protocol 578 supports more than one 'nexthop style' anchor to be attached to a 579 SID/Label binding, which results in a simple path description 580 language. In analogy to RSVP, the terminology for this is called an 581 'Explicit Route Object' (ERO). Since ERO style path notation allows 582 anchoring SID/label bindings to both link and node IP addresses, any 583 Label Switched Path (LSP) can be described. Additionally, SID/Label 584 Bindings from external protocols can be easily re-advertised. 586 The SID/Label Binding Sub-TLV may be used for advertising SID/Label 587 Bindings and their associated Primary and Backup paths. In a single 588 TLV, a primary ERO Path, backup ERO Path, or both can be advertised. 589 If a router wants to advertise multiple parallel paths, then it can 590 generate several TLVs for the same Prefix/FEC. Each occurrence of a 591 Binding TLV for a given FEC Prefix will add a new path. 593 The SID/Label Binding Sub-TLV is a Sub-TLV of the OSPF Extended 594 Prefix TLV described in [RFC7684] and the OSPF Extended Prefix Range 595 TLV described in Section 4. Multiple SID/Label Binding TLVs can be 596 present in their parent TLV. The SID/Label Binding Sub-TLV has 597 following format: 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Type | Length | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Flags | Reserved | MT-ID | Weight | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Sub-TLVs (variable) | 607 +- -+ 608 | | 610 where: 612 Type: TBD, suggested value 3 614 Length: Variable 616 Flags: Single octet field containing the following flags: 618 0 1 2 3 4 5 6 7 619 +-+-+-+-+-+-+-+-+ 620 |M| | 621 +-+-+-+-+-+-+-+-+ 623 where: 625 M-bit - When the bit is set, the binding represents a mirroring 626 context as defined in 627 [I-D.minto-rsvp-lsp-egress-fast-protection]. 629 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 631 Weight: Weight used for load-balancing purposes. The use of the 632 weight is defined in [I-D.ietf-spring-segment-routing]. 634 The SID/Label Binding Sub-TLV supports the following Sub-TLVs: 636 SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST 637 appear in the SID/Label Binding Sub-TLV and it SHOULD only appear 638 once. If the SID/Label Sub-TLV is not included in the SID/Label 639 Binding Sub-TLV, the SID/Label Binding Sub-TLV MUST be ignored. 640 If the SID/Label Sub-TLV appears in the SID/Label Binding Sub-TLV 641 more than once, instances other than the first will be ignored and 642 the condition SHOULD be logged for possible action by the network 643 operator. 645 ERO Metric Sub-TLV as defined in Section 6.1. 647 ERO Sub-TLVs as defined in Section 6.2. 649 6.1. ERO Metric Sub-TLV 651 The ERO Metric Sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 653 The ERO Metric Sub-TLV advertises the cost of an ERO path. It is 654 used to compare the cost of a given source/destination path. A 655 router SHOULD advertise the ERO Metric Sub-TLV in an advertised ERO 656 TLV. The cost of the ERO Metric Sub-TLV SHOULD be set to the 657 cumulative IGP or TE path cost of the advertised ERO. Since 658 manipulation of the Metric field may attract or repel traffic to and 659 from the advertised segment, it MAY be manually overridden. 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Type | Length | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Metric (4 octets) | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 ERO Metric Sub-TLV format 671 where: 673 Type: TBD, suggested value 8 675 Length: Always 4 677 Metric: A 4-octet metric representing the aggregate IGP or TE path 678 cost. 680 6.2. ERO Sub-TLVs 682 All ERO information represents an ordered set which describes the 683 segments of a path. The first ERO Sub-TLV describes the first 684 segment of a path. Similiarly, the last ERO Sub-TLV describes the 685 segment closest to the egress point. If a router extends or stitches 686 a path, it MUST prepend the new segment's path information to the ERO 687 list. This applies equally to advertised backup EROs. 689 All ERO Sub-TLVs must immediately follow the SID/Label Sub-TLV. 691 All Backup ERO Sub-TLVs must immediately follow the last ERO Sub-TLV. 693 6.2.1. IPv4 ERO Sub-TLV 695 The IPv4 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 697 The IPv4 ERO Sub-TLV describes a path segment using IPv4 Address 698 style encoding. Its semantics have been borrowed from [RFC3209]. 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Type | Length | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Flags | Reserved | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | IPv4 Address (4 octets) | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 IPv4 ERO Sub-TLV format 712 where: 714 Type: TBD, suggested value 4 716 Length: 8 octets 718 Flags: Single octet field containing the following flags: 720 0 1 2 3 4 5 6 7 721 +-+-+-+-+-+-+-+-+ 722 |L| | 723 +-+-+-+-+-+-+-+-+ 725 where: 727 L-bit - If the L-bit is set, then the segment path is 728 designated as 'loose'. Otherwise, the segment path is 729 designated as 'strict'. The terms 'loose' and 'strict' are 730 defined for RSVP subobjects in [RFC3209]. 732 IPv4 Address - The address of the explicit route hop. 734 6.2.2. Unnumbered Interface ID ERO Sub-TLV 736 The Unnumbered Interface ID ERO Sub-TLV is a Sub-TLV of the SID/Label 737 Binding Sub-TLV. 739 The appearance and semantics of the 'Unnumbered Interface ID' have 740 been borrowed from [RFC3477]. 742 The Unnumbered Interface-ID ERO Sub-TLV describes a path segment that 743 includes an unnumbered interface. Unnumbered interfaces are 744 referenced using the interface index. Interface indices are assigned 745 local to the router and therefore are not unique within a domain. 746 All elements in an ERO path need to be unique within a domain and 747 hence need to be disambiguated using a domain unique Router-ID. 749 0 1 2 3 750 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 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Type | Length | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Flags | Reserved | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Router ID | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Interface ID | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 where: 763 Unnumbered Interface ID ERO Sub-TLV format 765 Type: TBD, suggested value 5 767 Length: 12 octets 769 Flags: Single octet field containing the following flags: 771 0 1 2 3 4 5 6 7 772 +-+-+-+-+-+-+-+-+ 773 |L| | 774 +-+-+-+-+-+-+-+-+ 776 where: 778 L-bit - If the L-bit is set, then the segment path is 779 designated as 'loose'. Otherwise, the segment path is 780 designated as 'strict'. The terms 'loose' and 'strict' are 781 defined for RSVP subobjects in [RFC3209] 783 Router-ID: Router-ID of the next-hop. 785 Interface ID: The identifier assigned to the link by the router 786 specified by the Router-ID. 788 6.2.3. IPv4 Backup ERO Sub-TLV 790 IPv4 Prefix Backup ERO Sub-TLV is a Sub-TLV of the SID/Label Binding 791 Sub-TLV. 793 The IPv4 Backup ERO Sub-TLV describes a path segment using IPv4 794 Address style of encoding. Its semantics have been borrowed from 795 [RFC3209]. 797 0 1 2 3 798 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 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Type | Length | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Flags | Reserved | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | IPv4 Address (4 octets) | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 IPv4 Backup ERO Sub-TLV format 809 where: 811 Type: TBD, suggested value 6 813 Length: 8 octets 815 Flags: Single octet field containing the following flags: 817 0 1 2 3 4 5 6 7 818 +-+-+-+-+-+-+-+-+ 819 |L| | 820 +-+-+-+-+-+-+-+-+ 822 where: 824 L-bit - If the L-bit is set, then the segment path is 825 designated as 'loose'. Otherwise, the segment path is 826 designated as 'strict'. The terms 'loose' and 'strict' are 827 defined for RSVP subobjects in [RFC3209] 829 IPv4 Address - The address of the explicit route hop. 831 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV 833 The Unnumbered Interface ID Backup ERO Sub-TLV is a Sub-TLV of the 834 SID/Label Binding Sub-TLV. 836 The appearance and semantics of the 'Unnumbered Interface ID' have 837 been borrowed from [RFC3477]. 839 The Unnumbered Interface-ID Backup ERO Sub-TLV describes a path 840 segment that includes an unnumbered interface. Unnumbered interfaces 841 are referenced using the interface index. Interface indices are 842 assigned local to the router and are therefore not unique within a 843 domain. All elements in an ERO path need to be unique within a 844 domain and hence need to be disambiguated with specification of the 845 domain unique Router-ID. 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Type | Length | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Flags | Reserved | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Router ID | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Interface ID | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 Unnumbered Interface ID Backup ERO Sub-TLV format 861 where: 863 Type: TBD, suggested value 7 865 Length: 12 octets 867 Flags: Single octet field containing the following flags: 869 0 1 2 3 4 5 6 7 870 +-+-+-+-+-+-+-+-+ 871 |L| | 872 +-+-+-+-+-+-+-+-+ 874 where: 876 L-bit - If the L-bit is set, then the segment path is 877 designated as 'loose'. Otherwise, the segment path is 878 designated as 'strict'. 880 Router-ID: Router-ID of the next-hop. 882 Interface ID: The identifier assigned to the link by the router 883 specified by the Router-ID. 885 7. Adjacency Segment Identifier (Adj-SID) 887 An Adjacency Segment Identifier (Adj-SID) represents a router 888 adjacency in Segment Routing. 890 7.1. Adj-SID Sub-TLV 892 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 893 [RFC7684]. It MAY appear multiple times in the Extended Link TLV. 894 Examples where more than one Adj-SID may be used per neighbor are 895 described in section 4 of 896 [I-D.filsfils-spring-segment-routing-use-cases]. The Adj-SID Sub-TLV 897 has the following format: 899 0 1 2 3 900 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 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Type | Length | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Flags | Reserved | MT-ID | Weight | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | SID/Label/Index (variable) | 907 +---------------------------------------------------------------+ 909 where: 911 Type: TBD, suggested value 2. 913 Length: Variable. 915 Flags: Single octet field containing the following flags: 917 0 1 2 3 4 5 6 7 918 +-+-+-+-+-+-+-+-+ 919 |B|V|L|G| | 920 +-+-+-+-+-+-+-+-+ 922 where: 924 B-Flag: Backup Flag. If set, the Adj-SID refers to an 925 adjacency that is eligible for protection (e.g.: using IPFRR or 926 MPLS-FRR) as described in section 3.5 of 927 [I-D.ietf-spring-segment-routing]. 929 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 930 an absolute value. If not set, then the Adj-SID carries an 931 index. 933 The L-Flag: Local/Global Flag. If set, then the value/index 934 carried by the Adj-SID has local significance. If not set, 935 then the value/index carried by this Sub-TLV has global 936 significance. 938 The G-Flag: Group Flag. When set, the G-Flag indicates that 939 the Adj-SID refers to a group of adjacencies (and therefore MAY 940 be assigned to other adjacencies as well). 942 Other bits: Reserved. These MUST be zero when sent and are 943 ignored when received. 945 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 947 Weight: Weight used for load-balancing purposes. The use of the 948 weight is defined in [I-D.ietf-spring-segment-routing]. 950 SID/Index/Label: According to the V and L flags, it contains 951 either: 953 A 32-bit index defining the offset in the SID/Label space 954 advertised by this router. 956 A 24-bit label where the 20 rightmost bits are used for 957 encoding the label value. 959 An SR capable router MAY allocate an Adj-SID for each of its 960 adjacencies and set the B-Flag when the adjacency is eligible for 961 protection by an FRR mechanism (IP or MPLS) as described in section 962 3.5 of [I-D.ietf-spring-segment-routing]. 964 7.2. LAN Adj-SID Sub-TLV 966 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 967 in [RFC7684]. It MAY appear multiple times in the Extended-Link TLV. 968 It is used to advertise a SID/Label for an adjacency to a non-DR 969 router on a broadcast, NBMA, or hybrid [RFC6845] network. 971 0 1 2 3 972 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 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Type | Length | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Flags | Reserved | MT-ID | Weight | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Neighbor ID | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | SID/Label/Index (variable) | 981 +---------------------------------------------------------------+ 983 where: 985 Type: TBD, suggested value 3. 987 Length: Variable. 989 Flags: Single octet field containing the following flags: 991 0 1 2 3 4 5 6 7 992 +-+-+-+-+-+-+-+-+ 993 |B|V|L|G| | 994 +-+-+-+-+-+-+-+-+ 996 where: 998 B-Flag: Backup-flag. If set, the LAN-Adj-SID refers to an 999 adjacency that is eligible for protection (e.g.: using IPFRR or 1000 MPLS-FRR) as described in section 3.5 of 1001 [I-D.ietf-spring-segment-routing]. 1003 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 1004 carries an absolute value. If not set, then the Prefix-SID 1005 carries an index. 1007 The L-Flag: Local/Global Flag. If set, then the value/index 1008 carried by the Prefix-SID has local significance. If not set, 1009 then the value/index carried by this Sub-TLV has global 1010 significance. 1012 The G-Flag: Group Flag. When set, the G-Flag indicates that 1013 the LAN-Adj-SID refers to a group of adjacencies (and therefore 1014 MAY be assigned to other adjacencies as well). 1016 Other bits: Reserved. These MUST be zero when sent and are 1017 ignored when received. 1019 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1021 Weight: Weight used for load-balancing purposes. The use of the 1022 weight is defined in [I-D.ietf-spring-segment-routing]. 1024 Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- 1025 SID is advertised. 1027 SID/Index/Label: According to the V and L flags, it contains 1028 either: 1030 A 32-bit index defining the offset in the SID/Label space 1031 advertised by this router. 1033 A 24-bit label where the 20 rightmost bits are used for 1034 encoding the label value. 1036 8. Elements of Procedure 1038 8.1. Intra-area Segment routing in OSPFv2 1040 An OSPFv2 router that supports segment routing MAY advertise Prefix- 1041 SIDs for any prefix to which it is advertising reachability (e.g., a 1042 loopback IP address as described in Section 5). 1044 If multiple routers advertise a Prefix-SID for the same prefix, then 1045 the Prefix-SID MUST be the same. This is required in order to allow 1046 traffic load-balancing when multiple equal cost paths to the 1047 destination exist in the OSPFv2 routing domain. 1049 Prefix-SID can also be advertised by the SR Mapping Servers (as 1050 described in [I-D.filsfils-spring-segment-routing-ldp-interop]). The 1051 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 1052 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 1053 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 1054 MUST be advertised by all of them. The flooding scope of the OSPF 1055 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 1056 could be either area scoped or AS scoped and is determined based on 1057 the configuration of the SR Mapping Server. 1059 The SR Mapping Server MUST use OSPF Extended Prefix Range TLV when 1060 advertising SIDs for prefixes. Prefixes of different route-types can 1061 be combined in a single OSPF Extended Prefix Range TLV advertised by 1062 the SR Mapping Server. 1064 Area-scoped OSPF Extended Prefix Range TLV are propagated between 1065 areas. Similar to propagation of prefixes between areas, an ABR only 1066 propagates the OSPF Extended Prefix Range TLV that it considers to be 1067 the best from the set it received. The rules used to pick the best 1068 OSPF Extended Prefix Range TLV are described in Section 4. 1070 When propagating an OSPF Extended Prefix Range TLV between areas, 1071 ABRs MUST set the IA-Flag, that is used to prevent redundant flooding 1072 of the OSPF Extended Prefix Range TLV between areas as described in 1073 Section 4. 1075 If the Prefix-SID that is advertised in a Prefix SID Sub-TLV is also 1076 covered by the OSPF Extended Prefix Range TLV, the Prefix-SID 1077 advertised in Prefix SID Sub-TLV MUST be preferred. 1079 8.2. Inter-area Segment routing in OSPFv2 1081 In order to support SR in a multi-area environment, OSPFv2 must 1082 propagate Prefix-SID information between areas. The following 1083 procedure is used to propagate Prefix SIDs between areas. 1085 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 1086 prefix to all its connected areas, it will also originate an Extended 1087 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 1088 the Extended Prefix Opaque LSA type will be set to area-scope. The 1089 route-type in the OSPF Extended Prefix TLV is set to inter-area. The 1090 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1091 value will be set as follows: 1093 The ABR will look at its best path to the prefix in the source 1094 area and find the advertising router associated with the best path 1095 to that prefix. 1097 The ABR will then determine if such router advertised a Prefix-SID 1098 for the prefix and use it when advertising the Prefix-SID to other 1099 connected areas. 1101 If no Prefix-SID was advertised for the prefix in the source area 1102 by the router that contributes to the best path to the prefix, the 1103 originating ABR will use the Prefix-SID advertised by any other 1104 router when propagating the Prefix-SID for the prefix to other 1105 areas. 1107 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 1108 route to all its connected areas, it will also originate an Extended 1109 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 1110 the Extended Prefix Opaque LSA type will be set to area-scope. The 1111 route-type in OSPF Extended Prefix TLV is set to inter-area. The 1112 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1113 will be set as follows: 1115 The ABR will look at its best path to the prefix in the backbone 1116 area and find the advertising router associated with the best path 1117 to that prefix. 1119 The ABR will then determine if such router advertised a Prefix-SID 1120 for the prefix and use it when advertising the Prefix-SID to other 1121 connected areas. 1123 If no Prefix-SID was advertised for the prefix in the backbone 1124 area by the ABR that contributes to the best path to the prefix, 1125 the originating ABR will use the Prefix-SID advertised by any 1126 other router when propagating the Prefix-SID for the prefix to 1127 other areas. 1129 8.3. SID for External Prefixes 1131 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1132 SR, generates Type-5 LSAs, it should also originate Extended Prefix 1133 Opaque LSAs, as described in [RFC7684]. The flooding scope of the 1134 Extended Prefix Opaque LSA type is set to AS-scope. The route-type 1135 in the OSPF Extended Prefix TLV is set to external. The Prefix-SID 1136 Sub-TLV is included in this LSA and the Prefix-SID value will be set 1137 to the SID that has been reserved for that prefix. 1139 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 1140 also advertise the Prefix-SID for the prefix. The NSSA ABR 1141 determines its best path to the prefix advertised in the translated 1142 Type-7 LSA and finds the advertising router associated with that 1143 path. If the advertising router has advertised a Prefix-SID for the 1144 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 1145 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 1146 router will be used. 1148 8.4. Advertisement of Adj-SID 1150 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1151 using the Adj-SID Sub-TLV as described in Section 7. 1153 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 1155 An Adj-SID MAY be advertised for any adjacency on a P2P link that is 1156 in neighbor state 2-Way or higher. If the adjacency on a P2P link 1157 transitions from the FULL state, then the Adj-SID for that adjacency 1158 MAY be removed from the area. If the adjacency transitions to a 1159 state lower then 2-Way, then the Adj-SID advertisement MUST be 1160 removed from the area. 1162 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1164 Broadcast, NBMA or or hybrid [RFC6845] networks in OSPF are 1165 represented by a star topology where the Designated Router (DR) is 1166 the central point to which all other routers on the broadcast, NBMA, 1167 or hybrid network connect. As a result, routers on the broadcast, 1168 NBMA, or hybrid network advertise only their adjacency to the DR. 1169 Routers that do not act as DR do not form or advertise adjacencies 1170 with each other. They do, however, maintain 2-Way adjacency state 1171 with each other and are directly reachable. 1173 When Segment Routing is used, each router on the broadcast or NBMA 1174 network MAY advertise the Adj-SID for its adjacency to the DR using 1175 the Adj-SID Sub-TLV as described in Section 7.1. 1177 SR capable routers MAY also advertise an LAN-Adj-SID for other 1178 neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA or hybrid 1179 network using the LAN-ADJ-SID Sub-TLV as described in Section 7.2. 1181 9. IANA Considerations 1183 This specification updates several existing OSPF registries. 1185 9.1. OSPF OSPF Router Information (RI) TLVs Registry 1187 o 8 (IANA Preallocated) - SR-Algorithm TLV 1189 o 9 (IANA Preallocated) - SID/Label Range TLV 1191 9.2. OSPF Extended Prefix LSA TLV Registry 1193 Following values are allocated: 1195 o 2 - OSPF Extended Prefix Range TLV 1197 9.3. OSPF Extended Prefix LSA Sub-TLV Registry 1199 Following values are allocated: 1201 o 1 - SID/Label Sub-TLV 1203 o 2 - Prefix SID Sub-TLV 1205 o 3 - SID/Label Binding Sub-TLV 1207 o 4 - IPv4 ERO Sub-TLV 1209 o 5 - Unnumbered Interface ID ERO Sub-TLV 1211 o 6 - IPv4 Backup ERO Sub-TLV 1213 o 7 - Unnumbered Interface ID Backup ERO Sub-TLV 1215 o 8 - ERO Metric Sub-TLV 1217 9.4. OSPF Extended Link LSA Sub-TLV Registry 1219 Following initial values are allocated: 1221 o 1 - SID/Label Sub-TLV 1223 o 2 - Adj-SID Sub-TLV 1224 o 3 - LAN Adj-SID/Label Sub-TLV 1226 10. Implementation Status 1228 An implementation survey with seven questions related to the 1229 implementer's support of OSPFv2 Segment Routing was sent to the OSPF 1230 WG list and several known implementers. This section contains 1231 responses from two implementers who completed the survey. No 1232 external means were used to verify the accuracy of the information 1233 submitted by the respondents. The respondents are considered experts 1234 on the products they reported on. Additionally, responses were 1235 omitted from implementers who indicated that they have not 1236 implemented the function yet. 1238 Responses from Nokia (former Alcatel-Lucent): 1240 Link to a web page describing the implementation: 1241 https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/ 1242 3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Un 1243 icast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf 1245 The implementation's level of maturity: Production. 1247 Coverage: We have implemented all sections and have support for the 1248 latest draft. 1250 Licensing: Part of the software package that needs to be purchased. 1252 Implementation experience: Great spec. We also performed inter- 1253 operability testing with Cisco's OSPF Segment Routing implementation. 1255 Contact information: wim.henderickx@nokia.com 1257 Responses from Cisco Systems: 1259 Link to a web page describing the implementation: 1261 www.segment-routing.net/home/tutorial 1263 The implementation's level of maturity: Production. 1265 Coverage: All sections, except the section 6 (SID/Label Binding Sub- 1266 TLV) have been implemented according to the latest draft. 1268 Licensing: Part of a commercial software package. 1270 Implementation experience: Many aspects of the draft are result of 1271 the actual implementation experience, as the draft evolved from its 1272 initial version to the current one. Interoperability testing with 1273 Alcatel-Lucent was performed, which confirmed the draft's ability to 1274 serve as a reference for the implementors. 1276 Contact information: ppsenak@cisco.com 1278 Responses from Juniper: 1280 The implementation's name and/or a link to a web page describing the 1281 implementation: 1283 Feature name is OSPF SPRING 1285 The implementation's level of maturity: To be released in 16.2 1286 (second half of 2016) 1288 Coverage: All sections implemented except Sections 4, and 6. 1290 Licensing: JUNOS Licensing needed. 1292 Implementation experience: NA 1294 Contact information: shraddha@juniper.net 1296 11. Security Considerations 1298 Implementations must assure that malformed TLV and Sub-TLV 1299 permutations do not result in errors which cause hard OSPF failures. 1301 12. Contributors 1303 The following people gave a substantial contribution to the content 1304 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1305 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1306 Saku Ytti. 1308 13. Acknowledgements 1310 We would like to thank Anton Smirnov for his contribution. 1312 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1313 contribution on earlier incarnations of the "Binding / MPLS Label 1314 TLV" in [I-D.gredler-ospf-label-advertisement]. 1316 Thanks to Acee Lindem for the detail review of the draft, 1317 corrections, as well as discussion about details of the encoding. 1319 14. References 1321 14.1. Normative References 1323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1324 Requirement Levels", BCP 14, RFC 2119, 1325 DOI 10.17487/RFC2119, March 1997, 1326 . 1328 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1329 DOI 10.17487/RFC2328, April 1998, 1330 . 1332 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1333 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1334 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1335 . 1337 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1338 in Resource ReSerVation Protocol - Traffic Engineering 1339 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1340 . 1342 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1343 (TE) Extensions to OSPF Version 2", RFC 3630, 1344 DOI 10.17487/RFC3630, September 2003, 1345 . 1347 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1348 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1349 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1350 . 1352 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1353 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 1354 July 2008, . 1356 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 1357 and Point-to-Multipoint Interface Type", RFC 6845, 1358 DOI 10.17487/RFC6845, January 2013, 1359 . 1361 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1362 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1363 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1364 2015, . 1366 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1367 S. Shaffer, "Extensions to OSPF for Advertising Optional 1368 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1369 February 2016, . 1371 14.2. Informative References 1373 [I-D.filsfils-spring-segment-routing-ldp-interop] 1374 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1375 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1376 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1377 "Segment Routing interoperability with LDP", draft- 1378 filsfils-spring-segment-routing-ldp-interop-02 (work in 1379 progress), September 2014. 1381 [I-D.filsfils-spring-segment-routing-use-cases] 1382 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1383 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1384 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1385 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1386 spring-segment-routing-use-cases-01 (work in progress), 1387 October 2014. 1389 [I-D.gredler-ospf-label-advertisement] 1390 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1391 "Advertising MPLS labels in OSPF", draft-gredler-ospf- 1392 label-advertisement-03 (work in progress), May 2013. 1394 [I-D.ietf-spring-segment-routing] 1395 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1396 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1397 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 1398 spring-segment-routing-00 (work in progress), December 1399 2014. 1401 [I-D.minto-rsvp-lsp-egress-fast-protection] 1402 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1403 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1404 protection-03 (work in progress), November 2013. 1406 Authors' Addresses 1407 Peter Psenak (editor) 1408 Cisco Systems, Inc. 1409 Apollo Business Center 1410 Mlynske nivy 43 1411 Bratislava 821 09 1412 Slovakia 1414 Email: ppsenak@cisco.com 1416 Stefano Previdi (editor) 1417 Cisco Systems, Inc. 1418 Via Del Serafico, 200 1419 Rome 00142 1420 Italy 1422 Email: sprevidi@cisco.com 1424 Clarence Filsfils 1425 Cisco Systems, Inc. 1426 Brussels 1427 Belgium 1429 Email: cfilsfil@cisco.com 1431 Hannes Gredler 1432 Individual 1433 Austria 1435 Email: hannes@gredler.at 1437 Rob Shakir 1438 Jive Communications, Inc. 1439 1275 West 1600 North, Suite 100 1440 Orem, UT 84057 1441 US 1443 Email: rrjs@rob.sh 1444 Wim Henderickx 1445 Alcatel-Lucent 1446 Copernicuslaan 50 1447 Antwerp 2018 1448 BE 1450 Email: wim.henderickx@alcatel-lucent.com 1452 Jeff Tantsura 1453 Individual 1454 US 1456 Email: Jeff.Tantsura@ericsson.com