idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-02.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 (August 15, 2014) is 3542 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 1172, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 1182, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: A later version (-13) exists of draft-ietf-ospf-prefix-link-attr-00 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: February 16, 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 August 15, 2014 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-02 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 February 16, 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 . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . 15 81 6.2.3. IPv4 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 17 82 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV . . . . . 17 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 | Address Prefix (variable) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Sub-TLVs (variable) | 330 +- -+ 331 | | 333 where: 335 Type: TBD, suggested value 2. 337 Length: variable 339 Prefix length: length of the prefix 341 AF: 0 - IPv4 unicast 343 Range size: represents the number of prefixes that are covered by 344 the advertisement. The Range Size MUST NOT exceed the number of 345 prefixes that could be satisfied by the prefix length without 346 including the IPv4 multicast address range (224.0.0.0/3). 348 Address Prefix: the prefix, encoded as an even multiple of 32-bit 349 words, padded with zeroed bits as necessary. This encoding 350 consumes ((PrefixLength + 31) / 32) 32-bit words. The Address 351 Prefix represents the first prefix in the prefix range. 353 5. Prefix SID Sub-TLV 355 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV 356 described in [I-D.ietf-ospf-prefix-link-attr] and the OSPF Extended 357 Prefix Range TLV described in Section 4. It MAY appear more than 358 once in the parent TLV and has the following format: 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type | Length | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Flags | Reserved | MT-ID | Algorithm | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | SID/Index/Label (variable) | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 where: 372 Type: TBD, suggested value 2. 374 Length: variable 376 Flags: 1 octet field. The following flags are defined: 378 0 1 2 3 4 5 6 7 379 +--+--+--+--+--+--+--+--+ 380 |N |NP|M |E |V |L | | | 381 +--+--+--+--+--+--+--+--+ 383 where: 385 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 386 the router identified by the prefix. Typically, the N-Flag is 387 set to Prefix-SIDs corresponding to a router loopback address. 388 The N-Flag is set when the Prefix-SID is a Node-SID, as 389 described in [I-D.filsfils-rtgwg-segment-routing]. 391 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 392 NOT pop the Prefix-SID before delivering the packet to the node 393 that advertised the Prefix-SID. 395 M-Flag: Mapping Server Flag. If set, the SID is advertised 396 from the Segment Routing Mapping Server functionality as 397 described in [I-D.filsfils-rtgwg-segment-routing]. 399 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 400 the Prefix-SID originator MUST replace the Prefix-SID with a 401 Prefix-SID having an Explicit-NULL value (0 for IPv4) before 402 forwarding the packet. 404 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 405 an absolute value. If not set, then the Prefix-SID carries an 406 index. 408 L-Flag: Local/Global Flag. If set, then the value/index 409 carried by the Prefix-SID has local significance. If not set, 410 then the value/index carried by this Sub-TLV has global 411 significance. 413 Other bits: Reserved. These MUST be zero when sent and are 414 ignored when received. 416 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 418 Algorithm: one octet identifying the algorithm the Prefix-SID is 419 associated with as defined in Section 3.1. 421 SID/Index/Label: according to the V and L flags, it contains 422 either: 424 A 32 bit index defining the offset in the SID/Label space 425 advertised by this router. 427 A 24 bit label where the 20 rightmost bits are used for 428 encoding the label value. 430 If multiple Prefix-SIDs are advertised for the same prefix, the 431 receiving router MUST use the first encoded SID and MAY use the 432 subsequent SIDs. 434 When propagating Prefix-SIDs between areas, if multiple prefix-SIDs 435 are advertised for a prefix, an implementation SHOULD preserve the 436 original order when advertising prefix-SIDs to other areas. This 437 allows implementations that only support a single Prefix-SID to have 438 a consistent view across areas. 440 When calculating the outgoing label for the prefix, the router MUST 441 take into account E and P flags advertised by the next-hop router, if 442 next-hop router advertised the SID for the prefix. This MUST be done 443 regardless of whether the next-hop router contributes to the best 444 path to the prefix. 446 The NP-Flag (No-PHP) MUST be set on the Prefix-SIDs allocated to 447 inter-area prefixes that are originated by the ABR based on intra- 448 area or inter-area reachability between areas. When the inter-area 449 prefix is generated based on the prefix which is directly attached to 450 the ABR, NP-Flag SHOULD NOT be set 452 The NP-Flag (No-PHP) MUST be be set on the Prefix-SIDs allocated to 453 redistributed prefixes, unless the redistributed prefix is directly 454 attached to ASBR, in which case the NP-flag SHOULD NOT be set. 456 If the NP-Flag is not set then any upstream neighbor of the Prefix- 457 SID originator MUST pop the Prefix-SID. This is equivalent to the 458 penultimate hop popping mechanism used in the MPLS dataplane. In 459 such case, MPLS EXP bits of the Prefix-SID are not preserved for the 460 final destination (the Prefix-SID being removed). If the NP-flag is 461 clear then the received E-flag is ignored. 463 If the NP-flag is set then: 465 If the E-flag is not set then any upstream neighbor of the Prefix- 466 SID originator MUST keep the Prefix-SID on top of the stack. This 467 is useful when the originator of the Prefix-SID must stitch the 468 incoming packet into a continuing MPLS LSP to the final 469 destination. This could occur at an inter-area border router 470 (prefix propagation from one area to another) or at an inter- 471 domain border router (prefix propagation from one domain to 472 another). 474 If the E-flag is set then any upstream neighbor of the Prefix-SID 475 originator MUST replace the Prefix-SID with a Prefix-SID having an 476 Explicit-NULL value. This is useful, e.g., when the originator of 477 the Prefix-SID is the final destination for the related prefix and 478 the originator wishes to receive the packet with the original EXP 479 bits. 481 When M-Flag is set, NP-flag MUST be set and E-bit MUST NOT be set. 483 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 484 the value advertised in Prefix SID Sub-TLV is interpreted as a 485 starting SID value. 487 Example 1: if the following router addresses (loopback addresses) 488 need to be mapped into the corresponding Prefix SID indexes: 490 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 491 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 492 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 493 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 495 then the Prefix field in the Extended Prefix Range TLV would be set 496 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 497 set to 4 and the Index value in the Prefix-SID Sub-TLV would be set 498 to 1. 500 Example 2: If the following prefixes need to be mapped into the 501 corresponding Prefix-SID indexes: 503 10.1.1/24, Prefix-SID: Index 51 504 10.1.2/24, Prefix-SID: Index 52 505 10.1.3/24, Prefix-SID: Index 53 506 10.1.4/24, Prefix-SID: Index 54 507 10.1.5/24, Prefix-SID: Index 55 508 10.1.6/24, Prefix-SID: Index 56 509 10.1.7/24, Prefix-SID: Index 57 511 then the Prefix field in the Extended Prefix Range TLV would be set 512 to 10.1.1.0, Prefix Length would be set to 24, Range Size would be 7 513 and the Index value in the Prefix-SID Sub-TLV would be set to 51. 515 6. SID/Label Binding Sub-TLV 517 The SID/Label Binding Sub-TLV is used to advertise a SID/Label 518 mapping for a path to the prefix. 520 The SID/Label Binding TLV MAY be originated by any router in an OSPF 521 domain. The router may advertise a SID/Label binding to a FEC along 522 with at least a single 'nexthop style' anchor. The protocol supports 523 more than one 'nexthop style' anchor to be attached to a SID/Label 524 binding, which results in a simple path description language. In 525 analogy to RSVP, the terminology for this is called an 'Explicit 526 Route Object' (ERO). Since ERO style path notation allows anchoring 527 SID/label bindings to both link and node IP addresses, any Label 528 Switched Path (LSP) can be described. Additionally, SID/Label 529 Bindings from external protocols can be easily re-advertised. 531 The SID/Label Binding TLV may be used for advertising SID/Label 532 Bindings and their associated Primary and Backup paths. In a single 533 TLV, a primary ERO Path, backup ERO Path, or both can be advertised. 534 If a router wants to advertise multiple parallel paths, then it can 535 generate several TLVs for the same Prefix/FEC. Each occurrence of a 536 Binding TLV for a given FEC Prefix will add a new path. 538 The SID/Label Binding Sub-TLV is a Sub-TLV of the OSPF Extended 539 Prefix TLV described in [I-D.ietf-ospf-prefix-link-attr] and the OSPF 540 Extended Prefix Range TLV described in Section 4. Multiple SID/Label 541 Binding TLVs can be present in their parent TLV. The SID/Label 542 Binding Sub-TLV has following format: 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Type | Length | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Flags | Reserved | MT-ID | Weight | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Sub-TLVs (variable) | 552 +- -+ 553 | | 555 where: 557 Type: TBD, suggested value 3 559 Length: variable 561 Flags: 1 octet field of following flags: 563 0 1 2 3 4 5 6 7 564 +-+-+-+-+-+-+-+-+ 565 |M| | 566 +-+-+-+-+-+-+-+-+ 568 where: 570 M-bit - When the bit is set the binding represents the 571 mirroring context as defined in 572 [I-D.minto-rsvp-lsp-egress-fast-protection]. 574 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 576 Weight: weight used for load-balancing purposes. The use of the 577 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 579 The SID/Label Binding TLV supports the following Sub-TLVs: 581 SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST 582 appear in the SID/Label Binding Sub-TLV and it MUST only appear 583 once. 585 ERO Metric Sub-TLV as defined in Section 6.1. 587 ERO Sub-TLVs as defined in Section 6.2. 589 6.1. ERO Metric Sub-TLV 591 The ERO Metric Sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 593 The ERO Metric Sub-TLV advertises the cost of an ERO path. It is 594 used to compare the cost of a given source/destination path. A 595 router SHOULD advertise the ERO Metric Sub-TLV in an advertised ERO 596 TLV. The cost of the ERO Metric Sub-TLV SHOULD be set to the 597 cumulative IGP or TE path cost of the advertised ERO. Since 598 manipulation of the Metric field may attract or repel traffic to and 599 from the advertised segment, it MAY be manually overridden. 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Type | Length | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Metric (4 octets) | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 ERO Metric Sub-TLV format 611 where: 613 Type: TBD, suggested value 8 615 Length: Always 4 617 Metric: A 4 octet metric representing the aggregate IGP or TE path 618 cost. 620 6.2. ERO Sub-TLVs 622 All 'ERO' information represents an ordered set which describes the 623 segments of a path. The first ERO Sub-TLV describes the first 624 segment of a path. Similiarly, the last ERO Sub-TLV describes the 625 segment closest to the egress point. If a router extends or stitches 626 a path, it MUST prepend the new segment's path information to the ERO 627 list. This applies equally to advertised backup EROs. 629 All ERO Sub-TLVs must immediately follow the (SID)/Label Sub-TLV. 631 All Backup ERO Sub-TLVs must immediately follow the last ERO Sub-TLV. 633 6.2.1. IPv4 ERO Sub-TLV 635 IPv4 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 637 The IPv4 ERO Sub-TLV describes a path segment using IPv4 Address 638 style encoding. Its semantics have been borrowed from [RFC3209]. 640 0 1 2 3 641 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 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Type | Length | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Flags | Reserved | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | IPv4 Address (4 octets) | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 IPv4 ERO Sub-TLV format 652 where: 654 Type: TBD, suggested value 4 656 Length: 8 bytes 658 Flags: 1 octet field of following flags: 660 0 1 2 3 4 5 6 7 661 +-+-+-+-+-+-+-+-+ 662 |L| | 663 +-+-+-+-+-+-+-+-+ 665 where: 667 L-bit - If the L-bit is set, then the segment path is 668 designated as 'loose'. Otherwise, the segment path is 669 designated as 'strict'. 671 IPv4 Address - the address of the explicit route hop. 673 6.2.2. Unnumbered Interface ID ERO Sub-TLV 675 The Unnumbered Interface ID ERO Sub-TLV is a Sub-TLV of the SID/Label 676 Binding Sub-TLV. 678 The appearance and semantics of the 'Unnumbered Interface ID' have 679 been borrowed from [RFC3477]. 681 The Unnumbered Interface-ID ERO Sub-TLV describes a path segment that 682 includes an unnumbered interface. Unnumbered interfaces are 683 referenced using the interface index. Interface indices are assigned 684 local to the router and therefore not unique within a domain. All 685 elements in an ERO path need to be unique within a domain and hence 686 need to be disambiguated using a domain unique Router-ID. 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Type | Length | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Flags | Reserved | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Router ID | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Interface ID | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 where: 702 Unnumbered Interface ID ERO Sub-TLV format 704 Type: TBD, suggested value 5 706 Length: 12 bytes 708 Flags: 1 octet field of following flags: 710 0 1 2 3 4 5 6 7 711 +-+-+-+-+-+-+-+-+ 712 |L| | 713 +-+-+-+-+-+-+-+-+ 715 where: 717 L-bit - If the L-bit is set, then the segment path is 718 designated as 'loose'. Otherwise, the segment path is 719 designated as 'strict'. 721 Router-ID: Router-ID of the next-hop. 723 Interface ID: is the identifier assigned to the link by the router 724 specified by the Router-ID. 726 6.2.3. IPv4 Backup ERO Sub-TLV 728 IPv4 Prefix Backup ERO Sub-TLV is a Sub-TLV of the SID/Label Binding 729 Sub-TLV. 731 The IPv4 Backup ERO Sub-TLV describes a path segment using IPv4 732 Address style of encoding. Its semantics have been borrowed from 733 [RFC3209]. 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Type | Length | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Flags | Reserved | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | IPv4 Address (4 octets) | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 IPv4 Backup ERO Sub-TLV format 747 where: 749 Type: TBD, suggested value 6 751 Length: 8 bytes 753 Flags: 1 octet field of following flags: 755 0 1 2 3 4 5 6 7 756 +-+-+-+-+-+-+-+-+ 757 |L| | 758 +-+-+-+-+-+-+-+-+ 760 where: 762 L-bit - If the L-bit is set, then the segment path is 763 designated as 'loose'. Otherwise, the segment path is 764 designated as 'strict'. 766 IPv4 Address - the address of the explicit route hop. 768 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV 770 The Unnumbered Interface ID Backup ERO Sub-TLV is a Sub-TLV of the 771 SID/Label Binding Sub-TLV. 773 The appearance and semantics of the 'Unnumbered Interface ID' have 774 been borrowed from [RFC3477]. 776 The Unnumbered Interface-ID Backup ERO Sub-TLV describes a path 777 segment that includes an unnumbered interface. Unnumbered interfaces 778 are referenced using the interface index. Interface indices are 779 assigned local to the router and are therefore not unique within a 780 domain. All elements in an ERO path need to be unique within a 781 domain and hence need to be disambiguated with specification of the 782 domain unique Router-ID. 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Type | Length | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Flags | Reserved | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Router ID | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Interface ID | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 Unnumbered Interface ID Backup ERO Sub-TLV format 798 where: 800 Type: TBD, suggested value 7 802 Length: 12 bytes 804 Flags: 1 octet field of following flags: 806 0 1 2 3 4 5 6 7 807 +-+-+-+-+-+-+-+-+ 808 |L| | 809 +-+-+-+-+-+-+-+-+ 811 where: 813 L-bit - If the L-bit is set, then the segment path is 814 designated as 'loose'. Otherwise, the segment path is 815 designated as 'strict'. 817 Router-ID: Router-ID of the next-hop. 819 Interface ID: is the identifier assigned to the link by the router 820 specified by the Router-ID. 822 7. Adjacency Segment Identifier (Adj-SID) 824 An Adjacency Segment Identifier (Adj-SID) represents a router 825 adjacency in Segment Routing. 827 7.1. Adj-SID Sub-TLV 829 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 830 [I-D.ietf-ospf-prefix-link-attr]. It MAY appear multiple times in 831 the Extended Link TLV. Examples where more than one Adj-SID may be 832 used per neighbor are described in 833 [I-D.filsfils-rtgwg-segment-routing-use-cases]. The Adj-SID Sub-TLV 834 has the following format: 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 | MT-ID | Weight | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | SID/Label/Index (variable) | 844 +---------------------------------------------------------------+ 846 where: 848 Type: TBD, suggested value 2. 850 Length: variable. 852 Flags. 1 octet field of following flags: 854 0 1 2 3 4 5 6 7 855 +-+-+-+-+-+-+-+-+ 856 |B|V|L|S| | 857 +-+-+-+-+-+-+-+-+ 859 where: 861 B-Flag: Backup Flag. If set, the Adj-SID refers to an 862 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 863 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 865 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 866 carries an absolute value. If not set, then the Prefix-SID 867 carries an index. 869 The L-Flag: Local/Global Flag. If set, then the value/index 870 carried by the Prefix-SID has local significance. If not set, 871 then the value/index carried by this Sub-TLV has global 872 significance. 874 The S-Flag. Set Flag. When set, the S-Flag indicates that the 875 Adj-SID refers to a set of adjacencies (and therefore MAY be 876 assigned to other adjacencies as well). 878 Other bits: Reserved. These MUST be zero when sent and are 879 ignored when received. 881 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 883 Weight: weight used for load-balancing purposes. The use of the 884 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 886 SID/Index/Label: according to the V and L flags, it contains 887 either: 889 A 32 bit index defining the offset in the SID/Label space 890 advertised by this router. 892 A 24 bit label where the 20 rightmost bits are used for 893 encoding the label value. 895 An SR capable router MAY allocate an Adj-SID for each of its 896 adjacencies and set the B-Flag when the adjacency is protected by an 897 FRR mechanism (IP or MPLS) as described in 898 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 900 7.2. LAN Adj-SID Sub-TLV 902 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 903 in [I-D.ietf-ospf-prefix-link-attr]. It MAY appear multiple times in 904 the Extended-Link TLV. It is used to advertise a SID/Label for an 905 adjacency to a non-DR node on a broadcast or NBMA network. 907 0 1 2 3 908 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 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Type | Length | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Flags | Reserved | MT-ID | Weight | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Neighbor ID | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | SID/Label/Index (variable) | 917 +---------------------------------------------------------------+ 919 where: 921 Type: TBD, suggested value 3. 923 Length: variable. 925 Flags. 1 octet field of following flags: 927 0 1 2 3 4 5 6 7 928 +-+-+-+-+-+-+-+-+ 929 |B|V|L|S| | 930 +-+-+-+-+-+-+-+-+ 932 where: 934 B-Flag: Backup-flag: set if the LAN-Adj-SID refer to an 935 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 936 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 938 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 939 carries an absolute value. If not set, then the Prefix-SID 940 carries an index. 942 The L-Flag: Local/Global Flag. If set, then the value/index 943 carried by the Prefix-SID has local significance. If not set, 944 then the value/index carried by this Sub-TLV has global 945 significance. 947 The S-Flag. Set Flag. When set, the S-Flag indicates that the 948 Adj-SID refers to a set of adjacencies (and therefore MAY be 949 assigned to other adjacencies as well). 951 Other bits: Reserved. These MUST be zero when sent and are 952 ignored when received. 954 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 956 Weight: weight used for load-balancing purposes. The use of the 957 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 959 SID/Index/Label: according to the V and L flags, it contains 960 either: 962 A 32 bit index defining the offset in the SID/Label space 963 advertised by this router. 965 A 24 bit label where the 20 rightmost bits are used for 966 encoding the label value. 968 8. Elements of Procedure 970 8.1. Intra-area Segment routing in OSPFv2 972 An OSPFv2 router that supports segment routing MAY advertise Prefix- 973 SIDs for any prefix to which it is advertising reachability (e.g., a 974 loopback IP address as described in Section 5). 976 If multiple routers advertise a Prefix-SID for the same prefix, then 977 the Prefix-SID MUST be the same. This is required in order to allow 978 traffic load-balancing when multiple equal cost paths to the 979 destination exist in the network. 981 Prefix-SID can also be advertised by the SR Mapping Servers (as 982 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]). The 983 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 984 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 985 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 986 MUST be advertised by all of them. The flooding scope of the OSPF 987 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 988 could be either area scoped or AS scoped and is determined based on 989 the configuration of the SR Mapping Server. 991 8.2. Inter-area Segment routing in OSPFv2 993 In order to support SR in a multi-area environment, OSPFv2 must 994 propagate Prefix-SID information between areas. The following 995 procedure is used in order to propagate Prefix SIDs between areas. 997 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 998 prefix to all its connected areas, it will also originate an Extended 999 Prefix Opaque LSA, as described in [I-D.ietf-ospf-prefix-link-attr]. 1000 The flooding scope of the Extended Prefix Opaque LSA type will be set 1001 to area-scope. The route-type in the OSPF Extended Prefix TLV is set 1002 to inter-area. The Prefix-SID Sub-TLV will be included in this LSA 1003 and the Prefix-SID value will be set as follows: 1005 The ABR will look at its best path to the prefix in the source 1006 area and find the advertising router associated with the best path 1007 to that prefix. 1009 The ABR will then determine if such router advertised a Prefix-SID 1010 for the prefix and use it when advertising the Prefix-SID to other 1011 connected areas. 1013 If no Prefix-SID was advertised for the prefix in the source area 1014 by the router that contributes to the best path to the prefix, the 1015 originating ABR will use the Prefix-SID advertised by any other 1016 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 1017 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 1018 propagating the Prefix-SID for the prefix to other areas. 1020 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 1021 route to all its connected areas it will also originate an Extended 1022 Prefix Opaque LSA, as described in [I-D.ietf-ospf-prefix-link-attr]. 1023 The flooding scope of the Extended Prefix Opaque LSA type will be set 1024 to area-scope. The route-type in OSPF Extended Prefix TLV is set to 1025 inter-area. The Prefix-SID Sub-TLV will be included in this LSA and 1026 the Prefix-SID will be set as follows: 1028 The ABR will look at its best path to the prefix in the source 1029 area and find the advertising router associated with the best path 1030 to that prefix. 1032 The ABR will then determine if such router advertised a Prefix-SID 1033 for the prefix and use it when advertising the Prefix-SID to other 1034 connected areas. 1036 If no Prefix-SID was advertised for the prefix in the source area 1037 by the ABR that contributes to the best path to the prefix, the 1038 originating ABR will use the Prefix-SID advertised by any other 1039 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 1040 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 1041 propagating the Prefix-SID for the prefix to other areas. 1043 8.3. SID for External Prefixes 1045 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1046 SR, generates Type-5 LSAs, it should also originate an Extended 1047 Prefix Opaque LSAs, as described in [I-D.ietf-ospf-prefix-link-attr]. 1048 The flooding scope of the Extended Prefix Opaque LSA type is set to 1049 AS-scope. The route-type in the OSPF Extended Prefix TLV is set to 1050 external. The Prefix-SID Sub-TLV is included in this LSA and the 1051 Prefix-SID value will be set to the SID that has been reserved for 1052 that prefix. 1054 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 1055 also advertise the Prefix-SID for the prefix. The NSSA ABR 1056 determines its best path to the prefix advertised in the translated 1057 Type-7 LSA and finds the advertising router associated with that 1058 path. If the advertising router has advertised a Prefix-SID for the 1059 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 1060 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 1061 router will be used (e.g.: a Prefix-SID coming from an SR Mapping 1062 Server as defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]). 1064 8.4. Advertisement of Adj-SID 1066 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1067 using the Adj-SID Sub-TLV as described in Section 7. 1069 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 1071 An Adj-SID MAY be advertised for any adjacency on a p2p link that is 1072 in neighbor state 2-Way or higher. If the adjacency on a p2p link 1073 transitions from the FULL state, then the Adj-SID for that adjacency 1074 MAY be removed from the area. If the adjacency transitions to a 1075 state lower then 2-Way, then the Adj-SID advertisement MUST be 1076 removed from the area. 1078 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1080 Broadcast or NBMA networks in OSPF are represented by a star topology 1081 where the Designated Router (DR) is the central point to which all 1082 other routers on the broadcast or NBMA network connect. As a result, 1083 routers on the broadcast or NBMA network advertise only their 1084 adjacency to the DR. Routers that do not act as DR do not form or 1085 advertise adjacencies with each other. They do, however, maintain 1086 2-Way adjacency state with each other and are directly reachable. 1088 When Segment Routing is used, each router on the broadcast or NBMA 1089 network MAY advertise the Adj-SID for its adjacency to the DR using 1090 Adj-SID Sub-TLV as described in Section 7.1. 1092 SR capable routers MAY also advertise an Adj-SID for other neighbors 1093 (e.g. BDR, DR-OTHER) on the broadcast or NBMA network using the LAN 1094 ADJ-SID Sub-TLV as described in Section 7.2. 1096 9. IANA Considerations 1098 This specification updates several existing OSPF registries. 1100 9.1. OSPF OSPF Router Information (RI) TLVs Registry 1102 o 8 (IANA Preallocated) - SR-Algorithm TLV 1104 o 9 (IANA Preallocated) - SID/Label Range TLV 1106 9.2. OSPF Extended Prefix LSA TLV Registry 1108 Following values are allocated: 1110 o 2 - OSPF Extended Prefix Range TLV 1112 9.3. OSPF Extended Prefix LSA Sub-TLV Registry 1114 Following values are allocated: 1116 o 1 - SID/Label Sub-TLV 1118 o 2 - Prefix SID Sub-TLV 1120 o 3 - SID/Label Binding Sub-TLV 1122 o 4 - IPv4 ERO Sub-TLV 1124 o 5 - Unnumbered Interface ID ERO Sub-TLV 1126 o 6 - IPv4 Backup ERO Sub-TLV 1128 o 7 - Unnumbered Interface ID Backup ERO Sub-TLV 1130 o 8 - ERO Metric Sub-TLV 1132 9.4. OSPF Extended Link LSA Sub-TLV Registry 1134 Following initial values are allocated: 1136 o 1 - SID/Label Sub-TLV 1138 o 2 - Adj-SID Sub-TLV 1140 o 3 - LAN Adj-SID/Label Sub-TLV 1142 10. Security Considerations 1144 Implementations must assure that malformed TLV and Sub-TLV 1145 permutations do not result in errors which cause hard OSPF failures. 1147 11. Contributors 1149 The following people gave a substantial contribution to the content 1150 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1151 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1152 Saku Ytti. 1154 12. Acknowledgements 1156 We would like to thank Anton Smirnov for his contribution. 1158 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1159 contribution on earlier incarnations of the "Binding / MPLS Label 1160 TLV" in [I-D.gredler-ospf-label-advertisement]. 1162 Thanks to Acee Lindem for the detail review of the draft, 1163 corrections, as well as discussion about details of the encoding. 1165 13. References 1167 13.1. Normative References 1169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1170 Requirement Levels", BCP 14, RFC 2119, March 1997. 1172 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1174 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1175 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1176 Tunnels", RFC 3209, December 2001. 1178 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1179 in Resource ReSerVation Protocol - Traffic Engineering 1180 (RSVP-TE)", RFC 3477, January 2003. 1182 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1183 (TE) Extensions to OSPF Version 2", RFC 3630, September 1184 2003. 1186 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1187 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 1188 4915, June 2007. 1190 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1191 Shaffer, "Extensions to OSPF for Advertising Optional 1192 Router Capabilities", RFC 4970, July 2007. 1194 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1195 OSPF Opaque LSA Option", RFC 5250, July 2008. 1197 13.2. Informative References 1199 [I-D.filsfils-rtgwg-segment-routing] 1200 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1201 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1202 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1203 "Segment Routing Architecture", draft-filsfils-rtgwg- 1204 segment-routing-01 (work in progress), October 2013. 1206 [I-D.filsfils-rtgwg-segment-routing-use-cases] 1207 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1208 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1209 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1210 Crabbe, "Segment Routing Use Cases", draft-filsfils-rtgwg- 1211 segment-routing-use-cases-02 (work in progress), October 1212 2013. 1214 [I-D.gredler-ospf-label-advertisement] 1215 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1216 "Advertising MPLS labels in OSPF", draft-gredler-ospf- 1217 label-advertisement-03 (work in progress), May 2013. 1219 [I-D.ietf-ospf-prefix-link-attr] 1220 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1221 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1222 Advertisement", draft-ietf-ospf-prefix-link-attr-00 (work 1223 in progress), August 2014. 1225 [I-D.minto-rsvp-lsp-egress-fast-protection] 1226 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1227 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1228 protection-03 (work in progress), November 2013. 1230 Authors' Addresses 1232 Peter Psenak (editor) 1233 Cisco Systems, Inc. 1234 Apollo Business Center 1235 Mlynske nivy 43 1236 Bratislava 821 09 1237 Slovakia 1239 Email: ppsenak@cisco.com 1240 Stefano Previdi (editor) 1241 Cisco Systems, Inc. 1242 Via Del Serafico, 200 1243 Rome 00142 1244 Italy 1246 Email: sprevidi@cisco.com 1248 Clarence Filsfils 1249 Cisco Systems, Inc. 1250 Brussels 1251 Belgium 1253 Email: cfilsfil@cisco.com 1255 Hannes Gredler 1256 Juniper Networks, Inc. 1257 1194 N. Mathilda Ave. 1258 Sunnyvale, CA 94089 1259 US 1261 Email: hannes@juniper.net 1263 Rob Shakir 1264 British Telecom 1265 London 1266 UK 1268 Email: rob.shakir@bt.com 1270 Wim Henderickx 1271 Alcatel-Lucent 1272 Copernicuslaan 50 1273 Antwerp 2018 1274 BE 1276 Email: wim.henderickx@alcatel-lucent.com 1277 Jeff Tantsura 1278 Ericsson 1279 300 Holger Way 1280 San Jose, CA 95134 1281 US 1283 Email: Jeff.Tantsura@ericsson.com