idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-01.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 (July 3, 2014) is 3582 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 281 -- Looks like a reference, but probably isn't: '199' on line 281 -- Looks like a reference, but probably isn't: '1000' on line 282 -- Looks like a reference, but probably isn't: '1099' on line 282 -- Looks like a reference, but probably isn't: '500' on line 283 -- Looks like a reference, but probably isn't: '599' on line 283 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) Summary: 1 error (**), 0 flaws (~~), 2 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: January 4, 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 July 3, 2014 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-01 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 January 4, 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. OSPFv2 Extended Prefix Opaque LSA . . . . . . . . . . . . . . 7 75 4.1. OSPF Extended Prefix TLV . . . . . . . . . . . . . . . . 8 76 4.2. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . 9 77 4.3. SID/Label Binding sub-TLV . . . . . . . . . . . . . . . . 13 78 4.3.1. ERO Metric sub-TLV . . . . . . . . . . . . . . . . . 15 79 4.3.2. ERO sub-TLVs . . . . . . . . . . . . . . . . . . . . 15 80 5. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 20 81 5.1. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . 20 82 5.2. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . 21 83 5.3. Adj-SID sub-TLV . . . . . . . . . . . . . . . . . . . . . 21 84 5.4. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 23 85 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 24 86 6.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 24 87 6.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 25 88 6.3. SID for External Prefixes . . . . . . . . . . . . . . . . 26 89 6.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 26 90 6.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 26 91 6.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 27 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 93 7.1. OSPF Extend Prefix LSA TLV Registry . . . . . . . . . . . 27 94 7.2. OSPF Extend Prefix LSA sub-TLV Registry . . . . . . . . . 28 95 7.3. OSPF Extend Link LSA TLV Registry . . . . . . . . . . . . 29 96 7.4. OSPF Extend Link LSA sub-TLV Registry . . . . . . . . . . 29 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 99 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 103 11.2. Informative References . . . . . . . . . . . . . . . . . 31 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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 (defined in [RFC5250]) are defined. These new LSAs are 139 defined as generic containers that can be used to advertise any 140 additional attributes associated with the prefix or link. These new 141 Opaque LSAs are complementary to the existing LSAs and are not aimed 142 to replace any of the existing LSAs. 144 2.1. SID/Label sub-TLV 146 SID/Label sub-TLV appears in multiple TLVs or sub-TLVs defined later 147 in this document. It is used to advertise SID or label associated 148 with the prefix or adjacency. SID/Label TLV has following format: 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Type | Length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | SID/Label (variable) | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 where: 160 Type: TBD, suggested value 1 162 Length: variable, 3 or 4 bytes 164 SID/Label: if length is set to 3, then the 20 rightmost bits 165 represent a label. If length is set to 4 then the value 166 represents a 32 bit SID. 168 The receiving router MUST ignore SID/Label sub-TLV if the length 169 is other then 3 or 4. 171 3. Segment Routing Capabilities 173 Segment Routing requires some additional router capabilities to be 174 advertised to other routers in the area. 176 These SR capabilities are advertised in the Router Information Opaque 177 LSA (defined in [RFC4970]). 179 3.1. SR-Algorithm TLV 181 SR-Algorithm TLV is a top-level TLV of the Router Information Opaque 182 LSA (defined in [RFC4970]). 184 The SR-Algorithm Sub-TLV is optional, it MAY only appear once inside 185 the Router Informational Opaque LSA. If the SID/Label Range TLV, as 186 defined in Section 3.2, is advertised, then SR-Algorithm TLV MUST 187 also be advertised. 189 As SR Router may use various algorithms when calculating reachability 190 to OSPF routers or prefixes in an OSPF area. Examples of these 191 algorithms are metric based Shortest Path First (SPF), various 192 flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a 193 router to advertise the algorithms that the router is currently using 194 to other routers in an OSPF area. The SR-Algorithm TLV has following 195 format: 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Type | Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Algorithm 1 | Algorithm... | Algorithm n | | 203 +- -+ 204 | | 205 + + 207 where: 209 Type: TBD, suggested value 8 211 Length: variable 213 Algorithm: Single octet identifying the algorithm. The following 214 value is defined by this document: 216 0: IGP metric based Shortest Path Tree (SPT) 218 The RI LSA can be advertised at any of the defined opaque flooding 219 scopes (link, area, or Autonomous System (AS)). For the purpose of 220 the SR-Algorithm TLV propagation, area scope flooding is required. 222 3.2. SID/Label Range TLV 224 The SID/Label Range TLV is a top-level TLV of Router Information 225 Opaque LSA (defined in [RFC4970]). 227 The SID/Label Range TLV MAY appear multiple times and has the 228 following format: 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type | Length | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Range Size | Reserved | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Sub-TLVs (variable) | 238 +- -+ 239 | | 240 + + 242 where: 244 Type: TBD, suggested value 9 246 Length: variable 248 Range Size: 3 octet of the SID/label range 250 Currently the only supported Sub-TLV is the SID/Label TLV as defined 251 in Section 2.1. The SID/Label advertised in SID/Label TLV represents 252 the first SID/Label in the advertised range. 254 Multiple occurrence of the SID/Label Range TLV MAY be advertised, in 255 order to advertise multiple ranges. In such case: 257 o The originating router MUST encode each range into a different 258 SID/Label Range TLV. 260 o The originating router decides in which order the set of SID/Label 261 Range TLVs are advertised inside Router Information Opaque LSA. 262 The originating router MUST ensure the order is same after a 263 graceful restart (using checkpointing, non-volatile storage or any 264 other mechanism) in order to SID/label range and SID index 265 correspondence is preserved across graceful restarts. 267 o The receiving router must adhere to the order in which the ranges 268 are advertised when calculating a SID/label from a SID index. 270 The following example illustrates the advertisement of multiple 271 ranges: 273 The originating router advertises following ranges: 274 Range 1: [100, 199] 275 Range 2: [1000, 1099] 276 Range 3: [500, 599] 278 The receiving routers concatenate the ranges and build the SRGB 279 is as follows: 281 SRGB = [100, 199] 282 [1000, 1099] 283 [500, 599] 285 The indexes span multiple ranges: 287 index=0 means label 100 288 ... 289 index 99 means label 199 290 index 100 means label 1000 291 index 199 means label 1099 292 ... 293 index 200 means label 500 294 ... 296 The RI LSA can be advertised at any of the defined flooding scopes 297 (link, area, or autonomous system (AS)). For the purposes of the SR- 298 Capability TLV propagation, area scope flooding is required. 300 4. OSPFv2 Extended Prefix Opaque LSA 302 A new Opaque LSA (defined in [RFC5250]) is defined in OSPFv2 in order 303 to advertise additional prefix attributes: OSPFv2 Extended Prefix 304 Opaque LSA. 306 Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by an 307 OSPFv2 router. The flooding scope of the OSPFv2 Extended Prefix 308 Opaque LSA depends on the scope of the advertised prefixes and is 309 under the control of the advertising router. In some cases (e.g., 310 mapping server deployment), the LSA flooding scope may be greater 311 than the scope of the corresponding prefixes. 313 The format of the OSPFv2 Extended Prefix Opaque LSA is as follows: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | LS age | Options | 9, 10, or 11 | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Opaque type | Instance | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Advertising Router | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | LS sequence number | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | LS checksum | length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | 329 +- TLVs -+ 330 | ... | 332 The opaque type used by OSPFv2 Extended Prefix Opaque LSA is 7. 334 The format of the TLVs within the body of the LSA is the same as the 335 format used by the Traffic Engineering Extensions to OSPF defined in 336 [RFC3630]. The LSA payload consists of one or more nested 337 Type/Length/Value (TLV) triplets. The format of each TLV is: 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Type | Length | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Value... | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 The Length field defines the length of the value portion in octets. 348 The TLV is padded to 4-octet alignment; padding is not included in 349 the length field. Nested TLVs are also 32-bit aligned. Unrecognized 350 types are ignored. 352 4.1. OSPF Extended Prefix TLV 354 The OSPF Extended Prefix TLV is used in order to advertise additional 355 attributes associated with the prefix. Multiple OSPF Extended Prefix 356 TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but 357 all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA 358 MUST have the same flooding scope. The OSPF Extended Prefix TLV has 359 the following format: 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Type | Length | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Route Type | Prefix Length | AF | Reserved | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Address Prefix (variable) | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Sub-TLVs (variable) | 371 +- -+ 372 | | 374 where: 376 Type: TBD, suggested value 1. 378 Length: variable 380 Route type: type of the OSPF route. Supported types are: 382 0 - unspecified 383 1 - intra-area 384 3 - inter-area 385 5 - external 386 7 - NSSA external 388 If the route type is 0 (unspecified), the information inside the 389 OSPF External Prefix TLV applies to the prefix regardless of 390 prefix's route-type. This is useful when some prefix specific 391 attributes are advertised by some external entity, which is not 392 aware of the route-type associated with the prefix. 394 Prefix length: length of the prefix 396 AF: 0 - IPv4 unicast 398 Address Prefix: the prefix itself encoded as an even multiple of 399 32-bit words, padded with zeroed bits as necessary. This encoding 400 consumes ((PrefixLength + 31) / 32) 32-bit words. The default 401 route is represented by a prefix of length 0. 403 4.2. Prefix SID Sub-TLV 405 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV. 406 It MAY appear more than once and has following format: 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type | Length | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Flags | Reserved | MT-ID | Algorithm | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Range Size | Reserved + 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | SID/Index/Label (variable) | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 where: 422 Type: TBD, suggested value 2. 424 Length: variable 426 Flags: 1 octet field. The following flags are defined: 428 0 1 2 3 4 5 6 7 429 +--+--+--+--+--+--+--+--+ 430 |N |NP|M |E |V |L | | | 431 +--+--+--+--+--+--+--+--+ 433 where: 435 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 436 the router identified by the prefix. Typically, the N-Flag is 437 set on Prefix-SIDs attached to a router loopback address. The 438 N-Flag is set when the Prefix-SID is a Node-SID, as described 439 in [I-D.filsfils-rtgwg-segment-routing]. 441 NP-Flag: no-PHP flag. If set, then the penultimate hop MUST 442 NOT pop the Prefix-SID before delivering the packet to the node 443 that advertised the Prefix-SID. 445 M-Flag: Mapping Server Flag. If set, the SID is advertised 446 from the Segment Routing Mapping Server functionality as 447 described in [I-D.filsfils-rtgwg-segment-routing]. 449 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 450 the Prefix-SID originator MUST replace the Prefix-SID with a 451 Prefix-SID having an Explicit-NULL value (0 for IPv4) before 452 forwarding the packet. 454 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 455 carries an absolute value. If not set, then the Prefix-SID 456 carries an index. 458 The L-Flag: Local/Global Flag. If set, then the value/index 459 carried by the PrefixSID has local significance. If not set, 460 then the value/index carried by this subTLV has global 461 significance. 463 Other bits: MUST be zero when sent and ignored when received. 465 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 467 Algorithm: one octet identifying the algorithm the Prefix-SID is 468 associated with as defined in Section 3.1. 470 Range size: this field provides the ability to specify a range of 471 addresses and their associated Prefix SIDs. It represents a 472 compression scheme to distribute a continuous Prefix and their 473 continuous, corresponding SID/Label Block. If a single SID is 474 advertised then the Range Size field MUST be set to one. For 475 range advertisements > 1, Range Size represents the number of 476 addresses that need to be mapped into a Prefix-SID. 478 SID/Index/Label: according to the V and L flags, it contains 479 either: 481 A 32 bit index defining the offset in the SID/Label space 482 advertised by this router. 484 A 24 bit label where the 20 rightmost bits are used for 485 encoding the label value. 487 If multiple Prefix-SIDs are advertised for the same prefix, the 488 receiving router MUST use the first encoded SID and MAY use the 489 subsequent ones. 491 When propagating Prefix-SIDs between areas, if multiple prefix-SIDs 492 are advertised for a prefix, an implementation SHOULD preserve the 493 original ordering, when advertising prefix-SIDs to other areas. This 494 allows implementations that only use single Prefix-SID to have a 495 consistent view across areas. 497 When calculating the outgoing label for the prefix, the router MUST 498 take into account E and P flags advertised by the next-hop router, if 499 next-hop router advertised the SID for the prefix. This MUST be done 500 regardless of next-hop router contributing to the best path to the 501 prefix or not. 503 NP-Flag (no-PHP) MUST be set on the Prefix-SIDs allocated to inter- 504 area prefixes that are originated by the ABR based on intra-area or 505 inter-area reachability between areas. In case the inter-area prefix 506 is generated based on the prefix which is directly attached to the 507 ABR, NP-Flag SHOULD NOT be set 509 NP-flag (no-PHP) MUST NOT be set on the Prefix-SIDs allocated to 510 redistributed prefixes, unless the redistributed prefix is directly 511 attached to ASBR, in which case the NP-flag SHOULD NOT be set. 513 If the NP-flag is not set then any upstream neighbor of the Prefix- 514 SID originator MUST pop the Prefix-SID. This is equivalent to the 515 penultimate hop popping mechanism used in the MPLS dataplane. In 516 such case MPLS EXP bits of the Prefix-SID are not preserved to the 517 ultimate hop (the Prefix-SID being removed). If the NP-flag is clear 518 the received E-flag is ignored. 520 If the NP-flag is set then: 522 If the E-flag is not set then any upstream neighbor of the Prefix- 523 SID originator MUST keep the Prefix-SID on top of the stack. This 524 is useful when the originator of the Prefix-SID must stitch the 525 incoming packet into a continuing MPLS LSP to the final 526 destination. This could occur at an inter-area border router 527 (prefix propagation from one area to another) or at an inter- 528 domain border router (prefix propagation from one domain to 529 another). 531 If the E-flag is set then any upstream neighbor of the Prefix-SID 532 originator MUST replace the PrefixSID with a Prefix-SID having an 533 Explicit-NULL value. This is useful, e.g., when the originator of 534 the Prefix-SID is the final destination for the related prefix and 535 the originator wishes to receive the packet with the original EXP 536 bits. 538 When M-Flag is set, NP-flag MUST be set and E-bit MUST NOT be set. 540 Example 1: if the following router addresses (loopback addresses) 541 need to be mapped into the corresponding Prefix SID indexes: 543 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 544 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 545 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 546 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 548 then the Prefix field in Extended Prefix TLV would be set to 549 192.0.2.1, Prefix Length would be set to 32, Range Size in Prefix SID 550 sub-TLV would be 4 and Index value would be set to 1. 552 Example 2: If the following prefixes need to be mapped into the 553 corresponding Prefix-SID indexes: 555 10.1.1/24, Prefix-SID: Index 51 556 10.1.2/24, Prefix-SID: Index 52 557 10.1.3/24, Prefix-SID: Index 53 558 10.1.4/24, Prefix-SID: Index 54 559 10.1.5/24, Prefix-SID: Index 55 560 10.1.6/24, Prefix-SID: Index 56 561 10.1.7/24, Prefix-SID: Index 57 563 then the Prefix field in Extended Prefix TLV would be set to 564 10.1.1.0, Prefix Length would be set to 24, Range Size in Prefix SID 565 sub-TLV would be 7 and Index value would be set to 51. 567 4.3. SID/Label Binding sub-TLV 569 The SID/Label Binding sub-TLV is used to advertise a SID/Label 570 mapping for a path to the prefix. 572 The SID/Label Binding TLV MAY be originated by any router in an OSPF 573 domain. The router may advertise a SID/Label binding to a FEC along 574 with at least a single 'nexthop style' anchor. The protocol supports 575 more than one 'nexthop style' anchor to be attached to a SID/Label 576 binding, which results in a simple path description language. In 577 analogy to RSVP, the terminology for this is called an 'Explicit 578 Route Object' (ERO). Since ERO style path notation allows to anchor 579 SID/label bindings to both link and node IP addresses, any label 580 switched path can be described. Additionally, SID/Label Bindings 581 from external protocols can be easily re-advertised. 583 The SID/Label Binding TLV may be used for advertising SID/Label 584 Bindings and their associated Primary and Backup paths. In a single 585 TLV, a primary ERO Path, backup ERO Path, or both can be advertised. 586 If a router wants to advertise multiple parallel paths, then it can 587 generate several TLVs for the same Prefix/FEC. Each occurrence of a 588 Binding TLV for a given FEC Prefix will add a new path. 590 The SID/Label Binding sub-TLV is a sub-TLV of the OSPF Extended 591 Prefix TLV. Multiple SID/Label Binding TLVs can be present in OSPF 592 Extended Prefix TLV. The SID/Label Binding sub-TLV has following 593 format: 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Type | Length | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Flags | Reserved | MT-ID | Weight | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Range Size | Reserved + 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Sub-TLVs (variable) | 605 +- -+ 606 | | 608 where: 610 Type: TBD, suggested value 3 612 Length: variable 614 Flags: 1 octet field of following flags: 616 0 1 2 3 4 5 6 7 617 +-+-+-+-+-+-+-+-+ 618 |M| | 619 +-+-+-+-+-+-+-+-+ 621 where: 623 M-bit - When the bit is set the binding represents the 624 mirroring context as defined in 625 [I-D.minto-rsvp-lsp-egress-fast-protection]. 627 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 629 Weight: weight used for load-balancing purposes. The use of the 630 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 632 Range Size: usage is the same as described in Section 4.2. 634 The SID/Label Binding TLV supports the following Sub-TLVs: 636 SID/Label sub-TLV as described in Section 2.1. This sub-TLV MUST 637 appear in the SID/Label Binding Sub-TLV and it MUST only appear 638 once. 640 ERO Metric sub-TLV as defined in Section 4.3.1. 642 ERO sub-TLVs as defined in Section 4.3.2. 644 4.3.1. ERO Metric sub-TLV 646 ERO Metric sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 648 The ERO Metric sub-TLV advertises the cost of an ERO path. It is 649 used to compare the cost of a given source/destination path. A 650 router SHOULD advertise the ERO Metric sub-TLV. The cost of the ERO 651 Metric sub-TLV SHOULD be set to the cumulative IGP or TE path cost of 652 the advertised ERO. Since manipulation of the Metric field may 653 attract or repel traffic to and from the advertised segment, it MAY 654 be manually overridden. 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Type | Length | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Metric (4 octets) | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 ERO Metric sub-TLV format 666 where: 668 Type: TBD, suggested value 8 670 Length: 4 bytes 672 Metric: 4 bytes 674 4.3.2. ERO sub-TLVs 676 All 'ERO' information represents an ordered set which describes the 677 segments of a path. The last ERO sub-TLV describes the segment 678 closest to the egress point, contrary the first ERO sub-TLV describes 679 the first segment of a path. If a router extends or stitches a path 680 it MUST prepend the new segments path information to the ERO list. 682 The above similarly applies to backup EROs. 684 All ERO Sub-TLVs must immediately follow the (SID)/Label Sub-TLV. 686 All Backup sub-ERO TLVs must immediately follow last ERO Sub-TLV. 688 4.3.2.1. IPv4 ERO sub-TLV 690 IPv4 ERO sub-TLV is a sub-TLV of the SID/Label Binding sub-TLV. 692 The IPv4 ERO sub-TLV describes a path segment using IPv4 Address 693 style of encoding. Its semantics have been borrowed from [RFC3209]. 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Type | Length | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Flags | Reserved | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | IPv4 Address (4 octets) | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 IPv4 ERO sub-TLV format 707 where: 709 Type: TBD, suggested value 4 711 Length: 8 bytes 713 Flags: 1 octet field of following flags: 715 0 1 2 3 4 5 6 7 716 +-+-+-+-+-+-+-+-+ 717 |L| | 718 +-+-+-+-+-+-+-+-+ 720 where: 722 L-bit - If the L bit is set, then the value of the attribute is 723 'loose.' Otherwise, the value of the attribute is 'strict.' 725 IPv4 Address - the address of the explicit route hop. 727 4.3.2.2. Unnumbered Interface ID ERO sub-TLV 729 Unnumbered Interface ID ERO sub-TLV is a sub-TLV of the SID/Label 730 Binding sub-TLV. 732 The appearance and semantics of the 'Unnumbered Interface ID' have 733 been borrowed from [RFC3477]. 735 The Unnumbered Interface-ID ERO sub-TLV describes a path segment that 736 includes an unnumbered interface. Unnumbered interfaces are 737 referenced using the interface index. Interface indices are assigned 738 local to the router and therefore not unique within a domain. All 739 elements in an ERO path need to be unique within a domain and hence 740 need to be disambiguated using a domain unique Router-ID. 742 0 1 2 3 743 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 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Type | Length | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Flags | Reserved | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Router ID | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Interface ID | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 where: 756 Unnumbered Interface ID ERO sub-TLV format 758 Type: TBD, suggested value 5 760 Length: 12 bytes 762 Flags: 1 octet field of following flags: 764 0 1 2 3 4 5 6 7 765 +-+-+-+-+-+-+-+-+ 766 |L| | 767 +-+-+-+-+-+-+-+-+ 769 where: 771 L-bit - If the L bit is set, then the value of the attribute is 772 'loose.' Otherwise, the value of the attribute is 'strict.' 774 Router-ID: Router-ID of the next-hop. 776 Interface ID: is the identifier assigned to the link by the router 777 specified by the Router-ID. 779 4.3.2.3. IPv4 Backup ERO sub-TLV 781 IPv4 Prefix Backup ERO sub-TLV is a Sub-TLV of the SID/Label Binding 782 sub-TLV. 784 The IPv4 Backup ERO sub-TLV describes a path segment using IPv4 785 Address style of encoding. Its semantics have been borrowed from 786 [RFC3209]. 788 0 1 2 3 789 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 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Type | Length | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Flags | Reserved | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | IPv4 Address (4 octets) | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 IPv4 Backup ERO sub-TLV format 800 where: 802 Type: TBD, suggested value 6 804 Length: 8 bytes 806 Flags: 1 octet field of following flags: 808 0 1 2 3 4 5 6 7 809 +-+-+-+-+-+-+-+-+ 810 |L| | 811 +-+-+-+-+-+-+-+-+ 813 where: 815 L-bit - If the L bit is set, then the value of the attribute is 816 'loose.' Otherwise, the value of the attribute is 'strict.' 818 IPv4 Address - the address of the explicit route hop. 820 4.3.2.4. Unnumbered Interface ID Backup ERO sub-TLV 822 Unnumbered Interface ID Backup sub-TLV is a sub-TLV of the SID/Label 823 Binding sub-TLV. 825 The appearance and semantics of the 'Unnumbered Interface ID' have 826 been borrowed from [RFC3477]. 828 The Unnumbered Interface-ID ERO sub-TLV describes a path segment that 829 includes an unnumbered interface. Unnumbered interfaces are 830 referenced using the interface index. Interface indices are assigned 831 local to the router and therefore not unique within a domain. All 832 elements in an ERO path need to be unique within a domain and hence 833 need to be disambiguated using a domain unique Router-ID. 835 0 1 2 3 836 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 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Type | Length | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Flags | Reserved | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Router ID | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Interface ID | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 Unnumbered Interface ID Backup ERO sub-TLV format 849 where: 851 Type: TBD, suggested value 7 853 Length: 12 bytes 855 Flags: 1 octet field of following flags: 857 0 1 2 3 4 5 6 7 858 +-+-+-+-+-+-+-+-+ 859 |L| | 860 +-+-+-+-+-+-+-+-+ 862 where: 864 L-bit - If the L bit is set, then the value of the attribute is 865 'loose.' Otherwise, the value of the attribute is 'strict.' 867 Router-ID: Router-ID of the next-hop. 869 Interface ID: is the identifier assigned to the link by the router 870 specified by the Router-ID. 872 5. Adjacency Segment Identifier (Adj-SID) 874 An Adjacency Segment Identifier (Adj-SID) represents a router 875 adjacency in Segment Routing. 877 5.1. OSPFv2 Extended Link Opaque LSA 879 A new Opaque LSA (defined in [RFC5250] is defined in OSPFv2 in order 880 to advertise additional link attributes: the OSPFv2 Extended Link 881 Opaque LSA. 883 The OSPFv2 Extended Link Opaque LSA has an area flooding scope. 884 Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a 885 single router in an area. 887 The format of the OSPFv2 Extended Link Opaque LSA is as follows: 889 0 1 2 3 890 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 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | LS age | Options | 10 | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Opaque type | Instance | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Advertising Router | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | LS sequence number | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | LS checksum | length | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | | 903 +- TLVs -+ 904 | ... | 906 Opaque type used by OSPFv2 Extended Link Opaque LSA is 8. 908 The format of the TLVs within the body of LSA is the same as the 909 format used by the Traffic Engineering Extensions to OSPF defined in 910 [RFC3630]. The LSA payload consists of one or more nested 911 Type/Length/Value (TLV) triplets. The format of each TLV is: 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Type | Length | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Value... | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 The Length field defines the length of the value portion in octets. 921 The TLV is padded to 4-octet alignment; padding is not included in 922 the length field. Nested TLVs are also 32-bit aligned. Unrecognized 923 types are ignored. 925 5.2. OSPFv2 Extended Link TLV 927 OSPFv2 Extended Link TLV is used in order to advertise various 928 attributes of the link. It describes a single link and is 929 constructed of a set of Sub-TLVs. There are no ordering requirements 930 for the Sub-TLVs. Only one Extended Link TLV SHALL be advertised in 931 each Extended Link Opaque LSA, allowing for fine granularity changes 932 in the topology. 934 The Extended Link TLV has following format: 936 0 1 2 3 937 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 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Type | Length | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Link-Type | Reserved | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Link ID | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Link Data | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Sub-TLVs (variable) | 948 +- -+ 949 | | 951 where: 953 Type is 1. 955 Length is variable. 957 Link-Type: as defined in section A.4.2 of [RFC2328]. 959 Link-ID: as defined in section A.4.2 of [RFC2328]. 961 Link Data: as defined in section A.4.2 of [RFC2328]. 963 5.3. Adj-SID sub-TLV 965 Adj-SID is an optional sub-TLV of the Extended Link TLV. It MAY 966 appear multiple times in the Extended Link TLV. Examples where more 967 than one Adj-SID may be used per neighbor are described in 969 [I-D.filsfils-rtgwg-segment-routing-use-cases]. The Adj-SID sub-TLV 970 has the following format: 972 0 1 2 3 973 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 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Type | Length | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Flags | Reserved | MT-ID | Weight | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | SID/Label/Index (variable) | 980 +---------------------------------------------------------------+ 982 where: 984 Type: TBD, suggested value 2. 986 Length: variable. 988 Flags. 1 octet field of following flags: 990 0 1 2 3 4 5 6 7 991 +-+-+-+-+-+-+-+-+ 992 |B|V|L|S| | 993 +-+-+-+-+-+-+-+-+ 995 where: 997 B-Flag: Backup-flag: set if the Adj-SID refers to an adjacency 998 being protected (e.g.: using IPFRR or MPLS-FRR) as described in 999 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 1001 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 1002 carries an absolute value. If not set, then the Prefix-SID 1003 carries an index. 1005 The L-Flag: Local/Global Flag. If set, then the value/index 1006 carried by the PrefixSID has local significance. If not set, 1007 then the value/index carried by this subTLV has global 1008 significance. 1010 The S-Flag. Set Flag. When set, the S-Flag indicates that the 1011 Adj-SID refers to a set of adjacencies (and therefore MAY be 1012 assigned to other adjacencies as well). 1014 Other bits: MUST be zero when originated and ignored when 1015 received. 1017 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1019 Weight: weight used for load-balancing purposes. The use of the 1020 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 1022 SID/Index/Label: according to the V and L flags, it contains 1023 either: 1025 A 32 bit index defining the offset in the SID/Label space 1026 advertised by this router. 1028 A 24 bit label where the 20 rightmost bits are used for 1029 encoding the label value. 1031 An SR capable router MAY allocate an Adj-SID for each of its 1032 adjacencies and set the B-Flag when the adjacency is protected by an 1033 FRR mechanism (IP or MPLS) as described in 1034 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 1036 5.4. LAN Adj-SID Sub-TLV 1038 LAN Adj-SID is an optional sub-TLV of the Extended Link TLV. It MAY 1039 appear multiple times in Extended Link TLV. It is used to advertise 1040 SID/Label for adjacency to non-DR node on broadcast or NBMA network. 1042 0 1 2 3 1043 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 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Type | Length | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Flags | Reserved | MT-ID | Weight | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Neighbor ID | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | SID/Label/Index (variable) | 1052 +---------------------------------------------------------------+ 1054 where: 1056 Type: TBD, suggested value 3. 1058 Length: variable. 1060 Flags. 1 octet field of following flags: 1062 0 1 2 3 4 5 6 7 1063 +-+-+-+-+-+-+-+-+ 1064 |B|V|L|S| | 1065 +-+-+-+-+-+-+-+-+ 1067 where: 1069 B-Flag: Backup-flag: set if the LAN-Adj-SID refer to an 1070 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 1071 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 1073 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 1074 carries an absolute value. If not set, then the Prefix-SID 1075 carries an index. 1077 The L-Flag: Local/Global Flag. If set, then the value/index 1078 carried by the PrefixSID has local significance. If not set, 1079 then the value/index carried by this subTLV has global 1080 significance. 1082 The S-Flag. Set Flag. When set, the S-Flag indicates that the 1083 Adj-SID refers to a set of adjacencies (and therefore MAY be 1084 assigned to other adjacencies as well). 1086 Other bits: MUST be zero when originated and ignored when 1087 received. 1089 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1091 Weight: weight used for load-balancing purposes. The use of the 1092 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 1094 SID/Index/Label: according to the V and L flags, it contains 1095 either: 1097 A 32 bit index defining the offset in the SID/Label space 1098 advertised by this router. 1100 A 24 bit label where the 20 rightmost bits are used for 1101 encoding the label value. 1103 6. Elements of Procedure 1105 6.1. Intra-area Segment routing in OSPFv2 1107 The OSPFv2 node that supports segment routing MAY advertise Prefix- 1108 SIDs for any prefix to which it is advertising reachability (e.g., a 1109 loopback IP address as described in Section 4.2). 1111 If multiple routers advertise Prefix-SID for the same prefix, then 1112 the Prefix-SID MUST be the same. This is required in order to allow 1113 traffic load-balancing if multiple equal cost paths to the 1114 destination exist in the network. 1116 Prefix-SID can also be advertised by the SR Mapping Servers (as 1117 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]). The 1118 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 1119 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 1120 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 1121 MUST be advertised by all of them. The flooding scope of the OSPF 1122 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 1123 could be either area scoped or AS scoped and is determined based on 1124 the configuration of the SR Mapping Server. 1126 6.2. Inter-area Segment routing in OSPFv2 1128 In order to support SR in a multi-area environment, OSPFv2 must 1129 propagate Prefix-SID information between areas. The following 1130 procedure is used in order to propagate Prefix SIDs between areas. 1132 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 1133 prefix to all its connected areas, it will also originate an Extended 1134 Prefix Opaque LSA, as described in Section 4. The flooding scope of 1135 the Extended Prefix Opaque LSA type will be set to area-scope. The 1136 route-type in OSPF Extended Prefix TLV is set to inter-area. The 1137 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1138 value will be set as follows: 1140 The ABR will look at its best path to the prefix in the source 1141 area and find the advertising router associated with its best path 1142 to that prefix. 1144 If no Prefix-SID was advertised for the prefix in the source area 1145 by the router that contributes to the best path to the prefix, 1146 then the ABR will use the Prefix-SID advertised by any other 1147 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 1148 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 1149 propagating the Prefix-SID for the prefix to other areas. 1151 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 1152 route to all its connected areas it will also originate an Extended 1153 Prefix Opaque LSA, as described in Section 4. The flooding scope of 1154 the Extended Prefix Opaque LSA type will be set to area-scope. The 1155 route-type in OSPF Extended Prefix TLV is set to inter-area. The 1156 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1157 will be set as follows: 1159 The ABR will look at its best path to the prefix in the source 1160 area and find the advertising router associated with its best path 1161 to that prefix. 1163 The ABR will then determine if such router advertised a Prefix-SID 1164 for the prefix and use it when advertising the Prefix-SID to other 1165 connected areas. 1167 If no Prefix-SID was advertised for the prefix in the source area 1168 by the ABR that contributes to the best path to the prefix, the 1169 originating ABR will use the Prefix-SID advertised by any other 1170 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 1171 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 1172 propagating the Prefix-SID for the prefix to other areas. 1174 6.3. SID for External Prefixes 1176 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1177 SR, generates Type-5 LSAs, it should also originate an Extended 1178 Prefix Opaque LSAs, as described in Section 4. The flooding scope of 1179 the Extended Prefix Opaque LSA type is set to AS-scope. The route- 1180 type in OSPF Extended Prefix TLV is set to external. The Prefix-SID 1181 sub-TLV is included in this LSA and the Prefix-SID value will be set 1182 to the SID that has been reserved for that prefix. 1184 When a NSSA ASBR translates Type-7 LSAs into Type-5 LSAs, it should 1185 also advertise the Prefix-SID for the prefix. The NSSA ABR 1186 determines its best path to the prefix advertised in the translated 1187 Type-7 LSA and finds the advertising router associated with such 1188 path. If such advertising router has advertised a Prefix-SID, for 1189 the prefix, then the NSSA ASBR uses it when advertising the Prefix- 1190 SID for the Type-5 prefix. Otherwise, the Prefix-SID advertised by 1191 any other router will be used (e.g.: a Prefix-SID coming from an SR 1192 Mapping Server as defined in 1193 [I-D.filsfils-rtgwg-segment-routing-use-cases]). 1195 6.4. Advertisement of Adj-SID 1197 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1198 using the Adj-SID Sub-TLV as described in Section 5. 1200 6.4.1. Advertisement of Adj-SID on Point-to-Point Links 1202 Adj-SID MAY be advertised for any adjacency on a p2p link that is in 1203 neighbor state 2-Way or higher. If the adjacency on a p2p link 1204 transitions from the FULL state, then the Adj-SID for that adjacency 1205 MAY be removed from the area. If the adjacency transitions to a 1206 state lower then 2-Way, then the Adj-SID MUST be removed from the 1207 area. 1209 6.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1211 Broadcast or NBMA networks in OSPF are represented by a star topology 1212 where the Designated Router (DR) is the central point all other 1213 routers on the broadcast or NBMA network connect to. As a result, 1214 routers on the broadcast or NBMA network advertise only their 1215 adjacency to DR and BDR. Routers that are neither DR nor BDR do not 1216 form and do not advertise adjacencies between them. They, however, 1217 maintain a 2-Way adjacency state between them. 1219 When Segment Routing is used, each router on the broadcast or NBMA 1220 network MAY advertise the Adj-SID for its adjacency to DR using Adj- 1221 SID Sub-TLV as described in Section 5.3. 1223 SR capable router MAY also advertise Adj-SID for other neighbors 1224 (e.g. BDR, DR-OTHER) on broadcast or NBMA network using the LAN ADJ- 1225 SID Sub-TLV as described in section 5.1.1.2. Section 5.4. 1227 7. IANA Considerations 1229 This specification updates two existing OSPF registries. 1231 Opaque Link-State Advertisements (LSA) Option Types: 1233 o suggested value 7 - OSPFv2 Extended Prefix Opaque LSA 1235 o suggested value 8 - OSPFv2 Extended Link Opaque LSA 1237 OSPF Router Information (RI) TLVs: 1239 o suggested value 8 - SR-Algorithm TLV 1241 o suggested value 9 - SID/Label Range TLV 1243 This specification also creates four new registries: 1245 - OSPF Extended Prefix LSA TLVs and sub-TLVs 1247 - OSPF Extended Link LSA TLVs and sub-TLVs 1249 7.1. OSPF Extend Prefix LSA TLV Registry 1251 The OSPF Extend Prefix LSA TLV registry will define top-level TLVs 1252 for Extended Prefix LSAs and should be placed in the existing OSPF 1253 IANA registry. New values can be allocated via IETF Consensus or 1254 IESG Approval. 1256 Following initial values are allocated: 1258 o 0 - Reserved 1260 o 1 - OSPF Extended Prefix TLV 1262 Types in the range 32768-32023 are for experimental use; these will 1263 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1265 Types in the range 32023-65535 are not to be assigned at this time. 1266 Before any assignments can be made in this range, there MUST be a 1267 Standards Track RFC that specifies IANA Considerations that covers 1268 the range being assigned. 1270 7.2. OSPF Extend Prefix LSA sub-TLV Registry 1272 The OSPF Extended Prefix sub-TLV registry will define will define 1273 sub-TLVs at any level of nesting for Extended Prefix LSAs and should 1274 be placed in the existing OSPF IANA registry. New values can be 1275 allocated via IETF Consensus or IESG Approval. 1277 Following initial values are allocated: 1279 o 0 - Reserved 1281 o 1 - SID/Label sub-TLV 1283 o 2 - Prefix SID sub-TLV 1285 o 3 - SID/Label Binding sub-TLV 1287 o 4 - IPv4 ERO sub-TLV 1289 o 5 - Unnumbered Interface ID ERO sub-TLV 1291 o 6 - IPv4 Backup ERO sub-TLV 1293 o 7 - Unnumbered Interface ID Backup ERO sub-TLV 1295 o 8 - ERO Metric sub-TLV 1297 Types in the range 32768-32023 are for experimental use; these will 1298 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1300 Types in the range 32023-65535 are not to be assigned at this time. 1301 Before any assignments can be made in this range, there MUST be a 1302 Standards Track RFC that specifies IANA Considerations that covers 1303 the range being assigned. 1305 7.3. OSPF Extend Link LSA TLV Registry 1307 The OSPF Extend Link LSA TLV registry will define top-level TLVs for 1308 Extended Link LSAs and should be placed in the existing OSPF IANA 1309 registry. New values can be allocated via IETF Consensus or IESG 1310 Approval. 1312 Following initial values are allocated: 1314 o 0 - Reserved 1316 o 1 - OSPFv2 Extended Link TLV 1318 Types in the range 32768-32023 are for experimental use; these will 1319 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1321 Types in the range 32023-65535 are not to be assigned at this time. 1322 Before any assignments can be made in this range, there MUST be a 1323 Standards Track RFC that specifies IANA Considerations that covers 1324 the range being assigned. 1326 7.4. OSPF Extend Link LSA sub-TLV Registry 1328 The OSPF Extended Link LSA sub-TLV registry will define will define 1329 sub-TLVs at any level of nesting for Extended Link LSAs and should be 1330 placed in the existing OSPF IANA registry. New values can be 1331 allocated via IETF Consensus or IESG Approval. 1333 Following initial values are allocated: 1335 o 1 - SID/Label sub-TLV 1337 o 2 - Adj-SID sub-TLV 1339 o 3 - LAN Adj-SID/Label Sub-TLV 1341 Types in the range 32768-32023 are for experimental use; these will 1342 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1344 Types in the range 32023-65535 are not to be assigned at this time. 1345 Before any assignments can be made in this range, there MUST be a 1346 Standards Track RFC that specifies IANA Considerations that covers 1347 the range being assigned. 1349 8. Security Considerations 1351 In general, new LSAs defined in this document are subject to the same 1352 security concerns as those described in [RFC2328]. Additionally, 1353 implementations must assure that malformed TLV and Sub-TLV 1354 permutations do not result in errors which cause hard OSPF failures. 1356 9. Contributors 1358 The following people gave a substantial contribution to the content 1359 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1360 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1361 Saku Ytti. 1363 10. Acknowledgements 1365 We would like to thank Anton Smirnov for his contribution. 1367 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1368 contribution on earlier incarnations of the "Binding / MPLS Label 1369 TLV" in [I-D.gredler-ospf-label-advertisement]. 1371 Thanks to Acee Lindem for the detail review of the draft, 1372 corrections, as well as discussion about details of the encoding. 1374 11. References 1376 11.1. Normative References 1378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1379 Requirement Levels", BCP 14, RFC 2119, March 1997. 1381 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1383 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1384 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1385 Tunnels", RFC 3209, December 2001. 1387 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1388 in Resource ReSerVation Protocol - Traffic Engineering 1389 (RSVP-TE)", RFC 3477, January 2003. 1391 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1392 (TE) Extensions to OSPF Version 2", RFC 3630, September 1393 2003. 1395 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1396 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 1397 4915, June 2007. 1399 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1400 Shaffer, "Extensions to OSPF for Advertising Optional 1401 Router Capabilities", RFC 4970, July 2007. 1403 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1404 OSPF Opaque LSA Option", RFC 5250, July 2008. 1406 11.2. Informative References 1408 [I-D.filsfils-rtgwg-segment-routing] 1409 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1410 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1411 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1412 "Segment Routing Architecture", draft-filsfils-rtgwg- 1413 segment-routing-01 (work in progress), October 2013. 1415 [I-D.filsfils-rtgwg-segment-routing-use-cases] 1416 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1417 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1418 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1419 Crabbe, "Segment Routing Use Cases", draft-filsfils-rtgwg- 1420 segment-routing-use-cases-02 (work in progress), October 1421 2013. 1423 [I-D.gredler-ospf-label-advertisement] 1424 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1425 "Advertising MPLS labels in OSPF", draft-gredler-ospf- 1426 label-advertisement-03 (work in progress), May 2013. 1428 [I-D.minto-rsvp-lsp-egress-fast-protection] 1429 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1430 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1431 protection-03 (work in progress), November 2013. 1433 Authors' Addresses 1435 Peter Psenak (editor) 1436 Cisco Systems, Inc. 1437 Apollo Business Center 1438 Mlynske nivy 43 1439 Bratislava 821 09 1440 Slovakia 1442 Email: ppsenak@cisco.com 1443 Stefano Previdi (editor) 1444 Cisco Systems, Inc. 1445 Via Del Serafico, 200 1446 Rome 00142 1447 Italy 1449 Email: sprevidi@cisco.com 1451 Clarence Filsfils 1452 Cisco Systems, Inc. 1453 Brussels 1454 Belgium 1456 Email: cfilsfil@cisco.com 1458 Hannes Gredler 1459 Juniper Networks, Inc. 1460 1194 N. Mathilda Ave. 1461 Sunnyvale, CA 94089 1462 US 1464 Email: hannes@juniper.net 1466 Rob Shakir 1467 British Telecom 1468 London 1469 UK 1471 Email: rob.shakir@bt.com 1473 Wim Henderickx 1474 Alcatel-Lucent 1475 Copernicuslaan 50 1476 Antwerp 2018 1477 BE 1479 Email: wim.henderickx@alcatel-lucent.com 1480 Jeff Tantsura 1481 Ericsson 1482 300 Holger Way 1483 San Jose, CA 95134 1484 US 1486 Email: Jeff.Tantsura@ericsson.com