idnits 2.17.1 draft-psenak-ospf-segment-routing-extensions-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2014) is 3715 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) ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Shortest Path First IGP P. Psenak, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Standards Track C. Filsfils 5 Expires: August 17, 2014 Cisco Systems, Inc. 6 H. Gredler 7 Juniper Networks, Inc. 8 R. Shakir 9 British Telecom 10 W. Henderickx 11 Alcatel-Lucent 12 February 13, 2014 14 OSPF Extensions for Segment Routing 15 draft-psenak-ospf-segment-routing-extensions-04 17 Abstract 19 Segment Routing (SR) allows for a flexible definition of end-to-end 20 paths within IGP topologies by encoding paths as sequences of 21 topological sub-paths, called "segments". These segments are 22 advertised by the link-state routing protocols (IS-IS and OSPF). 24 This draft describes the necessary OSPF extensions that need to be 25 introduced for Segment Routing. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 17, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 4 69 2.1. SID/Label sub-TLV . . . . . . . . . . . . . . . . . . . . 4 70 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . . 5 71 3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . . 5 72 3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 6 73 4. OSPFv2 Extended Prefix Opaque LSA type . . . . . . . . . . . . 7 74 4.1. OSPF Extended Prefix TLV . . . . . . . . . . . . . . . . . 8 75 4.2. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . 9 76 4.3. SID/Label Binding sub-TLV . . . . . . . . . . . . . . . . 11 77 4.3.1. ERO Metric sub-TLV . . . . . . . . . . . . . . . . . . 13 78 4.3.2. ERO sub-TLVs . . . . . . . . . . . . . . . . . . . . . 13 79 5. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . . 17 80 5.1. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . 18 81 5.2. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . . 19 82 5.3. Adj-SID sub-TLV . . . . . . . . . . . . . . . . . . . . . 19 83 5.4. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 21 84 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 22 85 6.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . . 22 86 6.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . . 22 87 6.3. SID for External Prefixes . . . . . . . . . . . . . . . . 23 88 6.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . . 24 89 6.4.1. Advertisement of Adj-SID on Point-to-Point Links . . . 24 90 6.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 24 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 93 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 94 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 96 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 97 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 100 1. Introduction 102 Segment Routing (SR) allows for a flexible definition of end-to-end 103 paths within IGP topologies by encoding paths as sequences of 104 topological sub-paths, called "segments". These segments are 105 advertised by the link-state routing protocols (IS-IS and OSPF). 106 Prefix segments represent an ecmp-aware shortest-path to a prefix (or 107 a node), as per the state of the IGP topology. Adjacency segments 108 represent a hop over a specific adjacency between two nodes in the 109 IGP. A prefix segment is typically a multi-hop path while an 110 adjacency segment, in most of the cases, is a one-hop path. SR's 111 control-plane can be applied to both IPv6 and MPLS data-planes, and 112 do not require any additional signaling (other than the regular IGP). 113 For example, when used in MPLS networks, SR paths do not require any 114 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 115 of LSPs established with RSVP or LDP . 117 This draft describes the necessary OSPF extensions that need to be 118 introduced for Segment Routing. 120 Segment Routing architecture is described in 121 [I-D.filsfils-rtgwg-segment-routing]. 123 Segment Routing use cases are described in 124 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 126 2. Segment Routing Identifiers 128 Segment Routing defines various types of Segment Identifiers (SIDs): 129 Prefix-SID, Adjacency-SID, LAN Adjacency SID and Binding SID. 131 For the purpose of the advertisements of various SID values new 132 Opaque LSAs (defined in [RFC5250]) are defined. These new LSAs are 133 defined as generic containers that can be used in order to advertise 134 any additional attributes associated with the prefix or link. These 135 new Opaque LSAs are complementary to the existing LSAs and are not 136 aimed to replace any of the existing LSAs. 138 2.1. SID/Label sub-TLV 140 SID/Label sub-TLV appears in multiple TLVs or sub-TLVs defined later 141 in this document. It is used to advertise SID or label associated 142 with the prefix or adjacency. SID/Label TLV has following format: 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Type | Length | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | SID/Label (variable) | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 where: 154 Type: 1 156 Length: variable, 3 or 4 bytes 158 SID/Label: if length is set to 3, then the 20 rightmost bits 159 represent a label. If length is set to 4 then the value 160 represents a 32 bit SID. 162 3. Segment Routing Capabilities 164 Segment Routing requires some additional capabilities of the router 165 to be advertised to other routers in the area. 167 These SR capabilities are advertised in Router Information Opaque LSA 168 (defined in [RFC4970]). 170 3.1. SR-Algorithm TLV 172 SR-Algorithm TLV is a TLV of Router Information Opaque LSA (defined 173 in [RFC4970]). 175 Router may use various algorithms when calculating reachability to 176 other nodes in area or to prefixes attached to these nodes. Examples 177 of these algorithms are metric based Shortest Path First (SPF), 178 various sorts of Constrained SPF, etc. SR-Algorithm TLV allows a 179 router to advertise algorithms that router is currently using to 180 other routers in an area. SR-Algorithm TLV has following structure: 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type | Length | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Algorithm 1 | Algorithm... | Algorithm n | | 188 +- -+ 189 | | 190 + + 192 where: 194 Type: 8 196 Length: variable 198 Algorithm: one octet identifying the algorithm. The following 199 value has been defined: 201 0: IGP metric based SPT. 203 RI LSA can be advertised at any of the defined flooding scopes (link, 204 area, or autonomous system (AS)). For the purpose of the SR- 205 Algorithm TLV propagation area scope flooding is required. 207 3.2. SID/Label Range TLV 209 The SID/Label Range TLV is a TLV of Router Information Opaque LSA 210 (defined in [RFC4970]). 212 SID/Label Sub-TLV MAY appear multiple times and has following format: 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Type | Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Range Size | Reserved | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Sub-TLVs (variable) | 222 +- -+ 223 | | 224 + + 226 where: 228 Type: 9 230 Length: variable 232 Range Size: 3 octet of the SID/label range 234 Currently the only supported Sub-TLV is the SID/Label TLV as defined 235 in Section 2.1. SID/Label advertised in SID/Label TLV represents the 236 first SID/Label from the advertised range. 238 RI LSA can be advertised at any of the defined flooding scopes (link, 239 area, or autonomous system (AS)). For the purpose of the SR- 240 Capability TLV propagation area scope flooding is required. 242 4. OSPFv2 Extended Prefix Opaque LSA type 244 A new Opaque LSA (defined in [RFC5250]) is defined in OSPFv2 in order 245 to advertise additional prefix attributes: OSPFv2 Extended Prefix 246 Opaque LSA. 248 Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by a 249 single router. Flooding scope of the OSPFv2 Extended Prefix Opaque 250 LSA depends on the content inside the LSA and is in control of the 251 originating router. 253 The format of the OSPFv2 Extended Prefix Opaque LSA is as follows: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | LS age | Options | 9, 10, or 11 | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Opaque type | Instance | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Advertising Router | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | LS sequence number | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | LS checksum | length | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | | 269 +- TLVs -+ 270 | ... | 272 Opaque type used by OSPFv2 Extended Prefix Opaque LSA is 7. 274 The format of the TLVs within the body of the LSA is the same as the 275 format used by the Traffic Engineering Extensions to OSPF defined in 276 [RFC3630]. The LSA payload consists of one or more nested Type/ 277 Length/Value (TLV) triplets. The format of each TLV is: 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Type | Length | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Value... | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 The Length field defines the length of the value portion in octets. 288 The TLV is padded to 4-octet alignment; padding is not included in 289 the length field. Nested TLVs are also 32-bit aligned. Unrecognized 290 types are ignored. 292 4.1. OSPF Extended Prefix TLV 294 The OSPF Extended Prefix TLV is used in order to advertise additional 295 attributes associated with the prefix. Multiple OSPF Extended Prefix 296 TLVs MAY be carried in each OSPFv2 Extended Prefix Opaque LSA, 297 however all prefixes included in the single OSPFv2 Extended Prefix 298 Opaque LSA MUST have the same flooding scope. The structure of the 299 OSPF Extended Prefix TLV is as follows: 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Type | Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Route Type | Prefix Length | AF | Reserved | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Address Prefix (variable) | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Sub-TLVs (variable) | 311 +- -+ 312 | | 314 where: 316 Type is 1. 318 Length is variable 319 Route type: type of the OSPF route. Supported types are: 321 0 - unspecified 322 1 - intra-area 323 3 - inter-area 324 5 - external 325 7 - NSSA external 326 If the route type is 0 (unspecified) the information inside the 327 OSPF External Prefix TLV applies to the prefix regardless of what 328 route-type it is. This is useful when some prefix specific 329 attributes are advertised by some external entity, which is not 330 aware of the route-type associated with the prefix. 332 Prefix length: length of the prefix 334 AF: 0 - IPv4 unicast 336 Address Prefix: the prefix itself encoded as an even multiple of 337 32-bit words, padded with zeroed bits as necessary. This encoding 338 consumes ((PrefixLength + 31) / 32) 32-bit words. The default 339 route is represented by a prefix of length 0. 341 4.2. Prefix SID Sub-TLV 343 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV. 344 It MAY appear more than once and has following format: 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Flags | MT-ID | Algorithm | Reserved | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Range Size | Reserved + 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Index | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 where: 360 Type: 2. 362 Length: A 16-bit field that indicates the length of the value 363 portion in octets. Set to 8. 365 Flags: 1 octet field. The following flags are defined: 367 0 368 0 1 2 3 4 5 6 7 369 +-+-+-+-+-+-+-+-+ 370 |N|P|M| | 371 +-+-+-+-+-+-+-+-+ 373 where: 375 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 376 the router identified by the prefix. Typically, the N-Flag is 377 set on Prefix-SIDs attached to a router loopback address. The 378 N-Flag is set when the Prefix-SID is a Node- SID as described 379 in [I-D.filsfils-rtgwg-segment-routing]. 381 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 382 pop the Prefix-SID before delivering the packet to the node 383 that advertised the Prefix-SID. 385 M-Flag: Mapping Server Flag. If set, the SID is advertised 386 from the Segment Routing Mapping Server functionality as 387 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 389 Other bits: MUST be zero when sent and ignored when received. 391 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 393 Algorithm: one octet identifying the algorithm the Prefix-SID is 394 associated with as defined in Section 3.1. 396 Range size: this field provides the ability to specify a range of 397 addresses and their associated Prefix SIDs. It represents a 398 compression scheme to distribute a continuous Prefix and their 399 continuous, corresponding SID/Label Block. If a single SID is 400 advertised then the Range Size field MUST be set to one. For 401 range advertisements > 1, Range Size represents the the number of 402 addresses that need to be mapped into a Prefix-SID. 404 Index: 32 bits representing the offset to the advertised SID/Label 405 range. 407 If multiple Prefix-SIDs are advertised for the same prefix, the 408 receiving router MUST use the first encoded SID and MAY use the 409 subsequent ones. 411 P-Flag (no-PHP) MUST be set on the Prefix-SIDs allocated to inter- 412 area prefixes that are originated by the ABR based on intra-area or 413 inter-area reachability between areas. In case the inter-area prefix 414 is generated based on the prefix which is directly attached to the 415 ABR, P-Flag SHOULD NOT be set 417 P-Flag (no-PHP) MUST NOT be set on the Prefix-SIDs allocated to 418 redistributed prefixes, unless the redistributed prefix is directly 419 attached to ASBR, in which case the P-Flag SHOULD NOT be set. 421 When M-Flag is set, PHP MUST NOT be done. 423 Example 1: if the following router addresses (loopback addresses) 424 need to be mapped into the corresponding Prefix SID indexes: 426 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 427 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 428 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 429 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 431 then the Prefix field in Extended Prefix TLV would be set to 432 192.0.2.1, Prefix Length would be set to 32, Range Size in Prefix SID 433 sub-TLV would be 4 and Index value would be set to 1. 435 Example 2: If the following prefixes need to be mapped into the 436 corresponding Prefix-SID indexes: 438 10.1.1/24, Prefix-SID: Index 51 439 10.1.2/24, Prefix-SID: Index 52 440 10.1.3/24, Prefix-SID: Index 53 441 10.1.4/24, Prefix-SID: Index 54 442 10.1.5/24, Prefix-SID: Index 55 443 10.1.6/24, Prefix-SID: Index 56 444 10.1.7/24, Prefix-SID: Index 57 446 then the Prefix field in Extended Prefix TLV would be set to 447 10.1.1.0, Prefix Length would be set to 24, Range Size in Prefix SID 448 sub-TLV would be 7 and Index value would be set to 51. 450 4.3. SID/Label Binding sub-TLV 452 SID/Label Binding sub-TLV is used to advertise SID/Label mapping for 453 a prefix or a path to the prefix. SID/Label value advertised in this 454 sub-TLV has local significance (to the router). 456 SID/Label Binding sub-TLV is a sub-TLV of the OSPF Extended Prefix 457 TLV. Multiple SID/Label Binding TLVs can be present in OSPF Extended 458 Prefix TLV. SID/Label Binding sub-TLV has following format: 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type | Length | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Flags | MT-ID | Weight | Reserved | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Range Size | Reserved + 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Sub-TLVs (variable) | 470 +- -+ 471 | | 473 where: 475 Type: 3 477 Length: variable 479 Flags: 1 octet field of following flags: 481 0 1 2 3 4 5 6 7 482 +-+-+-+-+-+-+-+-+ 483 |M| | 484 +-+-+-+-+-+-+-+-+ 486 where: 488 M-bit - When the bit is set the binding represents the 489 mirroring context as defined in 490 [I-D.minto-rsvp-lsp-egress-fast-protection]. 492 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 494 Weight: weight used for load-balancing purposes. The use of the 495 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 497 Range Size: usage is the same as described in Section 4.2. 499 SID/Label Binding TLV currently supports following Sub-TLVs: 501 SID/Label sub-TLV as described in Section 2.1. This sub-TLV MUST 502 appear in the SID/Label Binding Sub-TLV and it MUST only appear 503 once. 505 ERO Metric sub-TLV as defined in Section 4.3.1. 507 ERO sub-TLVs as defined in Section 4.3.2. 509 4.3.1. ERO Metric sub-TLV 511 ERO Metric sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 513 The ERO Metric sub-TLV carries the cost of an ERO path. It is used 514 to compare the cost of a given source/destination path. A router 515 SHOULD advertise the ERO Metric sub-TLV. The cost of the ERO Metric 516 sub-TLV SHOULD be set to the cumulative IGP or TE path cost of the 517 advertised ERO. Since manipulation of the Metric field may attract 518 or distract traffic from and to the advertised segment it MAY be 519 manually overridden. 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Type | Length | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Metric (4 octets) | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 ERO Metric sub-TLV format 531 where: 533 Type: 8 535 Length: 4 bytes 537 Metric: 4 bytes 539 4.3.2. ERO sub-TLVs 541 All 'ERO' information represents an ordered set which describes the 542 segments of a path. The last ERO sub-TLV describes the segment 543 closest to the egress point, contrary the first ERO sub-TLV describes 544 the first segment of a path. If a router extends or stitches a path 545 it MUST prepend the new segments path information to the ERO list. 547 The above similarly applies to backup EROs. 549 All ERO Sub-TLVs must immediately follow the (SID)/Label Sub-TLV. 551 All Backup sub-ERO TLVs must immediately follow last ERO Sub-TLV. 553 4.3.2.1. IPv4 ERO subTLV 555 IPv4 ERO sub-TLV is a Sub-TLV of the SID/Label Binding sub-TLV. 557 The IPv4 ERO sub-TLV describes a path segment using IPv4 Address 558 style of encoding. Its semantics have been borrowed from [RFC3209]. 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Type | Length | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Flags | Reserved | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | IPv4 Address (4 octets) | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 IPv4 ERO sub-TLV format 572 where: 574 Type: 4 576 Length: 8 bytes 578 Flags: 1 octet field of following flags: 580 0 1 2 3 4 5 6 7 581 +-+-+-+-+-+-+-+-+ 582 |L| | 583 +-+-+-+-+-+-+-+-+ 585 where: 587 L-bit - If the L bit is set, then the value of the attribute is 588 'loose.' Otherwise, the value of the attribute is 'strict.' 590 IPv4 Address - the address of the explicit route hop. 592 4.3.2.2. Unnumbered Interface ID ERO sub-TLV 594 Unnumbered Interface ID ERO sub-TLV is a Sub-TLV of the SID/Label 595 Binding sub-TLV. 597 The appearance and semantics of the 'Unnumbered Interface ID' have 598 been borrowed from [RFC3477]. 600 The Unnumbered Interface-ID ERO sub-TLV describes a path segment that 601 spans over an unnumbered interface. Unnumbered interfaces are 602 referenced using the interface index. Interface indices are assigned 603 local to the router and therefore not unique within a domain. All 604 elements in an ERO path need to be unique within a domain and hence 605 need to be disambiguated using a domain unique Router-ID. 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Type | Length | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Flags | Reserved | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Router ID | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Interface ID | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 where: 621 Unnumbered Interface ID ERO sub-TLV format 623 Type: 5 625 Length: 12 bytes 627 Flags: 1 octet field of following flags: 629 0 1 2 3 4 5 6 7 630 +-+-+-+-+-+-+-+-+ 631 |L| | 632 +-+-+-+-+-+-+-+-+ 634 where: 636 L-bit - If the L bit is set, then the value of the attribute is 637 'loose.' Otherwise, the value of the attribute is 'strict.' 639 Router-ID: Router-ID of the next-hop. 641 Interface ID: is the identifier assigned to the link by the router 642 specified by the Router-ID. 644 4.3.2.3. IPv4 Backup ERO sub-TLV 646 IPv4 Prefix Backup ERO sub-TLV is a Sub-TLV of the SID/Label Binding 647 sub-TLV. 649 The IPv4 Backup ERO sub-TLV describes a path segment using IPv4 650 Address style of encoding. Its semantics have been borrowed from 651 [RFC3209]. 653 0 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Type | Length | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Flags | Reserved | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | IPv4 Address (4 octets) | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 IPv4 Backup ERO sub-TLV format 665 where: 667 Type: 6 669 Length: 8 bytes 671 Flags: 1 octet field of following flags: 673 0 1 2 3 4 5 6 7 674 +-+-+-+-+-+-+-+-+ 675 |L| | 676 +-+-+-+-+-+-+-+-+ 678 where: 680 L-bit - If the L bit is set, then the value of the attribute is 681 'loose.' Otherwise, the value of the attribute is 'strict.' 683 IPv4 Address - the address of the explicit route hop. 685 4.3.2.4. Unnumbered Interface ID Backup ERO sub-TLV 687 Unnumbered Interface ID Backup -sub-TLV is a sub-TLV of the SID/Label 688 Binding sub-TLV. 690 The appearance and semantics of the 'Unnumbered Interface ID' have 691 been borrowed from [RFC3477]. 693 The Unnumbered Interface-ID ERO sub-TLV describes a path segment that 694 spans over an unnumbered interface. Unnumbered interfaces are 695 referenced using the interface index. Interface indices are assigned 696 local to the router and therefore not unique within a domain. All 697 elements in an ERO path need to be unique within a domain and hence 698 need to be disambiguated using a domain unique Router-ID. 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Type | Length | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Flags | Reserved | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Router ID | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Interface ID | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 Unnumbered Interface ID Backup ERO sub-TLV format 714 where: 716 Type: 7 718 Length: 12 bytes 720 Flags: 1 octet field of following flags: 722 0 1 2 3 4 5 6 7 723 +-+-+-+-+-+-+-+-+ 724 |L| | 725 +-+-+-+-+-+-+-+-+ 727 where: 729 L-bit - If the L bit is set, then the value of the attribute is 730 'loose.' Otherwise, the value of the attribute is 'strict.' 732 Router-ID: Router-ID of the next-hop. 734 Interface ID: is the identifier assigned to the link by the router 735 specified by the Router-ID. 737 5. Adjacency Segment Identifier (Adj-SID) 739 An Adjacency Segment Identifier (Adj-SID) represents a router 740 adjacency in Segment Routing. At the current stage of Segment 741 Routing architecture it is assumed that the Adj-SID value has local 742 significance (to the router). 744 5.1. OSPFv2 Extended Link Opaque LSA 746 A new Opaque LSA (defined in [RFC5250] is defined in OSPFv2 in order 747 to advertise additional link attributes: the OSPFv2 Extended Link 748 Opaque LSA. 750 The OSPFv2 Extended Link Opaque LSA has an area flooding scope. 751 Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a 752 single router in an area. 754 The format of the OSPFv2 Extended Link Opaque LSA is as follows: 756 0 1 2 3 757 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 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | LS age | Options | 10 | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Opaque type | Instance | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Advertising Router | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | LS sequence number | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | LS checksum | length | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | | 770 +- TLVs -+ 771 | ... | 773 Opaque type used by OSPFv2 Extended Link Opaque LSA is 8. 775 The format of the TLVs within the body of LSA is the same as the 776 format used by the Traffic Engineering Extensions to OSPF defined in 777 [RFC3630]. The LSA payload consists of one or more nested Type/ 778 Length/Value (TLV) triplets. The format of each TLV is: 780 0 1 2 3 781 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 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Type | Length | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Value... | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 The Length field defines the length of the value portion in octets. 789 The TLV is padded to 4-octet alignment; padding is not included in 790 the length field. Nested TLVs are also 32-bit aligned. Unrecognized 791 types are ignored. 793 5.2. OSPFv2 Extended Link TLV 795 OSPFv2 Extended Link TLV is used in order to advertise various 796 attributes of the link. It describes a single link and is 797 constructed of a set of Sub-TLVs. There are no ordering requirements 798 for the Sub-TLVs. Only one Extended Link TLV SHALL be carried in 799 each Extended Link Opaque LSA, allowing for fine granularity changes 800 in the topology. 802 The Extended Link TLV has following format: 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Type | Length | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Link-Type | Reserved | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Link ID | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Link Data | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Sub-TLVs (variable) | 816 +- -+ 817 | | 819 where: 821 Type is 1. 823 Length is variable. 825 Link-Type: as defined in section A.4.2 of [RFC2328]. 827 Link-ID: as defined in section A.4.2 of [RFC2328]. 829 Link Data: as defined in section A.4.2 of [RFC2328]. 831 5.3. Adj-SID sub-TLV 833 Adj-SID is an optional Sub-TLV of the Extended Link TLV. It MAY 834 appear multiple times in Extended Link TLV. Examples where more than 835 one Adj-SID may be used per neighbor are described in 836 [I-D.filsfils-rtgwg-segment-routing-use-cases]. The structure of the 837 Adj-SID Sub-TLV is as follows: 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Type | Length | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Flags | MT-ID | Weight | Reserved | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Sub-TLVs (variable) | 847 +- -+ 848 | | 850 where: 852 Type: 2. 854 Length: variable. 856 Flags. 1 octet field of following flags: 858 0 1 2 3 4 5 6 7 859 +-+-+-+-+-+-+-+-+ 860 |B| | 861 +-+-+-+-+-+-+-+-+ 863 where: 865 B-Flag: Backup-flag: set if the Adj-SID refer to an adjacency 866 being protected (e.g.: using IPFRR or MPLS-FRR) as described in 867 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 869 Other bits: MUST be zero when originated and ignored when 870 received. 872 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 874 Weight: weight used for load-balancing purposes. The use of the 875 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 877 Adj-SID Sub-TLV supports following Sub-TLVs: 879 SID/Label sub-TLV as described in Section 2.1. This TLV MUST 880 appear in the Adj-SID Sub-TLV and it MUST only appear once. 882 A SR capable router MAY allocate an Adj-SID for each of its 883 adjacencies and set the B-Flag when the adjacency is protected by a 884 FRR mechanism (IP or MPLS) as described in 885 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 887 5.4. LAN Adj-SID Sub-TLV 889 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV. It MAY 890 appear multiple times in Extended Link TLV. It is used to advertise 891 SID/Label for adjacency to non-DR node on broadcast or NBMA network. 893 0 1 2 3 894 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 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Type | Length | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Flags | MT-ID | Weight | Reserved | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Neighbor ID | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Sub-TLVs (variable) | 903 +- -+ 904 | | 906 where: 908 Type: 3. 910 Length: variable. 912 Flags. 1 octet field of following flags: 914 0 1 2 3 4 5 6 7 915 +-+-+-+-+-+-+-+-+ 916 |B| | 917 +-+-+-+-+-+-+-+-+ 919 where: 921 B-Flag: Backup-flag: set if the LAN-Adj-SID refer to an 922 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 923 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 925 Other bits: MUST be zero when originated and ignored when 926 received. 928 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 930 Weight: weight used for load-balancing purposes. The use of the 931 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 933 LAN Adj-SID Sub-TLV supports following Sub-TLVs: 935 SID/Label TLV as described in Section 2.1. This TLV MUST 936 appear in the Adj-SID Sub-TLV and it MUST only appear once. 938 6. Elements of Procedure 940 6.1. Intra-area Segment routing in OSPFv2 942 The OSPFv2 node that supports segment routing MAY advertise Prefix- 943 SIDs for any prefix that it is advertising reachability for (e.g. 944 loopback IP address) as described in Section 4.2. 946 If multiple routers advertise Prefix-SID for the same prefix, then 947 the Prefix-SID MUST be the same. This is required in order to allow 948 traffic load-balancing if multiple equal cost paths to the 949 destination exist in the network. 951 Prefix-SID can also be advertised by the SR Mapping Servers (as 952 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]). The 953 Mapping Server advertise Prefix-SID for remote prefixes that exist in 954 the network. Multiple Mapping Servers can advertise Prefix-SID for 955 the same prefix, in which case the same Prefix-SID MUST be advertised 956 by all of them. Flooding scope of the OSPF Extended Prefix Opaque 957 LSA that is generated by the SR Mapping Server could be either area 958 scope or autonomous system scope and is decided based on the 959 configuration of the SR Mapping Server. 961 6.2. Inter-area Segment routing in OSPFv2 963 In order to support SR in a multi-area environment, OSPFv2 must 964 propagate Prefix-SID information between areas. The following 965 procedure is used in order to propagate Prefix SIDs between areas. 967 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 968 prefix to all its connected areas, it will also originate an Extended 969 Prefix Opaque LSA, as described in Section 4. The flooding scope of 970 the Extended Prefix Opaque LSA type will be set to area-scope. The 971 route-type in OSPF Extended Prefix TLV is set to inter-area. The 972 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 973 value will be set as follows: 975 The ABR will look at its best path to the prefix in the source 976 area and find out the advertising router associated with its best 977 path to that prefix. 979 If no Prefix-SID was advertised for the prefix in the source area 980 by the router that contributes to the best path to the prefix, 981 then the ABR will use the Prefix-SID advertised by any other 982 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 983 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 984 propagating Prefix-SID for the prefix to other areas. 986 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 987 route to all its connected areas it will also originate an Extended 988 Prefix Opaque LSA, as described in Section 4. The flooding scope of 989 the Extended Prefix Opaque LSA type will be set to area-scope. The 990 route-type in OSPF Extended Prefix TLV is set to inter-area. The 991 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 992 will be set as follows: 994 The ABR will look at its best path to the prefix in the source 995 area and find out the advertising router associated with its best 996 path to that prefix. 998 The ABR will then look if such router advertised a Prefix-SID for 999 the prefix and use it when advertising the Prefix-SID to other 1000 connected areas. 1002 If no Prefix-SID was advertised for the prefix in the source area 1003 by the ABR that contributes to the best path to the prefix, the 1004 originating ABR will use the Prefix-SID advertised by any other 1005 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 1006 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 1007 propagating Prefix-SID for the prefix to other areas. 1009 6.3. SID for External Prefixes 1011 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1012 SR, generates Type-5 LSAs, it should also originate Extended Prefix 1013 Opaque LSAs, as described in Section 4. The flooding scope of the 1014 Extended Prefix Opaque LSA type is set to AS-scope. The route-type 1015 in OSPF Extended Prefix TLV is set to external. Prefix-SID Sub-TLV 1016 is included in this LSA and the Prefix-SID value will be set to the 1017 SID that has been reserved for that prefix. 1019 When a NSSA ASBR translates Type-7 LSAs into Type-5 LSAs, it should 1020 also advertise the Prefix-SID for the prefix. The NSSA ABR 1021 determines its best path to the prefix advertised in the translated 1022 Type-7 LSA and finds the advertising router associated with such 1023 path. If such advertising router has advertised a Prefix-SID for the 1024 prefix, then the NSSA ASBR uses it when advertising the Prefix-SID 1025 for the Type-5 prefix. Otherwise the Prefix-SID advertised by any 1026 other router will be used (e.g.: a Prefix-SID coming from an SR 1027 Mapping Server as defined in 1028 [I-D.filsfils-rtgwg-segment-routing-use-cases]). 1030 6.4. Advertisement of Adj-SID 1032 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1033 using the Adj-SID Sub-TLV as described in Section 5. 1035 6.4.1. Advertisement of Adj-SID on Point-to-Point Links 1037 Adj-SID MAY be advertised for any adjacency on p2p link that is in a 1038 state 2-Way or higher. If the adjacency on a p2p link transitions 1039 from the FULL state, then the Adj-SID for that adjacency MAY be 1040 removed from the area. If the adjacency transitions to a state lower 1041 then 2-Way, then the Adj-SID MUST be removed from the area. 1043 6.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1045 Broadcast or NBMA networks in OSPF are represented by a star topology 1046 where the Designated Router (DR) is the central point all other 1047 routers on the broadcast or NBMA network connect to. As a result, 1048 routers on the broadcast or NBMA network advertise only their 1049 adjacency to DR and BDR. Routers that are neither DR nor BDR do not 1050 form and do not advertise adjacencies between them. They, however, 1051 maintain a 2-Way adjacency state between them. 1053 When Segment Routing is used, each router on the broadcast or NBMA 1054 network MAY advertise the Adj-SID for its adjacency to DR using Adj- 1055 SID Sub-TLV as described in Section 5.3. 1057 SR capable router MAY also advertise Adj-SID for other neighbors 1058 (e.g. BDR, DR-OTHER) on broadcast or NBMA network using the LAN ADJ- 1059 SID Sub-TLV as described in section 5.1.1.2. Section 5.4. 1061 7. IANA Considerations 1063 This specification updates two existing OSPF registries. 1065 Opaque Link-State Advertisements (LSA) Option Types: 1067 o 7 - OSPFv2 Extended Prefix Opaque LSA 1069 o 8 - OSPFv2 Extended Link Opaque LSA 1071 OSPF Router Information (RI) TLVs: 1073 o 8 - SR-Algorithm TLV 1074 o 9 - SID/Label Range TLV 1076 This specification also creates four new registries: 1078 - OSPF Extended Prefix LSA TLVs and sub-TLVs 1080 - OSPF Extended Link LSA TLVs and sub-TLVs 1082 The OSPF Extend Prefix LSA TLV registry will define top-level TLVs 1083 for Extended Prefix LSAs and should be placed in the existing OSPF 1084 IANA registry. New values can be allocated via IETF Consensus or 1085 IESG Approval. 1087 Following initial values are allocated: 1089 o 0 - Reserved 1091 o 1 - OSPF Extended Prefix TLV 1093 The OSPF Extended Prefix sub-TLV registry will define will define 1094 sub-TLVs at any level of nesting for Extended Prefix LSAs and should 1095 be placed in the existing OSPF IANA registry. New values can be 1096 allocated via IETF Consensus or IESG Approval. 1098 Following initial values are allocated: 1100 o 0 - Reserved 1102 o 1 - SID/Label sub-TLV 1104 o 2 - Prefix SID sub-TLV 1106 o 3 - SID/Label Binding sub-TLV 1108 o 4 - IPv4 ERO sub-TLV 1110 o 5 - Unnumbered Interface ID ERO sub-TLV 1112 o 6 - IPv4 Backup ERO sub-TLV 1114 o 7 - Unnumbered Interface ID Backup ERO sub-TLV 1116 o 8 - ERO Metric sub-TLV 1118 The OSPF Extend Link LSA TLV registry will define top-level TLVs for 1119 Extended Link LSAs and should be placed in the existing OSPF IANA 1120 registry. New values can be allocated via IETF Consensus or IESG 1121 Approval. 1123 Following initial values are allocated: 1125 o 0 - Reserved 1127 o 1 - OSPFv2 Extended Link TLV 1129 The OSPF Extended Link LSA sub-TLV registry will define will define 1130 sub-TLVs at any level of nesting for Extended Link LSAs and should be 1131 placed in the existing OSPF IANA registry. New values can be 1132 allocated via IETF Consensus or IESG Approval. 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 8. Security Considerations 1144 In general, new LSAs defined in this document are subject to the same 1145 security concerns as those described in [RFC2328]. Additionally, 1146 implementations must assure that malformed TLV and Sub-TLV 1147 permutations do not result in errors which cause hard OSPF failures. 1149 9. Contributors 1151 The following people gave a substantial contribution to the content 1152 of this document: Ahmed Bashandy, Martin Horneffer, Bruno Decraene, 1153 Stephane Litkowski, Igor Milojevic, Rob Shakir and Saku Ytti. 1155 10. Acknowledgements 1157 We would like to thank Anton Smirnov for his contribution. 1159 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1160 contribution on earlier incarnations of the "Binding / MPLS Label 1161 TLV" in [I-D.gredler-ospf-label-advertisement]. 1163 11. References 1164 11.1. Normative References 1166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1167 Requirement Levels", BCP 14, RFC 2119, March 1997. 1169 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1171 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1172 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1173 Tunnels", RFC 3209, December 2001. 1175 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1176 in Resource ReSerVation Protocol - Traffic Engineering 1177 (RSVP-TE)", RFC 3477, January 2003. 1179 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1180 (TE) Extensions to OSPF Version 2", RFC 3630, 1181 September 2003. 1183 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1184 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1185 RFC 4915, June 2007. 1187 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1188 Shaffer, "Extensions to OSPF for Advertising Optional 1189 Router Capabilities", RFC 4970, July 2007. 1191 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1192 OSPF Opaque LSA Option", RFC 5250, July 2008. 1194 11.2. Informative References 1196 [I-D.filsfils-rtgwg-segment-routing] 1197 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1198 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1199 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1200 "Segment Routing Architecture", 1201 draft-filsfils-rtgwg-segment-routing-01 (work in 1202 progress), October 2013. 1204 [I-D.filsfils-rtgwg-segment-routing-use-cases] 1205 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1206 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1207 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1208 Crabbe, "Segment Routing Use Cases", 1209 draft-filsfils-rtgwg-segment-routing-use-cases-02 (work in 1210 progress), October 2013. 1212 [I-D.gredler-ospf-label-advertisement] 1213 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1214 "Advertising MPLS labels in OSPF", 1215 draft-gredler-ospf-label-advertisement-03 (work in 1216 progress), May 2013. 1218 [I-D.minto-rsvp-lsp-egress-fast-protection] 1219 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1220 egress fast-protection", 1221 draft-minto-rsvp-lsp-egress-fast-protection-03 (work in 1222 progress), November 2013. 1224 Authors' Addresses 1226 Peter Psenak (editor) 1227 Cisco Systems, Inc. 1228 Apollo Business Center 1229 Mlynske nivy 43 1230 Bratislava 821 09 1231 Slovakia 1233 Email: ppsenak@cisco.com 1235 Stefano Previdi (editor) 1236 Cisco Systems, Inc. 1237 Via Del Serafico, 200 1238 Rome 00142 1239 Italy 1241 Email: sprevidi@cisco.com 1243 Clarence Filsfils 1244 Cisco Systems, Inc. 1245 Brussels, 1246 Belgium 1248 Email: cfilsfil@cisco.com 1249 Hannes Gredler 1250 Juniper Networks, Inc. 1251 1194 N. Mathilda Ave. 1252 Sunnyvale, CA 94089 1253 US 1255 Email: hannes@juniper.net 1257 Rob Shakir 1258 British Telecom 1259 London 1260 UK 1262 Email: rob.shakir@bt.com 1264 Wim Henderickx 1265 Alcatel-Lucent 1266 Copernicuslaan 50 1267 Antwerp 2018 1268 BE 1270 Email: wim.henderickx@alcatel-lucent.com