idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-04.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 (February 1, 2015) is 3344 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 284 -- Looks like a reference, but probably isn't: '199' on line 284 -- Looks like a reference, but probably isn't: '1000' on line 285 -- Looks like a reference, but probably isn't: '1099' on line 285 -- Looks like a reference, but probably isn't: '500' on line 286 -- Looks like a reference, but probably isn't: '599' on line 286 == Unused Reference: 'RFC2328' is defined on line 1216, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 1226, 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-02 == 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: August 5, 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 February 1, 2015 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-04 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 August 5, 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 . . . . . . . . . . . . . . . . . . 12 77 6.1. ERO Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 14 78 6.2. ERO Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . 26 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 value is defined by this document: 218 0: IGP metric based Shortest Path Tree (SPT) 220 The RI LSA can be advertised at any of the defined opaque flooding 221 scopes (link, area, or Autonomous System (AS)). For the purpose of 222 the SR-Algorithm TLV propagation, area scope flooding is required. 224 3.2. SID/Label Range TLV 226 The SID/Label Range TLV is a top-level TLV of the Router Information 227 Opaque LSA (defined in [RFC4970]). 229 The SID/Label Range TLV MAY appear multiple times and has the 230 following format: 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Type | Length | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Range Size | Reserved | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Sub-TLVs (variable) | 240 +- -+ 241 | | 242 + + 244 where: 246 Type: TBD, suggested value 9 248 Length: variable 250 Range Size: 3 octets of the SID/label range 252 Initially, the only supported Sub-TLV is the SID/Label TLV as defined 253 in Section 2.1. The SID/Label advertised in the SID/Label TLV 254 represents the first SID/Label in the advertised range. 256 Multiple occurrence of the SID/Label Range TLV MAY be advertised, in 257 order to advertise multiple ranges. In such case: 259 o The originating router MUST encode each range into a different 260 SID/Label Range TLV. 262 o The originating router decides the order in which the set of SID/ 263 Label Range TLVs are advertised inside the Router Information 264 Opaque LSA. The originating router MUST ensure the order is same 265 after a graceful restart (using checkpointing, non-volatile 266 storage or any other mechanism) in order to assure the SID/label 267 range and SID index correspondence is preserved across graceful 268 restarts. 270 o The receiving router must adhere to the order in which the ranges 271 are advertised when calculating a SID/label from a SID index. 273 The following example illustrates the advertisement of multiple 274 ranges: 276 The originating router advertises following ranges: 277 Range 1: [100, 199] 278 Range 2: [1000, 1099] 279 Range 3: [500, 599] 281 The receiving routers concatenate the ranges and build the Segment Routing Global Block 282 (SRGB) is as follows: 284 SRGB = [100, 199] 285 [1000, 1099] 286 [500, 599] 288 The indexes span multiple ranges: 290 index=0 means label 100 291 ... 292 index 99 means label 199 293 index 100 means label 1000 294 index 199 means label 1099 295 ... 296 index 200 means label 500 297 ... 299 The RI LSA can be advertised at any of the defined flooding scopes 300 (link, area, or autonomous system (AS)). For the purposes of the SR- 301 Capability TLV propagation, area scope flooding is required. 303 4. OSPF Extended Prefix Range TLV 305 In some cases it is useful to advertise attributes for the range of 306 prefixes. Segment Routing Mapping Server, which is described in 307 [I-D.filsfils-spring-segment-routing-ldp-interop], is an example, 308 where we need a single advertisement to advertise SIDs for multiple 309 prefixes from a contiguous address range. 311 OSPF Extended Prefix Range TLV, which is a new top level TLV of the 312 Extended Prefix LSA described in [I-D.ietf-ospf-prefix-link-attr] is 313 defined for this purpose. 315 Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each 316 OSPF Extended Prefix Opaque LSA, but all prefix ranges included in a 317 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 318 scope. The OSPF Extended Prefix Range TLV has the following format: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Prefix Length | AF | Range Size | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Flags | Reserved | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Address Prefix (variable) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Sub-TLVs (variable) | 332 +- -+ 333 | | 335 where: 337 Type: TBD, suggested value 2. 339 Length: variable 341 Prefix length: length of the prefix 343 AF: 0 - IPv4 unicast 345 Range size: represents the number of prefixes that are covered by 346 the advertisement. The Range Size MUST NOT exceed the number of 347 prefixes that could be satisfied by the prefix length without 348 including the IPv4 multicast address range (224.0.0.0/3). 350 Flags: 1 octet field. The following flags are defined: 352 0 1 2 3 4 5 6 7 353 +--+--+--+--+--+--+--+--+ 354 |IA| | | | | | | | 355 +--+--+--+--+--+--+--+--+ 357 where: 359 IA-Flag: Inter-Area flag. If set, advertisement is of inter- 360 area type. ABR that is advertising the OSPF Extended Prefix 361 Range TLV between areas MUST set this bit. 363 This bit is used to prevent redundant flooding of Prefix Range 364 TLVs between areas as follows: 366 An ABR always prefers intra-area Prefix Range advertisement 367 over inter-area one. 369 An ABR does not consider inter-area Prefix Range 370 advertisements coming from non backbone area. 372 An ABR propagates inter-area Prefix Range advertisement from 373 backbone area to connected non backbone areas only if such 374 advertisement is considered to be the best one. 376 Address Prefix: the prefix, encoded as an even multiple of 32-bit 377 words, padded with zeroed bits as necessary. This encoding 378 consumes ((PrefixLength + 31) / 32) 32-bit words. The Address 379 Prefix represents the first prefix in the prefix range. 381 5. Prefix SID Sub-TLV 383 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV 384 described in [I-D.ietf-ospf-prefix-link-attr] and the OSPF Extended 385 Prefix Range TLV described in Section 4. It MAY appear more than 386 once in the parent TLV and has the following format: 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Type | Length | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Flags | Reserved | MT-ID | Algorithm | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | SID/Index/Label (variable) | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 where: 400 Type: TBD, suggested value 2. 402 Length: variable 404 Flags: 1 octet field. The following flags are defined: 406 0 1 2 3 4 5 6 7 407 +--+--+--+--+--+--+--+--+ 408 | |NP|M |E |V |L | | | 409 +--+--+--+--+--+--+--+--+ 411 where: 413 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 414 NOT pop the Prefix-SID before delivering the packet to the node 415 that advertised the Prefix-SID. 417 M-Flag: Mapping Server Flag. If set, the SID is advertised 418 from the Segment Routing Mapping Server functionality as 419 described in [I-D.filsfils-spring-segment-routing-ldp-interop]. 421 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 422 the Prefix-SID originator MUST replace the Prefix-SID with a 423 Prefix-SID having an Explicit-NULL value (0 for IPv4) before 424 forwarding the packet. 426 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 427 an absolute value. If not set, then the Prefix-SID carries an 428 index. 430 L-Flag: Local/Global Flag. If set, then the value/index 431 carried by the Prefix-SID has local significance. If not set, 432 then the value/index carried by this Sub-TLV has global 433 significance. 435 Other bits: Reserved. These MUST be zero when sent and are 436 ignored when received. 438 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 440 Algorithm: one octet identifying the algorithm the Prefix-SID is 441 associated with as defined in Section 3.1. 443 SID/Index/Label: according to the V and L flags, it contains 444 either: 446 A 32 bit index defining the offset in the SID/Label space 447 advertised by this router. 449 A 24 bit label where the 20 rightmost bits are used for 450 encoding the label value. 452 If multiple Prefix-SIDs are advertised for the same prefix, the 453 receiving router MUST use the first encoded SID and MAY use the 454 subsequent SIDs. 456 When propagating Prefix-SIDs between areas, if multiple prefix-SIDs 457 are advertised for a prefix, an implementation SHOULD preserve the 458 original order when advertising prefix-SIDs to other areas. This 459 allows implementations that only support a single Prefix-SID to have 460 a consistent view across areas. 462 When calculating the outgoing label for the prefix, the router MUST 463 take into account E and P flags advertised by the next-hop router, if 464 next-hop router advertised the SID for the prefix. This MUST be done 465 regardless of whether the next-hop router contributes to the best 466 path to the prefix. 468 The NP-Flag (No-PHP) MUST be set on the Prefix-SIDs allocated to 469 inter-area prefixes that are originated by the ABR based on intra- 470 area or inter-area reachability between areas. When the inter-area 471 prefix is generated based on the prefix which is directly attached to 472 the ABR, NP-Flag SHOULD NOT be set 474 The NP-Flag (No-PHP) MUST be be set on the Prefix-SIDs allocated to 475 redistributed prefixes, unless the redistributed prefix is directly 476 attached to ASBR, in which case the NP-flag SHOULD NOT be set. 478 If the NP-Flag is not set then any upstream neighbor of the Prefix- 479 SID originator MUST pop the Prefix-SID. This is equivalent to the 480 penultimate hop popping mechanism used in the MPLS dataplane. In 481 such case, MPLS EXP bits of the Prefix-SID are not preserved for the 482 final destination (the Prefix-SID being removed). If the NP-flag is 483 clear then the received E-flag is ignored. 485 If the NP-flag is set then: 487 If the E-flag is not set then any upstream neighbor of the Prefix- 488 SID originator MUST keep the Prefix-SID on top of the stack. This 489 is useful when the originator of the Prefix-SID must stitch the 490 incoming packet into a continuing MPLS LSP to the final 491 destination. This could occur at an inter-area border router 492 (prefix propagation from one area to another) or at an inter- 493 domain border router (prefix propagation from one domain to 494 another). 496 If the E-flag is set then any upstream neighbor of the Prefix-SID 497 originator MUST replace the Prefix-SID with a Prefix-SID having an 498 Explicit-NULL value. This is useful, e.g., when the originator of 499 the Prefix-SID is the final destination for the related prefix and 500 the originator wishes to receive the packet with the original EXP 501 bits. 503 When M-Flag is set, NP-flag MUST be set and E-bit MUST NOT be set. 505 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 506 the value advertised in Prefix SID Sub-TLV is interpreted as a 507 starting SID value. 509 Example 1: if the following router addresses (loopback addresses) 510 need to be mapped into the corresponding Prefix SID indexes: 512 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 513 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 514 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 515 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 517 then the Prefix field in the Extended Prefix Range TLV would be set 518 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 519 set to 4 and the Index value in the Prefix-SID Sub-TLV would be set 520 to 1. 522 Example 2: If the following prefixes need to be mapped into the 523 corresponding Prefix-SID indexes: 525 10.1.1/24, Prefix-SID: Index 51 526 10.1.2/24, Prefix-SID: Index 52 527 10.1.3/24, Prefix-SID: Index 53 528 10.1.4/24, Prefix-SID: Index 54 529 10.1.5/24, Prefix-SID: Index 55 530 10.1.6/24, Prefix-SID: Index 56 531 10.1.7/24, Prefix-SID: Index 57 533 then the Prefix field in the Extended Prefix Range TLV would be set 534 to 10.1.1.0, Prefix Length would be set to 24, Range Size would be 7 535 and the Index value in the Prefix-SID Sub-TLV would be set to 51. 537 6. SID/Label Binding Sub-TLV 539 The SID/Label Binding Sub-TLV is used to advertise a SID/Label 540 mapping for a path to the prefix. 542 The SID/Label Binding TLV MAY be originated by any router in an OSPF 543 domain. The router may advertise a SID/Label binding to a FEC along 544 with at least a single 'nexthop style' anchor. The protocol supports 545 more than one 'nexthop style' anchor to be attached to a SID/Label 546 binding, which results in a simple path description language. In 547 analogy to RSVP, the terminology for this is called an 'Explicit 548 Route Object' (ERO). Since ERO style path notation allows anchoring 549 SID/label bindings to both link and node IP addresses, any Label 550 Switched Path (LSP) can be described. Additionally, SID/Label 551 Bindings from external protocols can be easily re-advertised. 553 The SID/Label Binding TLV may be used for advertising SID/Label 554 Bindings and their associated Primary and Backup paths. In a single 555 TLV, a primary ERO Path, backup ERO Path, or both can be advertised. 556 If a router wants to advertise multiple parallel paths, then it can 557 generate several TLVs for the same Prefix/FEC. Each occurrence of a 558 Binding TLV for a given FEC Prefix will add a new path. 560 The SID/Label Binding Sub-TLV is a Sub-TLV of the OSPF Extended 561 Prefix TLV described in [I-D.ietf-ospf-prefix-link-attr] and the OSPF 562 Extended Prefix Range TLV described in Section 4. Multiple SID/Label 563 Binding TLVs can be present in their parent TLV. The SID/Label 564 Binding Sub-TLV has following format: 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type | Length | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Flags | Reserved | MT-ID | Weight | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Sub-TLVs (variable) | 574 +- -+ 575 | | 577 where: 579 Type: TBD, suggested value 3 581 Length: variable 583 Flags: 1 octet field of following flags: 585 0 1 2 3 4 5 6 7 586 +-+-+-+-+-+-+-+-+ 587 |M| | 588 +-+-+-+-+-+-+-+-+ 590 where: 592 M-bit - When the bit is set the binding represents the 593 mirroring context as defined in 594 [I-D.minto-rsvp-lsp-egress-fast-protection]. 596 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 598 Weight: weight used for load-balancing purposes. The use of the 599 weight is defined in [I-D.ietf-spring-segment-routing]. 601 The SID/Label Binding TLV supports the following Sub-TLVs: 603 SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST 604 appear in the SID/Label Binding Sub-TLV and it MUST only appear 605 once. 607 ERO Metric Sub-TLV as defined in Section 6.1. 609 ERO Sub-TLVs as defined in Section 6.2. 611 6.1. ERO Metric Sub-TLV 613 The ERO Metric Sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 615 The ERO Metric Sub-TLV advertises the cost of an ERO path. It is 616 used to compare the cost of a given source/destination path. A 617 router SHOULD advertise the ERO Metric Sub-TLV in an advertised ERO 618 TLV. The cost of the ERO Metric Sub-TLV SHOULD be set to the 619 cumulative IGP or TE path cost of the advertised ERO. Since 620 manipulation of the Metric field may attract or repel traffic to and 621 from the advertised segment, it MAY be manually overridden. 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Type | Length | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Metric (4 octets) | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 ERO Metric Sub-TLV format 633 where: 635 Type: TBD, suggested value 8 637 Length: Always 4 639 Metric: A 4 octet metric representing the aggregate IGP or TE path 640 cost. 642 6.2. ERO Sub-TLVs 644 All 'ERO' information represents an ordered set which describes the 645 segments of a path. The first ERO Sub-TLV describes the first 646 segment of a path. Similiarly, the last ERO Sub-TLV describes the 647 segment closest to the egress point. If a router extends or stitches 648 a path, it MUST prepend the new segment's path information to the ERO 649 list. This applies equally to advertised backup EROs. 651 All ERO Sub-TLVs must immediately follow the (SID)/Label Sub-TLV. 653 All Backup ERO Sub-TLVs must immediately follow the last ERO Sub-TLV. 655 6.2.1. IPv4 ERO Sub-TLV 657 IPv4 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 659 The IPv4 ERO Sub-TLV describes a path segment using IPv4 Address 660 style encoding. Its semantics have been borrowed from [RFC3209]. 662 0 1 2 3 663 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Type | Length | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Flags | Reserved | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | IPv4 Address (4 octets) | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 IPv4 ERO Sub-TLV format 674 where: 676 Type: TBD, suggested value 4 678 Length: 8 bytes 680 Flags: 1 octet field of following flags: 682 0 1 2 3 4 5 6 7 683 +-+-+-+-+-+-+-+-+ 684 |L| | 685 +-+-+-+-+-+-+-+-+ 687 where: 689 L-bit - If the L-bit is set, then the segment path is 690 designated as 'loose'. Otherwise, the segment path is 691 designated as 'strict'. 693 IPv4 Address - the address of the explicit route hop. 695 6.2.2. Unnumbered Interface ID ERO Sub-TLV 697 The Unnumbered Interface ID ERO Sub-TLV is a Sub-TLV of the SID/Label 698 Binding Sub-TLV. 700 The appearance and semantics of the 'Unnumbered Interface ID' have 701 been borrowed from [RFC3477]. 703 The Unnumbered Interface-ID ERO Sub-TLV describes a path segment that 704 includes an unnumbered interface. Unnumbered interfaces are 705 referenced using the interface index. Interface indices are assigned 706 local to the router and therefore not unique within a domain. All 707 elements in an ERO path need to be unique within a domain and hence 708 need to be disambiguated using a domain unique Router-ID. 710 0 1 2 3 711 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 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Type | Length | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Flags | Reserved | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Router ID | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Interface ID | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 where: 724 Unnumbered Interface ID ERO Sub-TLV format 726 Type: TBD, suggested value 5 728 Length: 12 bytes 730 Flags: 1 octet field of following flags: 732 0 1 2 3 4 5 6 7 733 +-+-+-+-+-+-+-+-+ 734 |L| | 735 +-+-+-+-+-+-+-+-+ 737 where: 739 L-bit - If the L-bit is set, then the segment path is 740 designated as 'loose'. Otherwise, the segment path is 741 designated as 'strict'. 743 Router-ID: Router-ID of the next-hop. 745 Interface ID: is the identifier assigned to the link by the router 746 specified by the Router-ID. 748 6.2.3. IPv4 Backup ERO Sub-TLV 750 IPv4 Prefix Backup ERO Sub-TLV is a Sub-TLV of the SID/Label Binding 751 Sub-TLV. 753 The IPv4 Backup ERO Sub-TLV describes a path segment using IPv4 754 Address style of encoding. Its semantics have been borrowed from 755 [RFC3209]. 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Type | Length | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Flags | Reserved | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | IPv4 Address (4 octets) | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 IPv4 Backup ERO Sub-TLV format 769 where: 771 Type: TBD, suggested value 6 773 Length: 8 bytes 775 Flags: 1 octet field of following flags: 777 0 1 2 3 4 5 6 7 778 +-+-+-+-+-+-+-+-+ 779 |L| | 780 +-+-+-+-+-+-+-+-+ 782 where: 784 L-bit - If the L-bit is set, then the segment path is 785 designated as 'loose'. Otherwise, the segment path is 786 designated as 'strict'. 788 IPv4 Address - the address of the explicit route hop. 790 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV 792 The Unnumbered Interface ID Backup ERO Sub-TLV is a Sub-TLV of the 793 SID/Label Binding Sub-TLV. 795 The appearance and semantics of the 'Unnumbered Interface ID' have 796 been borrowed from [RFC3477]. 798 The Unnumbered Interface-ID Backup ERO Sub-TLV describes a path 799 segment that includes an unnumbered interface. Unnumbered interfaces 800 are referenced using the interface index. Interface indices are 801 assigned local to the router and are therefore not unique within a 802 domain. All elements in an ERO path need to be unique within a 803 domain and hence need to be disambiguated with specification of the 804 domain unique Router-ID. 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Type | Length | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Flags | Reserved | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Router ID | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Interface ID | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 Unnumbered Interface ID Backup ERO Sub-TLV format 820 where: 822 Type: TBD, suggested value 7 824 Length: 12 bytes 826 Flags: 1 octet field of following flags: 828 0 1 2 3 4 5 6 7 829 +-+-+-+-+-+-+-+-+ 830 |L| | 831 +-+-+-+-+-+-+-+-+ 833 where: 835 L-bit - If the L-bit is set, then the segment path is 836 designated as 'loose'. Otherwise, the segment path is 837 designated as 'strict'. 839 Router-ID: Router-ID of the next-hop. 841 Interface ID: is the identifier assigned to the link by the router 842 specified by the Router-ID. 844 7. Adjacency Segment Identifier (Adj-SID) 846 An Adjacency Segment Identifier (Adj-SID) represents a router 847 adjacency in Segment Routing. 849 7.1. Adj-SID Sub-TLV 851 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 852 [I-D.ietf-ospf-prefix-link-attr]. It MAY appear multiple times in 853 the Extended Link TLV. Examples where more than one Adj-SID may be 854 used per neighbor are described in section 4 of 855 [I-D.filsfils-spring-segment-routing-use-cases]. The Adj-SID Sub-TLV 856 has the following format: 858 0 1 2 3 859 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 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Type | Length | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Flags | Reserved | MT-ID | Weight | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | SID/Label/Index (variable) | 866 +---------------------------------------------------------------+ 868 where: 870 Type: TBD, suggested value 2. 872 Length: variable. 874 Flags. 1 octet field of following flags: 876 0 1 2 3 4 5 6 7 877 +-+-+-+-+-+-+-+-+ 878 |B|V|L|S| | 879 +-+-+-+-+-+-+-+-+ 881 where: 883 B-Flag: Backup Flag. If set, the Adj-SID refers to an 884 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 885 described in section 3.1 of 886 [I-D.filsfils-spring-segment-routing-use-cases]. 888 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 889 an absolute value. If not set, then the Adj-SID carries an 890 index. 892 The L-Flag: Local/Global Flag. If set, then the value/index 893 carried by the Adj-SID has local significance. If not set, 894 then the value/index carried by this Sub-TLV has global 895 significance. 897 The S-Flag. Set Flag. When set, the S-Flag indicates that the 898 Adj-SID refers to a set of adjacencies (and therefore MAY be 899 assigned to other adjacencies as well). 901 Other bits: Reserved. These MUST be zero when sent and are 902 ignored when received. 904 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 906 Weight: weight used for load-balancing purposes. The use of the 907 weight is defined in [I-D.ietf-spring-segment-routing]. 909 SID/Index/Label: according to the V and L flags, it contains 910 either: 912 A 32 bit index defining the offset in the SID/Label space 913 advertised by this router. 915 A 24 bit label where the 20 rightmost bits are used for 916 encoding the label value. 918 An SR capable router MAY allocate an Adj-SID for each of its 919 adjacencies and set the B-Flag when the adjacency is protected by an 920 FRR mechanism (IP or MPLS) as described in section 3.1 of 921 [I-D.filsfils-spring-segment-routing-use-cases]. 923 7.2. LAN Adj-SID Sub-TLV 925 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 926 in [I-D.ietf-ospf-prefix-link-attr]. It MAY appear multiple times in 927 the Extended-Link TLV. It is used to advertise a SID/Label for an 928 adjacency to a non-DR node on a broadcast or NBMA network. 930 0 1 2 3 931 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 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Type | Length | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Flags | Reserved | MT-ID | Weight | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Neighbor ID | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | SID/Label/Index (variable) | 940 +---------------------------------------------------------------+ 942 where: 944 Type: TBD, suggested value 3. 946 Length: variable. 948 Flags. 1 octet field of following flags: 950 0 1 2 3 4 5 6 7 951 +-+-+-+-+-+-+-+-+ 952 |B|V|L|S| | 953 +-+-+-+-+-+-+-+-+ 955 where: 957 B-Flag: Backup-flag: set if the LAN-Adj-SID refer to an 958 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 959 described in section 3.1 of 960 [I-D.filsfils-spring-segment-routing-use-cases]. 962 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 963 carries an absolute value. If not set, then the Prefix-SID 964 carries an index. 966 The L-Flag: Local/Global Flag. If set, then the value/index 967 carried by the Prefix-SID has local significance. If not set, 968 then the value/index carried by this Sub-TLV has global 969 significance. 971 The S-Flag. Set Flag. When set, the S-Flag indicates that the 972 Adj-SID refers to a set of adjacencies (and therefore MAY be 973 assigned to other adjacencies as well). 975 Other bits: Reserved. These MUST be zero when sent and are 976 ignored when received. 978 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 980 Weight: weight used for load-balancing purposes. The use of the 981 weight is defined in [I-D.ietf-spring-segment-routing]. 983 SID/Index/Label: according to the V and L flags, it contains 984 either: 986 A 32 bit index defining the offset in the SID/Label space 987 advertised by this router. 989 A 24 bit label where the 20 rightmost bits are used for 990 encoding the label value. 992 8. Elements of Procedure 994 8.1. Intra-area Segment routing in OSPFv2 996 An OSPFv2 router that supports segment routing MAY advertise Prefix- 997 SIDs for any prefix to which it is advertising reachability (e.g., a 998 loopback IP address as described in Section 5). 1000 If multiple routers advertise a Prefix-SID for the same prefix, then 1001 the Prefix-SID MUST be the same. This is required in order to allow 1002 traffic load-balancing when multiple equal cost paths to the 1003 destination exist in the network. 1005 Prefix-SID can also be advertised by the SR Mapping Servers (as 1006 described in [I-D.filsfils-spring-segment-routing-ldp-interop]). The 1007 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 1008 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 1009 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 1010 MUST be advertised by all of them. The flooding scope of the OSPF 1011 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 1012 could be either area scoped or AS scoped and is determined based on 1013 the configuration of the SR Mapping Server. 1015 SR Mapping Server MUST use OSPF Extended Prefix Range TLV when 1016 advertising SIDs for prefixes. Prefixes of different route-types can 1017 be combined in a single OSPF Extended Prefix Range TLV advertised by 1018 the SR Mapping Server. 1020 Area scoped OSPF Extended Prefix Range TLV are propagated between 1021 areas. Similar to propagation of prefixes between areas, ABR only 1022 propagates the OSPF Extended Prefix Range TLV that it considers to be 1023 the best from the set it received. The rules used to pick the best 1024 OSPF Extended Prefix Range TLV is described in Section 4. 1026 When propagating OSPF Extended Prefix Range TLV between areas, ABR 1027 MUST set the IA-Flag, that is used to prevent redundant flooding of 1028 the OSPF Extended Prefix Range TLV between areas as described in 1029 Section 4. 1031 If the Prefix-SID that is advertised in Prefix SID Sub-TLV is also 1032 covered by the OSPF Extended Prefix Range TLV, the Prefix-SID 1033 advertised in Prefix SID Sub-TLV MUST be preferred. 1035 8.2. Inter-area Segment routing in OSPFv2 1037 In order to support SR in a multi-area environment, OSPFv2 must 1038 propagate Prefix-SID information between areas. The following 1039 procedure is used in order to propagate Prefix SIDs between areas. 1041 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 1042 prefix to all its connected areas, it will also originate an Extended 1043 Prefix Opaque LSA, as described in [I-D.ietf-ospf-prefix-link-attr]. 1044 The flooding scope of the Extended Prefix Opaque LSA type will be set 1045 to area-scope. The route-type in the OSPF Extended Prefix TLV is set 1046 to inter-area. The Prefix-SID Sub-TLV will be included in this LSA 1047 and the Prefix-SID value will be set as follows: 1049 The ABR will look at its best path to the prefix in the source 1050 area and find the advertising router associated with the best path 1051 to that prefix. 1053 The ABR will then determine if such router advertised a Prefix-SID 1054 for the prefix and use it when advertising the Prefix-SID to other 1055 connected areas. 1057 If no Prefix-SID was advertised for the prefix in the source area 1058 by the router that contributes to the best path to the prefix, the 1059 originating ABR will use the Prefix-SID advertised by any other 1060 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 1061 defined in [I-D.filsfils-spring-segment-routing-ldp-interop]) when 1062 propagating the Prefix-SID for the prefix to other areas. 1064 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 1065 route to all its connected areas it will also originate an Extended 1066 Prefix Opaque LSA, as described in [I-D.ietf-ospf-prefix-link-attr]. 1067 The flooding scope of the Extended Prefix Opaque LSA type will be set 1068 to area-scope. The route-type in OSPF Extended Prefix TLV is set to 1069 inter-area. The Prefix-SID Sub-TLV will be included in this LSA and 1070 the Prefix-SID will be set as follows: 1072 The ABR will look at its best path to the prefix in the source 1073 area and find the advertising router associated with the best path 1074 to that prefix. 1076 The ABR will then determine if such router advertised a Prefix-SID 1077 for the prefix and use it when advertising the Prefix-SID to other 1078 connected areas. 1080 If no Prefix-SID was advertised for the prefix in the source area 1081 by the ABR that contributes to the best path to the prefix, the 1082 originating ABR will use the Prefix-SID advertised by any other 1083 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 1084 defined in [I-D.filsfils-spring-segment-routing-ldp-interop]) when 1085 propagating the Prefix-SID for the prefix to other areas. 1087 8.3. SID for External Prefixes 1089 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1090 SR, generates Type-5 LSAs, it should also originate an Extended 1091 Prefix Opaque LSAs, as described in [I-D.ietf-ospf-prefix-link-attr]. 1092 The flooding scope of the Extended Prefix Opaque LSA type is set to 1093 AS-scope. The route-type in the OSPF Extended Prefix TLV is set to 1094 external. The Prefix-SID Sub-TLV is included in this LSA and the 1095 Prefix-SID value will be set to the SID that has been reserved for 1096 that prefix. 1098 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 1099 also advertise the Prefix-SID for the prefix. The NSSA ABR 1100 determines its best path to the prefix advertised in the translated 1101 Type-7 LSA and finds the advertising router associated with that 1102 path. If the advertising router has advertised a Prefix-SID for the 1103 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 1104 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 1105 router will be used (e.g.: a Prefix-SID coming from an SR Mapping 1106 Server as defined in 1107 [I-D.filsfils-spring-segment-routing-ldp-interop]). 1109 8.4. Advertisement of Adj-SID 1111 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1112 using the Adj-SID Sub-TLV as described in Section 7. 1114 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 1116 An Adj-SID MAY be advertised for any adjacency on a p2p link that is 1117 in neighbor state 2-Way or higher. If the adjacency on a p2p link 1118 transitions from the FULL state, then the Adj-SID for that adjacency 1119 MAY be removed from the area. If the adjacency transitions to a 1120 state lower then 2-Way, then the Adj-SID advertisement MUST be 1121 removed from the area. 1123 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1125 Broadcast or NBMA networks in OSPF are represented by a star topology 1126 where the Designated Router (DR) is the central point to which all 1127 other routers on the broadcast or NBMA network connect. As a result, 1128 routers on the broadcast or NBMA network advertise only their 1129 adjacency to the DR. Routers that do not act as DR do not form or 1130 advertise adjacencies with each other. They do, however, maintain 1131 2-Way adjacency state with each other and are directly reachable. 1133 When Segment Routing is used, each router on the broadcast or NBMA 1134 network MAY advertise the Adj-SID for its adjacency to the DR using 1135 Adj-SID Sub-TLV as described in Section 7.1. 1137 SR capable routers MAY also advertise an Adj-SID for other neighbors 1138 (e.g. BDR, DR-OTHER) on the broadcast or NBMA network using the LAN 1139 ADJ-SID Sub-TLV as described in Section 7.2. 1141 9. IANA Considerations 1143 This specification updates several existing OSPF registries. 1145 9.1. OSPF OSPF Router Information (RI) TLVs Registry 1147 o 8 (IANA Preallocated) - SR-Algorithm TLV 1149 o 9 (IANA Preallocated) - SID/Label Range TLV 1151 9.2. OSPF Extended Prefix LSA TLV Registry 1153 Following values are allocated: 1155 o 2 - OSPF Extended Prefix Range TLV 1157 9.3. OSPF Extended Prefix LSA Sub-TLV Registry 1159 Following values are allocated: 1161 o 1 - SID/Label Sub-TLV 1163 o 2 - Prefix SID Sub-TLV 1165 o 3 - SID/Label Binding Sub-TLV 1167 o 4 - IPv4 ERO Sub-TLV 1168 o 5 - Unnumbered Interface ID ERO Sub-TLV 1170 o 6 - IPv4 Backup ERO Sub-TLV 1172 o 7 - Unnumbered Interface ID Backup ERO Sub-TLV 1174 o 8 - ERO Metric Sub-TLV 1176 9.4. OSPF Extended Link LSA Sub-TLV Registry 1178 Following initial values are allocated: 1180 o 1 - SID/Label Sub-TLV 1182 o 2 - Adj-SID Sub-TLV 1184 o 3 - LAN Adj-SID/Label Sub-TLV 1186 10. Security Considerations 1188 Implementations must assure that malformed TLV and Sub-TLV 1189 permutations do not result in errors which cause hard OSPF failures. 1191 11. Contributors 1193 The following people gave a substantial contribution to the content 1194 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1195 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1196 Saku Ytti. 1198 12. Acknowledgements 1200 We would like to thank Anton Smirnov for his contribution. 1202 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1203 contribution on earlier incarnations of the "Binding / MPLS Label 1204 TLV" in [I-D.gredler-ospf-label-advertisement]. 1206 Thanks to Acee Lindem for the detail review of the draft, 1207 corrections, as well as discussion about details of the encoding. 1209 13. References 1211 13.1. Normative References 1213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1214 Requirement Levels", BCP 14, RFC 2119, March 1997. 1216 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1218 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1219 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1220 Tunnels", RFC 3209, December 2001. 1222 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1223 in Resource ReSerVation Protocol - Traffic Engineering 1224 (RSVP-TE)", RFC 3477, January 2003. 1226 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1227 (TE) Extensions to OSPF Version 2", RFC 3630, September 1228 2003. 1230 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1231 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 1232 4915, June 2007. 1234 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1235 Shaffer, "Extensions to OSPF for Advertising Optional 1236 Router Capabilities", RFC 4970, July 2007. 1238 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1239 OSPF Opaque LSA Option", RFC 5250, July 2008. 1241 13.2. Informative References 1243 [I-D.filsfils-spring-segment-routing-ldp-interop] 1244 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1245 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1246 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1247 "Segment Routing interoperability with LDP", draft- 1248 filsfils-spring-segment-routing-ldp-interop-02 (work in 1249 progress), September 2014. 1251 [I-D.filsfils-spring-segment-routing-use-cases] 1252 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1253 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1254 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1255 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1256 spring-segment-routing-use-cases-01 (work in progress), 1257 October 2014. 1259 [I-D.gredler-ospf-label-advertisement] 1260 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1261 "Advertising MPLS labels in OSPF", draft-gredler-ospf- 1262 label-advertisement-03 (work in progress), May 2013. 1264 [I-D.ietf-ospf-prefix-link-attr] 1265 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1266 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1267 Advertisement", draft-ietf-ospf-prefix-link-attr-02 (work 1268 in progress), December 2014. 1270 [I-D.ietf-spring-segment-routing] 1271 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1272 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1273 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 1274 spring-segment-routing-00 (work in progress), December 1275 2014. 1277 [I-D.minto-rsvp-lsp-egress-fast-protection] 1278 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1279 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1280 protection-03 (work in progress), November 2013. 1282 Authors' Addresses 1284 Peter Psenak (editor) 1285 Cisco Systems, Inc. 1286 Apollo Business Center 1287 Mlynske nivy 43 1288 Bratislava 821 09 1289 Slovakia 1291 Email: ppsenak@cisco.com 1293 Stefano Previdi (editor) 1294 Cisco Systems, Inc. 1295 Via Del Serafico, 200 1296 Rome 00142 1297 Italy 1299 Email: sprevidi@cisco.com 1301 Clarence Filsfils 1302 Cisco Systems, Inc. 1303 Brussels 1304 Belgium 1306 Email: cfilsfil@cisco.com 1307 Hannes Gredler 1308 Juniper Networks, Inc. 1309 1194 N. Mathilda Ave. 1310 Sunnyvale, CA 94089 1311 US 1313 Email: hannes@juniper.net 1315 Rob Shakir 1316 British Telecom 1317 London 1318 UK 1320 Email: rob.shakir@bt.com 1322 Wim Henderickx 1323 Alcatel-Lucent 1324 Copernicuslaan 50 1325 Antwerp 2018 1326 BE 1328 Email: wim.henderickx@alcatel-lucent.com 1330 Jeff Tantsura 1331 Ericsson 1332 300 Holger Way 1333 San Jose, CA 95134 1334 US 1336 Email: Jeff.Tantsura@ericsson.com