idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-07.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 (March 21, 2016) is 2957 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 297 -- Looks like a reference, but probably isn't: '199' on line 297 -- Looks like a reference, but probably isn't: '1000' on line 298 -- Looks like a reference, but probably isn't: '1099' on line 298 -- Looks like a reference, but probably isn't: '500' on line 299 -- Looks like a reference, but probably isn't: '599' on line 299 == Unused Reference: 'RFC2328' is defined on line 1246, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 1260, 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 (-15) exists of draft-ietf-spring-segment-routing-00 Summary: 2 errors (**), 0 flaws (~~), 6 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: September 22, 2016 Cisco Systems, Inc. 6 H. Gredler 7 Individual 8 R. Shakir 9 Jive Communications, Inc. 10 W. Henderickx 11 Alcatel-Lucent 12 J. Tantsura 13 Ericsson 14 March 21, 2016 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-07 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 September 22, 2016. 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 70 2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 71 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4 72 3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4 73 3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 6 74 4. OSPF Extended Prefix Range TLV . . . . . . . . . . . . . . . 7 75 5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 9 76 6. SID/Label Binding Sub-TLV . . . . . . . . . . . . . . . . . . 13 77 6.1. ERO Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 14 78 6.2. ERO Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 15 79 6.2.1. IPv4 ERO Sub-TLV . . . . . . . . . . . . . . . . . . 15 80 6.2.2. Unnumbered Interface ID ERO Sub-TLV . . . . . . . . . 16 81 6.2.3. IPv4 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 17 82 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV . . . . . 18 83 7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 19 84 7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 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 . . 25 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 . . . . . . . . . . . . . . . . . . . . . . . . . 27 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. If 223 the SR-Algorithm Sub-TLV is advertised, Algorithm 0 MUST be 224 included. 226 1: Strict Shortest Path First (SPF) algorithm based on link 227 metric. The algorithm is identical to Algorithm 0 but 228 Algorithm 1 requires that all nodes along the path will honor 229 the SPF routing decision. Local policy at the node claiming 230 the support of Algorithm 1 MUST NOT alter the forwarding 231 decision computed by Algorithm 1. 233 The RI LSA can be advertised at any of the defined opaque flooding 234 scopes (link, area, or Autonomous System (AS)). For the purpose of 235 the SR-Algorithm TLV propagation, area scope flooding is required. 237 3.2. SID/Label Range TLV 239 The SID/Label Range TLV is a top-level TLV of the Router Information 240 Opaque LSA (defined in [RFC4970]). 242 The SID/Label Range TLV MAY appear multiple times and has the 243 following format: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Range Size | Reserved | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Sub-TLVs (variable) | 253 +- -+ 254 | | 255 + + 257 where: 259 Type: TBD, suggested value 9 261 Length: variable 263 Range Size: 3 octets of the SID/label range 265 Initially, the only supported Sub-TLV is the SID/Label TLV as defined 266 in Section 2.1. The SID/Label advertised in the SID/Label TLV 267 represents the first SID/Label in the advertised range. 269 Multiple occurrence of the SID/Label Range TLV MAY be advertised, in 270 order to advertise multiple ranges. In such case: 272 o The originating router MUST encode each range into a different 273 SID/Label Range TLV. 275 o The originating router decides the order in which the set of SID/ 276 Label Range TLVs are advertised inside the Router Information 277 Opaque LSA. The originating router MUST ensure the order is same 278 after a graceful restart (using checkpointing, non-volatile 279 storage or any other mechanism) in order to assure the SID/label 280 range and SID index correspondence is preserved across graceful 281 restarts. 283 o The receiving router must adhere to the order in which the ranges 284 are advertised when calculating a SID/label from a SID index. 286 The following example illustrates the advertisement of multiple 287 ranges: 289 The originating router advertises following ranges: 290 Range 1: [100, 199] 291 Range 2: [1000, 1099] 292 Range 3: [500, 599] 294 The receiving routers concatenate the ranges and build the Segment Routing Global Block 295 (SRGB) is as follows: 297 SRGB = [100, 199] 298 [1000, 1099] 299 [500, 599] 301 The indexes span multiple ranges: 303 index=0 means label 100 304 ... 305 index 99 means label 199 306 index 100 means label 1000 307 index 199 means label 1099 308 ... 309 index 200 means label 500 310 ... 312 The RI LSA can be advertised at any of the defined flooding scopes 313 (link, area, or autonomous system (AS)). For the purposes of the 314 SID/Label Range TLV propagation, area scope flooding is required. 316 4. OSPF Extended Prefix Range TLV 318 In some cases it is useful to advertise attributes for the range of 319 prefixes. Segment Routing Mapping Server, which is described in 320 [I-D.filsfils-spring-segment-routing-ldp-interop], is an example, 321 where we need a single advertisement to advertise SIDs for multiple 322 prefixes from a contiguous address range. 324 OSPF Extended Prefix Range TLV, which is a new top level TLV of the 325 Extended Prefix LSA described in [I-D.ietf-ospf-prefix-link-attr] is 326 defined for this purpose. 328 Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each 329 OSPF Extended Prefix Opaque LSA, but all prefix ranges included in a 330 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 331 scope. The OSPF Extended Prefix Range TLV has the following format: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Type | Length | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Prefix Length | AF | Range Size | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Flags | Reserved | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Address Prefix (variable) | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Sub-TLVs (variable) | 345 +- -+ 346 | | 348 where: 350 Type: TBD, suggested value 2. 352 Length: variable 354 Prefix length: length of the prefix 356 AF: 0 - IPv4 unicast 358 Range size: represents the number of prefixes that are covered by 359 the advertisement. The Range Size MUST NOT exceed the number of 360 prefixes that could be satisfied by the prefix length without 361 including the IPv4 multicast address range (224.0.0.0/3). 363 Flags: 1 octet field. The following flags are defined: 365 0 1 2 3 4 5 6 7 366 +--+--+--+--+--+--+--+--+ 367 |IA| | | | | | | | 368 +--+--+--+--+--+--+--+--+ 370 where: 372 IA-Flag: Inter-Area flag. If set, advertisement is of inter- 373 area type. ABR that is advertising the OSPF Extended Prefix 374 Range TLV between areas MUST set this bit. 376 This bit is used to prevent redundant flooding of Prefix Range 377 TLVs between areas as follows: 379 An ABR always prefers intra-area Prefix Range advertisement 380 over inter-area one. 382 An ABR does not consider inter-area Prefix Range 383 advertisements coming from non backbone area. 385 An ABR propagates inter-area Prefix Range advertisement from 386 backbone area to connected non backbone areas only if such 387 advertisement is considered to be the best one. 389 Address Prefix: the prefix, encoded as an even multiple of 32-bit 390 words, padded with zeroed bits as necessary. This encoding 391 consumes ((PrefixLength + 31) / 32) 32-bit words. The Address 392 Prefix represents the first prefix in the prefix range. 394 5. Prefix SID Sub-TLV 396 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV 397 described in [I-D.ietf-ospf-prefix-link-attr] and the OSPF Extended 398 Prefix Range TLV described in Section 4. It MAY appear more than 399 once in the parent TLV and has the following format: 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Type | Length | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Flags | Reserved | MT-ID | Algorithm | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | SID/Index/Label (variable) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 where: 413 Type: TBD, suggested value 2. 415 Length: variable 417 Flags: 1 octet field. The following flags are defined: 419 0 1 2 3 4 5 6 7 420 +--+--+--+--+--+--+--+--+ 421 | |NP|M |E |V |L | | | 422 +--+--+--+--+--+--+--+--+ 424 where: 426 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 427 NOT pop the Prefix-SID before delivering the packet to the node 428 that advertised the Prefix-SID. 430 M-Flag: Mapping Server Flag. If set, the SID is advertised 431 from the Segment Routing Mapping Server functionality as 432 described in [I-D.filsfils-spring-segment-routing-ldp-interop]. 434 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 435 the Prefix-SID originator MUST replace the Prefix-SID with a 436 Prefix-SID having an Explicit-NULL value (0 for IPv4) before 437 forwarding the packet. 439 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 440 an absolute value. If not set, then the Prefix-SID carries an 441 index. 443 L-Flag: Local/Global Flag. If set, then the value/index 444 carried by the Prefix-SID has local significance. If not set, 445 then the value/index carried by this Sub-TLV has global 446 significance. 448 Other bits: Reserved. These MUST be zero when sent and are 449 ignored when received. 451 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 453 Algorithm: one octet identifying the algorithm the Prefix-SID is 454 associated with as defined in Section 3.1. 456 SID/Index/Label: according to the V and L flags, it contains 457 either: 459 A 32 bit index defining the offset in the SID/Label space 460 advertised by this router. 462 A 24 bit label where the 20 rightmost bits are used for 463 encoding the label value. 465 If multiple Prefix-SIDs are advertised for the same prefix, the 466 receiving router MUST use the first encoded SID and MAY use the 467 subsequent SIDs. 469 When propagating Prefix-SIDs between areas, if multiple prefix-SIDs 470 are advertised for a prefix, an implementation SHOULD preserve the 471 original order when advertising prefix-SIDs to other areas. This 472 allows implementations that only support a single Prefix-SID to have 473 a consistent view across areas. 475 When calculating the outgoing label for the prefix, the router MUST 476 take into account E and P flags advertised by the next-hop router, if 477 next-hop router advertised the SID for the prefix. This MUST be done 478 regardless of whether the next-hop router contributes to the best 479 path to the prefix. 481 The NP-Flag (No-PHP) MUST be set on the Prefix-SIDs allocated to 482 inter-area prefixes that are originated by the ABR based on intra- 483 area or inter-area reachability between areas. When the inter-area 484 prefix is generated based on the prefix which is directly attached to 485 the ABR, NP-Flag SHOULD NOT be set 487 The NP-Flag (No-PHP) MUST be be set on the Prefix-SIDs allocated to 488 redistributed prefixes, unless the redistributed prefix is directly 489 attached to ASBR, in which case the NP-flag SHOULD NOT be set. 491 If the NP-Flag is not set then any upstream neighbor of the Prefix- 492 SID originator MUST pop the Prefix-SID. This is equivalent to the 493 penultimate hop popping mechanism used in the MPLS dataplane. In 494 such case, MPLS EXP bits of the Prefix-SID are not preserved for the 495 final destination (the Prefix-SID being removed). If the NP-flag is 496 clear then the received E-flag is ignored. 498 If the NP-flag is set then: 500 If the E-flag is not set then any upstream neighbor of the Prefix- 501 SID originator MUST keep the Prefix-SID on top of the stack. This 502 is useful when the originator of the Prefix-SID must stitch the 503 incoming packet into a continuing MPLS LSP to the final 504 destination. This could occur at an inter-area border router 505 (prefix propagation from one area to another) or at an inter- 506 domain border router (prefix propagation from one domain to 507 another). 509 If the E-flag is set then any upstream neighbor of the Prefix-SID 510 originator MUST replace the Prefix-SID with a Prefix-SID having an 511 Explicit-NULL value. This is useful, e.g., when the originator of 512 the Prefix-SID is the final destination for the related prefix and 513 the originator wishes to receive the packet with the original EXP 514 bits. 516 When M-Flag is set, NP-flag and E-flag MUST be ignored at reception. 518 As the Mapping Server does not specify the originator of a prefix 519 advertisement it is not possible to determine PHP behavior solely 520 based on the Mapping Server advertisement. However, PHP behavior may 521 safely be done in following cases: 523 Prefix is of intra-area type and the downstream neighbor is the 524 originator of the prefix. 526 Prefix is of inter-area type and downstream neighbor is an ABR, 527 which is advertising the prefix reachability and is also 528 generating the Extended Prefix TLV with A-flag set for this prefix 529 as described in section 2.1 of [I-D.ietf-ospf-prefix-link-attr]. 531 Prefix is of external type and downstream neighbor is an ASBR, 532 which is advertising the prefix reachability and is also 533 generating the Extended Prefix TLV with A-flag set for this prefix 534 as described in section 2.1 of [I-D.ietf-ospf-prefix-link-attr]. 536 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 537 the value advertised in Prefix SID Sub-TLV is interpreted as a 538 starting SID value. 540 Example 1: if the following router addresses (loopback addresses) 541 need to be mapped into the corresponding Prefix SID indexes: 543 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 544 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 545 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 546 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 548 then the Prefix field in the Extended Prefix Range TLV would be set 549 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 550 set to 4 and the Index value in the Prefix-SID Sub-TLV would be set 551 to 1. 553 Example 2: If the following prefixes need to be mapped into the 554 corresponding Prefix-SID indexes: 556 10.1.1/24, Prefix-SID: Index 51 557 10.1.2/24, Prefix-SID: Index 52 558 10.1.3/24, Prefix-SID: Index 53 559 10.1.4/24, Prefix-SID: Index 54 560 10.1.5/24, Prefix-SID: Index 55 561 10.1.6/24, Prefix-SID: Index 56 562 10.1.7/24, Prefix-SID: Index 57 564 then the Prefix field in the Extended Prefix Range TLV would be set 565 to 10.1.1.0, Prefix Length would be set to 24, Range Size would be 7 566 and the Index value in the Prefix-SID Sub-TLV would be set to 51. 568 6. SID/Label Binding Sub-TLV 570 The SID/Label Binding Sub-TLV is used to advertise a SID/Label 571 mapping for a path to the prefix. 573 The SID/Label Binding Sub-TLV MAY be originated by any router in an 574 OSPF domain. The router may advertise a SID/Label binding to a FEC 575 along with at least a single 'nexthop style' anchor. The protocol 576 supports more than one 'nexthop style' anchor to be attached to a 577 SID/Label binding, which results in a simple path description 578 language. In analogy to RSVP, the terminology for this is called an 579 'Explicit Route Object' (ERO). Since ERO style path notation allows 580 anchoring SID/label bindings to both link and node IP addresses, any 581 Label Switched Path (LSP) can be described. Additionally, SID/Label 582 Bindings from external protocols can be easily re-advertised. 584 The SID/Label Binding Sub-TLV may be used for advertising SID/Label 585 Bindings and their associated Primary and Backup paths. In a single 586 TLV, a primary ERO Path, backup ERO Path, or both can be advertised. 587 If a router wants to advertise multiple parallel paths, then it can 588 generate several TLVs for the same Prefix/FEC. Each occurrence of a 589 Binding TLV for a given FEC Prefix will add a new path. 591 The SID/Label Binding Sub-TLV is a Sub-TLV of the OSPF Extended 592 Prefix TLV described in [I-D.ietf-ospf-prefix-link-attr] and the OSPF 593 Extended Prefix Range TLV described in Section 4. Multiple SID/Label 594 Binding TLVs can be present in their parent TLV. The SID/Label 595 Binding Sub-TLV has following format: 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Type | Length | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Flags | Reserved | MT-ID | Weight | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Sub-TLVs (variable) | 605 +- -+ 606 | | 608 where: 610 Type: TBD, suggested value 3 612 Length: variable 614 Flags: 1 octet field of following flags: 616 0 1 2 3 4 5 6 7 617 +-+-+-+-+-+-+-+-+ 618 |M| | 619 +-+-+-+-+-+-+-+-+ 621 where: 623 M-bit - When the bit is set the binding represents the 624 mirroring context as defined in 625 [I-D.minto-rsvp-lsp-egress-fast-protection]. 627 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 629 Weight: weight used for load-balancing purposes. The use of the 630 weight is defined in [I-D.ietf-spring-segment-routing]. 632 The SID/Label Binding Sub-TLV supports the following Sub-TLVs: 634 SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST 635 appear in the SID/Label Binding Sub-TLV and it MUST only appear 636 once. 638 ERO Metric Sub-TLV as defined in Section 6.1. 640 ERO Sub-TLVs as defined in Section 6.2. 642 6.1. ERO Metric Sub-TLV 644 The ERO Metric Sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 646 The ERO Metric Sub-TLV advertises the cost of an ERO path. It is 647 used to compare the cost of a given source/destination path. A 648 router SHOULD advertise the ERO Metric Sub-TLV in an advertised ERO 649 TLV. The cost of the ERO Metric Sub-TLV SHOULD be set to the 650 cumulative IGP or TE path cost of the advertised ERO. Since 651 manipulation of the Metric field may attract or repel traffic to and 652 from the advertised segment, it MAY be manually overridden. 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Type | Length | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Metric (4 octets) | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 ERO Metric Sub-TLV format 664 where: 666 Type: TBD, suggested value 8 668 Length: Always 4 670 Metric: A 4 octet metric representing the aggregate IGP or TE path 671 cost. 673 6.2. ERO Sub-TLVs 675 All 'ERO' information represents an ordered set which describes the 676 segments of a path. The first ERO Sub-TLV describes the first 677 segment of a path. Similiarly, the last ERO Sub-TLV describes the 678 segment closest to the egress point. If a router extends or stitches 679 a path, it MUST prepend the new segment's path information to the ERO 680 list. This applies equally to advertised backup EROs. 682 All ERO Sub-TLVs must immediately follow the (SID)/Label Sub-TLV. 684 All Backup ERO Sub-TLVs must immediately follow the last ERO Sub-TLV. 686 6.2.1. IPv4 ERO Sub-TLV 688 IPv4 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 690 The IPv4 ERO Sub-TLV describes a path segment using IPv4 Address 691 style encoding. Its semantics have been borrowed from [RFC3209]. 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Type | Length | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Flags | Reserved | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | IPv4 Address (4 octets) | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 IPv4 ERO Sub-TLV format 705 where: 707 Type: TBD, suggested value 4 709 Length: 8 bytes 711 Flags: 1 octet field of following flags: 713 0 1 2 3 4 5 6 7 714 +-+-+-+-+-+-+-+-+ 715 |L| | 716 +-+-+-+-+-+-+-+-+ 718 where: 720 L-bit - If the L-bit is set, then the segment path is 721 designated as 'loose'. Otherwise, the segment path is 722 designated as 'strict'. 724 IPv4 Address - the address of the explicit route hop. 726 6.2.2. Unnumbered Interface ID ERO Sub-TLV 728 The Unnumbered Interface ID ERO Sub-TLV is a Sub-TLV of the SID/Label 729 Binding Sub-TLV. 731 The appearance and semantics of the 'Unnumbered Interface ID' have 732 been borrowed from [RFC3477]. 734 The Unnumbered Interface-ID ERO Sub-TLV describes a path segment that 735 includes an unnumbered interface. Unnumbered interfaces are 736 referenced using the interface index. Interface indices are assigned 737 local to the router and therefore not unique within a domain. All 738 elements in an ERO path need to be unique within a domain and hence 739 need to be disambiguated using a domain unique Router-ID. 741 0 1 2 3 742 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 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Type | Length | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Flags | Reserved | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Router ID | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Interface ID | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 where: 755 Unnumbered Interface ID ERO Sub-TLV format 757 Type: TBD, suggested value 5 759 Length: 12 bytes 760 Flags: 1 octet field of following flags: 762 0 1 2 3 4 5 6 7 763 +-+-+-+-+-+-+-+-+ 764 |L| | 765 +-+-+-+-+-+-+-+-+ 767 where: 769 L-bit - If the L-bit is set, then the segment path is 770 designated as 'loose'. Otherwise, the segment path is 771 designated as 'strict'. 773 Router-ID: Router-ID of the next-hop. 775 Interface ID: is the identifier assigned to the link by the router 776 specified by the Router-ID. 778 6.2.3. IPv4 Backup ERO Sub-TLV 780 IPv4 Prefix Backup ERO Sub-TLV is a Sub-TLV of the SID/Label Binding 781 Sub-TLV. 783 The IPv4 Backup ERO Sub-TLV describes a path segment using IPv4 784 Address style of encoding. Its semantics have been borrowed from 785 [RFC3209]. 787 0 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Type | Length | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Flags | Reserved | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | IPv4 Address (4 octets) | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 IPv4 Backup ERO Sub-TLV format 799 where: 801 Type: TBD, suggested value 6 803 Length: 8 bytes 805 Flags: 1 octet field of following flags: 807 0 1 2 3 4 5 6 7 808 +-+-+-+-+-+-+-+-+ 809 |L| | 810 +-+-+-+-+-+-+-+-+ 812 where: 814 L-bit - If the L-bit is set, then the segment path is 815 designated as 'loose'. Otherwise, the segment path is 816 designated as 'strict'. 818 IPv4 Address - the address of the explicit route hop. 820 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV 822 The Unnumbered Interface ID Backup ERO Sub-TLV is a Sub-TLV of the 823 SID/Label Binding Sub-TLV. 825 The appearance and semantics of the 'Unnumbered Interface ID' have 826 been borrowed from [RFC3477]. 828 The Unnumbered Interface-ID Backup ERO Sub-TLV describes a path 829 segment that includes an unnumbered interface. Unnumbered interfaces 830 are referenced using the interface index. Interface indices are 831 assigned local to the router and are therefore not unique within a 832 domain. All elements in an ERO path need to be unique within a 833 domain and hence need to be disambiguated with specification of the 834 domain unique Router-ID. 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Type | Length | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Flags | Reserved | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Router ID | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Interface ID | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 Unnumbered Interface ID Backup ERO Sub-TLV format 850 where: 852 Type: TBD, suggested value 7 854 Length: 12 bytes 855 Flags: 1 octet field of following flags: 857 0 1 2 3 4 5 6 7 858 +-+-+-+-+-+-+-+-+ 859 |L| | 860 +-+-+-+-+-+-+-+-+ 862 where: 864 L-bit - If the L-bit is set, then the segment path is 865 designated as 'loose'. Otherwise, the segment path is 866 designated as 'strict'. 868 Router-ID: Router-ID of the next-hop. 870 Interface ID: is the identifier assigned to the link by the router 871 specified by the Router-ID. 873 7. Adjacency Segment Identifier (Adj-SID) 875 An Adjacency Segment Identifier (Adj-SID) represents a router 876 adjacency in Segment Routing. 878 7.1. Adj-SID Sub-TLV 880 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 881 [I-D.ietf-ospf-prefix-link-attr]. It MAY appear multiple times in 882 the Extended Link TLV. Examples where more than one Adj-SID may be 883 used per neighbor are described in section 4 of 884 [I-D.filsfils-spring-segment-routing-use-cases]. The Adj-SID Sub-TLV 885 has the following format: 887 0 1 2 3 888 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 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Type | Length | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Flags | Reserved | MT-ID | Weight | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | SID/Label/Index (variable) | 895 +---------------------------------------------------------------+ 897 where: 899 Type: TBD, suggested value 2. 901 Length: variable. 903 Flags. 1 octet field of following flags: 905 0 1 2 3 4 5 6 7 906 +-+-+-+-+-+-+-+-+ 907 |B|V|L|S| | 908 +-+-+-+-+-+-+-+-+ 910 where: 912 B-Flag: Backup Flag. If set, the Adj-SID refers to an 913 adjacency that is eligible for protection (e.g.: using IPFRR or 914 MPLS-FRR) as described in section 3.5 of 915 [I-D.ietf-spring-segment-routing]. 917 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 918 an absolute value. If not set, then the Adj-SID carries an 919 index. 921 The L-Flag: Local/Global Flag. If set, then the value/index 922 carried by the Adj-SID has local significance. If not set, 923 then the value/index carried by this Sub-TLV has global 924 significance. 926 The S-Flag. Set Flag. When set, the S-Flag indicates that the 927 Adj-SID refers to a set of adjacencies (and therefore MAY be 928 assigned to other adjacencies as well). 930 Other bits: Reserved. These MUST be zero when sent and are 931 ignored when received. 933 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 935 Weight: weight used for load-balancing purposes. The use of the 936 weight is defined in [I-D.ietf-spring-segment-routing]. 938 SID/Index/Label: according to the V and L flags, it contains 939 either: 941 A 32 bit index defining the offset in the SID/Label space 942 advertised by this router. 944 A 24 bit label where the 20 rightmost bits are used for 945 encoding the label value. 947 An SR capable router MAY allocate an Adj-SID for each of its 948 adjacencies and set the B-Flag when the adjacency is eligible for 949 protection by an FRR mechanism (IP or MPLS) as described in section 950 3.5 of [I-D.ietf-spring-segment-routing]. 952 7.2. LAN Adj-SID Sub-TLV 954 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 955 in [I-D.ietf-ospf-prefix-link-attr]. It MAY appear multiple times in 956 the Extended-Link TLV. It is used to advertise a SID/Label for an 957 adjacency to a non-DR node on a broadcast or NBMA network. 959 0 1 2 3 960 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 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Type | Length | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Flags | Reserved | MT-ID | Weight | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Neighbor ID | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | SID/Label/Index (variable) | 969 +---------------------------------------------------------------+ 971 where: 973 Type: TBD, suggested value 3. 975 Length: variable. 977 Flags. 1 octet field of following flags: 979 0 1 2 3 4 5 6 7 980 +-+-+-+-+-+-+-+-+ 981 |B|V|L|S| | 982 +-+-+-+-+-+-+-+-+ 984 where: 986 B-Flag: Backup-flag: set if the LAN-Adj-SID refer to an 987 adjacency that is eligible for protection (e.g.: using IPFRR or 988 MPLS-FRR) as described in section 3.5 of 989 [I-D.ietf-spring-segment-routing]. 991 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 992 carries an absolute value. If not set, then the Prefix-SID 993 carries an index. 995 The L-Flag: Local/Global Flag. If set, then the value/index 996 carried by the Prefix-SID has local significance. If not set, 997 then the value/index carried by this Sub-TLV has global 998 significance. 1000 The S-Flag. Set Flag. When set, the S-Flag indicates that the 1001 Adj-SID refers to a set of adjacencies (and therefore MAY be 1002 assigned to other adjacencies as well). 1004 Other bits: Reserved. These MUST be zero when sent and are 1005 ignored when received. 1007 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1009 Weight: weight used for load-balancing purposes. The use of the 1010 weight is defined in [I-D.ietf-spring-segment-routing]. 1012 Neighbor ID: The Router ID of the neighbor for which the Adj-SID 1013 is advertised. 1015 SID/Index/Label: according to the V and L flags, it contains 1016 either: 1018 A 32 bit index defining the offset in the SID/Label space 1019 advertised by this router. 1021 A 24 bit label where the 20 rightmost bits are used for 1022 encoding the label value. 1024 8. Elements of Procedure 1026 8.1. Intra-area Segment routing in OSPFv2 1028 An OSPFv2 router that supports segment routing MAY advertise Prefix- 1029 SIDs for any prefix to which it is advertising reachability (e.g., a 1030 loopback IP address as described in Section 5). 1032 If multiple routers advertise a Prefix-SID for the same prefix, then 1033 the Prefix-SID MUST be the same. This is required in order to allow 1034 traffic load-balancing when multiple equal cost paths to the 1035 destination exist in the network. 1037 Prefix-SID can also be advertised by the SR Mapping Servers (as 1038 described in [I-D.filsfils-spring-segment-routing-ldp-interop]). The 1039 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 1040 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 1041 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 1042 MUST be advertised by all of them. The flooding scope of the OSPF 1043 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 1044 could be either area scoped or AS scoped and is determined based on 1045 the configuration of the SR Mapping Server. 1047 SR Mapping Server MUST use OSPF Extended Prefix Range TLV when 1048 advertising SIDs for prefixes. Prefixes of different route-types can 1049 be combined in a single OSPF Extended Prefix Range TLV advertised by 1050 the SR Mapping Server. 1052 Area scoped OSPF Extended Prefix Range TLV are propagated between 1053 areas. Similar to propagation of prefixes between areas, ABR only 1054 propagates the OSPF Extended Prefix Range TLV that it considers to be 1055 the best from the set it received. The rules used to pick the best 1056 OSPF Extended Prefix Range TLV is described in Section 4. 1058 When propagating OSPF Extended Prefix Range TLV between areas, ABR 1059 MUST set the IA-Flag, that is used to prevent redundant flooding of 1060 the OSPF Extended Prefix Range TLV between areas as described in 1061 Section 4. 1063 If the Prefix-SID that is advertised in Prefix SID Sub-TLV is also 1064 covered by the OSPF Extended Prefix Range TLV, the Prefix-SID 1065 advertised in Prefix SID Sub-TLV MUST be preferred. 1067 8.2. Inter-area Segment routing in OSPFv2 1069 In order to support SR in a multi-area environment, OSPFv2 must 1070 propagate Prefix-SID information between areas. The following 1071 procedure is used in order to propagate Prefix SIDs between areas. 1073 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 1074 prefix to all its connected areas, it will also originate an Extended 1075 Prefix Opaque LSA, as described in [I-D.ietf-ospf-prefix-link-attr]. 1076 The flooding scope of the Extended Prefix Opaque LSA type will be set 1077 to area-scope. The route-type in the OSPF Extended Prefix TLV is set 1078 to inter-area. The Prefix-SID Sub-TLV will be included in this LSA 1079 and the Prefix-SID value will be set as follows: 1081 The ABR will look at its best path to the prefix in the source 1082 area and find the advertising router associated with the best path 1083 to that prefix. 1085 The ABR will then determine if such router advertised a Prefix-SID 1086 for the prefix and use it when advertising the Prefix-SID to other 1087 connected areas. 1089 If no Prefix-SID was advertised for the prefix in the source area 1090 by the router that contributes to the best path to the prefix, the 1091 originating ABR will use the Prefix-SID advertised by any other 1092 router when propagating the Prefix-SID for the prefix to other 1093 areas. 1095 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 1096 route to all its connected areas it will also originate an Extended 1097 Prefix Opaque LSA, as described in [I-D.ietf-ospf-prefix-link-attr]. 1098 The flooding scope of the Extended Prefix Opaque LSA type will be set 1099 to area-scope. The route-type in OSPF Extended Prefix TLV is set to 1100 inter-area. The Prefix-SID Sub-TLV will be included in this LSA and 1101 the Prefix-SID will be set as follows: 1103 The ABR will look at its best path to the prefix in the source 1104 area and find the advertising router associated with the best path 1105 to that prefix. 1107 The ABR will then determine if such router advertised a Prefix-SID 1108 for the prefix and use it when advertising the Prefix-SID to other 1109 connected areas. 1111 If no Prefix-SID was advertised for the prefix in the source area 1112 by the ABR that contributes to the best path to the prefix, the 1113 originating ABR will use the Prefix-SID advertised by any other 1114 router when propagating the Prefix-SID for the prefix to other 1115 areas. 1117 8.3. SID for External Prefixes 1119 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1120 SR, generates Type-5 LSAs, it should also originate an Extended 1121 Prefix Opaque LSAs, as described in [I-D.ietf-ospf-prefix-link-attr]. 1122 The flooding scope of the Extended Prefix Opaque LSA type is set to 1123 AS-scope. The route-type in the OSPF Extended Prefix TLV is set to 1124 external. The Prefix-SID Sub-TLV is included in this LSA and the 1125 Prefix-SID value will be set to the SID that has been reserved for 1126 that prefix. 1128 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 1129 also advertise the Prefix-SID for the prefix. The NSSA ABR 1130 determines its best path to the prefix advertised in the translated 1131 Type-7 LSA and finds the advertising router associated with that 1132 path. If the advertising router has advertised a Prefix-SID for the 1133 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 1134 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 1135 router will be used. 1137 8.4. Advertisement of Adj-SID 1139 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1140 using the Adj-SID Sub-TLV as described in Section 7. 1142 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 1144 An Adj-SID MAY be advertised for any adjacency on a p2p link that is 1145 in neighbor state 2-Way or higher. If the adjacency on a p2p link 1146 transitions from the FULL state, then the Adj-SID for that adjacency 1147 MAY be removed from the area. If the adjacency transitions to a 1148 state lower then 2-Way, then the Adj-SID advertisement MUST be 1149 removed from the area. 1151 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1153 Broadcast or NBMA networks in OSPF are represented by a star topology 1154 where the Designated Router (DR) is the central point to which all 1155 other routers on the broadcast or NBMA network connect. As a result, 1156 routers on the broadcast or NBMA network advertise only their 1157 adjacency to the DR. Routers that do not act as DR do not form or 1158 advertise adjacencies with each other. They do, however, maintain 1159 2-Way adjacency state with each other and are directly reachable. 1161 When Segment Routing is used, each router on the broadcast or NBMA 1162 network MAY advertise the Adj-SID for its adjacency to the DR using 1163 Adj-SID Sub-TLV as described in Section 7.1. 1165 SR capable routers MAY also advertise an Adj-SID for other neighbors 1166 (e.g. BDR, DR-OTHER) on the broadcast or NBMA network using the LAN 1167 ADJ-SID Sub-TLV as described in Section 7.2. 1169 9. IANA Considerations 1171 This specification updates several existing OSPF registries. 1173 9.1. OSPF OSPF Router Information (RI) TLVs Registry 1175 o 8 (IANA Preallocated) - SR-Algorithm TLV 1177 o 9 (IANA Preallocated) - SID/Label Range TLV 1179 9.2. OSPF Extended Prefix LSA TLV Registry 1181 Following values are allocated: 1183 o 2 - OSPF Extended Prefix Range TLV 1185 9.3. OSPF Extended Prefix LSA Sub-TLV Registry 1187 Following values are allocated: 1189 o 1 - SID/Label Sub-TLV 1190 o 2 - Prefix SID Sub-TLV 1192 o 3 - SID/Label Binding Sub-TLV 1194 o 4 - IPv4 ERO Sub-TLV 1196 o 5 - Unnumbered Interface ID ERO Sub-TLV 1198 o 6 - IPv4 Backup ERO Sub-TLV 1200 o 7 - Unnumbered Interface ID Backup ERO Sub-TLV 1202 o 8 - ERO Metric Sub-TLV 1204 9.4. OSPF Extended Link LSA Sub-TLV Registry 1206 Following initial values are allocated: 1208 o 1 - SID/Label Sub-TLV 1210 o 2 - Adj-SID Sub-TLV 1212 o 3 - LAN Adj-SID/Label Sub-TLV 1214 10. Security Considerations 1216 Implementations must assure that malformed TLV and Sub-TLV 1217 permutations do not result in errors which cause hard OSPF failures. 1219 11. Contributors 1221 The following people gave a substantial contribution to the content 1222 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1223 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1224 Saku Ytti. 1226 12. Acknowledgements 1228 We would like to thank Anton Smirnov for his contribution. 1230 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1231 contribution on earlier incarnations of the "Binding / MPLS Label 1232 TLV" in [I-D.gredler-ospf-label-advertisement]. 1234 Thanks to Acee Lindem for the detail review of the draft, 1235 corrections, as well as discussion about details of the encoding. 1237 13. References 1239 13.1. Normative References 1241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1242 Requirement Levels", BCP 14, RFC 2119, 1243 DOI 10.17487/RFC2119, March 1997, 1244 . 1246 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1247 DOI 10.17487/RFC2328, April 1998, 1248 . 1250 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1251 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1252 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1253 . 1255 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1256 in Resource ReSerVation Protocol - Traffic Engineering 1257 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1258 . 1260 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1261 (TE) Extensions to OSPF Version 2", RFC 3630, 1262 DOI 10.17487/RFC3630, September 2003, 1263 . 1265 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1266 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1267 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1268 . 1270 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1271 S. Shaffer, "Extensions to OSPF for Advertising Optional 1272 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 1273 2007, . 1275 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1276 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 1277 July 2008, . 1279 13.2. Informative References 1281 [I-D.filsfils-spring-segment-routing-ldp-interop] 1282 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1283 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1284 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1285 "Segment Routing interoperability with LDP", draft- 1286 filsfils-spring-segment-routing-ldp-interop-02 (work in 1287 progress), September 2014. 1289 [I-D.filsfils-spring-segment-routing-use-cases] 1290 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1291 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1292 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1293 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1294 spring-segment-routing-use-cases-01 (work in progress), 1295 October 2014. 1297 [I-D.gredler-ospf-label-advertisement] 1298 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1299 "Advertising MPLS labels in OSPF", draft-gredler-ospf- 1300 label-advertisement-03 (work in progress), May 2013. 1302 [I-D.ietf-ospf-prefix-link-attr] 1303 Psenak, P., Gredler, H., rjs@rob.sh, r., Henderickx, W., 1304 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1305 Advertisement", draft-ietf-ospf-prefix-link-attr-13 (work 1306 in progress), August 2015. 1308 [I-D.ietf-spring-segment-routing] 1309 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1310 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1311 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 1312 spring-segment-routing-00 (work in progress), December 1313 2014. 1315 [I-D.minto-rsvp-lsp-egress-fast-protection] 1316 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1317 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1318 protection-03 (work in progress), November 2013. 1320 Authors' Addresses 1321 Peter Psenak (editor) 1322 Cisco Systems, Inc. 1323 Apollo Business Center 1324 Mlynske nivy 43 1325 Bratislava 821 09 1326 Slovakia 1328 Email: ppsenak@cisco.com 1330 Stefano Previdi (editor) 1331 Cisco Systems, Inc. 1332 Via Del Serafico, 200 1333 Rome 00142 1334 Italy 1336 Email: sprevidi@cisco.com 1338 Clarence Filsfils 1339 Cisco Systems, Inc. 1340 Brussels 1341 Belgium 1343 Email: cfilsfil@cisco.com 1345 Hannes Gredler 1346 Individual 1347 Austria 1349 Email: hannes@gredler.at 1351 Rob Shakir 1352 Jive Communications, Inc. 1353 1275 West 1600 North, Suite 100 1354 Orem, UT 84057 1355 US 1357 Email: rrjs@rob.sh 1358 Wim Henderickx 1359 Alcatel-Lucent 1360 Copernicuslaan 50 1361 Antwerp 2018 1362 BE 1364 Email: wim.henderickx@alcatel-lucent.com 1366 Jeff Tantsura 1367 Ericsson 1368 300 Holger Way 1369 San Jose, CA 95134 1370 US 1372 Email: Jeff.Tantsura@ericsson.com