idnits 2.17.1 draft-ietf-ospf-ospfv3-segment-routing-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 18 characters in excess of 72. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 19, 2014) is 3537 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 277 -- Looks like a reference, but probably isn't: '199' on line 277 -- Looks like a reference, but probably isn't: '1000' on line 278 -- Looks like a reference, but probably isn't: '1099' on line 278 -- Looks like a reference, but probably isn't: '500' on line 279 -- Looks like a reference, but probably isn't: '599' on line 279 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Shortest Path First IGP P. Psenak, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Standards Track C. Filsfils 5 Expires: February 20, 2015 Cisco Systems, Inc. 6 H. Gredler 7 Juniper Networks, Inc. 8 R. Shakir 9 British Telecom 10 W. Henderickx 11 Alcatel-Lucent 12 J. Tantsura 13 Ericsson 14 August 19, 2014 16 OSPFv3 Extensions for Segment Routing 17 draft-ietf-ospf-ospfv3-segment-routing-extensions-00 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 OSPFv3 extensions that are required for 27 Segment Routing. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on February 20, 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 . . . . . . . . . . . . . . . . . . . . 3 71 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4 72 3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4 73 3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 5 74 4. OSPFv3 Extended Prefix Range TLV . . . . . . . . . . . . . . 7 75 5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 8 76 6. SID/Label Binding Sub-TLV . . . . . . . . . . . . . . . . . . 12 77 6.1. ERO Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 14 78 6.2. ERO Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 14 79 6.2.1. IPv4 ERO Sub-TLV . . . . . . . . . . . . . . . . . . 15 80 6.2.2. IPv6 ERO Sub-TLV . . . . . . . . . . . . . . . . . . 16 81 6.2.3. Unnumbered Interface ID ERO Sub-TLV . . . . . . . . . 17 82 6.2.4. IPv4 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 18 83 6.2.5. IPv6 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 19 84 6.2.6. Unnumbered Interface ID Backup ERO Sub-TLV . . . . . 20 85 7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 21 86 7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 21 87 7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 23 88 8. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 24 89 8.1. Intra-area Segment routing in OSPFv3 . . . . . . . . . . 24 90 8.2. Inter-area Segment routing in OSPFv3 . . . . . . . . . . 25 91 8.3. SID for External Prefixes . . . . . . . . . . . . . . . . 26 92 8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 26 93 8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 27 94 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 27 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 96 9.1. OSPF Router Information (RI) TLVs Registry . . . . . . . 27 97 9.2. OSPFv3 Extend-LSA TLV Registry . . . . . . . . . . . . . 27 98 9.3. OSPFv3 Extend-LSA Sub-TLV registry . . . . . . . . . . . 27 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 100 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 102 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 103 12.2. Informative References . . . . . . . . . . . . . . . . . 29 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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 of the cases, is a one-hop path. SR's 117 control-plane can be applied to both IPv6 and MPLS data-planes, and 118 does not require any additional signaling (other than the regular 119 IGP). For example, when used in MPLS networks, SR paths do not 120 require any LDP or RSVP-TE signaling. Still, SR can interoperate in 121 the presence of LSPs established with RSVP or LDP. 123 This draft describes the OSPFv3 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 2.1. SID/Label Sub-TLV 139 The SID/Label Sub-TLV appears in multiple TLVs or Sub-TLVs defined 140 later in this document. It is used to advertise the SID or label 141 associated with a prefix or adjacency. The SID/Label TLV has 142 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: TBD, suggested value 3 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 The receiving router MUST ignore the SID/Label Sub-TLV if the 163 length is other then 3 or 4. 165 3. Segment Routing Capabilities 167 Segment Routing requires some additional capabilities of the router 168 to be advertised to other routers in the area. 170 These SR capabilities are advertised in OSPFv3 Router Information LSA 171 (defined in [RFC4970]). 173 3.1. SR-Algorithm TLV 175 The SR-Algorithm TLV is a TLV of the OSPFv3 Router Information LSA 176 (defined in [RFC4970]). 178 The SR-Algorithm TLV is optional. It MAY only be advertised once in 179 the OSPFv3 Router Information LSA. If the SID/Label Range TLV, as 180 defined in Section 3.2, is advertised, then the SR-Algorithm TLV MUST 181 also be advertised. 183 An OSPFv3 router may use various algorithms when calculating 184 reachability to other nodes in area or to prefixes attached to these 185 nodes. Examples of these algorithms are metric based Shortest Path 186 First (SPF), various sorts of Constrained SPF, etc. The SR-Algorithm 187 TLV allows a router to advertise the algorithms that the router is 188 currently using to other routers in an area. The SR-Algorithm TLV 189 has following structure: 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Type | Length | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Algorithm 1 | Algorithm... | Algorithm n | | 197 +- -+ 198 | | 199 + + 201 where: 203 Type: TBD, suggested value 8 205 Length: variable 207 Algorithm: Single octet identifying the algorithm. The following 208 value has been defined: 210 0: IGP metric based SPT. 212 The RI LSA can be advertised at any of the defined flooding scopes 213 (link, area, or autonomous system (AS)). For the purpose of the SR- 214 Algorithm TLV propagation, area scope flooding is required. 216 3.2. SID/Label Range TLV 218 The SID/Label Range TLV is a TLV of the OSPFv3 Router Information LSA 219 (defined in [RFC4970]). 221 The SID/Label Sub-TLV MAY appear multiple times and has following 222 format: 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Type | Length | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Range Size | Reserved | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Sub-TLVs (variable) | 232 +- -+ 233 | | 234 + + 236 where: 238 Type: TBD, suggested value 9 239 Length: variable 241 Range Size: 3 octets of SID/label range 243 Initially, the only supported Sub-TLV is the SID/Label TLV as defined 244 in Section 2.1. The SID/Label advertised in the SID/Label TLV 245 represents the first SID/Label in the advertised range. 247 Multiple occurrence of the SID/Label Range TLV MAY be advertised, in 248 order to advertise multiple ranges. In such case: 250 o The originating router MUST encode each range into a different 251 SID/Label Range TLV. 253 o The originating router decides the order in which the set of SID/ 254 Label Range TLVs are advertised in the OSPFv3 Router Information 255 LSA. The originating router MUST ensure the order is same after a 256 graceful restart (using checkpointing, non-volatile storage or any 257 other mechanism) in order to assure the SID/label range and SID 258 index correspondence is preserved across graceful restarts. 260 o The receiving router must adhere to the order in which the ranges 261 are advertised when calculating a SID/label from the SID index. 263 o A router not supporting multiple occurrences of the SID/Label 264 Range TLV MUST use first advertised SID/Label Range TLV. 266 The following example illustrates the advertisement of multiple 267 ranges: 269 The originating router advertises the following ranges: 270 Range 1: [100, 199] 271 Range 2: [1000, 1099] 272 Range 3: [500, 599] 274 The receiving routers concatenate the ranges and build the Segment Routing Global Block 275 (SRGB) is as follows: 277 SRGB = [100, 199] 278 [1000, 1099] 279 [500, 599] 281 The indexes span multiple ranges: 283 index=0 means label 100 284 ... 285 index 99 means label 199 286 index 100 means label 1000 287 index 199 means label 1099 288 ... 289 index 200 means label 500 290 ... 292 The RI LSA can be advertised at any of the defined flooding scopes 293 (link, area, or autonomous system (AS)). For the purpose of the SR- 294 Capability TLV propagation, area scope flooding is required. 296 4. OSPFv3 Extended Prefix Range TLV 298 In some cases it is useful to advertise attributes for a range of 299 prefixes. Segment Routing Mapping Server, which is described in 300 [I-D.filsfils-rtgwg-segment-routing], is an example where we need a 301 single advertisement to advertise SIDs for multiple prefixes from a 302 contiguous address range. The OSPFv3 Extended Prefix Range TLV is 303 defined for this purpose. 305 The OSPFv3 Extended Prefix Range TLV is a new top level TLV of the 306 following LSAs defined in [I-D.ietf-ospf-ospfv3-lsa-extend]: 308 E-Intra-Area-Prefix-LSA 310 E-Inter-Area-Prefix-LSA 312 E-AS-External-LSA 314 E-Type-7-LSA 316 Multiple OSPFv3 Extended Prefix Range TLVs MAY be advertised in these 317 extended LSAs. The OSPFv3 Extended Prefix Range TLV has the 318 following format: 320 0 1 2 3 321 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Prefix Length | AF | Range Size | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Address Prefix (variable) | 328 | ... | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Sub-TLVs (variable) | 331 +- -+ 332 | | 334 where: 336 Type: TBD, suggested value 9. 338 Length: variable 340 Prefix length: length of the prefix 342 AF: 0 - IPv6 unicast 344 Range size: represents the number of prefixes that are covered by 345 the advertisement. The Range Size MUST NOT exceed the number of 346 prefixes that could be satisfied by the prefix length without 347 including addresses from other than the IPv6 unicast address 348 class. 350 Address Prefix: the prefix, encoded as an even multiple of 32-bit 351 words, padded with zeroed bits as necessary. This encoding 352 consumes ((PrefixLength + 31) / 32) 32-bit words. The Address 353 Prefix represents the first prefix in the prefix range. 355 5. Prefix SID Sub-TLV 357 The Prefix SID Sub-TLV is a Sub-TLV of the following OSPFv3 TLVs as 358 defined in [I-D.ietf-ospf-ospfv3-lsa-extend] and in Section 4: 360 Intra-Area Prefix TLV 362 Inter-Area Prefix TLV 363 External Prefix TLV 365 OSPFv3 Extended Prefix Range TLV 367 It MAY appear more than once in the parent TLV and has the following 368 format: 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type | Length | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Flags | Algorithm | Reserved | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | SID/Index/Label (variable) | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 where: 382 Type: TBD, suggested value 4. 384 Length: variable 386 Flags: 1 octet field. The following flags are defined: 388 0 389 0 1 2 3 4 5 6 7 390 +-+-+-+-+-+-+-+-+ 391 |N|P|M|E|V|L| | 392 +-+-+-+-+-+-+-+-+ 394 where: 396 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 397 the router identified by the prefix. Typically, the N-Flag is 398 set to Prefix-SIDs corresponding to a router loopback address. 399 The N-Flag is set when the Prefix-SID is a Node-SID as 400 described in [I-D.filsfils-rtgwg-segment-routing]. 402 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 403 NOT pop the Prefix-SID before delivering the packet to the node 404 that advertised the Prefix-SID. 406 M-Flag: Mapping Server Flag. If set, the SID is advertised 407 from the Segment Routing Mapping Server functionality as 408 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 410 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 411 the Prefix-SID originator MUST replace the Prefix-SID with a 412 Prefix-SID having an Explicit-NULL value (0 for IPv4) before 413 forwarding the packet. 415 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 416 carries an absolute value. If not set, then the Prefix-SID 417 carries an index. 419 The L-Flag: Local/Global Flag. If set, then the value/index 420 carried by the Prefix-SID has local significance. If not set, 421 then the value/index carried by this Sub-TLV has global 422 significance. 424 Other bits: Reserved. These MUST be zero when sent and are 425 ignored when received. 427 Algorithm: one octet identifying the algorithm the Prefix-SID is 428 associated with as defined in Section 3.1. 430 SID/Index/Label: label or index value depending on the V-bit 431 setting. 433 Examples: 435 A 32 bit global index defining the offset in the SID/Label 436 space advertised by this router - in this case the V and L 437 flags MUST NOT be set. 439 A 24 bit local label where the 20 rightmost bits are used 440 for encoding the label value - in this case the V and L 441 flags MUST be set. 443 If multiple Prefix-SIDs are advertised for the same prefix, the 444 receiving router MUST use the first encoded SID and MAY use the 445 subsequent SIDs. 447 When propagating Prefix-SIDs between areas, if multiple prefix-SIDs 448 are advertised for a prefix, an implementation SHOULD preserve the 449 original order when advertising prefix-SIDs to other areas. This 450 allows implementations that only support a single Prefix-SID to have 451 a consistent view across areas. 453 When calculating the outgoing label for the prefix, the router MUST 454 take into account E and P flags advertised by the next-hop router, if 455 next-hop router advertised the SID for the prefix. This MUST be done 456 regardless of whether the next-hop router contributes to the best 457 path to the prefix. 459 The NP-Flag (No-PHP) MUST be set for Prefix-SIDs allocated to inter- 460 area prefixes that are originated by the ABR based on intra-area or 461 inter-area reachability between areas. When the inter-area prefix is 462 generated based on a prefix which is directly attached to the ABR, 463 NP-Flag SHOULD NOT be set 465 The NP-Flag (No-PHP) MUST be set on the Prefix-SIDs allocated to 466 redistributed prefixes, unless the redistributed prefix is directly 467 attached to ASBR, in which case the NP-Flag SHOULD NOT be set. 469 If the NP-Flag is not set then any upstream neighbor of the Prefix- 470 SID originator MUST pop the Prefix-SID. This is equivalent to the 471 penultimate hop popping mechanism used in the MPLS dataplane. In 472 such case, MPLS EXP bits of the Prefix-SID are not preserved for the 473 final destination (the Prefix-SID being removed). If the NP-Flag is 474 clear then the received E-flag is ignored. 476 If the NP-Flag is set then: 478 If the E-flag is not set then any upstream neighbor of the Prefix- 479 SID originator MUST keep the Prefix-SID on top of the stack. This 480 is useful when the originator of the Prefix-SID must stitch the 481 incoming packet into a continuing MPLS LSP to the final 482 destination. This could occur at an inter-area border router 483 (prefix propagation from one area to another) or at an inter- 484 domain border router (prefix propagation from one domain to 485 another). 487 If the E-flag is set then any upstream neighbor of the Prefix-SID 488 originator MUST replace the Prefix-SID with a Prefix-SID having an 489 Explicit-NULL value. This is useful, e.g., when the originator of 490 the Prefix-SID is the final destination for the related prefix and 491 the originator wishes to receive the packet with the original EXP 492 bits. 494 When M-Flag is set, NP-Flag MUST be set and E-bit MUST NOT be set. 496 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 497 the value advertised in Prefix SID Sub-TLV is interpreted as a 498 starting SID value. 500 Example 1: if the following router addresses (loopback addresses) 501 need to be mapped into the corresponding Prefix SID indexes: 503 Router-A: 192::1/128, Prefix-SID: Index 1 504 Router-B: 192::2/128, Prefix-SID: Index 2 505 Router-C: 192::3/128, Prefix-SID: Index 3 506 Router-D: 192::4/128, Prefix-SID: Index 4 508 then the Address Prefix field in the OSPFv3 Extended Prefix Range TLV 509 is set to 192::1, Prefix Length would be set to 128, Range Size would 510 be set to 4 and the Index value in the Prefix-SID Sub-TLV would be 511 set to 1. 513 Example 2: If the following prefixes need to be mapped into the 514 corresponding Prefix-SID indexes: 516 10:1:1::0/120, Prefix-SID: Index 51 517 10:1:1::100/120, Prefix-SID: Index 52 518 10:1:1::200/120, Prefix-SID: Index 53 519 10:1:1::300/120, Prefix-SID: Index 54 520 10:1:1::400/120, Prefix-SID: Index 55 521 10:1:1::500/120, Prefix-SID: Index 56 522 10:1:1::600/120, Prefix-SID: Index 57 524 then the Address Prefix field in the OSPFv3 Extended Prefix Range TLV 525 is set to 10:1:1::0, Prefix Length would be set to 120, Range Size 526 would be set to 7 and the Index value in the Prefix-SID Sub-TLV would 527 be set to 51. 529 6. SID/Label Binding Sub-TLV 531 The SID/Label Binding Sub-TLV is used to advertise SID/Label mapping 532 for a path to the prefix. 534 The SID/Label Binding TLV MAY be originated by any router in an 535 OSPFv3 domain. The router may advertise a SID/Label binding to a FEC 536 along with at least a single 'nexthop style' anchor. The protocol 537 supports more than one 'nexthop style' anchor to be attached to a 538 SID/Label binding, which results into a simple path description 539 language. In analogy to RSVP the terminology for this is called an 540 'Explicit Route Object' (ERO). Since ERO style path notation allows 541 anchoring SID/label bindings to both link and node IP addresses, any 542 Label Switched Path (LSP) can be described. Furthermore, SID/Label 543 Bindings from external protocols can also be re-advertised. 545 The SID/Label Binding TLV may be used for advertising SID/Label 546 Bindings and their associated Primary and Backup paths. In one 547 single TLV, either a primary ERO Path, backup ERO Path, or both are 548 advertised. If a router wants to advertise multiple parallel paths, 549 then it can generate several TLVs for the same Prefix/FEC. Each 550 occurrence of a Binding TLV for a given FEC Prefix will add a new 551 path. 553 SID/Label Binding Sub-TLV is a Sub-TLV of the following OSPFv3 TLVs, 554 as defined in [I-D.ietf-ospf-ospfv3-lsa-extend] and in Section 4: 556 Intra-Area Prefix TLV 558 Inter-Area Prefix TLV 560 External Prefix TLV 562 OSPFv3 Extended Prefix Range TLV 564 Multiple SID/Label Binding Sub-TLVs can be present in these TLVs. 565 The SID/Label Binding Sub-TLV has following format: 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Type | Length | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Flags | Weight | Reserved | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Sub-TLVs (variable) | 575 +- -+ 576 | | 578 where: 580 Type: TBD, suggested value 7 582 Length: variable 584 Flags: 1 octet field of following flags: 586 0 1 2 3 4 5 6 7 587 +-+-+-+-+-+-+-+-+ 588 |M| | 589 +-+-+-+-+-+-+-+-+ 591 where: 593 M-bit - When the bit is set the binding represents the 594 mirroring context as defined in 595 [I-D.minto-rsvp-lsp-egress-fast-protection]. 597 Weight: weight used for load-balancing purposes. The use of the 598 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 600 SID/Label Binding Sub-TLV currently supports following Sub-TLVs: 602 SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST 603 appear in the SID/Label Binding Sub-TLV and it MUST only appear 604 once. 606 ERO Metric Sub-TLV as defined in Section 6.1. 608 ERO Sub-TLVs as defined in Section 6.2. 610 6.1. ERO Metric Sub-TLV 612 The ERO Metric Sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 614 The ERO Metric Sub-TLV advertises the cost of an ERO path. It is 615 used to compare the cost of a given source/destination path. A 616 router SHOULD advertise the ERO Metric Sub-TLV in an advertised ERO 617 TLV. The cost of the ERO Metric Sub-TLV SHOULD be set to the 618 cumulative IGP or TE path cost of the advertised ERO. Since 619 manipulation of the Metric field may attract or repel traffic to and 620 from the advertised segment, it MAY be manually overridden. 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Type | Length | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Metric (4 octets) | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 ERO Metric Sub-TLV format 632 where: 634 Type: TBD, suggested value 8 636 Length: Always 4 638 Metric: A 4 octet metric representing the aggregate IGP or TE path 639 cost. 641 6.2. ERO Sub-TLVs 643 All 'ERO' information represents an ordered set which describes the 644 segments of a path. The first ERO Sub-TLV describes the first 645 segment of a path. Similiarly, the last ERO Sub-TLV describes the 646 segment closest to the egress point. If a router extends or stitches 647 a path, it MUST prepend the new segment's path information to the ERO 648 list. This applies equally to advertised backup EROs. 650 All ERO Sub-TLVs must immediately follow the (SID)/Label Sub-TLV. 652 All Backup ERO Sub-TLVs must immediately follow the last ERO Sub-TLV. 654 6.2.1. IPv4 ERO Sub-TLV 656 IPv4 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 658 The IPv4 ERO Sub-TLV describes a path segment using IPv4 Address 659 style of encoding. Its semantics have been borrowed from [RFC3209]. 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Type | Length | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Flags | Reserved | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | IPv4 Address (4 octets) | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 IPv4 ERO Sub-TLV format 673 where: 675 Type: TBD, suggested value 9 677 Length: 8 bytes 679 Flags: 1 octet field of following flags: 681 0 1 2 3 4 5 6 7 682 +-+-+-+-+-+-+-+-+ 683 |L| | 684 +-+-+-+-+-+-+-+-+ 686 where: 688 L-bit - If the L-bit is set, then the segment path is 689 designated as 'loose'. Otherwise, the segment path is 690 designated as 'strict'. 692 IPv4 Address - the address of the explicit route hop. 694 6.2.2. IPv6 ERO Sub-TLV 696 IPv6 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 698 The IPv6 ERO Sub-TLV (Type TBA) describes a path segment using IPv6 699 Address style of encoding. Its semantics have been borrowed from 700 [RFC3209]. 702 0 1 2 3 703 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 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Type | Length | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Flags | Reserved | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | | 710 +- -+ 711 | | 712 +- IPv6 Address -+ 713 | | 714 +- -+ 715 | | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 IPv6 ERO Sub-TLV format 720 where: 722 Type: TBD, suggested value 10 724 Length: 8 bytes 726 Flags: 1 octet field of following flags: 728 0 1 2 3 4 5 6 7 729 +-+-+-+-+-+-+-+-+ 730 |L| | 731 +-+-+-+-+-+-+-+-+ 733 where: 735 L-bit - If the L-bit is set, then the segment path is 736 designated as 'loose'. Otherwise, the segment path is 737 designated as 'strict'. 739 IPv6 Address - the address of the explicit route hop. 741 6.2.3. Unnumbered Interface ID ERO Sub-TLV 743 The Unnumbered Interface ID ERO Sub-TLV is a Sub-TLV of the SID/Label 744 Binding Sub-TLV. 746 The appearance and semantics of the 'Unnumbered Interface ID' have 747 been borrowed from [RFC3477]. 749 The Unnumbered Interface-ID ERO Sub-TLV describes a path segment that 750 spans over an unnumbered interface. Unnumbered interfaces are 751 referenced using the interface index. Interface indices are assigned 752 local to the router and therefore not unique within a domain. All 753 elements in an ERO path need to be unique within a domain and hence 754 need to be disambiguated using a domain unique Router-ID. 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 | Type | Length | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Flags | Reserved | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Router ID | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Interface ID | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 where: 770 Unnumbered Interface ID ERO Sub-TLV format 772 Type: TBD, suggested value 11 774 Length: 12 bytes 776 Flags: 1 octet field of following flags: 778 0 1 2 3 4 5 6 7 779 +-+-+-+-+-+-+-+-+ 780 |L| | 781 +-+-+-+-+-+-+-+-+ 783 where: 785 L-bit - If the L-bit is set, then the segment path is 786 designated as 'loose'. Otherwise, the segment path is 787 designated as 'strict'. 789 Router-ID: Router-ID of the next-hop. 791 Interface ID: is the identifier assigned to the link by the router 792 specified by the Router-ID. 794 6.2.4. IPv4 Backup ERO Sub-TLV 796 IPv4 Prefix Backup ERO Sub-TLV is a Sub-TLV of the SID/Label Binding 797 Sub-TLV. 799 The IPv4 Backup ERO Sub-TLV describes a path segment using IPv4 800 Address style of encoding. Its semantics have been borrowed from 801 [RFC3209]. 803 0 1 2 3 804 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 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Type | Length | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Flags | Reserved | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | IPv4 Address (4 octets) | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 IPv4 Backup ERO Sub-TLV format 815 where: 817 Type: TBD, suggested value 12 819 Length: 8 bytes 821 Flags: 1 octet field of following flags: 823 0 1 2 3 4 5 6 7 824 +-+-+-+-+-+-+-+-+ 825 |L| | 826 +-+-+-+-+-+-+-+-+ 828 where: 830 L-bit - If the L-bit is set, then the segment path is 831 designated as 'loose'. Otherwise, the segment path is 832 designated as 'strict'.' 834 IPv4 Address - the address of the explicit route hop. 836 6.2.5. IPv6 Backup ERO Sub-TLV 838 The IPv6 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 840 The IPv6 Backup ERO Sub-TLV describes a Backup path segment using 841 IPv6 Address style of encoding. Its appearance and semantics have 842 been borrowed from [RFC3209]. 844 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 845 set, then the value of the attribute is 'loose.' Otherwise, the 846 value of the attribute is 'strict.' 848 0 1 2 3 849 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 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Type | Length | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Flags | Reserved | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | | 856 +- -+ 857 | | 858 +- IPv6 Address -+ 859 | | 860 +- -+ 861 | | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 IPv6 Backup ERO Sub-TLV format 866 where: 868 Type: TBD, suggested value 13 870 Length: 8 bytes 872 Flags: 1 octet field of following flags: 874 0 1 2 3 4 5 6 7 875 +-+-+-+-+-+-+-+-+ 876 |L| | 877 +-+-+-+-+-+-+-+-+ 879 where: 881 L-bit - If the L-bit is set, then the segment path is 882 designated as 'loose'. Otherwise, the segment path is 883 designated as 'strict'. 885 IPv6 Address - the address of the explicit route hop. 887 6.2.6. Unnumbered Interface ID Backup ERO Sub-TLV 889 The Unnumbered Interface ID Backup Sub-TLV is a Sub-TLV of the SID/ 890 Label Binding Sub-TLV. 892 The appearance and semantics of the 'Unnumbered Interface ID' have 893 been borrowed from [RFC3477]. 895 The Unnumbered Interface-ID Backup ERO Sub-TLV describes a path 896 segment that spans over an unnumbered interface. Unnumbered 897 interfaces are referenced using the interface index. Interface 898 indices are assigned local to the router and are therefore not unique 899 within a domain. All elements in an ERO path need to be unique 900 within a domain and hence need to be disambiguated with specification 901 of the unique Router-ID. 903 0 1 2 3 904 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 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Type | Length | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Flags | Reserved | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Router ID | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Interface ID | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 Unnumbered Interface ID Backup ERO Sub-TLV format 917 where: 919 Type: TBD, suggested value 14 921 Length: 12 bytes 923 Flags: 1 octet field of following flags: 925 0 1 2 3 4 5 6 7 926 +-+-+-+-+-+-+-+-+ 927 |L| | 928 +-+-+-+-+-+-+-+-+ 930 where: 932 L-bit - If the L-bit is set, then the segment path is 933 designated as 'loose'. Otherwise, the segment path is 934 designated as 'strict'. 936 Router-ID: Router-ID of the next-hop. 938 Interface ID: is the identifier assigned to the link by the router 939 specified by the Router-ID. 941 7. Adjacency Segment Identifier (Adj-SID) 943 An Adjacency Segment Identifier (Adj-SID) represents a router 944 adjacency in Segment Routing. 946 7.1. Adj-SID Sub-TLV 948 The extended OSPFv3 LSAs, as defined in 949 [I-D.ietf-ospf-ospfv3-lsa-extend], are used to advertise prefix SID 950 in OSPFv3 952 The Adj-SID Sub-TLV is an optional Sub-TLV of the Router-Link TLV as 953 defined in [I-D.ietf-ospf-ospfv3-lsa-extend]. It MAY appear multiple 954 times in Router-Link TLV. Examples where more than one Adj-SID may 955 be used per neighbor are described in 956 [I-D.filsfils-rtgwg-segment-routing-use-cases]. The Adj-SID Sub-TLV 957 has the following format: 959 0 1 2 3 960 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Type | Length | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Flags | Weight | Reserved | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | SID/Label/Index (variable) | 967 +---------------------------------------------------------------+ 969 where: 971 Type: TBD, suggested value 5. 973 Length: variable. 975 Flags. 1 octet field of following flags: 977 0 1 2 3 4 5 6 7 978 +-+-+-+-+-+-+-+-+ 979 |B|V|L|S| | 980 +-+-+-+-+-+-+-+-+ 982 where: 984 B-Flag: Backup-flag. If set, the Adj-SID refers to an 985 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 986 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 988 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 989 carries an absolute value. If not set, then the Prefix-SID 990 carries an index. 992 The L-Flag: Local/Global Flag. If set, then the value/index 993 carried by the Prefix-SID has local significance. If not set, 994 then the value/index carried by this Sub-TLV has global 995 significance. 997 The S-Flag. Set Flag. When set, the S-Flag indicates that the 998 Adj-SID refers to a set of adjacencies (and therefore MAY be 999 assigned to other adjacencies as well). 1001 Other bits: Reserved. These MUST be zero when sent and are 1002 ignored when received. 1004 Weight: weight used for load-balancing purposes. The use of the 1005 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 1007 SID/Index/Label: label or index value depending on the V-bit 1008 setting. 1010 Examples: 1012 A 32 bit global index defining the offset in the SID/Label 1013 space advertised by this router - in this case the V and L 1014 flags MUST NOT be set. 1016 A 24 bit local label where the 20 rightmost bits are used 1017 for encoding the label value - in this case the V and L 1018 flags MUST be set. 1020 16 octet IPv6 address - in this case the V-flag MUST be set. 1021 The L-flag MUST be set for link-local IPv6 address and MUST 1022 NOT be set for IPv6 global unicast address. 1024 An SR capable router MAY allocate an Adj-SID for each of its 1025 adjacencies and set the B-Flag when the adjacency is protected by a 1026 FRR mechanism (IP or MPLS) as described in 1027 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 1029 7.2. LAN Adj-SID Sub-TLV 1031 The LAN Adj-SID is an optional Sub-TLV of the Router-Link TLV. It 1032 MAY appear multiple times in the Router-Link TLV. It is used to 1033 advertise a SID/Label for an adjacency to a non-DR neighbor on a 1034 broadcast or NBMA network. 1036 0 1 2 3 1037 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 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Type | Length | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | Flags | Weight | Reserved | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Neighbor ID | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | SID/Label/Index (variable) | 1046 +---------------------------------------------------------------+ 1048 where: 1050 Type: TBD, suggested value 6. 1052 Length: variable. 1054 Flags. 1 octet field of following flags: 1056 0 1 2 3 4 5 6 7 1057 +-+-+-+-+-+-+-+-+ 1058 |B|V|L|S| | 1059 +-+-+-+-+-+-+-+-+ 1061 where: 1063 B-Flag: Backup-flag: set if the LAN-Adj-SID refer to an 1064 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 1065 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 1067 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 1068 carries an absolute value. If not set, then the Prefix-SID 1069 carries an index. 1071 The L-Flag: Local/Global Flag. If set, then the value/index 1072 carried by the Prefix-SID has local significance. If not set, 1073 then the value/index carried by this subTLV has global 1074 significance. 1076 The S-Flag. Set Flag. When set, the S-Flag indicates that the 1077 Adj-SID refers to a set of adjacencies (and therefore MAY be 1078 assigned to other adjacencies as well). 1080 Other bits: Reserved. These MUST be zero when sent and are 1081 ignored when received. 1083 Weight: weight used for load-balancing purposes. The use of the 1084 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 1086 SID/Index/Label: label or index value depending on the V-bit 1087 setting. 1089 Examples: 1091 A 32 bit global index defining the offset in the SID/Label 1092 space advertised by this router - in this case the V and L 1093 flags MUST NOT be set. 1095 A 24 bit local label where the 20 rightmost bits are used 1096 for encoding the label value - in this case the V and L 1097 flags MUST be set. 1099 16 octet IPv6 address - in this case the V-flag MUST be set. 1100 The L-flag MUST be set for link-local IPv6 address and MUST 1101 NOT be set for IPv6 global unicast address. 1103 8. Elements of Procedure 1105 8.1. Intra-area Segment routing in OSPFv3 1107 An OSPFv3 router that supports segment routing MAY advertise Prefix- 1108 SIDs for any prefix that it is advertising reachability for (e.g., 1109 loopback IP address) as described in Section 5. 1111 If multiple routers advertise a 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 when multiple equal cost paths to the 1114 destination exist in the network. 1116 The 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-SID for remote prefixes that exist 1119 in the network. Multiple Mapping Servers can advertise Prefix-SID 1120 for the same prefix, in which case the same Prefix-SID MUST be 1121 advertised by all of them. The SR Mapping Server could use either 1122 area scope or autonomous system flooding scope when advertising 1123 Prefix SID for prefixes, based on the configuration of the SR Mapping 1124 Server. Depending on the flooding scope used, the SR Mapping Server 1125 chooses the LSA that will be used. If the area flooding scope is 1126 needed, E-Intra-Area-Prefix-LSA ([I-D.ietf-ospf-ospfv3-lsa-extend]) 1127 is used. If autonomous system flooding scope is needed, E-AS- 1128 External-LSA ([I-D.ietf-ospf-ospfv3-lsa-extend]) is used. 1130 When a Prefix-SID is advertised by the Mapping Server, which is 1131 indicated by the M-flag in the Prefix-SID Sub-TLV (Section 5), the 1132 route type as implied by the LSA type is ignored and the Prefix-SID 1133 is bound to the corresponding prefix independent of the route type. 1135 Advertisement of the Prefix-SID by the Mapping Server using Inter- 1136 Area Prefix TLV, External-Prefix TLV or Intra-Area-Prefix TLV 1137 ([I-D.ietf-ospf-ospfv3-lsa-extend]) does not itself contribute to the 1138 prefix reachability. The NU-bit MUST be set in the PrefixOptions 1139 field of the LSA which is used by the Mapping Server to advertise SID 1140 or SID range, which prevents the advertisement to contribute to 1141 prefix reachability. 1143 8.2. Inter-area Segment routing in OSPFv3 1145 In order to support SR in a multi-area environment, OSPFv3 must 1146 propagate Prefix-SID information between areas. The following 1147 procedure is used in order to propagate Prefix SIDs between areas. 1149 When an OSPFv3 ABR advertises a Inter-Area-Prefix-LSA from an intra- 1150 area prefix to all its connected areas, it will also include Prefix- 1151 SID Sub-TLV, as described in Section 5. The Prefix-SID value will be 1152 set as follows: 1154 The ABR will look at its best path to the prefix in the source 1155 area and find out the advertising router associated with the best 1156 path to that prefix. 1158 The ABR will then determine if such router advertised a Prefix-SID 1159 for the prefix and use it when advertising the Prefix-SID to other 1160 connected areas. 1162 If no Prefix-SID was advertised for the prefix in the source area 1163 by the router that contributes to the best path to the prefix, the 1164 originating ABR will use the Prefix-SID advertised by any other 1165 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 1166 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 1167 propagating Prefix-SID for the prefix to other areas. 1169 When an OSPFv3 ABR advertises Inter-Area-Prefix-LSA LSAs from an 1170 inter-area route to all its connected areas it will also include 1171 Prefix-SID Sub-TLV, as described in Section 5. The Prefix-SID value 1172 will be set as follows: 1174 The ABR will look at its best path to the prefix in the source 1175 area and find out the advertising router associated with the best 1176 path to that prefix. 1178 The ABR will then look if such router advertised a Prefix-SID for 1179 the prefix and use it when advertising the Prefix-SID to other 1180 connected areas. 1182 If no Prefix-SID was advertised for the prefix in the source area 1183 by the ABR that contributes to the best path to the prefix, the 1184 originating ABR will use the Prefix-SID advertised by any other 1185 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 1186 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 1187 propagating Prefix-SID for the prefix to other areas. 1189 8.3. SID for External Prefixes 1191 AS-External-LSAs are flooded domain wide. When an ASBR, which 1192 supports SR, generates E-AS-External-LSA, it should also include 1193 Prefix-SID Sub-TLV, as described in Section 5. The Prefix-SID value 1194 will be set to the SID that has been reserved for that prefix. 1196 When an NSSA ASBR translates an E-NSSA-LSA into an E-AS-External-LSA, 1197 it should also advertise the Prefix-SID for the prefix. The NSSA ABR 1198 determines its best path to the prefix advertised in the translated 1199 E-NSSA-LSA and finds the advertising router associated with that 1200 path. If the advertising router has advertised a Prefix-SID for the 1201 prefix, then the NSSA ABR uses it when advertising the Prefix-SID in 1202 the E-AS-External-LSA. Otherwise the Prefix-SID advertised by any 1203 other router will be used (e.g.: a Prefix-SID coming from an SR 1204 Mapping Server as defined in 1205 [I-D.filsfils-rtgwg-segment-routing-use-cases]). 1207 8.4. Advertisement of Adj-SID 1209 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1210 using the Adj-SID Sub-TLV as described in Section 7. 1212 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 1214 An Adj-SID MAY be advertised for any adjacency on p2p link that is in 1215 a state 2-Way or higher. If the adjacency on a p2p link transitions 1216 from the FULL state, then the Adj-SID for that adjacency MAY be 1217 removed from the area. If the adjacency transitions to a state lower 1218 then 2-Way, then the Adj-SID advertisement MUST be removed from the 1219 area. 1221 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1223 Broadcast or NBMA networks in OSPFv3 are represented by a star 1224 topology where the Designated Router (DR) is the central point to 1225 which all other routers on the broadcast or NBMA network connect. As 1226 a result, routers on the broadcast or NBMA network advertise only 1227 their adjacency to the DR. Routers that do not act as DR do not form 1228 or advertise adjacencies with each other. They do, however, maintain 1229 a 2-Way adjacency state with each other and are directly reachable. 1231 When Segment Routing is used, each router on the broadcast or NBMA 1232 network MAY advertise the Adj-SID for its adjacency to the DR using 1233 Adj-SID Sub-TLV as described in Section 7.1. 1235 SR capable routers MAY also advertise an Adj-SID for other neighbors 1236 (e.g. BDR, DR-OTHER) on the broadcast or NBMA network using the LAN 1237 ADJ-SID Sub-TLV as described in Section 7.2. 1239 9. IANA Considerations 1241 This specification updates several existing OSPF registries. 1243 9.1. OSPF Router Information (RI) TLVs Registry 1245 o 8 (IANA Preallocated) - SR-Algorithm TLV 1247 o 9 (IANA Preallocated) - SID/Label Range TLV 1249 9.2. OSPFv3 Extend-LSA TLV Registry 1251 Following values are allocated: 1253 o suggested value 9 - OSPF Extended Prefix Range TLV 1255 9.3. OSPFv3 Extend-LSA Sub-TLV registry 1257 o suggested value 3 - SID/Label Sub-TLV 1259 o suggested value 4 - Prefix SID Sub-TLV 1260 o suggested value 5 - Adj-SID Sub-TLV 1262 o suggested value 6 - LAN Adj-SID Sub-TLV 1264 o suggested value 7 - SID/Label Binding Sub-TLV 1266 o suggested value 8 - ERO Metric Sub-TLV 1268 o suggested value 9 - IPv4 ERO Sub-TLV 1270 o suggested value 10 - IPv6 ERO Sub-TLV 1272 o suggested value 11 - Unnumbered Interface ID ERO Sub-TLV 1274 o suggested value 12 - IPv4 Backup ERO Sub-TLV 1276 o suggested value 13 - IPv6 Backup ERO Sub-TLV 1278 o suggested value 14 - Unnumbered Interface ID Backup ERO Sub-TLV 1280 10. Security Considerations 1282 Implementations must assure that malformed permutations of the newly 1283 defined sub-TLvs do not result in errors which cause hard OSPFv3 1284 failures. 1286 11. Acknowledgements 1288 Thanks to Acee Lindem for the detail review of the draft, 1289 corrections, as well as discussion about details of the encoding. 1291 We would like to thank Anton Smirnov for his contribution. 1293 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1294 contribution on earlier incarnations of the "Binding / MPLS Label 1295 TLV" in [I-D.gredler-ospf-label-advertisement]. 1297 12. References 1299 12.1. Normative References 1301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1302 Requirement Levels", BCP 14, RFC 2119, March 1997. 1304 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1305 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1306 Tunnels", RFC 3209, December 2001. 1308 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1309 in Resource ReSerVation Protocol - Traffic Engineering 1310 (RSVP-TE)", RFC 3477, January 2003. 1312 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1313 Shaffer, "Extensions to OSPF for Advertising Optional 1314 Router Capabilities", RFC 4970, July 2007. 1316 12.2. Informative References 1318 [I-D.filsfils-rtgwg-segment-routing] 1319 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1320 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1321 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1322 "Segment Routing Architecture", draft-filsfils-rtgwg- 1323 segment-routing-01 (work in progress), October 2013. 1325 [I-D.filsfils-rtgwg-segment-routing-use-cases] 1326 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1327 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1328 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1329 Crabbe, "Segment Routing Use Cases", draft-filsfils-rtgwg- 1330 segment-routing-use-cases-02 (work in progress), October 1331 2013. 1333 [I-D.gredler-ospf-label-advertisement] 1334 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1335 "Advertising MPLS labels in OSPF", draft-gredler-ospf- 1336 label-advertisement-03 (work in progress), May 2013. 1338 [I-D.ietf-ospf-ospfv3-lsa-extend] 1339 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 1340 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-03 1341 (work in progress), May 2014. 1343 [I-D.minto-rsvp-lsp-egress-fast-protection] 1344 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1345 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1346 protection-03 (work in progress), November 2013. 1348 Authors' Addresses 1349 Peter Psenak (editor) 1350 Cisco Systems, Inc. 1351 Apollo Business Center 1352 Mlynske nivy 43 1353 Bratislava 821 09 1354 Slovakia 1356 Email: ppsenak@cisco.com 1358 Stefano Previdi (editor) 1359 Cisco Systems, Inc. 1360 Via Del Serafico, 200 1361 Rome 00142 1362 Italy 1364 Email: sprevidi@cisco.com 1366 Clarence Filsfils 1367 Cisco Systems, Inc. 1368 Brussels 1369 Belgium 1371 Email: cfilsfil@cisco.com 1373 Hannes Gredler 1374 Juniper Networks, Inc. 1375 1194 N. Mathilda Ave. 1376 Sunnyvale, CA 94089 1377 US 1379 Email: hannes@juniper.net 1381 Rob Shakir 1382 British Telecom 1383 London 1384 UK 1386 Email: rob.shakir@bt.com 1387 Wim Henderickx 1388 Alcatel-Lucent 1389 Copernicuslaan 50 1390 Antwerp 2018 1391 BE 1393 Email: wim.henderickx@alcatel-lucent.com 1395 Jeff Tantsura 1396 Ericsson 1397 300 Holger Way 1398 San Jose, CA 95134 1399 US 1401 Email: Jeff.Tantsura@ericsson.com