idnits 2.17.00 (12 Aug 2021) /tmp/idnits13776/draft-ietf-ospf-segment-routing-extensions-03.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 (December 2, 2014) is 2727 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 1200, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 1210, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: draft-ietf-ospf-prefix-link-attr has been published as RFC 7684 Summary: 2 errors (**), 0 flaws (~~), 5 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: June 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 December 2, 2014 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-03 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 June 5, 2015. 51 Copyright Notice 53 Copyright (c) 2014 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 . . . . . . . . . . 22 89 8.3. SID for External Prefixes . . . . . . . . . . . . . . . . 23 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 . . . . 24 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . 25 98 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . . 27 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.filsfils-rtgwg-segment-routing]. 129 Segment Routing use cases are described in 130 [I-D.filsfils-rtgwg-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-rtgwg-segment-routing] is an example, where we need a 308 single advertisement to advertise SIDs for multiple prefixes from a 309 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 |N |NP|M |E |V |L | | | 409 +--+--+--+--+--+--+--+--+ 411 where: 413 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 414 the router identified by the prefix. Typically, the N-Flag is 415 set to Prefix-SIDs corresponding to a router loopback address. 416 The N-Flag is set when the Prefix-SID is a Node-SID, as 417 described in [I-D.filsfils-rtgwg-segment-routing]. 419 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 420 NOT pop the Prefix-SID before delivering the packet to the node 421 that advertised the Prefix-SID. 423 M-Flag: Mapping Server Flag. If set, the SID is advertised 424 from the Segment Routing Mapping Server functionality as 425 described in [I-D.filsfils-rtgwg-segment-routing]. 427 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 428 the Prefix-SID originator MUST replace the Prefix-SID with a 429 Prefix-SID having an Explicit-NULL value (0 for IPv4) before 430 forwarding the packet. 432 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 433 an absolute value. If not set, then the Prefix-SID carries an 434 index. 436 L-Flag: Local/Global Flag. If set, then the value/index 437 carried by the Prefix-SID has local significance. If not set, 438 then the value/index carried by this Sub-TLV has global 439 significance. 441 Other bits: Reserved. These MUST be zero when sent and are 442 ignored when received. 444 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 446 Algorithm: one octet identifying the algorithm the Prefix-SID is 447 associated with as defined in Section 3.1. 449 SID/Index/Label: according to the V and L flags, it contains 450 either: 452 A 32 bit index defining the offset in the SID/Label space 453 advertised by this router. 455 A 24 bit label where the 20 rightmost bits are used for 456 encoding the label value. 458 If multiple Prefix-SIDs are advertised for the same prefix, the 459 receiving router MUST use the first encoded SID and MAY use the 460 subsequent SIDs. 462 When propagating Prefix-SIDs between areas, if multiple prefix-SIDs 463 are advertised for a prefix, an implementation SHOULD preserve the 464 original order when advertising prefix-SIDs to other areas. This 465 allows implementations that only support a single Prefix-SID to have 466 a consistent view across areas. 468 When calculating the outgoing label for the prefix, the router MUST 469 take into account E and P flags advertised by the next-hop router, if 470 next-hop router advertised the SID for the prefix. This MUST be done 471 regardless of whether the next-hop router contributes to the best 472 path to the prefix. 474 The NP-Flag (No-PHP) MUST be set on the Prefix-SIDs allocated to 475 inter-area prefixes that are originated by the ABR based on intra- 476 area or inter-area reachability between areas. When the inter-area 477 prefix is generated based on the prefix which is directly attached to 478 the ABR, NP-Flag SHOULD NOT be set 480 The NP-Flag (No-PHP) MUST be be set on the Prefix-SIDs allocated to 481 redistributed prefixes, unless the redistributed prefix is directly 482 attached to ASBR, in which case the NP-flag SHOULD NOT be set. 484 If the NP-Flag is not set then any upstream neighbor of the Prefix- 485 SID originator MUST pop the Prefix-SID. This is equivalent to the 486 penultimate hop popping mechanism used in the MPLS dataplane. In 487 such case, MPLS EXP bits of the Prefix-SID are not preserved for the 488 final destination (the Prefix-SID being removed). If the NP-flag is 489 clear then the received E-flag is ignored. 491 If the NP-flag is set then: 493 If the E-flag is not set then any upstream neighbor of the Prefix- 494 SID originator MUST keep the Prefix-SID on top of the stack. This 495 is useful when the originator of the Prefix-SID must stitch the 496 incoming packet into a continuing MPLS LSP to the final 497 destination. This could occur at an inter-area border router 498 (prefix propagation from one area to another) or at an inter- 499 domain border router (prefix propagation from one domain to 500 another). 502 If the E-flag is set then any upstream neighbor of the Prefix-SID 503 originator MUST replace the Prefix-SID with a Prefix-SID having an 504 Explicit-NULL value. This is useful, e.g., when the originator of 505 the Prefix-SID is the final destination for the related prefix and 506 the originator wishes to receive the packet with the original EXP 507 bits. 509 When M-Flag is set, NP-flag MUST be set and E-bit MUST NOT be set. 511 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 512 the value advertised in Prefix SID Sub-TLV is interpreted as a 513 starting SID value. 515 Example 1: if the following router addresses (loopback addresses) 516 need to be mapped into the corresponding Prefix SID indexes: 518 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 519 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 520 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 521 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 523 then the Prefix field in the Extended Prefix Range TLV would be set 524 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 525 set to 4 and the Index value in the Prefix-SID Sub-TLV would be set 526 to 1. 528 Example 2: If the following prefixes need to be mapped into the 529 corresponding Prefix-SID indexes: 531 10.1.1/24, Prefix-SID: Index 51 532 10.1.2/24, Prefix-SID: Index 52 533 10.1.3/24, Prefix-SID: Index 53 534 10.1.4/24, Prefix-SID: Index 54 535 10.1.5/24, Prefix-SID: Index 55 536 10.1.6/24, Prefix-SID: Index 56 537 10.1.7/24, Prefix-SID: Index 57 539 then the Prefix field in the Extended Prefix Range TLV would be set 540 to 10.1.1.0, Prefix Length would be set to 24, Range Size would be 7 541 and the Index value in the Prefix-SID Sub-TLV would be set to 51. 543 6. SID/Label Binding Sub-TLV 545 The SID/Label Binding Sub-TLV is used to advertise a SID/Label 546 mapping for a path to the prefix. 548 The SID/Label Binding TLV MAY be originated by any router in an OSPF 549 domain. The router may advertise a SID/Label binding to a FEC along 550 with at least a single 'nexthop style' anchor. The protocol supports 551 more than one 'nexthop style' anchor to be attached to a SID/Label 552 binding, which results in a simple path description language. In 553 analogy to RSVP, the terminology for this is called an 'Explicit 554 Route Object' (ERO). Since ERO style path notation allows anchoring 555 SID/label bindings to both link and node IP addresses, any Label 556 Switched Path (LSP) can be described. Additionally, SID/Label 557 Bindings from external protocols can be easily re-advertised. 559 The SID/Label Binding TLV may be used for advertising SID/Label 560 Bindings and their associated Primary and Backup paths. In a single 561 TLV, a primary ERO Path, backup ERO Path, or both can be advertised. 562 If a router wants to advertise multiple parallel paths, then it can 563 generate several TLVs for the same Prefix/FEC. Each occurrence of a 564 Binding TLV for a given FEC Prefix will add a new path. 566 The SID/Label Binding Sub-TLV is a Sub-TLV of the OSPF Extended 567 Prefix TLV described in [I-D.ietf-ospf-prefix-link-attr] and the OSPF 568 Extended Prefix Range TLV described in Section 4. Multiple SID/Label 569 Binding TLVs can be present in their parent TLV. The SID/Label 570 Binding Sub-TLV has following format: 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Type | Length | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Flags | Reserved | MT-ID | Weight | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Sub-TLVs (variable) | 580 +- -+ 581 | | 583 where: 585 Type: TBD, suggested value 3 587 Length: variable 589 Flags: 1 octet field of following flags: 591 0 1 2 3 4 5 6 7 592 +-+-+-+-+-+-+-+-+ 593 |M| | 594 +-+-+-+-+-+-+-+-+ 596 where: 598 M-bit - When the bit is set the binding represents the 599 mirroring context as defined in 600 [I-D.minto-rsvp-lsp-egress-fast-protection]. 602 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 604 Weight: weight used for load-balancing purposes. The use of the 605 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 607 The SID/Label Binding TLV supports the following Sub-TLVs: 609 SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST 610 appear in the SID/Label Binding Sub-TLV and it MUST only appear 611 once. 613 ERO Metric Sub-TLV as defined in Section 6.1. 615 ERO Sub-TLVs as defined in Section 6.2. 617 6.1. ERO Metric Sub-TLV 619 The ERO Metric Sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 621 The ERO Metric Sub-TLV advertises the cost of an ERO path. It is 622 used to compare the cost of a given source/destination path. A 623 router SHOULD advertise the ERO Metric Sub-TLV in an advertised ERO 624 TLV. The cost of the ERO Metric Sub-TLV SHOULD be set to the 625 cumulative IGP or TE path cost of the advertised ERO. Since 626 manipulation of the Metric field may attract or repel traffic to and 627 from the advertised segment, it MAY be manually overridden. 629 0 1 2 3 630 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 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Type | Length | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Metric (4 octets) | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 ERO Metric Sub-TLV format 639 where: 641 Type: TBD, suggested value 8 643 Length: Always 4 645 Metric: A 4 octet metric representing the aggregate IGP or TE path 646 cost. 648 6.2. ERO Sub-TLVs 650 All 'ERO' information represents an ordered set which describes the 651 segments of a path. The first ERO Sub-TLV describes the first 652 segment of a path. Similiarly, the last ERO Sub-TLV describes the 653 segment closest to the egress point. If a router extends or stitches 654 a path, it MUST prepend the new segment's path information to the ERO 655 list. This applies equally to advertised backup EROs. 657 All ERO Sub-TLVs must immediately follow the (SID)/Label Sub-TLV. 659 All Backup ERO Sub-TLVs must immediately follow the last ERO Sub-TLV. 661 6.2.1. IPv4 ERO Sub-TLV 663 IPv4 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 665 The IPv4 ERO Sub-TLV describes a path segment using IPv4 Address 666 style encoding. Its semantics have been borrowed from [RFC3209]. 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Type | Length | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Flags | Reserved | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | IPv4 Address (4 octets) | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 IPv4 ERO Sub-TLV format 680 where: 682 Type: TBD, suggested value 4 684 Length: 8 bytes 686 Flags: 1 octet field of following flags: 688 0 1 2 3 4 5 6 7 689 +-+-+-+-+-+-+-+-+ 690 |L| | 691 +-+-+-+-+-+-+-+-+ 693 where: 695 L-bit - If the L-bit is set, then the segment path is 696 designated as 'loose'. Otherwise, the segment path is 697 designated as 'strict'. 699 IPv4 Address - the address of the explicit route hop. 701 6.2.2. Unnumbered Interface ID ERO Sub-TLV 703 The Unnumbered Interface ID ERO Sub-TLV is a Sub-TLV of the SID/Label 704 Binding Sub-TLV. 706 The appearance and semantics of the 'Unnumbered Interface ID' have 707 been borrowed from [RFC3477]. 709 The Unnumbered Interface-ID ERO Sub-TLV describes a path segment that 710 includes an unnumbered interface. Unnumbered interfaces are 711 referenced using the interface index. Interface indices are assigned 712 local to the router and therefore not unique within a domain. All 713 elements in an ERO path need to be unique within a domain and hence 714 need to be disambiguated using a domain unique Router-ID. 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Type | Length | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Flags | Reserved | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Router ID | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Interface ID | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 where: 730 Unnumbered Interface ID ERO Sub-TLV format 732 Type: TBD, suggested value 5 734 Length: 12 bytes 736 Flags: 1 octet field of following flags: 738 0 1 2 3 4 5 6 7 739 +-+-+-+-+-+-+-+-+ 740 |L| | 741 +-+-+-+-+-+-+-+-+ 743 where: 745 L-bit - If the L-bit is set, then the segment path is 746 designated as 'loose'. Otherwise, the segment path is 747 designated as 'strict'. 749 Router-ID: Router-ID of the next-hop. 751 Interface ID: is the identifier assigned to the link by the router 752 specified by the Router-ID. 754 6.2.3. IPv4 Backup ERO Sub-TLV 756 IPv4 Prefix Backup ERO Sub-TLV is a Sub-TLV of the SID/Label Binding 757 Sub-TLV. 759 The IPv4 Backup ERO Sub-TLV describes a path segment using IPv4 760 Address style of encoding. Its semantics have been borrowed from 761 [RFC3209]. 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Type | Length | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Flags | Reserved | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | IPv4 Address (4 octets) | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 IPv4 Backup ERO Sub-TLV format 775 where: 777 Type: TBD, suggested value 6 779 Length: 8 bytes 781 Flags: 1 octet field of following flags: 783 0 1 2 3 4 5 6 7 784 +-+-+-+-+-+-+-+-+ 785 |L| | 786 +-+-+-+-+-+-+-+-+ 788 where: 790 L-bit - If the L-bit is set, then the segment path is 791 designated as 'loose'. Otherwise, the segment path is 792 designated as 'strict'. 794 IPv4 Address - the address of the explicit route hop. 796 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV 798 The Unnumbered Interface ID Backup ERO Sub-TLV is a Sub-TLV of the 799 SID/Label Binding Sub-TLV. 801 The appearance and semantics of the 'Unnumbered Interface ID' have 802 been borrowed from [RFC3477]. 804 The Unnumbered Interface-ID Backup ERO Sub-TLV describes a path 805 segment that includes an unnumbered interface. Unnumbered interfaces 806 are referenced using the interface index. Interface indices are 807 assigned local to the router and are therefore not unique within a 808 domain. All elements in an ERO path need to be unique within a 809 domain and hence need to be disambiguated with specification of the 810 domain unique Router-ID. 812 0 1 2 3 813 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 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Type | Length | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Flags | Reserved | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Router ID | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Interface ID | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 Unnumbered Interface ID Backup ERO Sub-TLV format 826 where: 828 Type: TBD, suggested value 7 830 Length: 12 bytes 832 Flags: 1 octet field of following flags: 834 0 1 2 3 4 5 6 7 835 +-+-+-+-+-+-+-+-+ 836 |L| | 837 +-+-+-+-+-+-+-+-+ 839 where: 841 L-bit - If the L-bit is set, then the segment path is 842 designated as 'loose'. Otherwise, the segment path is 843 designated as 'strict'. 845 Router-ID: Router-ID of the next-hop. 847 Interface ID: is the identifier assigned to the link by the router 848 specified by the Router-ID. 850 7. Adjacency Segment Identifier (Adj-SID) 852 An Adjacency Segment Identifier (Adj-SID) represents a router 853 adjacency in Segment Routing. 855 7.1. Adj-SID Sub-TLV 857 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 858 [I-D.ietf-ospf-prefix-link-attr]. It MAY appear multiple times in 859 the Extended Link TLV. Examples where more than one Adj-SID may be 860 used per neighbor are described in 861 [I-D.filsfils-rtgwg-segment-routing-use-cases]. The Adj-SID Sub-TLV 862 has the following format: 864 0 1 2 3 865 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 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Type | Length | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Flags | Reserved | MT-ID | Weight | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | SID/Label/Index (variable) | 872 +---------------------------------------------------------------+ 874 where: 876 Type: TBD, suggested value 2. 878 Length: variable. 880 Flags. 1 octet field of following flags: 882 0 1 2 3 4 5 6 7 883 +-+-+-+-+-+-+-+-+ 884 |B|V|L|S| | 885 +-+-+-+-+-+-+-+-+ 887 where: 889 B-Flag: Backup Flag. If set, the Adj-SID refers to an 890 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 891 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 893 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 894 carries an absolute value. If not set, then the Prefix-SID 895 carries an index. 897 The L-Flag: Local/Global Flag. If set, then the value/index 898 carried by the Prefix-SID has local significance. If not set, 899 then the value/index carried by this Sub-TLV has global 900 significance. 902 The S-Flag. Set Flag. When set, the S-Flag indicates that the 903 Adj-SID refers to a set of adjacencies (and therefore MAY be 904 assigned to other adjacencies as well). 906 Other bits: Reserved. These MUST be zero when sent and are 907 ignored when received. 909 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 911 Weight: weight used for load-balancing purposes. The use of the 912 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 914 SID/Index/Label: according to the V and L flags, it contains 915 either: 917 A 32 bit index defining the offset in the SID/Label space 918 advertised by this router. 920 A 24 bit label where the 20 rightmost bits are used for 921 encoding the label value. 923 An SR capable router MAY allocate an Adj-SID for each of its 924 adjacencies and set the B-Flag when the adjacency is protected by an 925 FRR mechanism (IP or MPLS) as described in 926 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 928 7.2. LAN Adj-SID Sub-TLV 930 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 931 in [I-D.ietf-ospf-prefix-link-attr]. It MAY appear multiple times in 932 the Extended-Link TLV. It is used to advertise a SID/Label for an 933 adjacency to a non-DR node on a broadcast or NBMA network. 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Type | Length | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Flags | Reserved | MT-ID | Weight | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Neighbor ID | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | SID/Label/Index (variable) | 945 +---------------------------------------------------------------+ 947 where: 949 Type: TBD, suggested value 3. 951 Length: variable. 953 Flags. 1 octet field of following flags: 955 0 1 2 3 4 5 6 7 956 +-+-+-+-+-+-+-+-+ 957 |B|V|L|S| | 958 +-+-+-+-+-+-+-+-+ 960 where: 962 B-Flag: Backup-flag: set if the LAN-Adj-SID refer to an 963 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 964 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 966 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 967 carries an absolute value. If not set, then the Prefix-SID 968 carries an index. 970 The L-Flag: Local/Global Flag. If set, then the value/index 971 carried by the Prefix-SID has local significance. If not set, 972 then the value/index carried by this Sub-TLV has global 973 significance. 975 The S-Flag. Set Flag. When set, the S-Flag indicates that the 976 Adj-SID refers to a set of adjacencies (and therefore MAY be 977 assigned to other adjacencies as well). 979 Other bits: Reserved. These MUST be zero when sent and are 980 ignored when received. 982 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 984 Weight: weight used for load-balancing purposes. The use of the 985 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 987 SID/Index/Label: according to the V and L flags, it contains 988 either: 990 A 32 bit index defining the offset in the SID/Label space 991 advertised by this router. 993 A 24 bit label where the 20 rightmost bits are used for 994 encoding the label value. 996 8. Elements of Procedure 998 8.1. Intra-area Segment routing in OSPFv2 1000 An OSPFv2 router that supports segment routing MAY advertise Prefix- 1001 SIDs for any prefix to which it is advertising reachability (e.g., a 1002 loopback IP address as described in Section 5). 1004 If multiple routers advertise a Prefix-SID for the same prefix, then 1005 the Prefix-SID MUST be the same. This is required in order to allow 1006 traffic load-balancing when multiple equal cost paths to the 1007 destination exist in the network. 1009 Prefix-SID can also be advertised by the SR Mapping Servers (as 1010 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]). The 1011 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 1012 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 1013 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 1014 MUST be advertised by all of them. The flooding scope of the OSPF 1015 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 1016 could be either area scoped or AS scoped and is determined based on 1017 the configuration of the SR Mapping Server. 1019 8.2. Inter-area Segment routing in OSPFv2 1021 In order to support SR in a multi-area environment, OSPFv2 must 1022 propagate Prefix-SID information between areas. The following 1023 procedure is used in order to propagate Prefix SIDs between areas. 1025 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 1026 prefix to all its connected areas, it will also originate an Extended 1027 Prefix Opaque LSA, as described in [I-D.ietf-ospf-prefix-link-attr]. 1028 The flooding scope of the Extended Prefix Opaque LSA type will be set 1029 to area-scope. The route-type in the OSPF Extended Prefix TLV is set 1030 to inter-area. The Prefix-SID Sub-TLV will be included in this LSA 1031 and the Prefix-SID value will be set as follows: 1033 The ABR will look at its best path to the prefix in the source 1034 area and find the advertising router associated with the best path 1035 to that prefix. 1037 The ABR will then determine if such router advertised a Prefix-SID 1038 for the prefix and use it when advertising the Prefix-SID to other 1039 connected areas. 1041 If no Prefix-SID was advertised for the prefix in the source area 1042 by the router that contributes to the best path to the prefix, the 1043 originating ABR will use the Prefix-SID advertised by any other 1044 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 1045 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 1046 propagating the Prefix-SID for the prefix to other areas. 1048 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 1049 route to all its connected areas it will also originate an Extended 1050 Prefix Opaque LSA, as described in [I-D.ietf-ospf-prefix-link-attr]. 1051 The flooding scope of the Extended Prefix Opaque LSA type will be set 1052 to area-scope. The route-type in OSPF Extended Prefix TLV is set to 1053 inter-area. The Prefix-SID Sub-TLV will be included in this LSA and 1054 the Prefix-SID will be set as follows: 1056 The ABR will look at its best path to the prefix in the source 1057 area and find the advertising router associated with the best path 1058 to that prefix. 1060 The ABR will then determine if such router advertised a Prefix-SID 1061 for the prefix and use it when advertising the Prefix-SID to other 1062 connected areas. 1064 If no Prefix-SID was advertised for the prefix in the source area 1065 by the ABR that contributes to the best path to the prefix, the 1066 originating ABR will use the Prefix-SID advertised by any other 1067 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 1068 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 1069 propagating the Prefix-SID for the prefix to other areas. 1071 8.3. SID for External Prefixes 1073 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1074 SR, generates Type-5 LSAs, it should also originate an Extended 1075 Prefix Opaque LSAs, as described in [I-D.ietf-ospf-prefix-link-attr]. 1076 The flooding scope of the Extended Prefix Opaque LSA type is set to 1077 AS-scope. The route-type in the OSPF Extended Prefix TLV is set to 1078 external. The Prefix-SID Sub-TLV is included in this LSA and the 1079 Prefix-SID value will be set to the SID that has been reserved for 1080 that prefix. 1082 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 1083 also advertise the Prefix-SID for the prefix. The NSSA ABR 1084 determines its best path to the prefix advertised in the translated 1085 Type-7 LSA and finds the advertising router associated with that 1086 path. If the advertising router has advertised a Prefix-SID for the 1087 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 1088 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 1089 router will be used (e.g.: a Prefix-SID coming from an SR Mapping 1090 Server as defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]). 1092 8.4. Advertisement of Adj-SID 1094 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1095 using the Adj-SID Sub-TLV as described in Section 7. 1097 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 1099 An Adj-SID MAY be advertised for any adjacency on a p2p link that is 1100 in neighbor state 2-Way or higher. If the adjacency on a p2p link 1101 transitions from the FULL state, then the Adj-SID for that adjacency 1102 MAY be removed from the area. If the adjacency transitions to a 1103 state lower then 2-Way, then the Adj-SID advertisement MUST be 1104 removed from the area. 1106 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1108 Broadcast or NBMA networks in OSPF are represented by a star topology 1109 where the Designated Router (DR) is the central point to which all 1110 other routers on the broadcast or NBMA network connect. As a result, 1111 routers on the broadcast or NBMA network advertise only their 1112 adjacency to the DR. Routers that do not act as DR do not form or 1113 advertise adjacencies with each other. They do, however, maintain 1114 2-Way adjacency state with each other and are directly reachable. 1116 When Segment Routing is used, each router on the broadcast or NBMA 1117 network MAY advertise the Adj-SID for its adjacency to the DR using 1118 Adj-SID Sub-TLV as described in Section 7.1. 1120 SR capable routers MAY also advertise an Adj-SID for other neighbors 1121 (e.g. BDR, DR-OTHER) on the broadcast or NBMA network using the LAN 1122 ADJ-SID Sub-TLV as described in Section 7.2. 1124 9. IANA Considerations 1126 This specification updates several existing OSPF registries. 1128 9.1. OSPF OSPF Router Information (RI) TLVs Registry 1130 o 8 (IANA Preallocated) - SR-Algorithm TLV 1132 o 9 (IANA Preallocated) - SID/Label Range TLV 1134 9.2. OSPF Extended Prefix LSA TLV Registry 1136 Following values are allocated: 1138 o 2 - OSPF Extended Prefix Range TLV 1140 9.3. OSPF Extended Prefix LSA Sub-TLV Registry 1142 Following values are allocated: 1144 o 1 - SID/Label Sub-TLV 1146 o 2 - Prefix SID Sub-TLV 1148 o 3 - SID/Label Binding Sub-TLV 1150 o 4 - IPv4 ERO Sub-TLV 1152 o 5 - Unnumbered Interface ID ERO Sub-TLV 1154 o 6 - IPv4 Backup ERO Sub-TLV 1156 o 7 - Unnumbered Interface ID Backup ERO Sub-TLV 1158 o 8 - ERO Metric Sub-TLV 1160 9.4. OSPF Extended Link LSA Sub-TLV Registry 1162 Following initial values are allocated: 1164 o 1 - SID/Label Sub-TLV 1166 o 2 - Adj-SID Sub-TLV 1168 o 3 - LAN Adj-SID/Label Sub-TLV 1170 10. Security Considerations 1172 Implementations must assure that malformed TLV and Sub-TLV 1173 permutations do not result in errors which cause hard OSPF failures. 1175 11. Contributors 1177 The following people gave a substantial contribution to the content 1178 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1179 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1180 Saku Ytti. 1182 12. Acknowledgements 1184 We would like to thank Anton Smirnov for his contribution. 1186 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1187 contribution on earlier incarnations of the "Binding / MPLS Label 1188 TLV" in [I-D.gredler-ospf-label-advertisement]. 1190 Thanks to Acee Lindem for the detail review of the draft, 1191 corrections, as well as discussion about details of the encoding. 1193 13. References 1195 13.1. Normative References 1197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1198 Requirement Levels", BCP 14, RFC 2119, March 1997. 1200 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1202 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1203 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1204 Tunnels", RFC 3209, December 2001. 1206 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1207 in Resource ReSerVation Protocol - Traffic Engineering 1208 (RSVP-TE)", RFC 3477, January 2003. 1210 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1211 (TE) Extensions to OSPF Version 2", RFC 3630, September 1212 2003. 1214 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1215 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 1216 4915, June 2007. 1218 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1219 Shaffer, "Extensions to OSPF for Advertising Optional 1220 Router Capabilities", RFC 4970, July 2007. 1222 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1223 OSPF Opaque LSA Option", RFC 5250, July 2008. 1225 13.2. Informative References 1227 [I-D.filsfils-rtgwg-segment-routing] 1228 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1229 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1230 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1231 "Segment Routing Architecture", draft-filsfils-rtgwg- 1232 segment-routing-01 (work in progress), October 2013. 1234 [I-D.filsfils-rtgwg-segment-routing-use-cases] 1235 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1236 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1237 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1238 Crabbe, "Segment Routing Use Cases", draft-filsfils-rtgwg- 1239 segment-routing-use-cases-02 (work in progress), October 1240 2013. 1242 [I-D.gredler-ospf-label-advertisement] 1243 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1244 "Advertising MPLS labels in OSPF", draft-gredler-ospf- 1245 label-advertisement-03 (work in progress), May 2013. 1247 [I-D.ietf-ospf-prefix-link-attr] 1248 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1249 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1250 Advertisement", draft-ietf-ospf-prefix-link-attr-01 (work 1251 in progress), September 2014. 1253 [I-D.minto-rsvp-lsp-egress-fast-protection] 1254 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1255 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1256 protection-03 (work in progress), November 2013. 1258 Authors' Addresses 1260 Peter Psenak (editor) 1261 Cisco Systems, Inc. 1262 Apollo Business Center 1263 Mlynske nivy 43 1264 Bratislava 821 09 1265 Slovakia 1267 Email: ppsenak@cisco.com 1268 Stefano Previdi (editor) 1269 Cisco Systems, Inc. 1270 Via Del Serafico, 200 1271 Rome 00142 1272 Italy 1274 Email: sprevidi@cisco.com 1276 Clarence Filsfils 1277 Cisco Systems, Inc. 1278 Brussels 1279 Belgium 1281 Email: cfilsfil@cisco.com 1283 Hannes Gredler 1284 Juniper Networks, Inc. 1285 1194 N. Mathilda Ave. 1286 Sunnyvale, CA 94089 1287 US 1289 Email: hannes@juniper.net 1291 Rob Shakir 1292 British Telecom 1293 London 1294 UK 1296 Email: rob.shakir@bt.com 1298 Wim Henderickx 1299 Alcatel-Lucent 1300 Copernicuslaan 50 1301 Antwerp 2018 1302 BE 1304 Email: wim.henderickx@alcatel-lucent.com 1305 Jeff Tantsura 1306 Ericsson 1307 300 Holger Way 1308 San Jose, CA 95134 1309 US 1311 Email: Jeff.Tantsura@ericsson.com