idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-14.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 4, 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 5, 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 4, 2017 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-14 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 5, 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 for Prefix-SIDs allocated to inter- 620 area prefixes that are originated by the ABR based on intra-area or 621 inter-area reachability between areas. When the inter-area prefix is 622 generated based on a prefix which is directly attached to the ABR, 623 the NP-Flag SHOULD NOT be set. 625 The NP-Flag (No-PHP) MUST be be set for Prefix-SIDs allocated to 626 redistributed prefixes, unless the redistributed prefix is directly 627 attached to the ASBR, in which case the NP-flag SHOULD NOT be set. 629 If the NP-Flag is not set, then any upstream neighbor of the Prefix- 630 SID originator MUST pop the Prefix-SID. This is equivalent to the 631 penultimate hop popping mechanism used in the MPLS dataplane. In 632 such case, MPLS EXP bits of the Prefix-SID are not preserved for the 633 final destination (the Prefix-SID being removed). If the NP-flag is 634 not set then the received E-flag is ignored. 636 If the NP-flag is set then: 638 If the E-flag is not set, then any upstream neighbor of the 639 Prefix-SID originator MUST keep the Prefix-SID on top of the 640 stack. This is useful when the originator of the Prefix-SID must 641 stitch the incoming packet into a continuing MPLS LSP to the final 642 destination. This could occur at an Area Border Router (prefix 643 propagation from one area to another) or at an AS Boundary Router 644 (prefix propagation from one domain to another). 646 If the E-flag is set, then any upstream neighbor of the Prefix-SID 647 originator MUST replace the Prefix-SID with an Explicit-NULL 648 label. This is useful, e.g., when the originator of the Prefix- 649 SID is the final destination for the related prefix and the 650 originator wishes to receive the packet with the original EXP 651 bits. 653 When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at 654 reception. 656 As the Mapping Server does not specify the originator of a prefix 657 advertisement, it is not possible to determine PHP behavior solely 658 based on the Mapping Server advertisement. However, PHP behavior 659 SHOULD be done in following cases: 661 The Prefix is intra-area type and the downstream neighbor is the 662 originator of the prefix. 664 The Prefix is inter-area type and downstream neighbor is an ABR, 665 which is advertising prefix reachability and is also generating 666 the Extended Prefix TLV with the A-flag set for this prefix as 667 described in section 2.1 of [RFC7684]. 669 The Prefix is external type and downstream neighbor is an ASBR, 670 which is advertising prefix reachability and is also generating 671 the Extended Prefix TLV with the A-flag set for this prefix as 672 described in section 2.1 of [RFC7684]. 674 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 675 the value advertised in the Prefix SID Sub-TLV is interpreted as a 676 starting SID value. 678 Example 1: If the following router addresses (loopback addresses) 679 need to be mapped into the corresponding Prefix SID indexes: 681 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 682 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 683 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 684 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 686 then the Prefix field in the Extended Prefix Range TLV would be set 687 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 688 set to 4, and the Index value in the Prefix-SID Sub-TLV would be set 689 to 1. 691 Example 2: If the following prefixes need to be mapped into the 692 corresponding Prefix-SID indexes: 694 192.0.2.0/30, Prefix-SID: Index 51 695 192.0.2.4/30, Prefix-SID: Index 52 696 192.0.2.8/30, Prefix-SID: Index 53 697 192.0.2.12/30, Prefix-SID: Index 54 698 192.0.2.16/30, Prefix-SID: Index 55 699 192.0.2.20/30, Prefix-SID: Index 56 700 192.0.2.24/30, Prefix-SID: Index 57 702 then the Prefix field in the Extended Prefix Range TLV would be set 703 to 192.0.2.0, Prefix Length would be set to 30, Range Size would be 704 7, and the Index value in the Prefix-SID Sub-TLV would be set to 51. 706 6. SID/Label Binding Sub-TLV 708 The SID/Label Binding Sub-TLV is used to advertise a SID/Label 709 mapping for a path to the a prefix. 711 The SID/Label Binding Sub-TLV MAY be originated by any router in an 712 OSPF domain. The router may advertise a SID/Label binding to a FEC 713 along with at least a single 'nexthop style' anchor. The protocol 714 supports more than one 'nexthop style' anchor to be attached to a 715 SID/Label binding, which results in a simple path description 716 language. Analogous to RSVP, the terminology for this is called an 717 'Explicit Route Object' (ERO). Since ERO-style path notation allows 718 anchoring SID/label bindings to both link and node IP addresses, any 719 Label Switched Path (LSP) can be described. Additionally, SID/Label 720 Bindings from external protocols can be easily re-advertised. 722 The SID/Label Binding Sub-TLV may be used for advertising SID/Label 723 Bindings and their associated Primary and Backup paths. In a single 724 TLV, a primary ERO Path, backup ERO Path, or both can be advertised. 725 If a router wants to advertise multiple parallel paths, then it can 726 generate several TLVs for the same Prefix/FEC. Each occurrence of a 727 Binding TLV for a given FEC Prefix will add a new path. 729 The SID/Label Binding Sub-TLV is a Sub-TLV of the OSPF Extended 730 Prefix TLV described in [RFC7684] and the OSPF Extended Prefix Range 731 TLV described in Section 4. Multiple SID/Label Binding TLVs can be 732 present in their parent TLV. The SID/Label Binding Sub-TLV has 733 following format: 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Type | Length | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Flags | Reserved | MT-ID | Weight | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Sub-TLVs (variable) | 743 +- -+ 744 | | 746 where: 748 Type: TBD, suggested value 3 749 Length: Variable 751 Flags: Single octet field containing the following flags: 753 0 1 2 3 4 5 6 7 754 +-+-+-+-+-+-+-+-+ 755 |M| | 756 +-+-+-+-+-+-+-+-+ 758 where: 760 M-bit - When the bit is set, the binding represents a mirroring 761 context as defined in 762 [I-D.minto-rsvp-lsp-egress-fast-protection]. 764 Other bits: Reserved. These MUST be zero when sent and are 765 ignored when received. 767 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 769 Weight: 8 bits of weight used for load-balancing purposes. The 770 use of the weight is defined in [I-D.ietf-spring-segment-routing]. 772 The SID/Label Binding Sub-TLV supports the following Sub-TLVs: 774 SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST 775 appear in the SID/Label Binding Sub-TLV and it SHOULD only appear 776 once. If the SID/Label Sub-TLV is not included in the SID/Label 777 Binding Sub-TLV, the SID/Label Binding Sub-TLV MUST be ignored. 778 If the SID/Label Sub-TLV appears in the SID/Label Binding Sub-TLV 779 more than once, instances other than the first SHOULD be ignored 780 and the condition SHOULD be logged for possible action by the 781 network operator. 783 ERO Metric Sub-TLV as defined in Section 6.1. 785 ERO Sub-TLVs as defined in Section 6.2. 787 6.1. ERO Metric Sub-TLV 789 The ERO Metric Sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 791 The ERO Metric Sub-TLV advertises the cost of an ERO path. It is 792 used to compare the cost of a given source/destination path. ERO 793 Metric Sub-TLV is an option sub-TLV. The cost of the ERO Metric Sub- 794 TLV SHOULD be set to the cumulative IGP or TE path cost of the 795 advertised ERO. Since manipulation of the Metric field may attract 796 or repel traffic to and from the advertised segment, it MAY be 797 manually overridden. 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Type | Length | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Metric (4 octets) | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 ERO Metric Sub-TLV format 809 where: 811 Type: TBD, suggested value 8 813 Length: Always 4 815 Metric: A 4-octet metric representing the aggregate IGP or TE path 816 cost. 818 6.2. ERO Sub-TLVs 820 All ERO information represents an ordered set which describes the 821 segments of a path. The first ERO Sub-TLV describes the first 822 segment of a path. Similiarly, the last ERO Sub-TLV describes the 823 segment closest to the egress point. If a router extends or stitches 824 a path, it MUST prepend the new segment's path information to the ERO 825 list. This applies equally to advertised backup EROs. 827 All ERO sub-TLVs are sub-TLVs of the SID/Label Binding TLV. 829 6.2.1. IPv4 ERO Sub-TLV 831 The IPv4 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 833 The IPv4 ERO Sub-TLV describes a path segment using IPv4 Address 834 style encoding. Its semantics have been borrowed from [RFC3209]. 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Type | Length | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Flags | Reserved | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | IPv4 Address (4 octets) | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 IPv4 ERO Sub-TLV format 848 where: 850 Type: TBD, suggested value 4 852 Length: 8 octets 854 Flags: Single octet field containing the following flags: 856 0 1 2 3 4 5 6 7 857 +-+-+-+-+-+-+-+-+ 858 |L| | 859 +-+-+-+-+-+-+-+-+ 861 where: 863 L-bit - If the L-bit is set, then the segment path is 864 designated as 'loose'. Otherwise, the segment path is 865 designated as 'strict'. The terms 'loose' and 'strict' are 866 defined for RSVP subobjects in [RFC3209]. 868 Other bits: Reserved. These MUST be zero when sent and are 869 ignored when received. 871 IPv4 Address - The address of the explicit route hop. 873 6.2.2. Unnumbered Interface ID ERO Sub-TLV 875 The Unnumbered Interface ID ERO Sub-TLV is a Sub-TLV of the SID/Label 876 Binding Sub-TLV. 878 The appearance and semantics of the 'Unnumbered Interface ID' have 879 been borrowed from [RFC3477]. 881 The Unnumbered Interface-ID ERO Sub-TLV describes a path segment that 882 includes an unnumbered interface. Unnumbered interfaces are 883 referenced using the interface index. Interface indices are assigned 884 local to the router and therefore are not unique within a domain. 885 All elements in an ERO path need to be unique within a domain and 886 hence need to be disambiguated using a domain-unique Router-ID. 888 0 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Type | Length | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Flags | Reserved | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Router ID | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Interface ID | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 where: 902 Unnumbered Interface ID ERO Sub-TLV format 904 Type: TBD, suggested value 5 906 Length: 12 octets 908 Flags: Single octet field containing the following flags: 910 0 1 2 3 4 5 6 7 911 +-+-+-+-+-+-+-+-+ 912 |L| | 913 +-+-+-+-+-+-+-+-+ 915 where: 917 L-bit - If the L-bit is set, then the segment path is 918 designated as 'loose'. Otherwise, the segment path is 919 designated as 'strict'. The terms 'loose' and 'strict' are 920 defined for RSVP subobjects in [RFC3209] 922 Other bits: Reserved. These MUST be zero when sent and are 923 ignored when received. 925 Router ID: Router ID of the next-hop. 927 Interface ID: The identifier assigned to the link by the router 928 specified by the Router ID. 930 6.2.3. IPv4 Backup ERO Sub-TLV 932 IPv4 Prefix Backup ERO Sub-TLV is a Sub-TLV of the SID/Label Binding 933 Sub-TLV. 935 The IPv4 Backup ERO Sub-TLV describes a path segment using IPv4 936 Address style of encoding. Its semantics have been borrowed from 937 [RFC3209]. 939 0 1 2 3 940 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 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Type | Length | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Flags | Reserved | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | IPv4 Address (4 octets) | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 IPv4 Backup ERO Sub-TLV format 951 where: 953 Type: TBD, suggested value 6 955 Length: 8 octets 957 Flags: Single octet field containing the following flags: 959 0 1 2 3 4 5 6 7 960 +-+-+-+-+-+-+-+-+ 961 |L| | 962 +-+-+-+-+-+-+-+-+ 964 where: 966 L-bit - If the L-bit is set, then the segment path is 967 designated as 'loose'. Otherwise, the segment path is 968 designated as 'strict'. The terms 'loose' and 'strict' are 969 defined for RSVP subobjects in [RFC3209] 971 Other bits: Reserved. These MUST be zero when sent and are 972 ignored when received. 974 IPv4 Address - The address of the explicit route hop. 976 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV 978 The Unnumbered Interface ID Backup ERO Sub-TLV is a Sub-TLV of the 979 SID/Label Binding Sub-TLV. 981 The appearance and semantics of the 'Unnumbered Interface ID' have 982 been borrowed from [RFC3477]. 984 The Unnumbered Interface-ID Backup ERO Sub-TLV describes a path 985 segment that includes an unnumbered interface. Unnumbered interfaces 986 are referenced using the interface index. Interface indices are 987 assigned local to the router and are therefore not unique within a 988 domain. All elements in an ERO path need to be unique within a 989 domain and hence need to be disambiguated with specification of the 990 domain-unique Router-ID. 992 0 1 2 3 993 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 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Type | Length | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Flags | Reserved | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Router ID | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | Interface ID | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 Unnumbered Interface ID Backup ERO Sub-TLV format 1006 where: 1008 Type: TBD, suggested value 7 1010 Length: 12 octets 1012 Flags: Single octet field containing the following flags: 1014 0 1 2 3 4 5 6 7 1015 +-+-+-+-+-+-+-+-+ 1016 |L| | 1017 +-+-+-+-+-+-+-+-+ 1019 where: 1021 L-bit - If the L-bit is set, then the segment path is 1022 designated as 'loose'. Otherwise, the segment path is 1023 designated as 'strict'. 1025 Other bits: Reserved. These MUST be zero when sent and are 1026 ignored when received. 1028 Router ID: Router ID of the next-hop. 1030 Interface ID: The identifier assigned to the link by the router 1031 specified by the Router ID. 1033 7. Adjacency Segment Identifier (Adj-SID) 1035 An Adjacency Segment Identifier (Adj-SID) represents a router 1036 adjacency in Segment Routing. 1038 7.1. Adj-SID Sub-TLV 1040 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 1041 [RFC7684]. It MAY appear multiple times in the Extended Link TLV. 1042 Examples where more than one Adj-SID may be used per neighbor are 1043 described in section 4 of 1044 [I-D.filsfils-spring-segment-routing-use-cases]. The Adj-SID Sub-TLV 1045 has the following format: 1047 0 1 2 3 1048 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 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Type | Length | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Flags | Reserved | MT-ID | Weight | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | SID/Label/Index (variable) | 1055 +---------------------------------------------------------------+ 1057 where: 1059 Type: TBD, suggested value 2. 1061 Length: Variable. 1063 Flags: Single octet field containing the following flags: 1065 0 1 2 3 4 5 6 7 1066 +-+-+-+-+-+-+-+-+ 1067 |B|V|L|G|P| | 1068 +-+-+-+-+-+-+-+-+ 1070 where: 1072 B-Flag: Backup Flag. If set, the Adj-SID refers to an 1073 adjacency that is eligible for protection (e.g., using IPFRR or 1074 MPLS-FRR) as described in section 3.5 of 1075 [I-D.ietf-spring-segment-routing]. 1077 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 1078 an absolute value. If not set, then the Adj-SID carries an 1079 index. 1081 The L-Flag: Local/Global Flag. If set, then the value/index 1082 carried by the Adj-SID has local significance. If not set, 1083 then the value/index carried by this Sub-TLV has global 1084 significance. 1086 The G-Flag: Group Flag. When set, the G-Flag indicates that 1087 the Adj-SID refers to a group of adjacencies (and therefore MAY 1088 be assigned to other adjacencies as well). 1090 P-Flag. Persistent flag. When set, the P-Flag indicates that 1091 the Adj-SID is persistently allocated, i.e., the Adj-SID value 1092 remains consistent across router restart and/or interface flap. 1094 Other bits: Reserved. These MUST be zero when sent and are 1095 ignored when received. 1097 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1099 Weight: Weight used for load-balancing purposes. The use of the 1100 weight is defined in [I-D.ietf-spring-segment-routing]. 1102 SID/Index/Label: According to the V and L flags, it contains 1103 either: 1105 A 32-bit index defining the offset in the SID/Label space 1106 advertised by this router. 1108 A 24-bit label where the 20 rightmost bits are used for 1109 encoding the label value. 1111 An SR capable router MAY allocate an Adj-SID for each of its 1112 adjacencies and set the B-Flag when the adjacency is eligible for 1113 protection by an FRR mechanism (IP or MPLS) as described in section 1114 3.5 of [I-D.ietf-spring-segment-routing]. 1116 An SR capable router MAY allocate more than one Adj-SID to an 1117 adjacency 1118 An SR capable router MAY allocate the same Adj-SID to different 1119 adjacencies 1121 When the P-flag is not set, the Adj-SID MAY be persistent. When the 1122 P-flag is set, the Adj-SID MUST be persistent. 1124 7.2. LAN Adj-SID Sub-TLV 1126 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 1127 in [RFC7684]. It MAY appear multiple times in the Extended-Link TLV. 1128 It is used to advertise a SID/Label for an adjacency to a non-DR 1129 router on a broadcast, NBMA, or hybrid [RFC6845] network. 1131 0 1 2 3 1132 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 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Type | Length | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Flags | Reserved | MT-ID | Weight | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Neighbor ID | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | SID/Label/Index (variable) | 1141 +---------------------------------------------------------------+ 1143 where: 1145 Type: TBD, suggested value 3. 1147 Length: Variable. 1149 Flags: Single octet field containing the following flags: 1151 0 1 2 3 4 5 6 7 1152 +-+-+-+-+-+-+-+-+ 1153 |B|V|L|G|P| | 1154 +-+-+-+-+-+-+-+-+ 1156 where: 1158 B-Flag: Backup-flag. If set, the LAN-Adj-SID refers to an 1159 adjacency that is eligible for protection (e.g.: using IPFRR or 1160 MPLS-FRR) as described in section 3.5 of 1161 [I-D.ietf-spring-segment-routing]. 1163 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 1164 carries an absolute value. If not set, then the Prefix-SID 1165 carries an index. 1167 The L-Flag: Local/Global Flag. If set, then the value/index 1168 carried by the Prefix-SID has local significance. If not set, 1169 then the value/index carried by this Sub-TLV has global 1170 significance. 1172 The G-Flag: Group Flag. When set, the G-Flag indicates that 1173 the LAN-Adj-SID refers to a group of adjacencies (and therefore 1174 MAY be assigned to other adjacencies as well). 1176 P-Flag. Persistent flag. When set, the P-Flag indicates that 1177 the Adj-SID is persistently allocated, i.e., the Adj-SID value 1178 remains consistent across router restart and/or interface flap. 1180 Other bits: Reserved. These MUST be zero when sent and are 1181 ignored when received. 1183 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1185 Weight: Weight used for load-balancing purposes. The use of the 1186 weight is defined in [I-D.ietf-spring-segment-routing]. 1188 Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- 1189 SID is advertised. 1191 SID/Index/Label: According to the V and L flags, it contains 1192 either: 1194 A 32-bit index defining the offset in the SID/Label space 1195 advertised by this router. 1197 A 24-bit label where the 20 rightmost bits are used for 1198 encoding the label value. 1200 When the P-flag is not set, the Adj-SID MAY be persistent. When 1201 the P-flag is set, the Adj-SID MUST be persistent. 1203 8. Elements of Procedure 1205 8.1. Intra-area Segment routing in OSPFv2 1207 An OSPFv2 router that supports segment routing MAY advertise Prefix- 1208 SIDs for any prefix to which it is advertising reachability (e.g., a 1209 loopback IP address as described in Section 5). 1211 If multiple routers advertise a Prefix-SID for the same prefix, then 1212 the Prefix-SID MUST be the same. This is required in order to allow 1213 traffic load-balancing when multiple equal cost paths to the 1214 destination exist in the OSPFv2 routing domain. 1216 A Prefix-SID can also be advertised by the SR Mapping Servers (as 1217 described in [I-D.filsfils-spring-segment-routing-ldp-interop]). A 1218 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 1219 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 1220 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 1221 MUST be advertised by all of them. The flooding scope of the OSPF 1222 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 1223 could be either area scoped or AS scoped and is determined based on 1224 the configuration of the SR Mapping Server. 1226 An SR Mapping Server MUST use the OSPF Extended Prefix Range TLV when 1227 advertising SIDs for prefixes. Prefixes of different route-types can 1228 be combined in a single OSPF Extended Prefix Range TLV advertised by 1229 an SR Mapping Server. 1231 Area-scoped OSPF Extended Prefix Range TLV are propagated between 1232 areas. Similar to propagation of prefixes between areas, an ABR only 1233 propagates the OSPF Extended Prefix Range TLV that it considers to be 1234 the best from the set it received. The rules used to pick the best 1235 OSPF Extended Prefix Range TLV are described in Section 4. 1237 When propagating an OSPF Extended Prefix Range TLV between areas, 1238 ABRs MUST set the IA-Flag, that is used to prevent redundant flooding 1239 of the OSPF Extended Prefix Range TLV between areas as described in 1240 Section 4. 1242 8.2. Inter-area Segment routing in OSPFv2 1244 In order to support SR in a multi-area environment, OSPFv2 must 1245 propagate Prefix-SID information between areas. The following 1246 procedure is used to propagate Prefix SIDs between areas. 1248 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 1249 prefix to all its connected areas, it will also originate an Extended 1250 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 1251 the Extended Prefix Opaque LSA type will be set to area-scope. The 1252 route-type in the OSPF Extended Prefix TLV is set to inter-area. The 1253 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1254 value will be set as follows: 1256 The ABR will look at its best path to the prefix in the source 1257 area and find the advertising router associated with the best path 1258 to that prefix. 1260 The ABR will then determine if such router advertised a Prefix-SID 1261 for the prefix and use it when advertising the Prefix-SID to other 1262 connected areas. 1264 If no Prefix-SID was advertised for the prefix in the source area 1265 by the router that contributes to the best path to the prefix, the 1266 originating ABR will use the Prefix-SID advertised by any other 1267 router when propagating the Prefix-SID for the prefix to other 1268 areas. 1270 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 1271 route to all its connected areas, it will also originate an Extended 1272 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 1273 the Extended Prefix Opaque LSA type will be set to area-scope. The 1274 route-type in OSPF Extended Prefix TLV is set to inter-area. The 1275 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1276 will be set as follows: 1278 The ABR will look at its best path to the prefix in the backbone 1279 area and find the advertising router associated with the best path 1280 to that prefix. 1282 The ABR will then determine if such router advertised a Prefix-SID 1283 for the prefix and use it when advertising the Prefix-SID to other 1284 connected areas. 1286 If no Prefix-SID was advertised for the prefix in the backbone 1287 area by the ABR that contributes to the best path to the prefix, 1288 the originating ABR will use the Prefix-SID advertised by any 1289 other router when propagating the Prefix-SID for the prefix to 1290 other areas. 1292 8.3. Segment Routing for External Prefixes 1294 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1295 SR, generates Type-5 LSAs, it should also originate Extended Prefix 1296 Opaque LSAs, as described in [RFC7684]. The flooding scope of the 1297 Extended Prefix Opaque LSA type is set to AS-scope. The route-type 1298 in the OSPF Extended Prefix TLV is set to external. The Prefix-SID 1299 Sub-TLV is included in this LSA and the Prefix-SID value will be set 1300 to the SID that has been reserved for that prefix. 1302 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 1303 also advertise the Prefix-SID for the prefix. The NSSA ABR 1304 determines its best path to the prefix advertised in the translated 1305 Type-7 LSA and finds the advertising router associated with that 1306 path. If the advertising router has advertised a Prefix-SID for the 1307 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 1308 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 1309 router will be used. 1311 8.4. Advertisement of Adj-SID 1313 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1314 using the Adj-SID Sub-TLV as described in Section 7. 1316 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 1318 An Adj-SID MAY be advertised for any adjacency on a P2P link that is 1319 in neighbor state 2-Way or higher. If the adjacency on a P2P link 1320 transitions from the FULL state, then the Adj-SID for that adjacency 1321 MAY be removed from the area. If the adjacency transitions to a 1322 state lower then 2-Way, then the Adj-SID advertisement MUST be 1323 withdrawn from the area. 1325 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1327 Broadcast, NBMA, or hybrid [RFC6845] networks in OSPF are represented 1328 by a star topology where the Designated Router (DR) is the central 1329 point to which all other routers on the broadcast, NBMA, or hybrid 1330 network connect. As a result, routers on the broadcast, NBMA, or 1331 hybrid network advertise only their adjacency to the DR. Routers 1332 that do not act as DR do not form or advertise adjacencies with each 1333 other. They do, however, maintain 2-Way adjacency state with each 1334 other and are directly reachable. 1336 When Segment Routing is used, each router on the broadcast, NBMSA, or 1337 hybrid network MAY advertise the Adj-SID for its adjacency to the DR 1338 using the Adj-SID Sub-TLV as described in Section 7.1. 1340 SR capable routers MAY also advertise a LAN-Adj-SID for other 1341 neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid 1342 network using the LAN-ADJ-SID Sub-TLV as described in Section 7.2. 1344 9. IANA Considerations 1346 This specification updates several existing OSPF registries. 1348 9.1. OSPF OSPF Router Information (RI) TLVs Registry 1350 o 8 (IANA Preallocated) - SR-Algorithm TLV 1352 o 9 (IANA Preallocated) - SID/Label Range TLV 1354 o 12 - SR Local Block Sub-TLV 1356 o 13 - SRMS Preference Sub-TLV 1358 9.2. OSPF Extended Prefix LSA TLV Registry 1360 Following values are allocated: 1362 o 2 - OSPF Extended Prefix Range TLV 1364 9.3. OSPF Extended Prefix LSA Sub-TLV Registry 1366 Following values are allocated: 1368 o 1 - SID/Label Sub-TLV 1370 o 2 - Prefix SID Sub-TLV 1372 o 3 - SID/Label Binding Sub-TLV 1374 o 4 - IPv4 ERO Sub-TLV 1376 o 5 - Unnumbered Interface ID ERO Sub-TLV 1378 o 6 - IPv4 Backup ERO Sub-TLV 1380 o 7 - Unnumbered Interface ID Backup ERO Sub-TLV 1382 o 8 - ERO Metric Sub-TLV 1384 9.4. OSPF Extended Link LSA Sub-TLV Registry 1386 Following initial values are allocated: 1388 o 1 - SID/Label Sub-TLV 1390 o 2 - Adj-SID Sub-TLV 1392 o 3 - LAN Adj-SID/Label Sub-TLV 1394 10. Implementation Status 1396 An implementation survey with seven questions related to the 1397 implementer's support of OSPFv2 Segment Routing was sent to the OSPF 1398 WG list and several known implementers. This section contains 1399 responses from three implementers who completed the survey. No 1400 external means were used to verify the accuracy of the information 1401 submitted by the respondents. The respondents are considered experts 1402 on the products they reported on. Additionally, responses were 1403 omitted from implementers who indicated that they have not 1404 implemented the function yet. 1406 Responses from Nokia (former Alcatel-Lucent): 1408 Link to a web page describing the implementation: 1409 https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/ 1410 3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Un 1411 icast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf 1413 The implementation's level of maturity: Production. 1415 Coverage: We have implemented all sections and have support for the 1416 latest draft. 1418 Licensing: Part of the software package that needs to be purchased. 1420 Implementation experience: Great spec. We also performed inter- 1421 operability testing with Cisco's OSPF Segment Routing implementation. 1423 Contact information: wim.henderickx@nokia.com 1425 Responses from Cisco Systems: 1427 Link to a web page describing the implementation: 1429 http://www.segment-routing.net/home/tutorial 1431 The implementation's level of maturity: Production. 1433 Coverage: All sections, except the section 6 (SID/Label Binding Sub- 1434 TLV) have been implemented according to the latest draft. 1436 Licensing: Part of a commercial software package. 1438 Implementation experience: Many aspects of the draft are result of 1439 the actual implementation experience, as the draft evolved from its 1440 initial version to the current one. Interoperability testing with 1441 Alcatel-Lucent was performed, which confirmed the draft's ability to 1442 serve as a reference for the implementors. 1444 Contact information: ppsenak@cisco.com 1446 Responses from Juniper: 1448 The implementation's name and/or a link to a web page describing the 1449 implementation: 1451 Feature name is OSPF SPRING 1452 The implementation's level of maturity: To be released in 16.2 1453 (second half of 2016) 1455 Coverage: All sections implemented except Sections 4, and 6. 1457 Licensing: JUNOS Licensing needed. 1459 Implementation experience: NA 1461 Contact information: shraddha@juniper.net 1463 11. Security Considerations 1465 Implementations must assure that malformed TLV and Sub-TLV 1466 permutations do not result in errors which cause hard OSPF failures. 1468 12. Contributors 1470 The following people gave a substantial contribution to the content 1471 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1472 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1473 Saku Ytti. 1475 13. Acknowledgements 1477 We would like to thank Anton Smirnov for his contribution. 1479 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1480 contribution on earlier definition of the "Binding / MPLS Label TLV". 1482 Thanks to Acee Lindem for the detail review of the draft, 1483 corrections, as well as discussion about details of the encoding. 1485 14. References 1487 14.1. Normative References 1489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1490 Requirement Levels", BCP 14, RFC 2119, 1491 DOI 10.17487/RFC2119, March 1997, 1492 . 1494 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1495 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1496 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1497 . 1499 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1500 in Resource ReSerVation Protocol - Traffic Engineering 1501 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1502 . 1504 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1505 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1506 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1507 . 1509 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 1510 and Point-to-Multipoint Interface Type", RFC 6845, 1511 DOI 10.17487/RFC6845, January 2013, 1512 . 1514 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1515 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1516 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1517 2015, . 1519 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1520 S. Shaffer, "Extensions to OSPF for Advertising Optional 1521 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1522 February 2016, . 1524 14.2. Informative References 1526 [I-D.filsfils-spring-segment-routing-ldp-interop] 1527 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1528 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1529 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1530 "Segment Routing interoperability with LDP", draft- 1531 filsfils-spring-segment-routing-ldp-interop-03 (work in 1532 progress), March 2015. 1534 [I-D.filsfils-spring-segment-routing-use-cases] 1535 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1536 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1537 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1538 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1539 spring-segment-routing-use-cases-01 (work in progress), 1540 October 2014. 1542 [I-D.ietf-spring-conflict-resolution] 1543 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 1544 "Segment Routing Conflict Resolution", draft-ietf-spring- 1545 conflict-resolution-03 (work in progress), April 2017. 1547 [I-D.ietf-spring-segment-routing] 1548 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1549 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1550 spring-segment-routing-11 (work in progress), February 1551 2017. 1553 [I-D.minto-rsvp-lsp-egress-fast-protection] 1554 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1555 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1556 protection-03 (work in progress), November 2013. 1558 Authors' Addresses 1560 Peter Psenak (editor) 1561 Cisco Systems, Inc. 1562 Apollo Business Center 1563 Mlynske nivy 43 1564 Bratislava 821 09 1565 Slovakia 1567 Email: ppsenak@cisco.com 1569 Stefano Previdi (editor) 1570 Cisco Systems, Inc. 1571 Via Del Serafico, 200 1572 Rome 00142 1573 Italy 1575 Email: sprevidi@cisco.com 1577 Clarence Filsfils 1578 Cisco Systems, Inc. 1579 Brussels 1580 Belgium 1582 Email: cfilsfil@cisco.com 1584 Hannes Gredler 1585 RtBrick Inc. 1587 Email: hannes@rtbrick.com 1588 Rob Shakir 1589 Google, Inc. 1590 1600 Amphitheatre Parkway 1591 Mountain View, CA 94043 1592 US 1594 Email: robjs@google.com 1596 Wim Henderickx 1597 Nokia 1598 Copernicuslaan 50 1599 Antwerp 2018 1600 BE 1602 Email: wim.henderickx@nokia.com 1604 Jeff Tantsura 1605 Individual 1606 US 1608 Email: jefftant.ietf@gmail.com