idnits 2.17.1 draft-ietf-ospf-ospfv3-segment-routing-extensions-06.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 (July 6, 2016) is 2850 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 293 -- Looks like a reference, but probably isn't: '199' on line 293 -- Looks like a reference, but probably isn't: '1000' on line 294 -- Looks like a reference, but probably isn't: '1099' on line 294 -- Looks like a reference, but probably isn't: '500' on line 295 -- Looks like a reference, but probably isn't: '599' on line 295 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-ldp-interop-02 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-10 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-01 Summary: 2 errors (**), 0 flaws (~~), 5 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: January 7, 2017 Cisco Systems, Inc. 6 H. Gredler 7 Individual 8 R. Shakir 9 Jive Communications, Inc. 10 W. Henderickx 11 Nokia 12 J. Tantsura 13 Individual 14 July 6, 2016 16 OSPFv3 Extensions for Segment Routing 17 draft-ietf-ospf-ospfv3-segment-routing-extensions-06 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 January 7, 2017. 51 Copyright Notice 53 Copyright (c) 2016 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 3.3. SR-Forwarding Capabilities . . . . . . . . . . . . . . . 7 75 4. OSPFv3 Extended Prefix Range TLV . . . . . . . . . . . . . . 8 76 5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 9 77 6. SID/Label Binding Sub-TLV . . . . . . . . . . . . . . . . . . 13 78 6.1. ERO Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 15 79 6.2. ERO Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 16 80 6.2.1. IPv4 ERO Sub-TLV . . . . . . . . . . . . . . . . . . 16 81 6.2.2. IPv6 ERO Sub-TLV . . . . . . . . . . . . . . . . . . 17 82 6.2.3. Unnumbered Interface ID ERO Sub-TLV . . . . . . . . . 18 83 6.2.4. IPv4 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 19 84 6.2.5. IPv6 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 20 85 6.2.6. Unnumbered Interface ID Backup ERO Sub-TLV . . . . . 21 86 7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 22 87 7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 22 88 7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 24 89 8. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 26 90 8.1. Intra-area Segment routing in OSPFv3 . . . . . . . . . . 26 91 8.2. Inter-area Segment routing in OSPFv3 . . . . . . . . . . 27 92 8.3. SID for External Prefixes . . . . . . . . . . . . . . . . 28 93 8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 28 94 8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 28 95 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 28 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 97 9.1. OSPF Router Information (RI) TLVs Registry . . . . . . . 29 98 9.2. OSPFv3 Extend-LSA TLV Registry . . . . . . . . . . . . . 29 99 9.3. OSPFv3 Extend-LSA Sub-TLV registry . . . . . . . . . . . 29 100 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 101 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 103 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 104 12.2. Informative References . . . . . . . . . . . . . . . . . 31 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 107 1. Introduction 109 Segment Routing (SR) allows for a flexible definition of end-to-end 110 paths within IGP topologies by encoding paths as sequences of 111 topological sub-paths, called "segments". These segments are 112 advertised by the link-state routing protocols (IS-IS and OSPF). 113 Prefix segments represent an ecmp-aware shortest-path to a prefix (or 114 a node), as per the state of the IGP topology. Adjacency segments 115 represent a hop over a specific adjacency between two nodes in the 116 IGP. A prefix segment is typically a multi-hop path while an 117 adjacency segment, in most of the cases, is a one-hop path. SR's 118 control-plane can be applied to both IPv6 and MPLS data-planes, and 119 does not require any additional signaling (other than the regular 120 IGP). For example, when used in MPLS networks, SR paths do not 121 require any LDP or RSVP-TE signaling. Still, SR can interoperate in 122 the presence of LSPs established with RSVP or LDP. 124 This draft describes the OSPFv3 extensions required for segment 125 routing. 127 Segment Routing architecture is described in 128 [I-D.ietf-spring-segment-routing]. 130 Segment Routing use cases are described in 131 [I-D.filsfils-spring-segment-routing-use-cases]. 133 2. Segment Routing Identifiers 135 Segment Routing defines various types of Segment Identifiers (SIDs): 136 Prefix-SID, Adjacency-SID, LAN Adjacency SID and Binding SID. 138 2.1. SID/Label Sub-TLV 140 The SID/Label Sub-TLV appears in multiple TLVs or Sub-TLVs defined 141 later in this document. It is used to advertise the SID or label 142 associated with a prefix or adjacency. The SID/Label TLV has 143 following format: 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Type | Length | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | SID/Label (variable) | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 where: 155 Type: TBD, suggested value 3 157 Length: variable, 3 or 4 bytes 159 SID/Label: if length is set to 3, then the 20 rightmost bits 160 represent a label. If length is set to 4, then the value 161 represents a 32 bit SID. 163 The receiving router MUST ignore the SID/Label Sub-TLV if the 164 length is other then 3 or 4. 166 3. Segment Routing Capabilities 168 Segment Routing requires some additional capabilities of the router 169 to be advertised to other routers in the area. 171 These SR capabilities are advertised in OSPFv3 Router Information LSA 172 (defined in [RFC4970]). 174 3.1. SR-Algorithm TLV 176 The SR-Algorithm TLV is a TLV of the OSPFv3 Router Information LSA 177 (defined in [RFC4970]). 179 The SR-Algorithm TLV is optional. It MAY only be advertised once in 180 the OSPFv3 Router Information LSA. If the SID/Label Range TLV, as 181 defined in Section 3.2, is advertised, then the SR-Algorithm TLV MUST 182 also be advertised. If the SR-Algorithm TLV is not advertised by the 183 node, such node is considered as not being segment routing capable. 185 An OSPFv3 router may use various algorithms when calculating 186 reachability to other nodes in area or to prefixes attached to these 187 nodes. Examples of these algorithms are metric based Shortest Path 188 First (SPF), various sorts of Constrained SPF, etc. The SR-Algorithm 189 TLV allows a router to advertise the algorithms that the router is 190 currently using to other routers in an area. The SR-Algorithm TLV 191 has following structure: 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type | Length | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Algorithm 1 | Algorithm... | Algorithm n | | 199 +- -+ 200 | | 201 + + 203 where: 205 Type: TBD, suggested value 8 207 Length: variable 209 Algorithm: Single octet identifying the algorithm. The following 210 value has been defined: 212 0: Shortest Path First (SPF) algorithm based on link metric. 213 This is the standard shortest path algorithm as computed by the 214 OSPF protocol. Consistent with the deployed practice for link- 215 state protocols, Algorithm 0 permits any node to overwrite the 216 SPF path with a different path based on its local policy. If 217 the SR-Algorithm Sub-TLV is advertised, Algorithm 0 MUST be 218 included. 220 1: Strict Shortest Path First (SPF) algorithm based on link 221 metric. The algorithm is identical to Algorithm 0 but 222 Algorithm 1 requires that all nodes along the path will honor 223 the SPF routing decision. Local policy at the node claiming 224 the support of Algorithm 1 MUST NOT alter the forwarding 225 decision computed by Algorithm 1. 227 The RI LSA can be advertised at any of the defined flooding scopes 228 (link, area, or autonomous system (AS)). For the purpose of the SR- 229 Algorithm TLV propagation, area scope flooding is required. 231 3.2. SID/Label Range TLV 233 The SID/Label Range TLV is a TLV of the OSPFv3 Router Information LSA 234 (defined in [RFC4970]). 236 The SID/Label Sub-TLV MAY appear multiple times and has following 237 format: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type | Length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Range Size | Reserved | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Sub-TLVs (variable) | 247 +- -+ 248 | | 249 + + 251 where: 253 Type: TBD, suggested value 9 255 Length: variable 257 Range Size: 3 octets of SID/label range 259 Initially, the only supported Sub-TLV is the SID/Label TLV as defined 260 in Section 2.1. The SID/Label advertised in the SID/Label TLV 261 represents the first SID/Label in the advertised range. 263 Multiple occurrence of the SID/Label Range TLV MAY be advertised, in 264 order to advertise multiple ranges. In such case: 266 o The originating router MUST encode each range into a different 267 SID/Label Range TLV. 269 o The originating router decides the order in which the set of SID/ 270 Label Range TLVs are advertised in the OSPFv3 Router Information 271 LSA. The originating router MUST ensure the order is same after a 272 graceful restart (using checkpointing, non-volatile storage or any 273 other mechanism) in order to assure the SID/label range and SID 274 index correspondence is preserved across graceful restarts. 276 o The receiving router must adhere to the order in which the ranges 277 are advertised when calculating a SID/label from the SID index. 279 o A router not supporting multiple occurrences of the SID/Label 280 Range TLV MUST use first advertised SID/Label Range TLV. 282 The following example illustrates the advertisement of multiple 283 ranges: 285 The originating router advertises the following ranges: 286 Range 1: [100, 199] 287 Range 2: [1000, 1099] 288 Range 3: [500, 599] 290 The receiving routers concatenate the ranges and build the Segment Routing Global Block 291 (SRGB) is as follows: 293 SRGB = [100, 199] 294 [1000, 1099] 295 [500, 599] 297 The indexes span multiple ranges: 299 index=0 means label 100 300 ... 301 index 99 means label 199 302 index 100 means label 1000 303 index 199 means label 1099 304 ... 305 index 200 means label 500 306 ... 308 The RI LSA can be advertised at any of the defined flooding scopes 309 (link, area, or autonomous system (AS)). For the purpose of the SID/ 310 Label Range TLV propagation, area scope flooding is required. 312 3.3. SR-Forwarding Capabilities 314 OSPFv3 router supporting Segment Routing needs to advertise its SR 315 data-plane capabilities. Data-plane capabilities are advertised in 316 OSPF Router Informational Capabilities TLV, which is defined in 317 section 2.3 of RFC 4970 [RFC4970]. 319 Two new bits are allocated in the OSPF Router Informational 320 Capability Bits as follows: 322 Bit-6 - MPLS IPv6 flag. If set, then the router is capable of 323 processing SR MPLS encapsulated IPv6 packets on all interfaces. 325 Bit-7 - If set, then the router is capable of processing the IPv6 326 Segment Routing Header on all interfaces as defined in 327 [I-D.previdi-6man-segment-routing-header]. 329 For the purpose of the SR-Forwarding Capabilities propagation, area 330 scope flooding is required. 332 4. OSPFv3 Extended Prefix Range TLV 334 In some cases it is useful to advertise attributes for a range of 335 prefixes. Segment Routing Mapping Server, which is described in 336 [I-D.filsfils-spring-segment-routing-ldp-interop], is an example 337 where we need a single advertisement to advertise SIDs for multiple 338 prefixes from a contiguous address range. The OSPFv3 Extended Prefix 339 Range TLV is defined for this purpose. 341 The OSPFv3 Extended Prefix Range TLV is a new top level TLV of the 342 following LSAs defined in [I-D.ietf-ospf-ospfv3-lsa-extend]: 344 E-Intra-Area-Prefix-LSA 346 E-Inter-Area-Prefix-LSA 348 E-AS-External-LSA 350 E-Type-7-LSA 352 Multiple OSPFv3 Extended Prefix Range TLVs MAY be advertised in these 353 extended LSAs. The OSPFv3 Extended Prefix Range TLV has the 354 following format: 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Type | Length | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Prefix Length | AF | Range Size | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Flags | Reserved | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Address Prefix (variable) | 366 | ... | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Sub-TLVs (variable) | 369 +- -+ 370 | | 372 where: 374 Type: TBD, suggested value 9. 376 Length: variable 378 Prefix length: length of the prefix 379 AF: 0 - IPv6 unicast 381 Range size: represents the number of prefixes that are covered by 382 the advertisement. The Range Size MUST NOT exceed the number of 383 prefixes that could be satisfied by the prefix length without 384 including addresses from other than the IPv6 unicast address 385 class. 387 Flags: 1 octet field. The following flags are defined: 389 0 1 2 3 4 5 6 7 390 +--+--+--+--+--+--+--+--+ 391 |IA| | | | | | | | 392 +--+--+--+--+--+--+--+--+ 394 where: 396 IA-Flag: Inter-Area flag. If set, advertisement is of inter- 397 area type. ABR that is advertising the OSPF Extended Prefix 398 Range TLV between areas MUST set this bit. 400 This bit is used to prevent redundant flooding of Prefix Range 401 TLVs between areas as follows: 403 An ABR always prefers intra-area Prefix Range advertisement 404 over inter-area one. 406 An ABR does not consider inter-area Prefix Range 407 advertisements coming from non backbone area. 409 An ABR propagates inter-area Prefix Range advertisement from 410 backbone area to connected non backbone areas only if such 411 advertisement is considered to be the best one. 413 Address Prefix: the prefix, encoded as an even multiple of 32-bit 414 words, padded with zeroed bits as necessary. This encoding 415 consumes ((PrefixLength + 31) / 32) 32-bit words. The Address 416 Prefix represents the first prefix in the prefix range. 418 5. Prefix SID Sub-TLV 420 The Prefix SID Sub-TLV is a Sub-TLV of the following OSPFv3 TLVs as 421 defined in [I-D.ietf-ospf-ospfv3-lsa-extend] and in Section 4: 423 Intra-Area Prefix TLV 425 Inter-Area Prefix TLV 426 External Prefix TLV 428 OSPFv3 Extended Prefix Range TLV 430 It MAY appear more than once in the parent TLV and has the following 431 format: 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type | Length | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Flags | Algorithm | Reserved | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | SID/Index/Label (variable) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 where: 445 Type: TBD, suggested value 4. 447 Length: variable 449 Flags: 1 octet field. The following flags are defined: 451 0 1 2 3 4 5 6 7 452 +--+--+--+--+--+--+--+--+ 453 | |NP|M |E |V |L | | | 454 +--+--+--+--+--+--+--+--+ 456 where: 458 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 459 NOT pop the Prefix-SID before delivering the packet to the node 460 that advertised the Prefix-SID. 462 M-Flag: Mapping Server Flag. If set, the SID is advertised 463 from the Segment Routing Mapping Server functionality as 464 described in [I-D.filsfils-spring-segment-routing-ldp-interop]. 466 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 467 the Prefix-SID originator MUST replace the Prefix-SID with a 468 Prefix-SID having an Explicit-NULL value (0 for IPv4) before 469 forwarding the packet. 471 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 472 carries an absolute value. If not set, then the Prefix-SID 473 carries an index. 475 The L-Flag: Local/Global Flag. If set, then the value/index 476 carried by the Prefix-SID has local significance. If not set, 477 then the value/index carried by this Sub-TLV has global 478 significance. 480 Other bits: Reserved. These MUST be zero when sent and are 481 ignored when received. 483 Algorithm: one octet identifying the algorithm the Prefix-SID is 484 associated with as defined in Section 3.1. 486 SID/Index/Label: label or index value depending on the V-bit 487 setting. 489 Examples: 491 A 32 bit global index defining the offset in the SID/Label 492 space advertised by this router - in this case the V and L 493 flags MUST NOT be set. 495 A 24 bit local label where the 20 rightmost bits are used 496 for encoding the label value - in this case the V and L 497 flags MUST be set. 499 If multiple Prefix-SIDs are advertised for the same prefix, the 500 receiving router MUST use the first encoded SID and MAY use the 501 subsequent SIDs. 503 When propagating Prefix-SIDs between areas, if multiple prefix-SIDs 504 are advertised for a prefix, an implementation SHOULD preserve the 505 original order when advertising prefix-SIDs to other areas. This 506 allows implementations that only support a single Prefix-SID to have 507 a consistent view across areas. 509 When calculating the outgoing label for the prefix, the router MUST 510 take into account E and P flags advertised by the next-hop router, if 511 next-hop router advertised the SID for the prefix. This MUST be done 512 regardless of whether the next-hop router contributes to the best 513 path to the prefix. 515 The NP-Flag (No-PHP) MUST be set for Prefix-SIDs allocated to inter- 516 area prefixes that are originated by the ABR based on intra-area or 517 inter-area reachability between areas. When the inter-area prefix is 518 generated based on a prefix which is directly attached to the ABR, 519 NP-Flag SHOULD NOT be set 521 The NP-Flag (No-PHP) MUST be set on the Prefix-SIDs allocated to 522 redistributed prefixes, unless the redistributed prefix is directly 523 attached to ASBR, in which case the NP-Flag SHOULD NOT be set. 525 If the NP-Flag is not set then any upstream neighbor of the Prefix- 526 SID originator MUST pop the Prefix-SID. This is equivalent to the 527 penultimate hop popping mechanism used in the MPLS dataplane. In 528 such case, MPLS EXP bits of the Prefix-SID are not preserved for the 529 final destination (the Prefix-SID being removed). If the NP-Flag is 530 clear then the received E-flag is ignored. 532 If the NP-Flag is set then: 534 If the E-flag is not set then any upstream neighbor of the Prefix- 535 SID originator MUST keep the Prefix-SID on top of the stack. This 536 is useful when the originator of the Prefix-SID must stitch the 537 incoming packet into a continuing MPLS LSP to the final 538 destination. This could occur at an inter-area border router 539 (prefix propagation from one area to another) or at an inter- 540 domain border router (prefix propagation from one domain to 541 another). 543 If the E-flag is set then any upstream neighbor of the Prefix-SID 544 originator MUST replace the Prefix-SID with a Prefix-SID having an 545 Explicit-NULL value. This is useful, e.g., when the originator of 546 the Prefix-SID is the final destination for the related prefix and 547 the originator wishes to receive the packet with the original EXP 548 bits. 550 When M-Flag is set, NP-flag and E-flag MUST be ignored at reception. 552 As the Mapping Server does not specify the originator of a prefix 553 advertisement it is not possible to determine PHP behavior solely 554 based on the Mapping Server advertisement. However, PHP behavior may 555 safely be done in following cases: 557 Prefix is of intra-area type and the downstream neighbor is the 558 originator of the prefix. 560 Prefix is of inter-area type and downstream neighbor is an ABR, 561 which is advertising the prefix reachability and is setting LA-bit 562 in the Prefix Options as described in section 3.1 of 563 [I-D.ietf-ospf-ospfv3-lsa-extend]. 565 Prefix is of external type and downstream neighbor is an ASBR, 566 which is advertising the prefix reachability and is setting LA-bit 567 in the Prefix Options as described in section 3.1 of 568 [I-D.ietf-ospf-ospfv3-lsa-extend]. 570 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 571 the value advertised in Prefix SID Sub-TLV is interpreted as a 572 starting SID value. 574 Example 1: if the following router addresses (loopback addresses) 575 need to be mapped into the corresponding Prefix SID indexes: 577 Router-A: 192::1/128, Prefix-SID: Index 1 578 Router-B: 192::2/128, Prefix-SID: Index 2 579 Router-C: 192::3/128, Prefix-SID: Index 3 580 Router-D: 192::4/128, Prefix-SID: Index 4 582 then the Address Prefix field in the OSPFv3 Extended Prefix Range TLV 583 is set to 192::1, Prefix Length would be set to 128, Range Size would 584 be set to 4 and the Index value in the Prefix-SID Sub-TLV would be 585 set to 1. 587 Example 2: If the following prefixes need to be mapped into the 588 corresponding Prefix-SID indexes: 590 10:1:1::0/120, Prefix-SID: Index 51 591 10:1:1::100/120, Prefix-SID: Index 52 592 10:1:1::200/120, Prefix-SID: Index 53 593 10:1:1::300/120, Prefix-SID: Index 54 594 10:1:1::400/120, Prefix-SID: Index 55 595 10:1:1::500/120, Prefix-SID: Index 56 596 10:1:1::600/120, Prefix-SID: Index 57 598 then the Address Prefix field in the OSPFv3 Extended Prefix Range TLV 599 is set to 10:1:1::0, Prefix Length would be set to 120, Range Size 600 would be set to 7 and the Index value in the Prefix-SID Sub-TLV would 601 be set to 51. 603 6. SID/Label Binding Sub-TLV 605 The SID/Label Binding Sub-TLV is used to advertise SID/Label mapping 606 for a path to the prefix. 608 The SID/Label Binding Sub-TLV MAY be originated by any router in an 609 OSPFv3 domain. The router may advertise a SID/Label binding to a FEC 610 along with at least a single 'nexthop style' anchor. The protocol 611 supports more than one 'nexthop style' anchor to be attached to a 612 SID/Label binding, which results into a simple path description 613 language. In analogy to RSVP the terminology for this is called an 614 'Explicit Route Object' (ERO). Since ERO style path notation allows 615 anchoring SID/label bindings to both link and node IP addresses, any 616 Label Switched Path (LSP) can be described. Furthermore, SID/Label 617 Bindings from external protocols can also be re-advertised. 619 The SID/Label Binding Sub-TLV may be used for advertising SID/Label 620 Bindings and their associated Primary and Backup paths. In one 621 single TLV, either a primary ERO Path, backup ERO Path, or both are 622 advertised. If a router wants to advertise multiple parallel paths, 623 then it can generate several TLVs for the same Prefix/FEC. Each 624 occurrence of a Binding TLV for a given FEC Prefix will add a new 625 path. 627 SID/Label Binding Sub-TLV is a Sub-TLV of the following OSPFv3 TLVs, 628 as defined in [I-D.ietf-ospf-ospfv3-lsa-extend] and in Section 4: 630 Intra-Area Prefix TLV 632 Inter-Area Prefix TLV 634 External Prefix TLV 636 OSPFv3 Extended Prefix Range TLV 638 Multiple SID/Label Binding Sub-TLVs can be present in these TLVs. 639 The SID/Label Binding Sub-TLV has following format: 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Type | Length | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Flags | Weight | Reserved | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Sub-TLVs (variable) | 649 +- -+ 650 | | 652 where: 654 Type: TBD, suggested value 7 656 Length: variable 658 Flags: 1 octet field of following flags: 660 0 1 2 3 4 5 6 7 661 +-+-+-+-+-+-+-+-+ 662 |M| | 663 +-+-+-+-+-+-+-+-+ 665 where: 667 M-bit - When the bit is set the binding represents the 668 mirroring context as defined in 669 [I-D.minto-rsvp-lsp-egress-fast-protection]. 671 Weight: weight used for load-balancing purposes. The use of the 672 weight is defined in section 3.5.1 of 673 [I-D.ietf-spring-segment-routing]. 675 SID/Label Binding Sub-TLV currently supports following Sub-TLVs: 677 SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST 678 appear in the SID/Label Binding Sub-TLV and it MUST only appear 679 once. 681 ERO Metric Sub-TLV as defined in Section 6.1. 683 ERO Sub-TLVs as defined in Section 6.2. 685 6.1. ERO Metric Sub-TLV 687 The ERO Metric Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 689 The ERO Metric Sub-TLV advertises the cost of an ERO path. It is 690 used to compare the cost of a given source/destination path. A 691 router SHOULD advertise the ERO Metric Sub-TLV in an advertised ERO 692 TLV. The cost of the ERO Metric Sub-TLV SHOULD be set to the 693 cumulative IGP or TE path cost of the advertised ERO. Since 694 manipulation of the Metric field may attract or repel traffic to and 695 from the advertised segment, it MAY be manually overridden. 697 0 1 2 3 698 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 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Type | Length | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Metric (4 octets) | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 ERO Metric Sub-TLV format 707 where: 709 Type: TBD, suggested value 8 711 Length: Always 4 713 Metric: A 4 octet metric representing the aggregate IGP or TE path 714 cost. 716 6.2. ERO Sub-TLVs 718 All 'ERO' information represents an ordered set which describes the 719 segments of a path. The first ERO Sub-TLV describes the first 720 segment of a path. Similiarly, the last ERO Sub-TLV describes the 721 segment closest to the egress point. If a router extends or stitches 722 a path, it MUST prepend the new segment's path information to the ERO 723 list. This applies equally to advertised backup EROs. 725 All ERO Sub-TLVs must immediately follow the (SID)/Label Sub-TLV. 727 All Backup ERO Sub-TLVs must immediately follow the last ERO Sub-TLV. 729 6.2.1. IPv4 ERO Sub-TLV 731 IPv4 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 733 The IPv4 ERO Sub-TLV describes a path segment using IPv4 Address 734 style of encoding. Its semantics have been borrowed from [RFC3209]. 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Type | Length | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Flags | Reserved | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | IPv4 Address (4 octets) | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 IPv4 ERO Sub-TLV format 748 where: 750 Type: TBD, suggested value 9 752 Length: 8 bytes 754 Flags: 1 octet field of following flags: 756 0 1 2 3 4 5 6 7 757 +-+-+-+-+-+-+-+-+ 758 |L| | 759 +-+-+-+-+-+-+-+-+ 761 where: 763 L-bit - If the L-bit is set, then the segment path is 764 designated as 'loose'. Otherwise, the segment path is 765 designated as 'strict'. 767 IPv4 Address - the address of the explicit route hop. 769 6.2.2. IPv6 ERO Sub-TLV 771 IPv6 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 773 The IPv6 ERO Sub-TLV (Type TBA) describes a path segment using IPv6 774 Address style of encoding. Its semantics have been borrowed from 775 [RFC3209]. 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Type | Length | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Flags | Reserved | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | | 785 +- -+ 786 | | 787 +- IPv6 Address -+ 788 | | 789 +- -+ 790 | | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 IPv6 ERO Sub-TLV format 795 where: 797 Type: TBD, suggested value 10 799 Length: 8 bytes 801 Flags: 1 octet field of following flags: 803 0 1 2 3 4 5 6 7 804 +-+-+-+-+-+-+-+-+ 805 |L| | 806 +-+-+-+-+-+-+-+-+ 808 where: 810 L-bit - If the L-bit is set, then the segment path is 811 designated as 'loose'. Otherwise, the segment path is 812 designated as 'strict'. 814 IPv6 Address - the address of the explicit route hop. 816 6.2.3. Unnumbered Interface ID ERO Sub-TLV 818 The Unnumbered Interface ID ERO Sub-TLV is a Sub-TLV of the SID/Label 819 Binding Sub-TLV. 821 The appearance and semantics of the 'Unnumbered Interface ID' have 822 been borrowed from [RFC3477]. 824 The Unnumbered Interface-ID ERO Sub-TLV describes a path segment that 825 spans over an unnumbered interface. Unnumbered interfaces are 826 referenced using the interface index. Interface indices are assigned 827 local to the router and therefore not unique within a domain. All 828 elements in an ERO path need to be unique within a domain and hence 829 need to be disambiguated using a domain unique Router-ID. 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Type | Length | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Flags | Reserved | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Router ID | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Interface ID | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 where: 845 Unnumbered Interface ID ERO Sub-TLV format 847 Type: TBD, suggested value 11 849 Length: 12 bytes 850 Flags: 1 octet field of following flags: 852 0 1 2 3 4 5 6 7 853 +-+-+-+-+-+-+-+-+ 854 |L| | 855 +-+-+-+-+-+-+-+-+ 857 where: 859 L-bit - If the L-bit is set, then the segment path is 860 designated as 'loose'. Otherwise, the segment path is 861 designated as 'strict'. 863 Router-ID: Router-ID of the next-hop. 865 Interface ID: is the identifier assigned to the link by the router 866 specified by the Router-ID. 868 6.2.4. IPv4 Backup ERO Sub-TLV 870 IPv4 Prefix Backup ERO Sub-TLV is a Sub-TLV of the SID/Label Binding 871 Sub-TLV. 873 The IPv4 Backup ERO Sub-TLV describes a path segment using IPv4 874 Address style of encoding. Its semantics have been borrowed from 875 [RFC3209]. 877 0 1 2 3 878 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 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Type | Length | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Flags | Reserved | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | IPv4 Address (4 octets) | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 IPv4 Backup ERO Sub-TLV format 889 where: 891 Type: TBD, suggested value 12 893 Length: 8 bytes 895 Flags: 1 octet field of following flags: 897 0 1 2 3 4 5 6 7 898 +-+-+-+-+-+-+-+-+ 899 |L| | 900 +-+-+-+-+-+-+-+-+ 902 where: 904 L-bit - If the L-bit is set, then the segment path is 905 designated as 'loose'. Otherwise, the segment path is 906 designated as 'strict'.' 908 IPv4 Address - the address of the explicit route hop. 910 6.2.5. IPv6 Backup ERO Sub-TLV 912 The IPv6 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 914 The IPv6 Backup ERO Sub-TLV describes a Backup path segment using 915 IPv6 Address style of encoding. Its appearance and semantics have 916 been borrowed from [RFC3209]. 918 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 919 set, then the value of the attribute is 'loose.' Otherwise, the 920 value of the attribute is 'strict.' 922 0 1 2 3 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Type | Length | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Flags | Reserved | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | | 930 +- -+ 931 | | 932 +- IPv6 Address -+ 933 | | 934 +- -+ 935 | | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 IPv6 Backup ERO Sub-TLV format 940 where: 942 Type: TBD, suggested value 13 944 Length: 8 bytes 945 Flags: 1 octet field of following flags: 947 0 1 2 3 4 5 6 7 948 +-+-+-+-+-+-+-+-+ 949 |L| | 950 +-+-+-+-+-+-+-+-+ 952 where: 954 L-bit - If the L-bit is set, then the segment path is 955 designated as 'loose'. Otherwise, the segment path is 956 designated as 'strict'. 958 IPv6 Address - the address of the explicit route hop. 960 6.2.6. Unnumbered Interface ID Backup ERO Sub-TLV 962 The Unnumbered Interface ID Backup Sub-TLV is a Sub-TLV of the SID/ 963 Label Binding Sub-TLV. 965 The appearance and semantics of the 'Unnumbered Interface ID' have 966 been borrowed from [RFC3477]. 968 The Unnumbered Interface-ID Backup ERO Sub-TLV describes a path 969 segment that spans over an unnumbered interface. Unnumbered 970 interfaces are referenced using the interface index. Interface 971 indices are assigned local to the router and are therefore not unique 972 within a domain. All elements in an ERO path need to be unique 973 within a domain and hence need to be disambiguated with specification 974 of the unique Router-ID. 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Type | Length | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Flags | Reserved | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Router ID | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | Interface ID | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 Unnumbered Interface ID Backup ERO Sub-TLV format 990 where: 992 Type: TBD, suggested value 14 993 Length: 12 bytes 995 Flags: 1 octet field of following flags: 997 0 1 2 3 4 5 6 7 998 +-+-+-+-+-+-+-+-+ 999 |L| | 1000 +-+-+-+-+-+-+-+-+ 1002 where: 1004 L-bit - If the L-bit is set, then the segment path is 1005 designated as 'loose'. Otherwise, the segment path is 1006 designated as 'strict'. 1008 Router-ID: Router-ID of the next-hop. 1010 Interface ID: is the identifier assigned to the link by the router 1011 specified by the Router-ID. 1013 7. Adjacency Segment Identifier (Adj-SID) 1015 An Adjacency Segment Identifier (Adj-SID) represents a router 1016 adjacency in Segment Routing. 1018 7.1. Adj-SID Sub-TLV 1020 The extended OSPFv3 LSAs, as defined in 1021 [I-D.ietf-ospf-ospfv3-lsa-extend], are used to advertise prefix SID 1022 in OSPFv3 1024 The Adj-SID Sub-TLV is an optional Sub-TLV of the Router-Link TLV as 1025 defined in [I-D.ietf-ospf-ospfv3-lsa-extend]. It MAY appear multiple 1026 times in Router-Link TLV. Examples where more than one Adj-SID may 1027 be used per neighbor are described in section 4 of 1028 [I-D.filsfils-spring-segment-routing-use-cases]. The Adj-SID Sub-TLV 1029 has the following format: 1031 0 1 2 3 1032 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 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Type | Length | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Flags | Weight | Reserved | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | SID/Label/Index (variable) | 1039 +---------------------------------------------------------------+ 1041 where: 1043 Type: TBD, suggested value 5. 1045 Length: variable. 1047 Flags. 1 octet field of following flags: 1049 0 1 2 3 4 5 6 7 1050 +-+-+-+-+-+-+-+-+ 1051 |B|V|L|S| | 1052 +-+-+-+-+-+-+-+-+ 1054 where: 1056 B-Flag: Backup-flag. If set, the Adj-SID refers to an 1057 adjacency that is eligible for protection (e.g.: using IPFRR or 1058 MPLS-FRR) as described in section 3.5 of 1059 [I-D.ietf-spring-segment-routing]. 1061 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 1062 an absolute value. If not set, then the Adj-SID carries an 1063 index. 1065 The L-Flag: Local/Global Flag. If set, then the value/index 1066 carried by the Adj-SID has local significance. If not set, 1067 then the value/index carried by this Sub-TLV has global 1068 significance. 1070 The S-Flag. Set Flag. When set, the S-Flag indicates that the 1071 Adj-SID refers to a set of adjacencies (and therefore MAY be 1072 assigned to other adjacencies as well). 1074 Other bits: Reserved. These MUST be zero when sent and are 1075 ignored when received. 1077 Weight: weight used for load-balancing purposes. The use of the 1078 weight is defined in section 3.5.1 of 1079 [I-D.ietf-spring-segment-routing]. 1081 SID/Index/Label: label or index value depending on the V-bit 1082 setting. 1084 Examples: 1086 A 32 bit global index defining the offset in the SID/Label 1087 space advertised by this router - in this case the V and L 1088 flags MUST NOT be set. 1090 A 24 bit local label where the 20 rightmost bits are used 1091 for encoding the label value - in this case the V and L 1092 flags MUST be set. 1094 16 octet IPv6 address - in this case the V-flag MUST be set. 1095 The L-flag MUST be set for link-local IPv6 address and MUST 1096 NOT be set for IPv6 global unicast address. 1098 An SR capable router MAY allocate an Adj-SID for each of its 1099 adjacencies and set the B-Flag when the adjacency is eligible for 1100 protection by an FRR mechanism (IP or MPLS) as described in section 1101 3.5 of [I-D.ietf-spring-segment-routing]. 1103 7.2. LAN Adj-SID Sub-TLV 1105 The LAN Adj-SID is an optional Sub-TLV of the Router-Link TLV. It 1106 MAY appear multiple times in the Router-Link TLV. It is used to 1107 advertise a SID/Label for an adjacency to a non-DR neighbor on a 1108 broadcast or NBMA network. 1110 0 1 2 3 1111 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 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | Type | Length | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Flags | Weight | Reserved | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Neighbor ID | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | SID/Label/Index (variable) | 1120 +---------------------------------------------------------------+ 1122 where: 1124 Type: TBD, suggested value 6. 1126 Length: variable. 1128 Flags. 1 octet field of following flags: 1130 0 1 2 3 4 5 6 7 1131 +-+-+-+-+-+-+-+-+ 1132 |B|V|L|S| | 1133 +-+-+-+-+-+-+-+-+ 1135 where: 1137 B-Flag: Backup-flag: set if the LAN-Adj-SID refer to an 1138 adjacency that is eligible for protection (e.g.: using IPFRR or 1139 MPLS-FRR) as described in section 3.1 of 1140 [I-D.filsfils-spring-segment-routing-use-cases]. 1142 The V-Flag: Value/Index Flag. If set, then the LAN Adj-SID 1143 carries an absolute value. If not set, then the LAN Adj-SID 1144 carries an index. 1146 The L-Flag: Local/Global Flag. If set, then the value/index 1147 carried by the LAN Adj-SID has local significance. If not set, 1148 then the value/index carried by this subTLV has global 1149 significance. 1151 The S-Flag. Set Flag. When set, the S-Flag indicates that the 1152 LAN Adj-SID refers to a set of adjacencies (and therefore MAY 1153 be assigned to other adjacencies as well). 1155 Other bits: Reserved. These MUST be zero when sent and are 1156 ignored when received. 1158 Weight: weight used for load-balancing purposes. The use of the 1159 weight is defined in section 3.5.1 of 1160 [I-D.ietf-spring-segment-routing]. 1162 Neighbor ID: The Router ID of the neighbor for which the Adj-SID 1163 is advertised. 1165 SID/Index/Label: label or index value depending on the V-bit 1166 setting. 1168 Examples: 1170 A 32 bit global index defining the offset in the SID/Label 1171 space advertised by this router - in this case the V and L 1172 flags MUST NOT be set. 1174 A 24 bit local label where the 20 rightmost bits are used 1175 for encoding the label value - in this case the V and L 1176 flags MUST be set. 1178 16 octet IPv6 address - in this case the V-flag MUST be set. 1179 The L-flag MUST be set for link-local IPv6 address and MUST 1180 NOT be set for IPv6 global unicast address. 1182 8. Elements of Procedure 1184 8.1. Intra-area Segment routing in OSPFv3 1186 An OSPFv3 router that supports segment routing MAY advertise Prefix- 1187 SIDs for any prefix that it is advertising reachability for (e.g., 1188 loopback IP address) as described in Section 5. 1190 If multiple routers advertise a Prefix-SID for the same prefix, then 1191 the Prefix-SID MUST be the same. This is required in order to allow 1192 traffic load-balancing when multiple equal cost paths to the 1193 destination exist in the network. 1195 The Prefix-SID can also be advertised by the SR Mapping Servers (as 1196 described in [I-D.filsfils-spring-segment-routing-ldp-interop]). The 1197 Mapping Server advertises Prefix-SID for remote prefixes that exist 1198 in the network. Multiple Mapping Servers can advertise Prefix-SID 1199 for the same prefix, in which case the same Prefix-SID MUST be 1200 advertised by all of them. The SR Mapping Server could use either 1201 area scope or autonomous system flooding scope when advertising 1202 Prefix SID for prefixes, based on the configuration of the SR Mapping 1203 Server. Depending on the flooding scope used, the SR Mapping Server 1204 chooses the LSA that will be used. If the area flooding scope is 1205 needed, E-Intra-Area-Prefix-LSA ([I-D.ietf-ospf-ospfv3-lsa-extend]) 1206 is used. If autonomous system flooding scope is needed, E-AS- 1207 External-LSA ([I-D.ietf-ospf-ospfv3-lsa-extend]) is used. 1209 When a Prefix-SID is advertised by the Mapping Server, which is 1210 indicated by the M-flag in the Prefix-SID Sub-TLV (Section 5), the 1211 route type as implied by the LSA type is ignored and the Prefix-SID 1212 is bound to the corresponding prefix independent of the route type. 1214 Advertisement of the Prefix-SID by the Mapping Server using Inter- 1215 Area Prefix TLV, External-Prefix TLV or Intra-Area-Prefix TLV 1216 ([I-D.ietf-ospf-ospfv3-lsa-extend]) does not itself contribute to the 1217 prefix reachability. The NU-bit MUST be set in the PrefixOptions 1218 field of the LSA which is used by the Mapping Server to advertise SID 1219 or SID range, which prevents the advertisement to contribute to 1220 prefix reachability. 1222 SR Mapping Server MUST use OSPF Extended Prefix Range TLV when 1223 advertising SIDs for prefixes. Prefixes of different route-types can 1224 be combined in a single OSPF Extended Prefix Range TLV advertised by 1225 the SR Mapping Server. 1227 Area scoped OSPF Extended Prefix Range TLV are propagated between 1228 areas. Similar to propagation of prefixes between areas, ABR only 1229 propagates the OSPF Extended Prefix Range TLV that it considers to be 1230 the best from the set it received. The rules used to pick the best 1231 OSPF Extended Prefix Range TLV is described in Section 4. 1233 When propagating OSPF Extended Prefix Range TLV between areas, ABR 1234 MUST set the IA-Flag, that is used to prevent redundant flooding of 1235 the OSPF Extended Prefix Range TLV between areas as described in 1236 Section 4. 1238 If the Prefix-SID that is advertised in Prefix SID Sub-TLV is also 1239 covered by the OSPF Extended Prefix Range TLV, the Prefix-SID 1240 advertised in Prefix SID Sub-TLV MUST be preferred. 1242 8.2. Inter-area Segment routing in OSPFv3 1244 In order to support SR in a multi-area environment, OSPFv3 must 1245 propagate Prefix-SID information between areas. The following 1246 procedure is used in order to propagate Prefix SIDs between areas. 1248 When an OSPFv3 ABR advertises a Inter-Area-Prefix-LSA from an intra- 1249 area prefix to all its connected areas, it will also include Prefix- 1250 SID Sub-TLV, as described in Section 5. The Prefix-SID value will be 1251 set as follows: 1253 The ABR will look at its best path to the prefix in the source 1254 area and find out the advertising router associated with the best 1255 path to that prefix. 1257 The ABR will then determine if such router advertised a Prefix-SID 1258 for the prefix and use it when advertising the Prefix-SID to other 1259 connected areas. 1261 If no Prefix-SID was advertised for the prefix in the source area 1262 by the router that contributes to the best path to the prefix, the 1263 originating ABR will use the Prefix-SID advertised by any other 1264 router when propagating Prefix-SID for the prefix to other areas. 1266 When an OSPFv3 ABR advertises Inter-Area-Prefix-LSA LSAs from an 1267 inter-area route to all its connected areas it will also include 1268 Prefix-SID Sub-TLV, as described in Section 5. The Prefix-SID value 1269 will be set as follows: 1271 The ABR will look at its best path to the prefix in the source 1272 area and find out the advertising router associated with the best 1273 path to that prefix. 1275 The ABR will then look if such router advertised a Prefix-SID for 1276 the prefix and use it when advertising the Prefix-SID to other 1277 connected areas. 1279 If no Prefix-SID was advertised for the prefix in the source area 1280 by the ABR that contributes to the best path to the prefix, the 1281 originating ABR will use the Prefix-SID advertised by any other 1282 router when propagating Prefix-SID for the prefix to other areas. 1284 8.3. SID for External Prefixes 1286 AS-External-LSAs are flooded domain wide. When an ASBR, which 1287 supports SR, generates E-AS-External-LSA, it should also include 1288 Prefix-SID Sub-TLV, as described in Section 5. The Prefix-SID value 1289 will be set to the SID that has been reserved for that prefix. 1291 When an NSSA ASBR translates an E-NSSA-LSA into an E-AS-External-LSA, 1292 it should also advertise the Prefix-SID for the prefix. The NSSA ABR 1293 determines its best path to the prefix advertised in the translated 1294 E-NSSA-LSA and finds the advertising router associated with that 1295 path. If the advertising router has advertised a Prefix-SID for the 1296 prefix, then the NSSA ABR uses it when advertising the Prefix-SID in 1297 the E-AS-External-LSA. Otherwise the Prefix-SID advertised by any 1298 other router will be used. 1300 8.4. Advertisement of Adj-SID 1302 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1303 using the Adj-SID Sub-TLV as described in Section 7. 1305 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 1307 An Adj-SID MAY be advertised for any adjacency on p2p link that is in 1308 a state 2-Way or higher. If the adjacency on a p2p link transitions 1309 from the FULL state, then the Adj-SID for that adjacency MAY be 1310 removed from the area. If the adjacency transitions to a state lower 1311 then 2-Way, then the Adj-SID advertisement MUST be removed from the 1312 area. 1314 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1316 Broadcast or NBMA networks in OSPFv3 are represented by a star 1317 topology where the Designated Router (DR) is the central point to 1318 which all other routers on the broadcast or NBMA network connect. As 1319 a result, routers on the broadcast or NBMA network advertise only 1320 their adjacency to the DR. Routers that do not act as DR do not form 1321 or advertise adjacencies with each other. They do, however, maintain 1322 a 2-Way adjacency state with each other and are directly reachable. 1324 When Segment Routing is used, each router on the broadcast or NBMA 1325 network MAY advertise the Adj-SID for its adjacency to the DR using 1326 Adj-SID Sub-TLV as described in Section 7.1. 1328 SR capable routers MAY also advertise an Adj-SID for other neighbors 1329 (e.g. BDR, DR-OTHER) on the broadcast or NBMA network using the LAN 1330 ADJ-SID Sub-TLV as described in Section 7.2. 1332 9. IANA Considerations 1334 This specification updates several existing OSPF registries. 1336 9.1. OSPF Router Information (RI) TLVs Registry 1338 o 8 (IANA Preallocated) - SR-Algorithm TLV 1340 o 9 (IANA Preallocated) - SID/Label Range TLV 1342 9.2. OSPFv3 Extend-LSA TLV Registry 1344 Following values are allocated: 1346 o suggested value 9 - OSPF Extended Prefix Range TLV 1348 9.3. OSPFv3 Extend-LSA Sub-TLV registry 1350 o suggested value 3 - SID/Label Sub-TLV 1352 o suggested value 4 - Prefix SID Sub-TLV 1354 o suggested value 5 - Adj-SID Sub-TLV 1356 o suggested value 6 - LAN Adj-SID Sub-TLV 1358 o suggested value 7 - SID/Label Binding Sub-TLV 1360 o suggested value 8 - ERO Metric Sub-TLV 1362 o suggested value 9 - IPv4 ERO Sub-TLV 1364 o suggested value 10 - IPv6 ERO Sub-TLV 1366 o suggested value 11 - Unnumbered Interface ID ERO Sub-TLV 1367 o suggested value 12 - IPv4 Backup ERO Sub-TLV 1369 o suggested value 13 - IPv6 Backup ERO Sub-TLV 1371 o suggested value 14 - Unnumbered Interface ID Backup ERO Sub-TLV 1373 10. Security Considerations 1375 Implementations must assure that malformed permutations of the newly 1376 defined sub-TLvs do not result in errors which cause hard OSPFv3 1377 failures. 1379 11. Acknowledgements 1381 Thanks to Acee Lindem for the detail review of the draft, 1382 corrections, as well as discussion about details of the encoding. 1384 We would like to thank Anton Smirnov for his contribution. 1386 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1387 contribution on earlier incarnations of the "Binding / MPLS Label 1388 TLV" in [I-D.gredler-ospf-label-advertisement]. 1390 12. References 1392 12.1. Normative References 1394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1395 Requirement Levels", BCP 14, RFC 2119, 1396 DOI 10.17487/RFC2119, March 1997, 1397 . 1399 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1400 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1401 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1402 . 1404 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1405 in Resource ReSerVation Protocol - Traffic Engineering 1406 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1407 . 1409 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1410 S. Shaffer, "Extensions to OSPF for Advertising Optional 1411 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 1412 2007, . 1414 12.2. Informative References 1416 [I-D.filsfils-spring-segment-routing-ldp-interop] 1417 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1418 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1419 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1420 "Segment Routing interoperability with LDP", draft- 1421 filsfils-spring-segment-routing-ldp-interop-02 (work in 1422 progress), September 2014. 1424 [I-D.filsfils-spring-segment-routing-use-cases] 1425 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1426 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1427 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1428 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1429 spring-segment-routing-use-cases-01 (work in progress), 1430 October 2014. 1432 [I-D.gredler-ospf-label-advertisement] 1433 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1434 "Advertising MPLS labels in OSPF", draft-gredler-ospf- 1435 label-advertisement-03 (work in progress), May 2013. 1437 [I-D.ietf-ospf-ospfv3-lsa-extend] 1438 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 1439 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-10 1440 (work in progress), May 2016. 1442 [I-D.ietf-spring-segment-routing] 1443 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1444 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1445 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 1446 spring-segment-routing-01 (work in progress), February 1447 2015. 1449 [I-D.minto-rsvp-lsp-egress-fast-protection] 1450 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1451 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1452 protection-03 (work in progress), November 2013. 1454 [I-D.previdi-6man-segment-routing-header] 1455 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 1456 J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment 1457 Routing Header (SRH)", draft-previdi-6man-segment-routing- 1458 header-08 (work in progress), October 2015. 1460 Authors' Addresses 1462 Peter Psenak (editor) 1463 Cisco Systems, Inc. 1464 Apollo Business Center 1465 Mlynske nivy 43 1466 Bratislava 821 09 1467 Slovakia 1469 Email: ppsenak@cisco.com 1471 Stefano Previdi (editor) 1472 Cisco Systems, Inc. 1473 Via Del Serafico, 200 1474 Rome 00142 1475 Italy 1477 Email: sprevidi@cisco.com 1479 Clarence Filsfils 1480 Cisco Systems, Inc. 1481 Brussels 1482 Belgium 1484 Email: cfilsfil@cisco.com 1486 Hannes Gredler 1487 Individual 1488 Austria 1490 Email: hannes@gredler.at 1492 Rob Shakir 1493 Jive Communications, Inc. 1494 1275 West 1600 North, Suite 100 1495 Orem, UT 84057 1496 US 1498 Email: rrjs@rob.sh 1499 Wim Henderickx 1500 Nokia 1501 Copernicuslaan 50 1502 Antwerp 2018 1503 BE 1505 Email: wim.henderickx@nokia.com 1507 Jeff Tantsura 1508 Individual 1509 US 1511 Email: jefftant.ietf@gmail.com