idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-05.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 is 1 instance of too long lines in the document, the longest one being 18 characters in excess of 72. == 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 (June 26, 2015) is 3225 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 295 -- Looks like a reference, but probably isn't: '199' on line 295 -- Looks like a reference, but probably isn't: '1000' on line 296 -- Looks like a reference, but probably isn't: '1099' on line 296 -- Looks like a reference, but probably isn't: '500' on line 297 -- Looks like a reference, but probably isn't: '599' on line 297 == Unused Reference: 'RFC2328' is defined on line 1239, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 1249, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-ldp-interop-02 == Outdated reference: A later version (-13) exists of draft-ietf-ospf-prefix-link-attr-06 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Shortest Path First IGP P. Psenak, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Standards Track C. Filsfils 5 Expires: December 28, 2015 Cisco Systems, Inc. 6 H. Gredler 7 Juniper Networks, Inc. 8 R. Shakir 9 British Telecom 10 W. Henderickx 11 Alcatel-Lucent 12 J. Tantsura 13 Ericsson 14 June 26, 2015 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-05 19 Abstract 21 Segment Routing (SR) allows for a flexible definition of end-to-end 22 paths within IGP topologies by encoding paths as sequences of 23 topological sub-paths, called "segments". These segments are 24 advertised by the 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 December 28, 2015. 51 Copyright Notice 53 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 19 85 7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 21 86 8. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 22 87 8.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 22 88 8.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 23 89 8.3. SID for External Prefixes . . . . . . . . . . . . . . . . 24 90 8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 24 91 8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 24 92 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 25 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 94 9.1. OSPF OSPF Router Information (RI) TLVs Registry . . . . . 25 95 9.2. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 25 96 9.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 25 97 9.4. OSPF Extended Link LSA Sub-TLV Registry . . . . . . . . . 26 98 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 99 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 100 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 101 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 103 13.2. Informative References . . . . . . . . . . . . . . . . . 27 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 106 1. Introduction 108 Segment Routing (SR) allows for a flexible definition of end-to-end 109 paths within IGP topologies by encoding paths as sequences of 110 topological sub-paths, called "segments". These segments are 111 advertised by the link-state routing protocols (IS-IS and OSPF). 112 Prefix segments represent an ecmp-aware shortest-path to a prefix (or 113 a node), as per the state of the IGP topology. Adjacency segments 114 represent a hop over a specific adjacency between two nodes in the 115 IGP. A prefix segment is typically a multi-hop path while an 116 adjacency segment, in most cases, is a one-hop path. SR's control- 117 plane can be applied to both IPv6 and MPLS data-planes, and does not 118 require any additional signalling (other than IGP extensions). For 119 example, when used in MPLS networks, SR paths do not require any LDP 120 or RSVP-TE signalling. However, SR can interoperate in the presence 121 of LSPs established with RSVP or LDP. 123 This draft describes the OSPF extensions required for Segment 124 Routing. 126 Segment Routing architecture is described in 127 [I-D.ietf-spring-segment-routing]. 129 Segment Routing use cases are described in 130 [I-D.filsfils-spring-segment-routing-use-cases]. 132 2. Segment Routing Identifiers 134 Segment Routing defines various types of Segment Identifiers (SIDs): 135 Prefix-SID, Adjacency-SID, LAN Adjacency SID and Binding SID. 137 For the purpose of the advertisements of various SID values, new 138 Opaque LSAs [RFC5250] are defined in 139 [I-D.ietf-ospf-prefix-link-attr]. These new LSAs are defined as 140 generic containers that can be used to advertise any additional 141 attributes associated with a prefix or link. These new Opaque LSAs 142 are complementary to the existing LSAs and are not aimed to replace 143 any of the existing LSAs. 145 2.1. SID/Label Sub-TLV 147 The SID/Label Sub-TLV appears in multiple TLVs or Sub-TLVs defined 148 later in this document. It is used to advertise the SID or label 149 associated with a prefix or adjacency. The SID/Label TLV has 150 following format: 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Type | Length | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | SID/Label (variable) | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 where: 162 Type: TBD, suggested value 1 164 Length: variable, 3 or 4 bytes 166 SID/Label: if length is set to 3, then the 20 rightmost bits 167 represent a label. If length is set to 4, then the value 168 represents a 32 bit SID. 170 The receiving router MUST ignore SID/Label Sub-TLV if the length 171 is other then 3 or 4. 173 3. Segment Routing Capabilities 175 Segment Routing requires some additional router capabilities to be 176 advertised to other routers in the area. 178 These SR capabilities are advertised in the Router Information Opaque 179 LSA (defined in [RFC4970]). 181 3.1. SR-Algorithm TLV 183 The SR-Algorithm TLV is a top-level TLV of the Router Information 184 Opaque LSA (defined in [RFC4970]). 186 The SR-Algorithm Sub-TLV is optional. It MAY only be advertised once 187 in the Router Information Opaque LSA. If the SID/Label Range TLV, as 188 defined in Section 3.2, is advertised, then SR-Algorithm TLV MUST 189 also be advertised. 191 An SR Router may use various algorithms when calculating reachability 192 to OSPF routers or prefixes in an OSPF area. Examples of these 193 algorithms are metric based Shortest Path First (SPF), various 194 flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a 195 router to advertise the algorithms that the router is currently using 196 to other routers in an OSPF area. The SR-Algorithm TLV has following 197 format: 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type | Length | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Algorithm 1 | Algorithm... | Algorithm n | | 205 +- -+ 206 | | 207 + + 209 where: 211 Type: TBD, suggested value 8 213 Length: variable 215 Algorithm: Single octet identifying the algorithm. The following 216 values are defined by this document: 218 0: Shortest Path First (SPF) algorithm based on link metric. 219 This is the standard shortest path algorithm as computed by the 220 OSPF protocol. Consistent with the deployed practice for link- 221 state protocols, Algorithm 0 permits any node to overwrite the 222 SPF path with a different path based on its local policy. 224 1: Strict Shortest Path First (SPF) algorithm based on link 225 metric. The algorithm is identical to Algorithm 0 but 226 Algorithm 1 requires that all nodes along the path will honor 227 the SPF routing decision. Local policy at the node claiming 228 the support of Algorithm 1 MUST NOT alter the forwarding 229 decision computed by Algorithm 1. 231 The RI LSA can be advertised at any of the defined opaque flooding 232 scopes (link, area, or Autonomous System (AS)). For the purpose of 233 the SR-Algorithm TLV propagation, area scope flooding is required. 235 3.2. SID/Label Range TLV 237 The SID/Label Range TLV is a top-level TLV of the Router Information 238 Opaque LSA (defined in [RFC4970]). 240 The SID/Label Range TLV MAY appear multiple times and has the 241 following format: 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type | Length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Range Size | Reserved | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Sub-TLVs (variable) | 251 +- -+ 252 | | 253 + + 255 where: 257 Type: TBD, suggested value 9 259 Length: variable 261 Range Size: 3 octets of the SID/label range 263 Initially, the only supported Sub-TLV is the SID/Label TLV as defined 264 in Section 2.1. The SID/Label advertised in the SID/Label TLV 265 represents the first SID/Label in the advertised range. 267 Multiple occurrence of the SID/Label Range TLV MAY be advertised, in 268 order to advertise multiple ranges. In such case: 270 o The originating router MUST encode each range into a different 271 SID/Label Range TLV. 273 o The originating router decides the order in which the set of SID/ 274 Label Range TLVs are advertised inside the Router Information 275 Opaque LSA. The originating router MUST ensure the order is same 276 after a graceful restart (using checkpointing, non-volatile 277 storage or any other mechanism) in order to assure the SID/label 278 range and SID index correspondence is preserved across graceful 279 restarts. 281 o The receiving router must adhere to the order in which the ranges 282 are advertised when calculating a SID/label from a SID index. 284 The following example illustrates the advertisement of multiple 285 ranges: 287 The originating router advertises following ranges: 288 Range 1: [100, 199] 289 Range 2: [1000, 1099] 290 Range 3: [500, 599] 292 The receiving routers concatenate the ranges and build the Segment Routing Global Block 293 (SRGB) is as follows: 295 SRGB = [100, 199] 296 [1000, 1099] 297 [500, 599] 299 The indexes span multiple ranges: 301 index=0 means label 100 302 ... 303 index 99 means label 199 304 index 100 means label 1000 305 index 199 means label 1099 306 ... 307 index 200 means label 500 308 ... 310 The RI LSA can be advertised at any of the defined flooding scopes 311 (link, area, or autonomous system (AS)). For the purposes of the SR- 312 Capability TLV propagation, area scope flooding is required. 314 4. OSPF Extended Prefix Range TLV 316 In some cases it is useful to advertise attributes for the range of 317 prefixes. Segment Routing Mapping Server, which is described in 318 [I-D.filsfils-spring-segment-routing-ldp-interop], is an example, 319 where we need a single advertisement to advertise SIDs for multiple 320 prefixes from a contiguous address range. 322 OSPF Extended Prefix Range TLV, which is a new top level TLV of the 323 Extended Prefix LSA described in [I-D.ietf-ospf-prefix-link-attr] is 324 defined for this purpose. 326 Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each 327 OSPF Extended Prefix Opaque LSA, but all prefix ranges included in a 328 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 329 scope. The OSPF Extended Prefix Range TLV has the following format: 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Type | Length | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Prefix Length | AF | Range Size | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Flags | Reserved | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Address Prefix (variable) | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Sub-TLVs (variable) | 343 +- -+ 344 | | 346 where: 348 Type: TBD, suggested value 2. 350 Length: variable 352 Prefix length: length of the prefix 354 AF: 0 - IPv4 unicast 356 Range size: represents the number of prefixes that are covered by 357 the advertisement. The Range Size MUST NOT exceed the number of 358 prefixes that could be satisfied by the prefix length without 359 including the IPv4 multicast address range (224.0.0.0/3). 361 Flags: 1 octet field. The following flags are defined: 363 0 1 2 3 4 5 6 7 364 +--+--+--+--+--+--+--+--+ 365 |IA| | | | | | | | 366 +--+--+--+--+--+--+--+--+ 368 where: 370 IA-Flag: Inter-Area flag. If set, advertisement is of inter- 371 area type. ABR that is advertising the OSPF Extended Prefix 372 Range TLV between areas MUST set this bit. 374 This bit is used to prevent redundant flooding of Prefix Range 375 TLVs between areas as follows: 377 An ABR always prefers intra-area Prefix Range advertisement 378 over inter-area one. 380 An ABR does not consider inter-area Prefix Range 381 advertisements coming from non backbone area. 383 An ABR propagates inter-area Prefix Range advertisement from 384 backbone area to connected non backbone areas only if such 385 advertisement is considered to be the best one. 387 Address Prefix: the prefix, encoded as an even multiple of 32-bit 388 words, padded with zeroed bits as necessary. This encoding 389 consumes ((PrefixLength + 31) / 32) 32-bit words. The Address 390 Prefix represents the first prefix in the prefix range. 392 5. Prefix SID Sub-TLV 394 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV 395 described in [I-D.ietf-ospf-prefix-link-attr] and the OSPF Extended 396 Prefix Range TLV described in Section 4. It MAY appear more than 397 once in the parent TLV and has the following format: 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Type | Length | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Flags | Reserved | MT-ID | Algorithm | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | SID/Index/Label (variable) | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 where: 411 Type: TBD, suggested value 2. 413 Length: variable 415 Flags: 1 octet field. The following flags are defined: 417 0 1 2 3 4 5 6 7 418 +--+--+--+--+--+--+--+--+ 419 | |NP|M |E |V |L | | | 420 +--+--+--+--+--+--+--+--+ 422 where: 424 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 425 NOT pop the Prefix-SID before delivering the packet to the node 426 that advertised the Prefix-SID. 428 M-Flag: Mapping Server Flag. If set, the SID is advertised 429 from the Segment Routing Mapping Server functionality as 430 described in [I-D.filsfils-spring-segment-routing-ldp-interop]. 432 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 433 the Prefix-SID originator MUST replace the Prefix-SID with a 434 Prefix-SID having an Explicit-NULL value (0 for IPv4) before 435 forwarding the packet. 437 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 438 an absolute value. If not set, then the Prefix-SID carries an 439 index. 441 L-Flag: Local/Global Flag. If set, then the value/index 442 carried by the Prefix-SID has local significance. If not set, 443 then the value/index carried by this Sub-TLV has global 444 significance. 446 Other bits: Reserved. These MUST be zero when sent and are 447 ignored when received. 449 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 451 Algorithm: one octet identifying the algorithm the Prefix-SID is 452 associated with as defined in Section 3.1. 454 SID/Index/Label: according to the V and L flags, it contains 455 either: 457 A 32 bit index defining the offset in the SID/Label space 458 advertised by this router. 460 A 24 bit label where the 20 rightmost bits are used for 461 encoding the label value. 463 If multiple Prefix-SIDs are advertised for the same prefix, the 464 receiving router MUST use the first encoded SID and MAY use the 465 subsequent SIDs. 467 When propagating Prefix-SIDs between areas, if multiple prefix-SIDs 468 are advertised for a prefix, an implementation SHOULD preserve the 469 original order when advertising prefix-SIDs to other areas. This 470 allows implementations that only support a single Prefix-SID to have 471 a consistent view across areas. 473 When calculating the outgoing label for the prefix, the router MUST 474 take into account E and P flags advertised by the next-hop router, if 475 next-hop router advertised the SID for the prefix. This MUST be done 476 regardless of whether the next-hop router contributes to the best 477 path to the prefix. 479 The NP-Flag (No-PHP) MUST be set on the Prefix-SIDs allocated to 480 inter-area prefixes that are originated by the ABR based on intra- 481 area or inter-area reachability between areas. When the inter-area 482 prefix is generated based on the prefix which is directly attached to 483 the ABR, NP-Flag SHOULD NOT be set 485 The NP-Flag (No-PHP) MUST be be set on the Prefix-SIDs allocated to 486 redistributed prefixes, unless the redistributed prefix is directly 487 attached to ASBR, in which case the NP-flag SHOULD NOT be set. 489 If the NP-Flag is not set then any upstream neighbor of the Prefix- 490 SID originator MUST pop the Prefix-SID. This is equivalent to the 491 penultimate hop popping mechanism used in the MPLS dataplane. In 492 such case, MPLS EXP bits of the Prefix-SID are not preserved for the 493 final destination (the Prefix-SID being removed). If the NP-flag is 494 clear then the received E-flag is ignored. 496 If the NP-flag is set then: 498 If the E-flag is not set then any upstream neighbor of the Prefix- 499 SID originator MUST keep the Prefix-SID on top of the stack. This 500 is useful when the originator of the Prefix-SID must stitch the 501 incoming packet into a continuing MPLS LSP to the final 502 destination. This could occur at an inter-area border router 503 (prefix propagation from one area to another) or at an inter- 504 domain border router (prefix propagation from one domain to 505 another). 507 If the E-flag is set then any upstream neighbor of the Prefix-SID 508 originator MUST replace the Prefix-SID with a Prefix-SID having an 509 Explicit-NULL value. This is useful, e.g., when the originator of 510 the Prefix-SID is the final destination for the related prefix and 511 the originator wishes to receive the packet with the original EXP 512 bits. 514 When M-Flag is set, NP-flag MUST be set and E-bit MUST NOT be set. 516 As the Mapping Server does not specify the originator of a prefix 517 advertisement it is not possible to determine PHP behavior solely 518 based on the Mapping Server advertisement. However, PHP behavior may 519 safely be done in following cases: 521 Prefix is of intra-area type and the downstream neighbor is the 522 originator of the prefix. 524 Prefix is of inter-area type and downstream neighbor is an ABR, 525 which is advertising the prefix reachability and is also 526 generating the Extended Prefix TLV with A-flag set for this prefix 527 as described in section 2.1 of [I-D.ietf-ospf-prefix-link-attr]. 529 Prefix is of external type and downstream neighbor is an ASBR, 530 which is advertising the prefix reachability and is also 531 generating the Extended Prefix TLV with A-flag set for this prefix 532 as described in section 2.1 of [I-D.ietf-ospf-prefix-link-attr]. 534 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 535 the value advertised in Prefix SID Sub-TLV is interpreted as a 536 starting SID value. 538 Example 1: if the following router addresses (loopback addresses) 539 need to be mapped into the corresponding Prefix SID indexes: 541 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 542 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 543 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 544 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 546 then the Prefix field in the Extended Prefix Range TLV would be set 547 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 548 set to 4 and the Index value in the Prefix-SID Sub-TLV would be set 549 to 1. 551 Example 2: If the following prefixes need to be mapped into the 552 corresponding Prefix-SID indexes: 554 10.1.1/24, Prefix-SID: Index 51 555 10.1.2/24, Prefix-SID: Index 52 556 10.1.3/24, Prefix-SID: Index 53 557 10.1.4/24, Prefix-SID: Index 54 558 10.1.5/24, Prefix-SID: Index 55 559 10.1.6/24, Prefix-SID: Index 56 560 10.1.7/24, Prefix-SID: Index 57 562 then the Prefix field in the Extended Prefix Range TLV would be set 563 to 10.1.1.0, Prefix Length would be set to 24, Range Size would be 7 564 and the Index value in the Prefix-SID Sub-TLV would be set to 51. 566 6. SID/Label Binding Sub-TLV 568 The SID/Label Binding Sub-TLV is used to advertise a SID/Label 569 mapping for a path to the prefix. 571 The SID/Label Binding TLV MAY be originated by any router in an OSPF 572 domain. The router may advertise a SID/Label binding to a FEC along 573 with at least a single 'nexthop style' anchor. The protocol supports 574 more than one 'nexthop style' anchor to be attached to a SID/Label 575 binding, which results in a simple path description language. In 576 analogy to RSVP, the terminology for this is called an 'Explicit 577 Route Object' (ERO). Since ERO style path notation allows anchoring 578 SID/label bindings to both link and node IP addresses, any Label 579 Switched Path (LSP) can be described. Additionally, SID/Label 580 Bindings from external protocols can be easily re-advertised. 582 The SID/Label Binding TLV may be used for advertising SID/Label 583 Bindings and their associated Primary and Backup paths. In a single 584 TLV, a primary ERO Path, backup ERO Path, or both can be advertised. 585 If a router wants to advertise multiple parallel paths, then it can 586 generate several TLVs for the same Prefix/FEC. Each occurrence of a 587 Binding TLV for a given FEC Prefix will add a new path. 589 The SID/Label Binding Sub-TLV is a Sub-TLV of the OSPF Extended 590 Prefix TLV described in [I-D.ietf-ospf-prefix-link-attr] and the OSPF 591 Extended Prefix Range TLV described in Section 4. Multiple SID/Label 592 Binding TLVs can be present in their parent TLV. The SID/Label 593 Binding Sub-TLV has following format: 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Type | Length | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Flags | Reserved | MT-ID | Weight | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Sub-TLVs (variable) | 603 +- -+ 604 | | 606 where: 608 Type: TBD, suggested value 3 610 Length: variable 612 Flags: 1 octet field of following flags: 614 0 1 2 3 4 5 6 7 615 +-+-+-+-+-+-+-+-+ 616 |M| | 617 +-+-+-+-+-+-+-+-+ 619 where: 621 M-bit - When the bit is set the binding represents the 622 mirroring context as defined in 623 [I-D.minto-rsvp-lsp-egress-fast-protection]. 625 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 627 Weight: weight used for load-balancing purposes. The use of the 628 weight is defined in [I-D.ietf-spring-segment-routing]. 630 The SID/Label Binding TLV supports the following Sub-TLVs: 632 SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST 633 appear in the SID/Label Binding Sub-TLV and it MUST only appear 634 once. 636 ERO Metric Sub-TLV as defined in Section 6.1. 638 ERO Sub-TLVs as defined in Section 6.2. 640 6.1. ERO Metric Sub-TLV 642 The ERO Metric Sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 644 The ERO Metric Sub-TLV advertises the cost of an ERO path. It is 645 used to compare the cost of a given source/destination path. A 646 router SHOULD advertise the ERO Metric Sub-TLV in an advertised ERO 647 TLV. The cost of the ERO Metric Sub-TLV SHOULD be set to the 648 cumulative IGP or TE path cost of the advertised ERO. Since 649 manipulation of the Metric field may attract or repel traffic to and 650 from the advertised segment, it MAY be manually overridden. 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Type | Length | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Metric (4 octets) | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 ERO Metric Sub-TLV format 662 where: 664 Type: TBD, suggested value 8 666 Length: Always 4 668 Metric: A 4 octet metric representing the aggregate IGP or TE path 669 cost. 671 6.2. ERO Sub-TLVs 673 All 'ERO' information represents an ordered set which describes the 674 segments of a path. The first ERO Sub-TLV describes the first 675 segment of a path. Similiarly, the last ERO Sub-TLV describes the 676 segment closest to the egress point. If a router extends or stitches 677 a path, it MUST prepend the new segment's path information to the ERO 678 list. This applies equally to advertised backup EROs. 680 All ERO Sub-TLVs must immediately follow the (SID)/Label Sub-TLV. 682 All Backup ERO Sub-TLVs must immediately follow the last ERO Sub-TLV. 684 6.2.1. IPv4 ERO Sub-TLV 686 IPv4 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 688 The IPv4 ERO Sub-TLV describes a path segment using IPv4 Address 689 style encoding. Its semantics have been borrowed from [RFC3209]. 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Type | Length | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Flags | Reserved | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | IPv4 Address (4 octets) | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 IPv4 ERO Sub-TLV format 703 where: 705 Type: TBD, suggested value 4 707 Length: 8 bytes 709 Flags: 1 octet field of following flags: 711 0 1 2 3 4 5 6 7 712 +-+-+-+-+-+-+-+-+ 713 |L| | 714 +-+-+-+-+-+-+-+-+ 716 where: 718 L-bit - If the L-bit is set, then the segment path is 719 designated as 'loose'. Otherwise, the segment path is 720 designated as 'strict'. 722 IPv4 Address - the address of the explicit route hop. 724 6.2.2. Unnumbered Interface ID ERO Sub-TLV 726 The Unnumbered Interface ID ERO Sub-TLV is a Sub-TLV of the SID/Label 727 Binding Sub-TLV. 729 The appearance and semantics of the 'Unnumbered Interface ID' have 730 been borrowed from [RFC3477]. 732 The Unnumbered Interface-ID ERO Sub-TLV describes a path segment that 733 includes an unnumbered interface. Unnumbered interfaces are 734 referenced using the interface index. Interface indices are assigned 735 local to the router and therefore not unique within a domain. All 736 elements in an ERO path need to be unique within a domain and hence 737 need to be disambiguated using a domain unique Router-ID. 739 0 1 2 3 740 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 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Type | Length | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Flags | Reserved | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Router ID | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Interface ID | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 where: 753 Unnumbered Interface ID ERO Sub-TLV format 755 Type: TBD, suggested value 5 757 Length: 12 bytes 758 Flags: 1 octet field of following flags: 760 0 1 2 3 4 5 6 7 761 +-+-+-+-+-+-+-+-+ 762 |L| | 763 +-+-+-+-+-+-+-+-+ 765 where: 767 L-bit - If the L-bit is set, then the segment path is 768 designated as 'loose'. Otherwise, the segment path is 769 designated as 'strict'. 771 Router-ID: Router-ID of the next-hop. 773 Interface ID: is the identifier assigned to the link by the router 774 specified by the Router-ID. 776 6.2.3. IPv4 Backup ERO Sub-TLV 778 IPv4 Prefix Backup ERO Sub-TLV is a Sub-TLV of the SID/Label Binding 779 Sub-TLV. 781 The IPv4 Backup ERO Sub-TLV describes a path segment using IPv4 782 Address style of encoding. Its semantics have been borrowed from 783 [RFC3209]. 785 0 1 2 3 786 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 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Type | Length | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Flags | Reserved | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | IPv4 Address (4 octets) | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 IPv4 Backup ERO Sub-TLV format 797 where: 799 Type: TBD, suggested value 6 801 Length: 8 bytes 803 Flags: 1 octet field of following flags: 805 0 1 2 3 4 5 6 7 806 +-+-+-+-+-+-+-+-+ 807 |L| | 808 +-+-+-+-+-+-+-+-+ 810 where: 812 L-bit - If the L-bit is set, then the segment path is 813 designated as 'loose'. Otherwise, the segment path is 814 designated as 'strict'. 816 IPv4 Address - the address of the explicit route hop. 818 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV 820 The Unnumbered Interface ID Backup ERO Sub-TLV is a Sub-TLV of the 821 SID/Label Binding Sub-TLV. 823 The appearance and semantics of the 'Unnumbered Interface ID' have 824 been borrowed from [RFC3477]. 826 The Unnumbered Interface-ID Backup ERO Sub-TLV describes a path 827 segment that includes an unnumbered interface. Unnumbered interfaces 828 are referenced using the interface index. Interface indices are 829 assigned local to the router and are therefore not unique within a 830 domain. All elements in an ERO path need to be unique within a 831 domain and hence need to be disambiguated with specification of the 832 domain unique Router-ID. 834 0 1 2 3 835 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 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Type | Length | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Flags | Reserved | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Router ID | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Interface ID | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 Unnumbered Interface ID Backup ERO Sub-TLV format 848 where: 850 Type: TBD, suggested value 7 852 Length: 12 bytes 853 Flags: 1 octet field of following flags: 855 0 1 2 3 4 5 6 7 856 +-+-+-+-+-+-+-+-+ 857 |L| | 858 +-+-+-+-+-+-+-+-+ 860 where: 862 L-bit - If the L-bit is set, then the segment path is 863 designated as 'loose'. Otherwise, the segment path is 864 designated as 'strict'. 866 Router-ID: Router-ID of the next-hop. 868 Interface ID: is the identifier assigned to the link by the router 869 specified by the Router-ID. 871 7. Adjacency Segment Identifier (Adj-SID) 873 An Adjacency Segment Identifier (Adj-SID) represents a router 874 adjacency in Segment Routing. 876 7.1. Adj-SID Sub-TLV 878 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 879 [I-D.ietf-ospf-prefix-link-attr]. It MAY appear multiple times in 880 the Extended Link TLV. Examples where more than one Adj-SID may be 881 used per neighbor are described in section 4 of 882 [I-D.filsfils-spring-segment-routing-use-cases]. The Adj-SID Sub-TLV 883 has the following format: 885 0 1 2 3 886 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 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Type | Length | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Flags | Reserved | MT-ID | Weight | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | SID/Label/Index (variable) | 893 +---------------------------------------------------------------+ 895 where: 897 Type: TBD, suggested value 2. 899 Length: variable. 901 Flags. 1 octet field of following flags: 903 0 1 2 3 4 5 6 7 904 +-+-+-+-+-+-+-+-+ 905 |B|V|L|S| | 906 +-+-+-+-+-+-+-+-+ 908 where: 910 B-Flag: Backup Flag. If set, the Adj-SID refers to an 911 adjacency that is eligible for protection (e.g.: using IPFRR or 912 MPLS-FRR) as described in section 3.5 of 913 [I-D.ietf-spring-segment-routing]. 915 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 916 an absolute value. If not set, then the Adj-SID carries an 917 index. 919 The L-Flag: Local/Global Flag. If set, then the value/index 920 carried by the Adj-SID has local significance. If not set, 921 then the value/index carried by this Sub-TLV has global 922 significance. 924 The S-Flag. Set Flag. When set, the S-Flag indicates that the 925 Adj-SID refers to a set of adjacencies (and therefore MAY be 926 assigned to other adjacencies as well). 928 Other bits: Reserved. These MUST be zero when sent and are 929 ignored when received. 931 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 933 Weight: weight used for load-balancing purposes. The use of the 934 weight is defined in [I-D.ietf-spring-segment-routing]. 936 SID/Index/Label: according to the V and L flags, it contains 937 either: 939 A 32 bit index defining the offset in the SID/Label space 940 advertised by this router. 942 A 24 bit label where the 20 rightmost bits are used for 943 encoding the label value. 945 An SR capable router MAY allocate an Adj-SID for each of its 946 adjacencies and set the B-Flag when the adjacency is eligible for 947 protection by an FRR mechanism (IP or MPLS) as described in section 948 3.5 of [I-D.ietf-spring-segment-routing]. 950 7.2. LAN Adj-SID Sub-TLV 952 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 953 in [I-D.ietf-ospf-prefix-link-attr]. It MAY appear multiple times in 954 the Extended-Link TLV. It is used to advertise a SID/Label for an 955 adjacency to a non-DR node on a broadcast or NBMA network. 957 0 1 2 3 958 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 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Type | Length | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Flags | Reserved | MT-ID | Weight | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Neighbor ID | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | SID/Label/Index (variable) | 967 +---------------------------------------------------------------+ 969 where: 971 Type: TBD, suggested value 3. 973 Length: variable. 975 Flags. 1 octet field of following flags: 977 0 1 2 3 4 5 6 7 978 +-+-+-+-+-+-+-+-+ 979 |B|V|L|S| | 980 +-+-+-+-+-+-+-+-+ 982 where: 984 B-Flag: Backup-flag: set if the LAN-Adj-SID refer to an 985 adjacency that is eligible for protection (e.g.: using IPFRR or 986 MPLS-FRR) as described in section 3.5 of 987 [I-D.ietf-spring-segment-routing]. 989 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 990 carries an absolute value. If not set, then the Prefix-SID 991 carries an index. 993 The L-Flag: Local/Global Flag. If set, then the value/index 994 carried by the Prefix-SID has local significance. If not set, 995 then the value/index carried by this Sub-TLV has global 996 significance. 998 The S-Flag. Set Flag. When set, the S-Flag indicates that the 999 Adj-SID refers to a set of adjacencies (and therefore MAY be 1000 assigned to other adjacencies as well). 1002 Other bits: Reserved. These MUST be zero when sent and are 1003 ignored when received. 1005 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1007 Weight: weight used for load-balancing purposes. The use of the 1008 weight is defined in [I-D.ietf-spring-segment-routing]. 1010 SID/Index/Label: according to the V and L flags, it contains 1011 either: 1013 A 32 bit index defining the offset in the SID/Label space 1014 advertised by this router. 1016 A 24 bit label where the 20 rightmost bits are used for 1017 encoding the label value. 1019 8. Elements of Procedure 1021 8.1. Intra-area Segment routing in OSPFv2 1023 An OSPFv2 router that supports segment routing MAY advertise Prefix- 1024 SIDs for any prefix to which it is advertising reachability (e.g., a 1025 loopback IP address as described in Section 5). 1027 If multiple routers advertise a Prefix-SID for the same prefix, then 1028 the Prefix-SID MUST be the same. This is required in order to allow 1029 traffic load-balancing when multiple equal cost paths to the 1030 destination exist in the network. 1032 Prefix-SID can also be advertised by the SR Mapping Servers (as 1033 described in [I-D.filsfils-spring-segment-routing-ldp-interop]). The 1034 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 1035 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 1036 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 1037 MUST be advertised by all of them. The flooding scope of the OSPF 1038 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 1039 could be either area scoped or AS scoped and is determined based on 1040 the configuration of the SR Mapping Server. 1042 SR Mapping Server MUST use OSPF Extended Prefix Range TLV when 1043 advertising SIDs for prefixes. Prefixes of different route-types can 1044 be combined in a single OSPF Extended Prefix Range TLV advertised by 1045 the SR Mapping Server. 1047 Area scoped OSPF Extended Prefix Range TLV are propagated between 1048 areas. Similar to propagation of prefixes between areas, ABR only 1049 propagates the OSPF Extended Prefix Range TLV that it considers to be 1050 the best from the set it received. The rules used to pick the best 1051 OSPF Extended Prefix Range TLV is described in Section 4. 1053 When propagating OSPF Extended Prefix Range TLV between areas, ABR 1054 MUST set the IA-Flag, that is used to prevent redundant flooding of 1055 the OSPF Extended Prefix Range TLV between areas as described in 1056 Section 4. 1058 If the Prefix-SID that is advertised in Prefix SID Sub-TLV is also 1059 covered by the OSPF Extended Prefix Range TLV, the Prefix-SID 1060 advertised in Prefix SID Sub-TLV MUST be preferred. 1062 8.2. Inter-area Segment routing in OSPFv2 1064 In order to support SR in a multi-area environment, OSPFv2 must 1065 propagate Prefix-SID information between areas. The following 1066 procedure is used in order to propagate Prefix SIDs between areas. 1068 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 1069 prefix to all its connected areas, it will also originate an Extended 1070 Prefix Opaque LSA, as described in [I-D.ietf-ospf-prefix-link-attr]. 1071 The flooding scope of the Extended Prefix Opaque LSA type will be set 1072 to area-scope. The route-type in the OSPF Extended Prefix TLV is set 1073 to inter-area. The Prefix-SID Sub-TLV will be included in this LSA 1074 and the Prefix-SID value will be set as follows: 1076 The ABR will look at its best path to the prefix in the source 1077 area and find the advertising router associated with the best path 1078 to that prefix. 1080 The ABR will then determine if such router advertised a Prefix-SID 1081 for the prefix and use it when advertising the Prefix-SID to other 1082 connected areas. 1084 If no Prefix-SID was advertised for the prefix in the source area 1085 by the router that contributes to the best path to the prefix, the 1086 originating ABR will use the Prefix-SID advertised by any other 1087 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 1088 defined in [I-D.filsfils-spring-segment-routing-ldp-interop]) when 1089 propagating the Prefix-SID for the prefix to other areas. 1091 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 1092 route to all its connected areas it will also originate an Extended 1093 Prefix Opaque LSA, as described in [I-D.ietf-ospf-prefix-link-attr]. 1094 The flooding scope of the Extended Prefix Opaque LSA type will be set 1095 to area-scope. The route-type in OSPF Extended Prefix TLV is set to 1096 inter-area. The Prefix-SID Sub-TLV will be included in this LSA and 1097 the Prefix-SID will be set as follows: 1099 The ABR will look at its best path to the prefix in the source 1100 area and find the advertising router associated with the best path 1101 to that prefix. 1103 The ABR will then determine if such router advertised a Prefix-SID 1104 for the prefix and use it when advertising the Prefix-SID to other 1105 connected areas. 1107 If no Prefix-SID was advertised for the prefix in the source area 1108 by the ABR that contributes to the best path to the prefix, the 1109 originating ABR will use the Prefix-SID advertised by any other 1110 router when propagating the Prefix-SID for the prefix to other 1111 areas. 1113 8.3. SID for External Prefixes 1115 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1116 SR, generates Type-5 LSAs, it should also originate an Extended 1117 Prefix Opaque LSAs, as described in [I-D.ietf-ospf-prefix-link-attr]. 1118 The flooding scope of the Extended Prefix Opaque LSA type is set to 1119 AS-scope. The route-type in the OSPF Extended Prefix TLV is set to 1120 external. The Prefix-SID Sub-TLV is included in this LSA and the 1121 Prefix-SID value will be set to the SID that has been reserved for 1122 that prefix. 1124 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 1125 also advertise the Prefix-SID for the prefix. The NSSA ABR 1126 determines its best path to the prefix advertised in the translated 1127 Type-7 LSA and finds the advertising router associated with that 1128 path. If the advertising router has advertised a Prefix-SID for the 1129 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 1130 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 1131 router will be used. 1133 8.4. Advertisement of Adj-SID 1135 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1136 using the Adj-SID Sub-TLV as described in Section 7. 1138 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 1140 An Adj-SID MAY be advertised for any adjacency on a p2p link that is 1141 in neighbor state 2-Way or higher. If the adjacency on a p2p link 1142 transitions from the FULL state, then the Adj-SID for that adjacency 1143 MAY be removed from the area. If the adjacency transitions to a 1144 state lower then 2-Way, then the Adj-SID advertisement MUST be 1145 removed from the area. 1147 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1149 Broadcast or NBMA networks in OSPF are represented by a star topology 1150 where the Designated Router (DR) is the central point to which all 1151 other routers on the broadcast or NBMA network connect. As a result, 1152 routers on the broadcast or NBMA network advertise only their 1153 adjacency to the DR. Routers that do not act as DR do not form or 1154 advertise adjacencies with each other. They do, however, maintain 1155 2-Way adjacency state with each other and are directly reachable. 1157 When Segment Routing is used, each router on the broadcast or NBMA 1158 network MAY advertise the Adj-SID for its adjacency to the DR using 1159 Adj-SID Sub-TLV as described in Section 7.1. 1161 SR capable routers MAY also advertise an Adj-SID for other neighbors 1162 (e.g. BDR, DR-OTHER) on the broadcast or NBMA network using the LAN 1163 ADJ-SID Sub-TLV as described in Section 7.2. 1165 9. IANA Considerations 1167 This specification updates several existing OSPF registries. 1169 9.1. OSPF OSPF Router Information (RI) TLVs Registry 1171 o 8 (IANA Preallocated) - SR-Algorithm TLV 1173 o 9 (IANA Preallocated) - SID/Label Range TLV 1175 9.2. OSPF Extended Prefix LSA TLV Registry 1177 Following values are allocated: 1179 o 2 - OSPF Extended Prefix Range TLV 1181 9.3. OSPF Extended Prefix LSA Sub-TLV Registry 1183 Following values are allocated: 1185 o 1 - SID/Label Sub-TLV 1187 o 2 - Prefix SID Sub-TLV 1189 o 3 - SID/Label Binding Sub-TLV 1190 o 4 - IPv4 ERO Sub-TLV 1192 o 5 - Unnumbered Interface ID ERO Sub-TLV 1194 o 6 - IPv4 Backup ERO Sub-TLV 1196 o 7 - Unnumbered Interface ID Backup ERO Sub-TLV 1198 o 8 - ERO Metric Sub-TLV 1200 9.4. OSPF Extended Link LSA Sub-TLV Registry 1202 Following initial values are allocated: 1204 o 1 - SID/Label Sub-TLV 1206 o 2 - Adj-SID Sub-TLV 1208 o 3 - LAN Adj-SID/Label Sub-TLV 1210 10. Security Considerations 1212 Implementations must assure that malformed TLV and Sub-TLV 1213 permutations do not result in errors which cause hard OSPF failures. 1215 11. Contributors 1217 The following people gave a substantial contribution to the content 1218 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1219 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1220 Saku Ytti. 1222 12. Acknowledgements 1224 We would like to thank Anton Smirnov for his contribution. 1226 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1227 contribution on earlier incarnations of the "Binding / MPLS Label 1228 TLV" in [I-D.gredler-ospf-label-advertisement]. 1230 Thanks to Acee Lindem for the detail review of the draft, 1231 corrections, as well as discussion about details of the encoding. 1233 13. References 1234 13.1. Normative References 1236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1237 Requirement Levels", BCP 14, RFC 2119, March 1997. 1239 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1241 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1242 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1243 Tunnels", RFC 3209, December 2001. 1245 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1246 in Resource ReSerVation Protocol - Traffic Engineering 1247 (RSVP-TE)", RFC 3477, January 2003. 1249 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1250 (TE) Extensions to OSPF Version 2", RFC 3630, September 1251 2003. 1253 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1254 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 1255 4915, June 2007. 1257 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1258 Shaffer, "Extensions to OSPF for Advertising Optional 1259 Router Capabilities", RFC 4970, July 2007. 1261 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1262 OSPF Opaque LSA Option", RFC 5250, July 2008. 1264 13.2. Informative References 1266 [I-D.filsfils-spring-segment-routing-ldp-interop] 1267 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1268 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1269 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1270 "Segment Routing interoperability with LDP", draft- 1271 filsfils-spring-segment-routing-ldp-interop-02 (work in 1272 progress), September 2014. 1274 [I-D.filsfils-spring-segment-routing-use-cases] 1275 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1276 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1277 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1278 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1279 spring-segment-routing-use-cases-01 (work in progress), 1280 October 2014. 1282 [I-D.gredler-ospf-label-advertisement] 1283 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1284 "Advertising MPLS labels in OSPF", draft-gredler-ospf- 1285 label-advertisement-03 (work in progress), May 2013. 1287 [I-D.ietf-ospf-prefix-link-attr] 1288 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1289 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1290 Advertisement", draft-ietf-ospf-prefix-link-attr-06 (work 1291 in progress), June 2015. 1293 [I-D.ietf-spring-segment-routing] 1294 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1295 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1296 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 1297 spring-segment-routing-00 (work in progress), December 1298 2014. 1300 [I-D.minto-rsvp-lsp-egress-fast-protection] 1301 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1302 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1303 protection-03 (work in progress), November 2013. 1305 Authors' Addresses 1307 Peter Psenak (editor) 1308 Cisco Systems, Inc. 1309 Apollo Business Center 1310 Mlynske nivy 43 1311 Bratislava 821 09 1312 Slovakia 1314 Email: ppsenak@cisco.com 1316 Stefano Previdi (editor) 1317 Cisco Systems, Inc. 1318 Via Del Serafico, 200 1319 Rome 00142 1320 Italy 1322 Email: sprevidi@cisco.com 1323 Clarence Filsfils 1324 Cisco Systems, Inc. 1325 Brussels 1326 Belgium 1328 Email: cfilsfil@cisco.com 1330 Hannes Gredler 1331 Juniper Networks, Inc. 1332 1194 N. Mathilda Ave. 1333 Sunnyvale, CA 94089 1334 US 1336 Email: hannes@juniper.net 1338 Rob Shakir 1339 British Telecom 1340 London 1341 UK 1343 Email: rob.shakir@bt.com 1345 Wim Henderickx 1346 Alcatel-Lucent 1347 Copernicuslaan 50 1348 Antwerp 2018 1349 BE 1351 Email: wim.henderickx@alcatel-lucent.com 1353 Jeff Tantsura 1354 Ericsson 1355 300 Holger Way 1356 San Jose, CA 95134 1357 US 1359 Email: Jeff.Tantsura@ericsson.com