idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-16.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 23, 2017) is 2520 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 314 -- Looks like a reference, but probably isn't: '199' on line 314 -- Looks like a reference, but probably isn't: '1000' on line 315 -- Looks like a reference, but probably isn't: '1099' on line 315 -- Looks like a reference, but probably isn't: '500' on line 316 -- Looks like a reference, but probably isn't: '599' on line 316 == Outdated reference: A later version (-05) exists of draft-ietf-spring-conflict-resolution-03 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Shortest Path First IGP P. Psenak, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Standards Track C. Filsfils 5 Expires: November 24, 2017 Cisco Systems, Inc. 6 H. Gredler 7 RtBrick Inc. 8 R. Shakir 9 Google, Inc. 10 W. Henderickx 11 Nokia 12 J. Tantsura 13 Individual 14 May 23, 2017 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-16 19 Abstract 21 Segment Routing (SR) allows a flexible definition of end-to-end paths 22 within IGP topologies by encoding paths as sequences of topological 23 sub-paths, called "segments". These segments are advertised by the 24 link-state routing protocols (IS-IS and OSPF). 26 This draft describes the OSPF extensions required for Segment 27 Routing. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on November 24, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 70 2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 71 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4 72 3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4 73 3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 6 74 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 8 75 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 9 76 4. OSPF Extended Prefix Range TLV . . . . . . . . . . . . . . . 10 77 5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 12 78 6. SID/Label Binding Sub-TLV . . . . . . . . . . . . . . . . . . 16 79 6.1. ERO Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 17 80 6.2. ERO Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 18 81 6.2.1. IPv4 ERO Sub-TLV . . . . . . . . . . . . . . . . . . 18 82 6.2.2. Unnumbered Interface ID ERO Sub-TLV . . . . . . . . . 19 83 6.2.3. IPv4 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 21 84 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV . . . . . 22 85 7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 23 86 7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 23 87 7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 25 88 8. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 26 89 8.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 26 90 8.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 27 91 8.3. Segment Routing for External Prefixes . . . . . . . . . . 28 92 8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 29 93 8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 29 94 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 29 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 96 9.1. OSPF OSPF Router Information (RI) TLVs Registry . . . . . 29 97 9.2. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 30 98 9.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 30 99 9.4. OSPF Extended Link LSA Sub-TLV Registry . . . . . . . . . 30 100 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 30 101 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 102 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 103 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 104 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 105 14.1. Normative References . . . . . . . . . . . . . . . . . . 32 106 14.2. Informative References . . . . . . . . . . . . . . . . . 33 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 109 1. Introduction 111 Segment Routing (SR) allows a flexible definition of end-to-end paths 112 within IGP topologies by encoding paths as sequences of topological 113 sub-paths, called "segments". These segments are advertised by the 114 link-state routing protocols (IS-IS and OSPF). Prefix segments 115 represent an ECMP-aware shortest-path to a prefix (or a node), as per 116 the state of the IGP topology. Adjacency segments represent a hop 117 over a specific adjacency between two nodes in the IGP. A prefix 118 segment is typically a multi-hop path while an adjacency segment, in 119 most cases, is a one-hop path. SR's control-plane can be applied to 120 both IPv6 and MPLS data-planes, and does not require any additional 121 signalling (other than IGP extensions). The IPv6 data plane is out 122 of the scope of this specification - it is not applicable to OSPFv2 123 which only supports the IPv4 address-family. For example, when used 124 in MPLS networks, SR paths do not require any LDP or RSVP-TE 125 signalling. However, SR can interoperate in the presence of LSPs 126 established with RSVP or LDP. 128 There are additional segment types, e.g., Binding SID defined in 129 [I-D.ietf-spring-segment-routing]. 131 This draft describes the OSPF extensions required for Segment 132 Routing. 134 Segment Routing architecture is described in 135 [I-D.ietf-spring-segment-routing]. 137 Segment Routing use cases are described in 138 [I-D.filsfils-spring-segment-routing-use-cases]. 140 2. Segment Routing Identifiers 142 Segment Routing defines various types of Segment Identifiers (SIDs): 143 Prefix-SID, Adjacency-SID, LAN Adjacency SID, and Binding SID. 145 Extended Prefix/Link Opaque LSAs defined in [RFC7684] are used for 146 advertisements of the various SID types. 148 2.1. SID/Label Sub-TLV 150 The SID/Label Sub-TLV appears in multiple TLVs or Sub-TLVs defined 151 later in this document. It is used to advertise the SID or label 152 associated with a prefix or adjacency. The SID/Label TLV has 153 following format: 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Type | Length | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | SID/Label (variable) | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 where: 165 Type: TBD, suggested value 1 167 Length: Variable, 3 or 4 octet 169 SID/Label: If length is set to 3, then the 20 rightmost bits 170 represent a label. If length is set to 4, then the value 171 represents a 32-bit SID. 173 The receiving router MUST ignore the SID/Label Sub-TLV if the 174 length is other then 3 or 4. 176 3. Segment Routing Capabilities 178 Segment Routing requires some additional router capabilities to be 179 advertised to other routers in the area. 181 These SR capabilities are advertised in the Router Information Opaque 182 LSA (defined in [RFC7770]). 184 3.1. SR-Algorithm TLV 186 The SR-Algorithm TLV is a top-level TLV of the Router Information 187 Opaque LSA (defined in [RFC7770]). 189 The SR-Algorithm TLV is optional. It MUST only be advertised once in 190 the Router Information Opaque LSA. If the SID/Label Range TLV, as 191 defined in Section 3.2, is advertised, then the SR-Algorithm TLV MUST 192 also be advertised. If the SR-Algorithm TLV is not advertised by the 193 node, such node is considered as not being segment routing capable. 195 An SR Router may use various algorithms when calculating reachability 196 to OSPF routers or prefixes in an OSPF area. Examples of these 197 algorithms are metric based Shortest Path First (SPF), various 198 flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a 199 router to advertise the algorithms currently used by the router to 200 other routers in an OSPF area. The SR-Algorithm TLV has following 201 format: 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type | Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Algorithm 1 | Algorithm... | Algorithm n | | 209 +- -+ 210 | | 211 + + 213 where: 215 Type: TBD, suggested value 8 217 Length: Variable 219 Algorithm: Single octet identifying the algorithm. The following 220 values are defined by this document: 222 0: Shortest Path First (SPF) algorithm based on link metric. 223 This is the standard shortest path algorithm as computed by the 224 OSPF protocol. Consistent with the deployed practice for link- 225 state protocols, Algorithm 0 permits any node to overwrite the 226 SPF path with a different path based on its local policy. If 227 the SR-Algorithm TLV is advertised, Algorithm 0 MUST be 228 included. 230 1: Strict Shortest Path First (SPF) algorithm based on link 231 metric. The algorithm is identical to Algorithm 0 but 232 Algorithm 1 requires that all nodes along the path will honor 233 the SPF routing decision. Local policy at the node claiming 234 support for Algorithm 1 MUST NOT alter the SPF paths computed 235 by Algorithm 1. 237 When multiple SR-Algorithm TLVs are received from a given router, the 238 receiver SHOULD use the first occurrence of the TLV in the Router 239 Information LSA. If the SR-Algorithm TLV appears in multiple Router 240 Information LSAs that have different flooding scopes, the SR- 241 Algorithm TLV in the Router Information LSA with the narrowest 242 flooding scope SHOULD be used. If the SR-Algorithm TLV appears in 243 multiple Router Information LSAs that have the same flooding scope, 244 the SR-Algorithm TLV in the Router Information LSA with the 245 numerically smallest Instance ID SHOULD be used and subsequent 246 instances of the SR-Algorithm TLV SHOULD be ignored. 248 The RI LSA can be advertised at any of the defined opaque flooding 249 scopes (link, area, or Autonomous System (AS)). For the purpose of 250 SR-Algorithm TLV advertisement, area scope flooding is required. 252 3.2. SID/Label Range TLV 254 The SID/Label Range TLV is a top-level TLV of the Router Information 255 Opaque LSA (defined in [RFC7770]). 257 The SID/Label Range TLV MAY appear multiple times and has the 258 following format: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type | Length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Range Size | Reserved | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Sub-TLVs (variable) | 268 +- -+ 269 | | 270 + + 272 where: 274 Type: TBD, suggested value 9 276 Length: Variable 278 Range Size: 3-octet SID/label range size (i.e., the number of SIDs 279 or labels in the range including the first SID/label). It MUST be 280 greater than 0. 282 Initially, the only supported Sub-TLV is the SID/Label TLV as defined 283 in Section 2.1. The SID/Label advertised in the SID/Label TLV 284 represents the first SID/Label in the advertised range. 286 Multiple occurrences of the SID/Label Range TLV MAY be advertised, in 287 order to advertise multiple ranges. In such case: 289 o The originating router MUST encode each range into a different 290 SID/Label Range TLV. 292 o The originating router decides the order in which the set of SID/ 293 Label Range TLVs are advertised inside the Router Information 294 Opaque LSA. The originating router MUST ensure the order is the 295 same after a graceful restart (using checkpointing, non-volatile 296 storage, or any other mechanism) in order to assure the SID/label 297 range and SID index correspondence is preserved across graceful 298 restarts. 300 o The receiving router MUST adhere to the order in which the ranges 301 are advertised when calculating a SID/label from a SID index. 303 The following example illustrates the advertisement of multiple 304 ranges: 306 The originating router advertises the following ranges: 307 Range 1: [100, 199] 308 Range 2: [1000, 1099] 309 Range 3: [500, 599] 311 The receiving routers concatenate the ranges and build the Segment 312 Routing Global Block (SRGB) as follows: 314 SRGB = [100, 199] 315 [1000, 1099] 316 [500, 599] 318 The indexes span multiple ranges: 320 index=0 means label 100 321 ... 322 index 99 means label 199 323 index 100 means label 1000 324 index 199 means label 1099 325 ... 326 index 200 means label 500 327 ... 329 The RI LSA can be advertised at any of the defined flooding scopes 330 (link, area, or autonomous system (AS)). For the purpose of SID/ 331 Label Range TLV advertisement, area scope flooding is required. 333 3.3. SR Local Block Sub-TLV 335 The SR Local Block (SRLB) Sub-TLV contains the range of labels the 336 node has reserved for local SIDs. Local SIDs are used, e.g., for 337 Adjacency-SIDs, and may also be allocated by components other than 338 the OSPF protocol. As an example, an application or a controller may 339 instruct the router to allocate a specific local SID. Therefore, in 340 order for such applications or controllers to know what local SIDs 341 are available on the router, it is required that the router 342 advertises its SRLB. The SRLB Sub-TLV is used for that purpose. 344 The SR Local Block (SRLB) Sub-TLV is a top-level TLV of the Router 345 Information Opaque LSA (defined in [RFC7770]). 347 The SR Local Block Sub-TLV MAY appear multiple times in the Router 348 Information Opaque LSA and has the following format: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Type | Length | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Range Size | Reserved | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Sub-TLVs (variable) | 358 +- -+ 359 | | 360 + + 362 where: 364 Type: TBD, suggested value 12 366 Length: Variable 368 Range Size: 3-octet SID/label range size (i.e., the number of SIDs 369 or labels in the range including the first SID/label). It MUST be 370 greater than 0. 372 Initially, the only supported Sub-TLV is the SID/Label TLV as defined 373 in Section 2.1. The SID/Label advertised in the SID/Label TLV 374 represents the first SID/Label in the advertised range. 376 The originating router MUST NOT advertise overlapping ranges. 378 Each time a SID from the SRLB is allocated, it SHOULD also be 379 reported to all components (e.g., controller or applications) in 380 order for these components to have an up-to-date view of the current 381 SRLB allocation. This is required to avoid collisions between 382 allocation instructions. 384 Within the context of OSPF, the reporting of local SIDs is done 385 through OSPF Sub-TLVs such as the Adjacency-SID (Section 7). 386 However, the reporting of allocated local SIDs may also be done 387 through other means and protocols which are outside the scope of this 388 document. 390 A router advertising the SRLB TLV may also have other label ranges, 391 outside of the SRLB, used for its local allocation purposes which are 392 NOT advertised in the SRLB. For example, it is possible that an 393 Adjacency-SID is allocated using a local label that is not part of 394 the SRLB. 396 The RI LSA can be advertised at any of the defined flooding scopes 397 (link, area, or autonomous system (AS)). For the purpose of SR Local 398 Block Sub-TLV TLV advertisement, area scope flooding is required. 400 3.4. SRMS Preference Sub-TLV 402 The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used 403 to advertise a preference associated with the node that acts as an SR 404 Mapping Server. SRMS preference is defined in 405 [I-D.ietf-spring-conflict-resolution]. 407 The SRMS Preference Sub-TLV is a top-level TLV of the Router 408 Information Opaque LSA (defined in [RFC7770]). 410 The SRMS Preference Sub-TLV MAY only be advertised once in the Router 411 Information Opaque LSA and has the following format: 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Preference | Reserved | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 where: 423 Type: TBD, suggested value 13 425 Length: 4 octets 427 Preference: 1 octet. SRMS preference value from 0 to 255. 429 When multiple SRMS Preference sub-TLVs are received from a given 430 router, the receiver SHOULD use the first occurrence of the sub-TLV 431 in the Router Information LSA. If the SRMS Preference sub-TLV 432 appears in multiple Router Information LSAs that have different 433 flooding scopes, the SRLB sub-TLV in the Router Information LSA with 434 the narrowest flooding scope SHOULD be used. If the SRMS Preference 435 sub-TLV appears in multiple Router Information LSAs that have the 436 same flooding scope, the SRMS Preference sub-TLV in the Router 437 Information LSA with the numerically smallest Instance ID SHOULD be 438 used and subsequent instances of the SRMS Preference sub-TLV SHOULD 439 be ignored. 441 The RI LSA can be advertised at any of the defined flooding scopes 442 (link, area, or autonomous system (AS)). For the purpose of the SRMS 443 Preference Sub-TLV advertisement, AS scope flooding is required. If 444 the SRMS advertisements from the SRMS server are only used inside the 445 area to which the SRMS server is attached, area scope flooding may be 446 used. 448 4. OSPF Extended Prefix Range TLV 450 In some cases it is useful to advertise attributes for a range of 451 prefixes. The Segment Routing Mapping Server, which is described in 452 [I-D.filsfils-spring-segment-routing-ldp-interop], is an example 453 where we need a single advertisement to advertise SIDs for multiple 454 prefixes from a contiguous address range. 456 The OSPF Extended Prefix Range TLV, which is a top level TLV of the 457 Extended Prefix LSA described in [RFC7684] is defined for this 458 purpose. 460 Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each 461 OSPF Extended Prefix Opaque LSA, but all prefix ranges included in a 462 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 463 scope. The OSPF Extended Prefix Range TLV has the following format: 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Type | Length | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Prefix Length | AF | Range Size | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Flags | Reserved | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Address Prefix (variable) | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Sub-TLVs (variable) | 477 +- -+ 478 | | 480 where: 482 Type: TBD, suggested value 2. 484 Length: Variable 486 Prefix length: Length of the prefix 488 AF: Address family for the prefix. Currently, the only supported 489 value is 0 for IPv4 unicast. The inclusion of address family in 490 this TLV allows for future extension. 492 Range size: Represents the number of prefixes that are covered by 493 the advertisement. The Range Size MUST NOT exceed the number of 494 prefixes that could be satisfied by the prefix length without 495 including the IPv4 multicast address range (224.0.0.0/3). 497 Flags: Single octet field. The following flags are defined: 499 0 1 2 3 4 5 6 7 500 +--+--+--+--+--+--+--+--+ 501 |IA| | | | | | | | 502 +--+--+--+--+--+--+--+--+ 504 where: 506 IA-Flag: Inter-Area flag. If set, advertisement is of inter- 507 area type. An ABR that is advertising the OSPF Extended Prefix 508 Range TLV between areas MUST set this bit. 510 This bit is used to prevent redundant flooding of Prefix Range 511 TLVs between areas as follows: 513 An ABR always prefers intra-area Prefix Range advertisements 514 over inter-area advertisements. 516 An ABR does not consider inter-area Prefix Range 517 advertisements coming from non-backbone areas. 519 An ABR only propagates an inter-area Prefix Range 520 advertisement from the backbone area to connected non- 521 backbone areas if the advertisement is considered to be the 522 best one. 524 Address Prefix: The prefix, encoded as 32-bit value, padded with 525 zero bits as necessary. The prefix represents the first prefix in 526 the prefix range. 528 5. Prefix SID Sub-TLV 530 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV 531 described in [RFC7684] and the OSPF Extended Prefix Range TLV 532 described in Section 4. It MAY appear more than once in the parent 533 TLV and has the following format: 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Type | Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Flags | Reserved | MT-ID | Algorithm | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | SID/Index/Label (variable) | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 where: 547 Type: TBD, suggested value 2. 549 Length: Variable 551 Flags: Single octet field. The following flags are defined: 553 0 1 2 3 4 5 6 7 554 +--+--+--+--+--+--+--+--+ 555 | |NP|M |E |V |L | | | 556 +--+--+--+--+--+--+--+--+ 558 where: 560 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 561 NOT pop the Prefix-SID before delivering packets to the node 562 that advertised the Prefix-SID. 564 M-Flag: Mapping Server Flag. If set, the SID was advertised by 565 a Segment Routing Mapping Server as described in 566 [I-D.filsfils-spring-segment-routing-ldp-interop]. 568 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 569 the Prefix-SID originator MUST replace the Prefix-SID with the 570 Explicit-NULL label (0 for IPv4) before forwarding the packet. 572 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 573 an absolute value. If not set, then the Prefix-SID carries an 574 index. 576 L-Flag: Local/Global Flag. If set, then the value/index 577 carried by the Prefix-SID has local significance. If not set, 578 then the value/index carried by this Sub-TLV has global 579 significance. 581 Other bits: Reserved. These MUST be zero when sent and are 582 ignored when received. 584 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 586 Algorithm: Single octet identifying the algorithm the Prefix-SID 587 is associated with as defined in Section 3.1. 589 A router receiving a Prefix-SID from a remote node and with an 590 algorithm value that such remote node has not advertised in the 591 SR-Algorithm sub-TLV (Section 3.1) MUST ignore the Prefix-SID sub- 592 TLV. 594 SID/Index/Label: According to the V and L flags, it contains 595 either: 597 A 32-bit index defining the offset in the SID/Label space 598 advertised by this router. 600 A 24-bit label where the 20 rightmost bits are used for 601 encoding the label value. 603 If multiple Prefix-SIDs are advertised for the same prefix, the 604 receiving router MUST use the first encoded SID and MAY use 605 subsequent SIDs. 607 When propagating Prefix-SIDs between areas, if multiple prefix-SIDs 608 are advertised for a prefix, an implementation SHOULD preserve the 609 original order when advertising prefix-SIDs to other areas. This 610 allows implementations that only support a single Prefix-SID to have 611 a consistent view across areas. 613 When calculating the outgoing label for the prefix, the router MUST 614 take into account the E and P flags advertised by the next-hop router 615 if that router advertised the SID for the prefix. This MUST be done 616 regardless of whether the next-hop router contributes to the best 617 path to the prefix. 619 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 620 Prefix-SIDs allocated to inter-area prefixes that are originated by 621 the ABR based on intra-area or inter-area reachability between areas, 622 unless the advertised prefix is directly attached to the ABR. 624 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 625 Prefix-SIDs allocated to redistributed prefixes, unless the 626 redistributed prefix is directly attached to the ASBR. 628 If the NP-Flag is not set, then any upstream neighbor of the Prefix- 629 SID originator MUST pop the Prefix-SID. This is equivalent to the 630 penultimate hop popping mechanism used in the MPLS dataplane. In 631 such case, MPLS EXP bits of the Prefix-SID are not preserved for the 632 final destination (the Prefix-SID being removed). If the NP-flag is 633 not set then the received E-flag is ignored. 635 If the NP-flag is set then: 637 If the E-flag is not set, then any upstream neighbor of the 638 Prefix-SID originator MUST keep the Prefix-SID on top of the 639 stack. This is useful when the originator of the Prefix-SID must 640 stitch the incoming packet into a continuing MPLS LSP to the final 641 destination. This could occur at an Area Border Router (prefix 642 propagation from one area to another) or at an AS Boundary Router 643 (prefix propagation from one domain to another). 645 If the E-flag is set, then any upstream neighbor of the Prefix-SID 646 originator MUST replace the Prefix-SID with an Explicit-NULL 647 label. This is useful, e.g., when the originator of the Prefix- 648 SID is the final destination for the related prefix and the 649 originator wishes to receive the packet with the original EXP 650 bits. 652 When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at 653 reception. 655 As the Mapping Server does not specify the originator of a prefix 656 advertisement, it is not possible to determine PHP behavior solely 657 based on the Mapping Server advertisement. However, PHP behavior 658 SHOULD be done in following cases: 660 The Prefix is intra-area type and the downstream neighbor is the 661 originator of the prefix. 663 The Prefix is inter-area type and downstream neighbor is an ABR, 664 which is advertising prefix reachability and is also generating 665 the Extended Prefix TLV with the A-flag set for this prefix as 666 described in section 2.1 of [RFC7684]. 668 The Prefix is external type and downstream neighbor is an ASBR, 669 which is advertising prefix reachability and is also generating 670 the Extended Prefix TLV with the A-flag set for this prefix as 671 described in section 2.1 of [RFC7684]. 673 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 674 the value advertised in the Prefix SID Sub-TLV is interpreted as a 675 starting SID value. 677 Example 1: If the following router addresses (loopback addresses) 678 need to be mapped into the corresponding Prefix SID indexes: 680 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 681 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 682 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 683 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 685 then the Prefix field in the Extended Prefix Range TLV would be set 686 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 687 set to 4, and the Index value in the Prefix-SID Sub-TLV would be set 688 to 1. 690 Example 2: If the following prefixes need to be mapped into the 691 corresponding Prefix-SID indexes: 693 192.0.2.0/30, Prefix-SID: Index 51 694 192.0.2.4/30, Prefix-SID: Index 52 695 192.0.2.8/30, Prefix-SID: Index 53 696 192.0.2.12/30, Prefix-SID: Index 54 697 192.0.2.16/30, Prefix-SID: Index 55 698 192.0.2.20/30, Prefix-SID: Index 56 699 192.0.2.24/30, Prefix-SID: Index 57 701 then the Prefix field in the Extended Prefix Range TLV would be set 702 to 192.0.2.0, Prefix Length would be set to 30, Range Size would be 703 7, and the Index value in the Prefix-SID Sub-TLV would be set to 51. 705 6. SID/Label Binding Sub-TLV 707 The SID/Label Binding Sub-TLV is used to advertise a SID/Label 708 mapping for a path to the prefix. 710 The SID/Label Binding Sub-TLV MAY be originated by any router in an 711 OSPF domain. The router may advertise a SID/Label binding to a FEC 712 along with at least a single 'nexthop style' anchor. The protocol 713 supports more than one 'nexthop style' anchor to be attached to a 714 SID/Label binding, which results in a simple path description 715 language. Analogous to RSVP, the terminology for this is called an 716 'Explicit Route Object' (ERO). Since ERO-style path notation allows 717 anchoring SID/label bindings to both link and node IP addresses, any 718 Label Switched Path (LSP) can be described. Additionally, SID/Label 719 Bindings from external protocols can be easily re-advertised. 721 The SID/Label Binding Sub-TLV may be used for advertising SID/Label 722 Bindings and their associated Primary and Backup paths. In a single 723 TLV, a primary ERO Path, backup ERO Path, or both can be advertised. 724 If a router wants to advertise multiple parallel paths, then it can 725 generate several TLVs for the same Prefix/FEC. Each occurrence of a 726 Binding TLV for a given FEC Prefix will add a new path. 728 The SID/Label Binding Sub-TLV is a Sub-TLV of the OSPF Extended 729 Prefix TLV described in [RFC7684] and the OSPF Extended Prefix Range 730 TLV described in Section 4. Multiple SID/Label Binding TLVs can be 731 present in their parent TLV. The SID/Label Binding Sub-TLV has 732 following format: 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Type | Length | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Flags | Reserved | MT-ID | Weight | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Sub-TLVs (variable) | 742 +- -+ 743 | | 745 where: 747 Type: TBD, suggested value 3 748 Length: Variable 750 Flags: Single octet field containing the following flags: 752 0 1 2 3 4 5 6 7 753 +-+-+-+-+-+-+-+-+ 754 |M| | 755 +-+-+-+-+-+-+-+-+ 757 where: 759 M-bit - When the bit is set, the binding represents a mirroring 760 context as defined in 761 [I-D.minto-rsvp-lsp-egress-fast-protection]. 763 Other bits: Reserved. These MUST be zero when sent and are 764 ignored when received. 766 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 768 Weight: 8 bits of weight used for load-balancing purposes. The 769 use of the weight is defined in [I-D.ietf-spring-segment-routing]. 771 The SID/Label Binding Sub-TLV supports the following Sub-TLVs: 773 SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST 774 appear in the SID/Label Binding Sub-TLV and it SHOULD only appear 775 once. If the SID/Label Sub-TLV is not included in the SID/Label 776 Binding Sub-TLV, the SID/Label Binding Sub-TLV MUST be ignored. 777 If the SID/Label Sub-TLV appears in the SID/Label Binding Sub-TLV 778 more than once, instances other than the first SHOULD be ignored 779 and the condition SHOULD be logged for possible action by the 780 network operator. 782 ERO Metric Sub-TLV as defined in Section 6.1. 784 ERO Sub-TLVs as defined in Section 6.2. 786 6.1. ERO Metric Sub-TLV 788 The ERO Metric Sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 790 The ERO Metric Sub-TLV advertises the cost of an ERO path. It is 791 used to compare the cost of a given source/destination path. ERO 792 Metric Sub-TLV is an option sub-TLV. The cost of the ERO Metric Sub- 793 TLV SHOULD be set to the cumulative IGP or TE path cost of the 794 advertised ERO. Since manipulation of the Metric field may attract 795 or repel traffic to and from the advertised segment, it MAY be 796 manually overridden. 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Type | Length | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Metric (4 octets) | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 ERO Metric Sub-TLV format 808 where: 810 Type: TBD, suggested value 8 812 Length: Always 4 814 Metric: A 4-octet metric representing the aggregate IGP or TE path 815 cost. 817 6.2. ERO Sub-TLVs 819 All ERO information represents an ordered set which describes the 820 segments of a path. The first ERO Sub-TLV describes the first 821 segment of a path. Similarly, the last ERO Sub-TLV describes the 822 segment closest to the egress point. If a router extends or stitches 823 a path, it MUST prepend the new segment's path information to the ERO 824 list. This applies equally to advertised backup EROs. 826 All ERO sub-TLVs are sub-TLVs of the SID/Label Binding TLV. 828 6.2.1. IPv4 ERO Sub-TLV 830 The IPv4 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 832 The IPv4 ERO Sub-TLV describes a path segment using IPv4 Address 833 style encoding. Its semantics have been borrowed from [RFC3209]. 835 0 1 2 3 836 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Type | Length | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Flags | Reserved | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | IPv4 Address (4 octets) | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 IPv4 ERO Sub-TLV format 847 where: 849 Type: TBD, suggested value 4 851 Length: 8 octets 853 Flags: Single octet field containing the following flags: 855 0 1 2 3 4 5 6 7 856 +-+-+-+-+-+-+-+-+ 857 |L| | 858 +-+-+-+-+-+-+-+-+ 860 where: 862 L-bit - If the L-bit is set, then the segment path is 863 designated as 'loose'. Otherwise, the segment path is 864 designated as 'strict'. The terms 'loose' and 'strict' are 865 defined for RSVP subobjects in [RFC3209]. 867 Other bits: Reserved. These MUST be zero when sent and are 868 ignored when received. 870 IPv4 Address - The address of the explicit route hop. 872 6.2.2. Unnumbered Interface ID ERO Sub-TLV 874 The Unnumbered Interface ID ERO Sub-TLV is a Sub-TLV of the SID/Label 875 Binding Sub-TLV. 877 The appearance and semantics of the 'Unnumbered Interface ID' have 878 been borrowed from [RFC3477]. 880 The Unnumbered Interface-ID ERO Sub-TLV describes a path segment that 881 includes an unnumbered interface. Unnumbered interfaces are 882 referenced using the interface index. Interface indices are assigned 883 local to the router and therefore are not unique within a domain. 884 All elements in an ERO path need to be unique within a domain and 885 hence need to be disambiguated using a domain-unique Router-ID. 887 0 1 2 3 888 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 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Type | Length | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Flags | Reserved | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Router ID | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Interface ID | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 where: 901 Unnumbered Interface ID ERO Sub-TLV format 903 Type: TBD, suggested value 5 905 Length: 12 octets 907 Flags: Single octet field containing the following flags: 909 0 1 2 3 4 5 6 7 910 +-+-+-+-+-+-+-+-+ 911 |L| | 912 +-+-+-+-+-+-+-+-+ 914 where: 916 L-bit - If the L-bit is set, then the segment path is 917 designated as 'loose'. Otherwise, the segment path is 918 designated as 'strict'. The terms 'loose' and 'strict' are 919 defined for RSVP subobjects in [RFC3209] 921 Other bits: Reserved. These MUST be zero when sent and are 922 ignored when received. 924 Router ID: Router ID of the next-hop. 926 Interface ID: The identifier assigned to the link by the router 927 specified by the Router ID. 929 6.2.3. IPv4 Backup ERO Sub-TLV 931 IPv4 Prefix Backup ERO Sub-TLV is a Sub-TLV of the SID/Label Binding 932 Sub-TLV. 934 The IPv4 Backup ERO Sub-TLV describes a path segment using IPv4 935 Address style of encoding. Its semantics have been borrowed from 936 [RFC3209]. 938 0 1 2 3 939 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 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Type | Length | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Flags | Reserved | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | IPv4 Address (4 octets) | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 IPv4 Backup ERO Sub-TLV format 950 where: 952 Type: TBD, suggested value 6 954 Length: 8 octets 956 Flags: Single octet field containing the following flags: 958 0 1 2 3 4 5 6 7 959 +-+-+-+-+-+-+-+-+ 960 |L| | 961 +-+-+-+-+-+-+-+-+ 963 where: 965 L-bit - If the L-bit is set, then the segment path is 966 designated as 'loose'. Otherwise, the segment path is 967 designated as 'strict'. The terms 'loose' and 'strict' are 968 defined for RSVP subobjects in [RFC3209] 970 Other bits: Reserved. These MUST be zero when sent and are 971 ignored when received. 973 IPv4 Address - The address of the explicit route hop. 975 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV 977 The Unnumbered Interface ID Backup ERO Sub-TLV is a Sub-TLV of the 978 SID/Label Binding Sub-TLV. 980 The appearance and semantics of the 'Unnumbered Interface ID' have 981 been borrowed from [RFC3477]. 983 The Unnumbered Interface-ID Backup ERO Sub-TLV describes a path 984 segment that includes an unnumbered interface. Unnumbered interfaces 985 are referenced using the interface index. Interface indices are 986 assigned local to the router and are therefore not unique within a 987 domain. All elements in an ERO path need to be unique within a 988 domain and hence need to be disambiguated with specification of the 989 domain-unique Router-ID. 991 0 1 2 3 992 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 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Type | Length | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Flags | Reserved | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Router ID | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Interface ID | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 Unnumbered Interface ID Backup ERO Sub-TLV format 1005 where: 1007 Type: TBD, suggested value 7 1009 Length: 12 octets 1011 Flags: Single octet field containing the following flags: 1013 0 1 2 3 4 5 6 7 1014 +-+-+-+-+-+-+-+-+ 1015 |L| | 1016 +-+-+-+-+-+-+-+-+ 1018 where: 1020 L-bit - If the L-bit is set, then the segment path is 1021 designated as 'loose'. Otherwise, the segment path is 1022 designated as 'strict'. 1024 Other bits: Reserved. These MUST be zero when sent and are 1025 ignored when received. 1027 Router ID: Router ID of the next-hop. 1029 Interface ID: The identifier assigned to the link by the router 1030 specified by the Router ID. 1032 7. Adjacency Segment Identifier (Adj-SID) 1034 An Adjacency Segment Identifier (Adj-SID) represents a router 1035 adjacency in Segment Routing. 1037 7.1. Adj-SID Sub-TLV 1039 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 1040 [RFC7684]. It MAY appear multiple times in the Extended Link TLV. 1041 Examples where more than one Adj-SID may be used per neighbor are 1042 described in section 4 of 1043 [I-D.filsfils-spring-segment-routing-use-cases]. The Adj-SID Sub-TLV 1044 has the following format: 1046 0 1 2 3 1047 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 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Type | Length | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Flags | Reserved | MT-ID | Weight | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | SID/Label/Index (variable) | 1054 +---------------------------------------------------------------+ 1056 where: 1058 Type: TBD, suggested value 2. 1060 Length: Variable. 1062 Flags: Single octet field containing the following flags: 1064 0 1 2 3 4 5 6 7 1065 +-+-+-+-+-+-+-+-+ 1066 |B|V|L|G|P| | 1067 +-+-+-+-+-+-+-+-+ 1069 where: 1071 B-Flag: Backup Flag. If set, the Adj-SID refers to an 1072 adjacency that is eligible for protection (e.g., using IPFRR or 1073 MPLS-FRR) as described in section 3.5 of 1074 [I-D.ietf-spring-segment-routing]. 1076 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 1077 an absolute value. If not set, then the Adj-SID carries an 1078 index. 1080 The L-Flag: Local/Global Flag. If set, then the value/index 1081 carried by the Adj-SID has local significance. If not set, 1082 then the value/index carried by this Sub-TLV has global 1083 significance. 1085 The G-Flag: Group Flag. When set, the G-Flag indicates that 1086 the Adj-SID refers to a group of adjacencies (and therefore MAY 1087 be assigned to other adjacencies as well). 1089 P-Flag. Persistent flag. When set, the P-Flag indicates that 1090 the Adj-SID is persistently allocated, i.e., the Adj-SID value 1091 remains consistent across router restart and/or interface flap. 1093 Other bits: Reserved. These MUST be zero when sent and are 1094 ignored when received. 1096 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1098 Weight: Weight used for load-balancing purposes. The use of the 1099 weight is defined in [I-D.ietf-spring-segment-routing]. 1101 SID/Index/Label: According to the V and L flags, it contains 1102 either: 1104 A 32-bit index defining the offset in the SID/Label space 1105 advertised by this router. 1107 A 24-bit label where the 20 rightmost bits are used for 1108 encoding the label value. 1110 An SR capable router MAY allocate an Adj-SID for each of its 1111 adjacencies and set the B-Flag when the adjacency is eligible for 1112 protection by an FRR mechanism (IP or MPLS) as described in section 1113 3.5 of [I-D.ietf-spring-segment-routing]. 1115 An SR capable router MAY allocate more than one Adj-SID to an 1116 adjacency 1117 An SR capable router MAY allocate the same Adj-SID to different 1118 adjacencies 1120 When the P-flag is not set, the Adj-SID MAY be persistent. When the 1121 P-flag is set, the Adj-SID MUST be persistent. 1123 7.2. LAN Adj-SID Sub-TLV 1125 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 1126 in [RFC7684]. It MAY appear multiple times in the Extended-Link TLV. 1127 It is used to advertise a SID/Label for an adjacency to a non-DR 1128 router on a broadcast, NBMA, or hybrid [RFC6845] network. 1130 0 1 2 3 1131 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 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Type | Length | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | Flags | Reserved | MT-ID | Weight | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | Neighbor ID | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | SID/Label/Index (variable) | 1140 +---------------------------------------------------------------+ 1142 where: 1144 Type: TBD, suggested value 3. 1146 Length: Variable. 1148 Flags: Single octet field containing the following flags: 1150 0 1 2 3 4 5 6 7 1151 +-+-+-+-+-+-+-+-+ 1152 |B|V|L|G|P| | 1153 +-+-+-+-+-+-+-+-+ 1155 where: 1157 B-Flag: Backup-flag. If set, the LAN-Adj-SID refers to an 1158 adjacency that is eligible for protection (e.g.: using IPFRR or 1159 MPLS-FRR) as described in section 3.5 of 1160 [I-D.ietf-spring-segment-routing]. 1162 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 1163 carries an absolute value. If not set, then the Prefix-SID 1164 carries an index. 1166 The L-Flag: Local/Global Flag. If set, then the value/index 1167 carried by the Prefix-SID has local significance. If not set, 1168 then the value/index carried by this Sub-TLV has global 1169 significance. 1171 The G-Flag: Group Flag. When set, the G-Flag indicates that 1172 the LAN-Adj-SID refers to a group of adjacencies (and therefore 1173 MAY be assigned to other adjacencies as well). 1175 P-Flag. Persistent flag. When set, the P-Flag indicates that 1176 the Adj-SID is persistently allocated, i.e., the Adj-SID value 1177 remains consistent across router restart and/or interface flap. 1179 Other bits: Reserved. These MUST be zero when sent and are 1180 ignored when received. 1182 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1184 Weight: Weight used for load-balancing purposes. The use of the 1185 weight is defined in [I-D.ietf-spring-segment-routing]. 1187 Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- 1188 SID is advertised. 1190 SID/Index/Label: According to the V and L flags, it contains 1191 either: 1193 A 32-bit index defining the offset in the SID/Label space 1194 advertised by this router. 1196 A 24-bit label where the 20 rightmost bits are used for 1197 encoding the label value. 1199 When the P-flag is not set, the Adj-SID MAY be persistent. When 1200 the P-flag is set, the Adj-SID MUST be persistent. 1202 8. Elements of Procedure 1204 8.1. Intra-area Segment routing in OSPFv2 1206 An OSPFv2 router that supports segment routing MAY advertise Prefix- 1207 SIDs for any prefix to which it is advertising reachability (e.g., a 1208 loopback IP address as described in Section 5). 1210 If multiple routers advertise a Prefix-SID for the same prefix, then 1211 the Prefix-SID MUST be the same. This is required in order to allow 1212 traffic load-balancing when multiple equal cost paths to the 1213 destination exist in the OSPFv2 routing domain. 1215 A Prefix-SID can also be advertised by the SR Mapping Servers (as 1216 described in [I-D.filsfils-spring-segment-routing-ldp-interop]). A 1217 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 1218 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 1219 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 1220 MUST be advertised by all of them. The flooding scope of the OSPF 1221 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 1222 could be either area scoped or AS scoped and is determined based on 1223 the configuration of the SR Mapping Server. 1225 An SR Mapping Server MUST use the OSPF Extended Prefix Range TLV when 1226 advertising SIDs for prefixes. Prefixes of different route-types can 1227 be combined in a single OSPF Extended Prefix Range TLV advertised by 1228 an SR Mapping Server. 1230 Area-scoped OSPF Extended Prefix Range TLV are propagated between 1231 areas. Similar to propagation of prefixes between areas, an ABR only 1232 propagates the OSPF Extended Prefix Range TLV that it considers to be 1233 the best from the set it received. The rules used to pick the best 1234 OSPF Extended Prefix Range TLV are described in Section 4. 1236 When propagating an OSPF Extended Prefix Range TLV between areas, 1237 ABRs MUST set the IA-Flag, that is used to prevent redundant flooding 1238 of the OSPF Extended Prefix Range TLV between areas as described in 1239 Section 4. 1241 8.2. Inter-area Segment routing in OSPFv2 1243 In order to support SR in a multi-area environment, OSPFv2 must 1244 propagate Prefix-SID information between areas. The following 1245 procedure is used to propagate Prefix SIDs between areas. 1247 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 1248 prefix to all its connected areas, it will also originate an Extended 1249 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 1250 the Extended Prefix Opaque LSA type will be set to area-scope. The 1251 route-type in the OSPF Extended Prefix TLV is set to inter-area. The 1252 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1253 value will be set as follows: 1255 The ABR will look at its best path to the prefix in the source 1256 area and find the advertising router associated with the best path 1257 to that prefix. 1259 The ABR will then determine if such router advertised a Prefix-SID 1260 for the prefix and use it when advertising the Prefix-SID to other 1261 connected areas. 1263 If no Prefix-SID was advertised for the prefix in the source area 1264 by the router that contributes to the best path to the prefix, the 1265 originating ABR will use the Prefix-SID advertised by any other 1266 router when propagating the Prefix-SID for the prefix to other 1267 areas. 1269 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 1270 route to all its connected areas, it will also originate an Extended 1271 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 1272 the Extended Prefix Opaque LSA type will be set to area-scope. The 1273 route-type in OSPF Extended Prefix TLV is set to inter-area. The 1274 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1275 will be set as follows: 1277 The ABR will look at its best path to the prefix in the backbone 1278 area and find the advertising router associated with the best path 1279 to that prefix. 1281 The ABR will then determine if such router advertised a Prefix-SID 1282 for the prefix and use it when advertising the Prefix-SID to other 1283 connected areas. 1285 If no Prefix-SID was advertised for the prefix in the backbone 1286 area by the ABR that contributes to the best path to the prefix, 1287 the originating ABR will use the Prefix-SID advertised by any 1288 other router when propagating the Prefix-SID for the prefix to 1289 other areas. 1291 8.3. Segment Routing for External Prefixes 1293 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1294 SR, generates Type-5 LSAs, it should also originate Extended Prefix 1295 Opaque LSAs, as described in [RFC7684]. The flooding scope of the 1296 Extended Prefix Opaque LSA type is set to AS-scope. The route-type 1297 in the OSPF Extended Prefix TLV is set to external. The Prefix-SID 1298 Sub-TLV is included in this LSA and the Prefix-SID value will be set 1299 to the SID that has been reserved for that prefix. 1301 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 1302 also advertise the Prefix-SID for the prefix. The NSSA ABR 1303 determines its best path to the prefix advertised in the translated 1304 Type-7 LSA and finds the advertising router associated with that 1305 path. If the advertising router has advertised a Prefix-SID for the 1306 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 1307 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 1308 router will be used. 1310 8.4. Advertisement of Adj-SID 1312 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1313 using the Adj-SID Sub-TLV as described in Section 7. 1315 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 1317 An Adj-SID MAY be advertised for any adjacency on a P2P link that is 1318 in neighbor state 2-Way or higher. If the adjacency on a P2P link 1319 transitions from the FULL state, then the Adj-SID for that adjacency 1320 MAY be removed from the area. If the adjacency transitions to a 1321 state lower then 2-Way, then the Adj-SID advertisement MUST be 1322 withdrawn from the area. 1324 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1326 Broadcast, NBMA, or hybrid [RFC6845] networks in OSPF are represented 1327 by a star topology where the Designated Router (DR) is the central 1328 point to which all other routers on the broadcast, NBMA, or hybrid 1329 network connect. As a result, routers on the broadcast, NBMA, or 1330 hybrid network advertise only their adjacency to the DR. Routers 1331 that do not act as DR do not form or advertise adjacencies with each 1332 other. They do, however, maintain 2-Way adjacency state with each 1333 other and are directly reachable. 1335 When Segment Routing is used, each router on the broadcast, NBMA, or 1336 hybrid network MAY advertise the Adj-SID for its adjacency to the DR 1337 using the Adj-SID Sub-TLV as described in Section 7.1. 1339 SR capable routers MAY also advertise a LAN-Adj-SID for other 1340 neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid 1341 network using the LAN-ADJ-SID Sub-TLV as described in Section 7.2. 1343 9. IANA Considerations 1345 This specification updates several existing OSPF registries. 1347 9.1. OSPF OSPF Router Information (RI) TLVs Registry 1349 o 8 (IANA Preallocated) - SR-Algorithm TLV 1351 o 9 (IANA Preallocated) - SID/Label Range TLV 1353 o 12 - SR Local Block Sub-TLV 1355 o 13 - SRMS Preference Sub-TLV 1357 9.2. OSPF Extended Prefix LSA TLV Registry 1359 Following values are allocated: 1361 o 2 - OSPF Extended Prefix Range TLV 1363 9.3. OSPF Extended Prefix LSA Sub-TLV Registry 1365 Following values are allocated: 1367 o 1 - SID/Label Sub-TLV 1369 o 2 - Prefix SID Sub-TLV 1371 o 3 - SID/Label Binding Sub-TLV 1373 o 4 - IPv4 ERO Sub-TLV 1375 o 5 - Unnumbered Interface ID ERO Sub-TLV 1377 o 6 - IPv4 Backup ERO Sub-TLV 1379 o 7 - Unnumbered Interface ID Backup ERO Sub-TLV 1381 o 8 - ERO Metric Sub-TLV 1383 9.4. OSPF Extended Link LSA Sub-TLV Registry 1385 Following initial values are allocated: 1387 o 1 - SID/Label Sub-TLV 1389 o 2 - Adj-SID Sub-TLV 1391 o 3 - LAN Adj-SID/Label Sub-TLV 1393 10. Implementation Status 1395 An implementation survey with seven questions related to the 1396 implementer's support of OSPFv2 Segment Routing was sent to the OSPF 1397 WG list and several known implementers. This section contains 1398 responses from three implementers who completed the survey. No 1399 external means were used to verify the accuracy of the information 1400 submitted by the respondents. The respondents are considered experts 1401 on the products they reported on. Additionally, responses were 1402 omitted from implementers who indicated that they have not 1403 implemented the function yet. 1405 Responses from Nokia (former Alcatel-Lucent): 1407 Link to a web page describing the implementation: 1408 https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/ 1409 3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Un 1410 icast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf 1412 The implementation's level of maturity: Production. 1414 Coverage: We have implemented all sections and have support for the 1415 latest draft. 1417 Licensing: Part of the software package that needs to be purchased. 1419 Implementation experience: Great spec. We also performed inter- 1420 operability testing with Cisco's OSPF Segment Routing implementation. 1422 Contact information: wim.henderickx@nokia.com 1424 Responses from Cisco Systems: 1426 Link to a web page describing the implementation: 1428 http://www.segment-routing.net/home/tutorial 1430 The implementation's level of maturity: Production. 1432 Coverage: All sections, except the section 6 (SID/Label Binding Sub- 1433 TLV) have been implemented according to the latest draft. 1435 Licensing: Part of a commercial software package. 1437 Implementation experience: Many aspects of the draft are result of 1438 the actual implementation experience, as the draft evolved from its 1439 initial version to the current one. Interoperability testing with 1440 Alcatel-Lucent was performed, which confirmed the draft's ability to 1441 serve as a reference for the implementors. 1443 Contact information: ppsenak@cisco.com 1445 Responses from Juniper: 1447 The implementation's name and/or a link to a web page describing the 1448 implementation: 1450 Feature name is OSPF SPRING 1451 The implementation's level of maturity: To be released in 16.2 1452 (second half of 2016) 1454 Coverage: All sections implemented except Sections 4, and 6. 1456 Licensing: JUNOS Licensing needed. 1458 Implementation experience: NA 1460 Contact information: shraddha@juniper.net 1462 11. Security Considerations 1464 Implementations must assure that malformed TLV and Sub-TLV 1465 permutations do not result in errors which cause hard OSPF failures. 1467 12. Contributors 1469 The following people gave a substantial contribution to the content 1470 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1471 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1472 Saku Ytti. 1474 13. Acknowledgements 1476 We would like to thank Anton Smirnov for his contribution. 1478 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1479 contribution on earlier definition of the "Binding / MPLS Label TLV". 1481 Thanks to Acee Lindem for the detail review of the draft, 1482 corrections, as well as discussion about details of the encoding. 1484 14. References 1486 14.1. Normative References 1488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1489 Requirement Levels", BCP 14, RFC 2119, 1490 DOI 10.17487/RFC2119, March 1997, 1491 . 1493 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1494 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1495 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1496 . 1498 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1499 in Resource ReSerVation Protocol - Traffic Engineering 1500 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1501 . 1503 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1504 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1505 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1506 . 1508 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 1509 and Point-to-Multipoint Interface Type", RFC 6845, 1510 DOI 10.17487/RFC6845, January 2013, 1511 . 1513 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1514 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1515 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1516 2015, . 1518 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1519 S. Shaffer, "Extensions to OSPF for Advertising Optional 1520 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1521 February 2016, . 1523 14.2. Informative References 1525 [I-D.filsfils-spring-segment-routing-ldp-interop] 1526 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1527 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1528 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1529 "Segment Routing interoperability with LDP", draft- 1530 filsfils-spring-segment-routing-ldp-interop-03 (work in 1531 progress), March 2015. 1533 [I-D.filsfils-spring-segment-routing-use-cases] 1534 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1535 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1536 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1537 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1538 spring-segment-routing-use-cases-01 (work in progress), 1539 October 2014. 1541 [I-D.ietf-spring-conflict-resolution] 1542 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 1543 "Segment Routing Conflict Resolution", draft-ietf-spring- 1544 conflict-resolution-03 (work in progress), April 2017. 1546 [I-D.ietf-spring-segment-routing] 1547 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1548 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1549 spring-segment-routing-11 (work in progress), February 1550 2017. 1552 [I-D.minto-rsvp-lsp-egress-fast-protection] 1553 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1554 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1555 protection-03 (work in progress), November 2013. 1557 Authors' Addresses 1559 Peter Psenak (editor) 1560 Cisco Systems, Inc. 1561 Apollo Business Center 1562 Mlynske nivy 43 1563 Bratislava 821 09 1564 Slovakia 1566 Email: ppsenak@cisco.com 1568 Stefano Previdi (editor) 1569 Cisco Systems, Inc. 1570 Via Del Serafico, 200 1571 Rome 00142 1572 Italy 1574 Email: sprevidi@cisco.com 1576 Clarence Filsfils 1577 Cisco Systems, Inc. 1578 Brussels 1579 Belgium 1581 Email: cfilsfil@cisco.com 1583 Hannes Gredler 1584 RtBrick Inc. 1586 Email: hannes@rtbrick.com 1587 Rob Shakir 1588 Google, Inc. 1589 1600 Amphitheatre Parkway 1590 Mountain View, CA 94043 1591 US 1593 Email: robjs@google.com 1595 Wim Henderickx 1596 Nokia 1597 Copernicuslaan 50 1598 Antwerp 2018 1599 BE 1601 Email: wim.henderickx@nokia.com 1603 Jeff Tantsura 1604 Individual 1605 US 1607 Email: jefftant.ietf@gmail.com