idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2017) is 2607 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 313 -- Looks like a reference, but probably isn't: '199' on line 313 -- Looks like a reference, but probably isn't: '1000' on line 314 -- Looks like a reference, but probably isn't: '1099' on line 314 -- Looks like a reference, but probably isn't: '500' on line 315 -- Looks like a reference, but probably isn't: '599' on line 315 == Unused Reference: 'RFC2328' is defined on line 1479, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 1493, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-ldp-interop-02 == Outdated reference: A later version (-05) exists of draft-ietf-spring-conflict-resolution-01 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-00 Summary: 0 errors (**), 0 flaws (~~), 8 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: September 9, 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 March 8, 2017 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-12 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 September 9, 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 . . . . . . . . . . . . . . . 20 84 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV . . . . . 21 85 7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 22 86 7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 23 87 7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 24 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. SID for External Prefixes . . . . . . . . . . . . . . . . 28 92 8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 28 93 8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 28 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 . . . . . . . . . . 29 98 9.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 29 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 This draft describes the OSPF extensions required for Segment 129 Routing. 131 Segment Routing architecture is described in 132 [I-D.ietf-spring-segment-routing]. 134 Segment Routing use cases are described in 135 [I-D.filsfils-spring-segment-routing-use-cases]. 137 2. Segment Routing Identifiers 139 Segment Routing defines various types of Segment Identifiers (SIDs): 140 Prefix-SID, Adjacency-SID, LAN Adjacency SID and Binding SID. 142 For the purpose of the advertisements of various SID values, new 143 Opaque LSAs [RFC5250] are defined in [RFC7684]. These LSAs are 144 generic containers that can be used to advertise any additional 145 attributes associated with a prefix or link. These Opaque LSAs are 146 complementary to the existing LSAs and are not aimed to replace any 147 of the existing LSAs. 149 2.1. SID/Label Sub-TLV 151 The SID/Label Sub-TLV appears in multiple TLVs or Sub-TLVs defined 152 later in this document. It is used to advertise the SID or label 153 associated with a prefix or adjacency. The SID/Label TLV has 154 following format: 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Type | Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | SID/Label (variable) | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 where: 166 Type: TBD, suggested value 1 168 Length: variable, 3 or 4 octet 170 SID/Label: If length is set to 3, then the 20 rightmost bits 171 represent a label. If length is set to 4, then the value 172 represents a 32-bit SID. 174 The receiving router MUST ignore SID/Label Sub-TLV if the length 175 is other then 3 or 4. 177 3. Segment Routing Capabilities 179 Segment Routing requires some additional router capabilities to be 180 advertised to other routers in the area. 182 These SR capabilities are advertised in the Router Information Opaque 183 LSA (defined in [RFC7770]). 185 3.1. SR-Algorithm TLV 187 The SR-Algorithm TLV is a top-level TLV of the Router Information 188 Opaque LSA (defined in [RFC7770]). 190 The SR-Algorithm Sub-TLV is optional. It MAY only be advertised once 191 in the Router Information Opaque LSA. If the SID/Label Range TLV, as 192 defined in Section 3.2, is advertised, then the SR-Algorithm TLV MUST 193 also be advertised. If the SR-Algorithm TLV is not advertised by the 194 node, such node is considered as not being segment routing capable. 196 An SR Router may use various algorithms when calculating reachability 197 to OSPF routers or prefixes in an OSPF area. Examples of these 198 algorithms are metric based Shortest Path First (SPF), various 199 flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a 200 router to advertise the algorithms currently used by the router to 201 other routers in an OSPF area. The SR-Algorithm TLV has following 202 format: 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type | Length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Algorithm 1 | Algorithm... | Algorithm n | | 210 +- -+ 211 | | 212 + + 214 where: 216 Type: TBD, suggested value 8 218 Length: variable 220 Algorithm: Single octet identifying the algorithm. The following 221 values are defined by this document: 223 0: Shortest Path First (SPF) algorithm based on link metric. 224 This is the standard shortest path algorithm as computed by the 225 OSPF protocol. Consistent with the deployed practice for link- 226 state protocols, Algorithm 0 permits any node to overwrite the 227 SPF path with a different path based on its local policy. If 228 the SR-Algorithm Sub-TLV is advertised, Algorithm 0 MUST be 229 included. 231 1: Strict Shortest Path First (SPF) algorithm based on link 232 metric. The algorithm is identical to Algorithm 0 but 233 Algorithm 1 requires that all nodes along the path will honor 234 the SPF routing decision. Local policy at the node claiming 235 support for Algorithm 1 MUST NOT alter the SPF paths computed 236 by Algorithm 1. 238 When multiple SR-Algorithm sub-TLVs are received from a given router 239 the receiver SHOULD use the first occurrence of the sub-TLV in the 240 Router Information LSA. If the SR-Algorithm sub-TLV appears in 241 multiple Router Information LSAs that have different flooding scopes, 242 the SR-Algorithm sub-TLV in the Router Information LSA with the 243 lowest flooding scope SHOULD be used. If the SR-Algorithm sub-TLV 244 appears in multiple Router Information LSAs that have the same 245 flooding scope, the SR-Algorithm sub-TLV in the Router Information 246 LSA with the numerically smallest Instance ID SHOULD be used and 247 subsequent instances of the SR-Algorithm sub-TLV SHOULD be ignored. 249 The RI LSA can be advertised at any of the defined opaque flooding 250 scopes (link, area, or Autonomous System (AS)). For the purpose of 251 SR-Algorithm TLV advertisement, area scope flooding is required. 253 3.2. SID/Label Range TLV 255 The SID/Label Range TLV is a top-level TLV of the Router Information 256 Opaque LSA (defined in [RFC7770]). 258 The SID/Label Range TLV MAY appear multiple times and has the 259 following format: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type | Length | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Range Size | Reserved | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Sub-TLVs (variable) | 269 +- -+ 270 | | 271 + + 273 where: 275 Type: TBD, suggested value 9 277 Length: variable 279 Range Size: 3 octets of the SID/label range 281 Initially, the only supported Sub-TLV is the SID/Label TLV as defined 282 in Section 2.1. The SID/Label advertised in the SID/Label TLV 283 represents the first SID/Label in the advertised range. 285 Multiple occurrences of the SID/Label Range TLV MAY be advertised, in 286 order to advertise multiple ranges. In such case: 288 o The originating router MUST encode each range into a different 289 SID/Label Range TLV. 291 o The originating router decides the order in which the set of SID/ 292 Label Range TLVs are advertised inside the Router Information 293 Opaque LSA. The originating router MUST ensure the order is the 294 same after a graceful restart (using checkpointing, non-volatile 295 storage or any other mechanism) in order to assure the SID/label 296 range and SID index correspondence is preserved across graceful 297 restarts. 299 o The receiving router must adhere to the order in which the ranges 300 are advertised when calculating a SID/label from a SID index. 302 The following example illustrates the advertisement of multiple 303 ranges: 305 The originating router advertises following ranges: 306 Range 1: [100, 199] 307 Range 2: [1000, 1099] 308 Range 3: [500, 599] 310 The receiving routers concatenate the ranges and build the Segment 311 Routing Global Block (SRGB) as follows: 313 SRGB = [100, 199] 314 [1000, 1099] 315 [500, 599] 317 The indexes span multiple ranges: 319 index=0 means label 100 320 ... 321 index 99 means label 199 322 index 100 means label 1000 323 index 199 means label 1099 324 ... 325 index 200 means label 500 326 ... 328 The RI LSA can be advertised at any of the defined flooding scopes 329 (link, area, or autonomous system (AS)). For the purpose of SID/ 330 Label Range TLV advertisement, area scope flooding is required. 332 3.3. SR Local Block Sub-TLV 334 The SR Local Block (SRLB) Sub-TLV contains the range of labels the 335 node has reserved for local SIDs. Local SIDs are used, e.g., for 336 Adjacency-SIDs, and may also be allocated by other components than 337 OSPF protocol. As an example, an application or a controller may 338 instruct the router to allocate a specific local SID. Therefore, in 339 order for such applications or controllers to know what are the local 340 SIDs available in the router, it is required that the router 341 advertises its SRLB. The SRLB Sub-TLV is used for that purpose. 343 The SR Local Block (SRLB) Sub-TLV is a top-level TLV of the Router 344 Information Opaque LSA (defined in [RFC7770]). 346 The SR Local Block Sub-TLV MAY appear multiple times in the Router 347 Information Opaque LSA and has the following format: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Type | Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Range Size | Reserved | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Sub-TLVs (variable) | 357 +- -+ 358 | | 359 + + 361 where: 363 Type: TBD, suggested value 12 365 Length: variable 367 Range Size: 3 octets of the SID/label range. MUST be higher then 368 0. 370 Initially, the only supported Sub-TLV is the SID/Label TLV as defined 371 in Section 2.1. The SID/Label advertised in the SID/Label TLV 372 represents the first SID/Label in the advertised range. 374 The originating router MUST NOT advertise overlapping ranges. 376 Each time a SID from the SRLB is allocated, it SHOULD also be 377 reported to all components (e.g.: controller or applications) in 378 order for these components to have an up-to-date view of the current 379 SRLB allocation. This is required to avoid collision between 380 allocation instructions. 382 Within the context of OSPF, the reporting of local SIDs is done 383 through OSPF Sub-TLVs such as the Adjacency-SID (Section 7). 384 However, the reporting of allocated local SIDs may also be done 385 through other means and protocols which mechanisms are outside the 386 scope of this document. 388 A router advertising the SRLB TLV may also have other label ranges, 389 outside of the SRLB, used for its local allocation purposes which are 390 NOT advertised in the SRLB. For example, it is possible that an 391 Adjacency-SID is allocated using a local label that is not part of 392 the SRLB. 394 The RI LSA can be advertised at any of the defined flooding scopes 395 (link, area, or autonomous system (AS)). For the purpose of SR Local 396 Block Sub-TLV TLV advertisement, area scope flooding is required. 398 3.4. SRMS Preference Sub-TLV 400 The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used 401 to advertise a preference associated with the node that acts as a SR 402 Mapping Server. SRMS preference is defined in 403 [I-D.ietf-spring-conflict-resolution]. 405 The SRMS Preference Sub-TLV is a top-level TLV of the Router 406 Information Opaque LSA (defined in [RFC7770]). 408 The SRMS Preference Sub-TLV MAY only be advertised once in the Router 409 Information Opaque LSA and has the following format: 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Type | Length | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Preference | Reserved | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 where: 421 Type: TBD, suggested value 13 423 Length: 4 octets 425 Preference: 1 octet. SRMS preference value from 0 to 255. 427 When multiple SRMS Preference sub-TLVs are received from a given 428 router the receiver SHOULD use the first occurrence of the sub-TLV in 429 the Router Information LSA. If the SRMS Preference sub-TLV appears 430 in multiple Router Information LSAs that have different flooding 431 scopes, the SRLB sub-TLV in the Router Information LSA with the 432 lowest flooding scope SHOULD be used. If the SRMS Preference sub-TLV 433 appears in multiple Router Information LSAs that have the same 434 flooding scope, the SRMS Preference sub-TLV in the Router Information 435 LSA with the numerically smallest Instance ID SHOULD be used and 436 subsequent instances of the SRMS Preference sub-TLV SHOULD be 437 ignored. 439 The RI LSA can be advertised at any of the defined flooding scopes 440 (link, area, or autonomous system (AS)). For the purpose of the SRMS 441 Preference Sub-TLV advertisement, AS scope flooding is required. If 442 the SRMS advertisements from the SRMS server are only used inside the 443 area to which the SRMS server is attached, area scope flooding may be 444 used. 446 4. OSPF Extended Prefix Range TLV 448 In some cases it is useful to advertise attributes for a range of 449 prefixes. The Segment Routing Mapping Server, which is described in 450 [I-D.filsfils-spring-segment-routing-ldp-interop], is an example 451 where we need a single advertisement to advertise SIDs for multiple 452 prefixes from a contiguous address range. 454 The OSPF Extended Prefix Range TLV, which is a new top level TLV of 455 the Extended Prefix LSA described in [RFC7684] is defined for this 456 purpose. 458 Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each 459 OSPF Extended Prefix Opaque LSA, but all prefix ranges included in a 460 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 461 scope. The OSPF Extended Prefix Range TLV has the following format: 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Type | Length | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Prefix Length | AF | Range Size | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Flags | Reserved | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Address Prefix (variable) | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Sub-TLVs (variable) | 475 +- -+ 476 | | 478 where: 480 Type: TBD, suggested value 2. 482 Length: Variable 484 Prefix length: Length of the prefix 486 AF: 0 - IPv4 unicast 488 Range size: Represents the number of prefixes that are covered by 489 the advertisement. The Range Size MUST NOT exceed the number of 490 prefixes that could be satisfied by the prefix length without 491 including the IPv4 multicast address range (224.0.0.0/3). 493 Flags: Single octet field. The following flags are defined: 495 0 1 2 3 4 5 6 7 496 +--+--+--+--+--+--+--+--+ 497 |IA| | | | | | | | 498 +--+--+--+--+--+--+--+--+ 500 where: 502 IA-Flag: Inter-Area flag. If set, advertisement is of inter- 503 area type. The ABR that is advertising the OSPF Extended 504 Prefix Range TLV between areas MUST set this bit. 506 This bit is used to prevent redundant flooding of Prefix Range 507 TLVs between areas as follows: 509 An ABR always prefers intra-area Prefix Range advertisements 510 over inter-area advertisements. 512 An ABR does not consider inter-area Prefix Range 513 advertisements coming from non-backbone areas. 515 An ABR only propagates an inter-area Prefix Range 516 advertisement from the backbone area to connected non- 517 backbone areas if the advertisement is considered to be the 518 best one. 520 Address Prefix: The prefix, encoded as an even multiple of 32-bit 521 words, padded with zero bits as necessary. This encoding consumes 522 ((PrefixLength + 31) / 32) 32-bit words. The Address Prefix 523 represents the first prefix in the prefix range. 525 5. Prefix SID Sub-TLV 527 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV 528 described in [RFC7684] and the OSPF Extended Prefix Range TLV 529 described in Section 4. It MAY appear more than once in the parent 530 TLV and has the following format: 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Type | Length | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Flags | Reserved | MT-ID | Algorithm | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | SID/Index/Label (variable) | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 where: 544 Type: TBD, suggested value 2. 546 Length: Variable 548 Flags: Single octet field. The following flags are defined: 550 0 1 2 3 4 5 6 7 551 +--+--+--+--+--+--+--+--+ 552 | |NP|M |E |V |L | | | 553 +--+--+--+--+--+--+--+--+ 555 where: 557 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 558 NOT pop the Prefix-SID before delivering packets to the node 559 that advertised the Prefix-SID. 561 M-Flag: Mapping Server Flag. If set, the SID was advertised by 562 a Segment Routing Mapping Server as described in 563 [I-D.filsfils-spring-segment-routing-ldp-interop]. 565 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 566 the Prefix-SID originator MUST replace the Prefix-SID with the 567 Explicit-NULL label (0 for IPv4) before forwarding the packet. 569 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 570 an absolute value. If not set, then the Prefix-SID carries an 571 index. 573 L-Flag: Local/Global Flag. If set, then the value/index 574 carried by the Prefix-SID has local significance. If not set, 575 then the value/index carried by this Sub-TLV has global 576 significance. 578 Other bits: Reserved. These MUST be zero when sent and are 579 ignored when received. 581 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 583 Algorithm: Single octet identifying the algorithm the Prefix-SID 584 is associated with as defined in Section 3.1. 586 A router receiving a Prefix-SID from a remote node and with an 587 algorithm value that such remote node has not advertised in the 588 SR-Algorithm sub-TLV (Section 3.1) MUST ignore the Prefix-SID sub- 589 TLV. 591 SID/Index/Label: According to the V and L flags, it contains 592 either: 594 A 32-bit index defining the offset in the SID/Label space 595 advertised by this router. 597 A 24-bit label where the 20 rightmost bits are used for 598 encoding the label value. 600 If multiple Prefix-SIDs are advertised for the same prefix, the 601 receiving router MUST use the first encoded SID and MAY use the 602 subsequent SIDs. 604 When propagating Prefix-SIDs between areas, if multiple prefix-SIDs 605 are advertised for a prefix, an implementation SHOULD preserve the 606 original order when advertising prefix-SIDs to other areas. This 607 allows implementations that only support a single Prefix-SID to have 608 a consistent view across areas. 610 When calculating the outgoing label for the prefix, the router MUST 611 take into account the E and P flags advertised by the next-hop router 612 if that router advertised the SID for the prefix. This MUST be done 613 regardless of whether the next-hop router contributes to the best 614 path to the prefix. 616 The NP-Flag (No-PHP) MUST be set for Prefix-SIDs allocated to inter- 617 area prefixes that are originated by the ABR based on intra-area or 618 inter-area reachability between areas. When the inter-area prefix is 619 generated based on a prefix which is directly attached to the ABR, 620 the NP-Flag SHOULD NOT be set. 622 The NP-Flag (No-PHP) MUST be be set for the Prefix-SIDs allocated to 623 redistributed prefixes, unless the redistributed prefix is directly 624 attached to the ASBR, in which case the NP-flag SHOULD NOT be set. 626 If the NP-Flag is not set, then any upstream neighbor of the Prefix- 627 SID originator MUST pop the Prefix-SID. This is equivalent to the 628 penultimate hop popping mechanism used in the MPLS dataplane. In 629 such case, MPLS EXP bits of the Prefix-SID are not preserved for the 630 final destination (the Prefix-SID being removed). If the NP-flag is 631 not set then the received E-flag is ignored. 633 If the NP-flag is set then: 635 If the E-flag is not set, then any upstream neighbor of the 636 Prefix-SID originator MUST keep the Prefix-SID on top of the 637 stack. This is useful when the originator of the Prefix-SID must 638 stitch the incoming packet into a continuing MPLS LSP to the final 639 destination. This could occur at an Area Border Router (prefix 640 propagation from one area to another) or at an AS Boundary Router 641 (prefix propagation from one domain to another). 643 If the E-flag is set, then any upstream neighbor of the Prefix-SID 644 originator MUST replace the Prefix-SID with an Explicit-NULL 645 label. This is useful, e.g., when the originator of the Prefix- 646 SID is the final destination for the related prefix and the 647 originator wishes to receive the packet with the original EXP 648 bits. 650 When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at 651 reception. 653 As the Mapping Server does not specify the originator of a prefix 654 advertisement, it is not possible to determine PHP behavior solely 655 based on the Mapping Server advertisement. However, PHP behavior may 656 safely be done in following cases: 658 The Prefix is intra-area type and the downstream neighbor is the 659 originator of the prefix. 661 The Prefix is inter-area type and downstream neighbor is an ABR, 662 which is advertising the prefix reachability and is also 663 generating the Extended Prefix TLV with the A-flag set for this 664 prefix as described in section 2.1 of [RFC7684]. 666 The Prefix is external type and downstream neighbor is an ASBR, 667 which is advertising the prefix reachability and is also 668 generating the Extended Prefix TLV with the A-flag set for this 669 prefix as described in section 2.1 of [RFC7684]. 671 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 672 the value advertised in Prefix SID Sub-TLV is interpreted as a 673 starting SID value. 675 Example 1: If the following router addresses (loopback addresses) 676 need to be mapped into the corresponding Prefix SID indexes: 678 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 679 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 680 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 681 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 683 then the Prefix field in the Extended Prefix Range TLV would be set 684 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 685 set to 4, and the Index value in the Prefix-SID Sub-TLV would be set 686 to 1. 688 Example 2: If the following prefixes need to be mapped into the 689 corresponding Prefix-SID indexes: 691 10.1.1/24, Prefix-SID: Index 51 692 10.1.2/24, Prefix-SID: Index 52 693 10.1.3/24, Prefix-SID: Index 53 694 10.1.4/24, Prefix-SID: Index 54 695 10.1.5/24, Prefix-SID: Index 55 696 10.1.6/24, Prefix-SID: Index 56 697 10.1.7/24, Prefix-SID: Index 57 699 then the Prefix field in the Extended Prefix Range TLV would be set 700 to 10.1.1.0, Prefix Length would be set to 24, Range Size would be 7, 701 and the Index value in the Prefix-SID Sub-TLV would be set to 51. 703 6. SID/Label Binding Sub-TLV 705 The SID/Label Binding Sub-TLV is used to advertise a SID/Label 706 mapping for a path to the prefix. 708 The SID/Label Binding Sub-TLV MAY be originated by any router in an 709 OSPF domain. The router may advertise a SID/Label binding to a FEC 710 along with at least a single 'nexthop style' anchor. The protocol 711 supports more than one 'nexthop style' anchor to be attached to a 712 SID/Label binding, which results in a simple path description 713 language. In analogy to RSVP, the terminology for this is called an 714 'Explicit Route Object' (ERO). Since ERO style path notation allows 715 anchoring SID/label bindings to both link and node IP addresses, any 716 Label Switched Path (LSP) can be described. Additionally, SID/Label 717 Bindings from external protocols can be easily re-advertised. 719 The SID/Label Binding Sub-TLV may be used for advertising SID/Label 720 Bindings and their associated Primary and Backup paths. In a single 721 TLV, a primary ERO Path, backup ERO Path, or both can be advertised. 722 If a router wants to advertise multiple parallel paths, then it can 723 generate several TLVs for the same Prefix/FEC. Each occurrence of a 724 Binding TLV for a given FEC Prefix will add a new path. 726 The SID/Label Binding Sub-TLV is a Sub-TLV of the OSPF Extended 727 Prefix TLV described in [RFC7684] and the OSPF Extended Prefix Range 728 TLV described in Section 4. Multiple SID/Label Binding TLVs can be 729 present in their parent TLV. The SID/Label Binding Sub-TLV has 730 following format: 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Type | Length | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Flags | Reserved | MT-ID | Weight | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Sub-TLVs (variable) | 740 +- -+ 741 | | 743 where: 745 Type: TBD, suggested value 3 746 Length: Variable 748 Flags: Single octet field containing the following flags: 750 0 1 2 3 4 5 6 7 751 +-+-+-+-+-+-+-+-+ 752 |M| | 753 +-+-+-+-+-+-+-+-+ 755 where: 757 M-bit - When the bit is set, the binding represents a mirroring 758 context as defined in 759 [I-D.minto-rsvp-lsp-egress-fast-protection]. 761 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 763 Weight: Weight used for load-balancing purposes. The use of the 764 weight is defined in [I-D.ietf-spring-segment-routing]. 766 The SID/Label Binding Sub-TLV supports the following Sub-TLVs: 768 SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST 769 appear in the SID/Label Binding Sub-TLV and it SHOULD only appear 770 once. If the SID/Label Sub-TLV is not included in the SID/Label 771 Binding Sub-TLV, the SID/Label Binding Sub-TLV MUST be ignored. 772 If the SID/Label Sub-TLV appears in the SID/Label Binding Sub-TLV 773 more than once, instances other than the first will be ignored and 774 the condition SHOULD be logged for possible action by the network 775 operator. 777 ERO Metric Sub-TLV as defined in Section 6.1. 779 ERO Sub-TLVs as defined in Section 6.2. 781 6.1. ERO Metric Sub-TLV 783 The ERO Metric Sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 785 The ERO Metric Sub-TLV advertises the cost of an ERO path. It is 786 used to compare the cost of a given source/destination path. A 787 router SHOULD advertise the ERO Metric Sub-TLV in an advertised ERO 788 TLV. The cost of the ERO Metric Sub-TLV SHOULD be set to the 789 cumulative IGP or TE path cost of the advertised ERO. Since 790 manipulation of the Metric field may attract or repel traffic to and 791 from the advertised segment, it MAY be manually overridden. 793 0 1 2 3 794 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 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Type | Length | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Metric (4 octets) | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 ERO Metric Sub-TLV format 803 where: 805 Type: TBD, suggested value 8 807 Length: Always 4 809 Metric: A 4-octet metric representing the aggregate IGP or TE path 810 cost. 812 6.2. ERO Sub-TLVs 814 All ERO information represents an ordered set which describes the 815 segments of a path. The first ERO Sub-TLV describes the first 816 segment of a path. Similiarly, the last ERO Sub-TLV describes the 817 segment closest to the egress point. If a router extends or stitches 818 a path, it MUST prepend the new segment's path information to the ERO 819 list. This applies equally to advertised backup EROs. 821 All ERO Sub-TLVs must immediately follow the SID/Label Sub-TLV. 823 All Backup ERO Sub-TLVs must immediately follow the last ERO Sub-TLV. 825 6.2.1. IPv4 ERO Sub-TLV 827 The IPv4 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 829 The IPv4 ERO Sub-TLV describes a path segment using IPv4 Address 830 style encoding. Its semantics have been borrowed from [RFC3209]. 832 0 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Type | Length | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Flags | Reserved | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | IPv4 Address (4 octets) | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 IPv4 ERO Sub-TLV format 844 where: 846 Type: TBD, suggested value 4 848 Length: 8 octets 850 Flags: Single octet field containing the following flags: 852 0 1 2 3 4 5 6 7 853 +-+-+-+-+-+-+-+-+ 854 |L| | 855 +-+-+-+-+-+-+-+-+ 857 where: 859 L-bit - If the L-bit is set, then the segment path is 860 designated as 'loose'. Otherwise, the segment path is 861 designated as 'strict'. The terms 'loose' and 'strict' are 862 defined for RSVP subobjects in [RFC3209]. 864 IPv4 Address - The address of the explicit route hop. 866 6.2.2. Unnumbered Interface ID ERO Sub-TLV 868 The Unnumbered Interface ID ERO Sub-TLV is a Sub-TLV of the SID/Label 869 Binding Sub-TLV. 871 The appearance and semantics of the 'Unnumbered Interface ID' have 872 been borrowed from [RFC3477]. 874 The Unnumbered Interface-ID ERO Sub-TLV describes a path segment that 875 includes an unnumbered interface. Unnumbered interfaces are 876 referenced using the interface index. Interface indices are assigned 877 local to the router and therefore are not unique within a domain. 878 All elements in an ERO path need to be unique within a domain and 879 hence need to be disambiguated using a domain unique Router-ID. 881 0 1 2 3 882 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 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Type | Length | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Flags | Reserved | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Router ID | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Interface ID | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 where: 895 Unnumbered Interface ID ERO Sub-TLV format 897 Type: TBD, suggested value 5 899 Length: 12 octets 901 Flags: Single octet field containing the following flags: 903 0 1 2 3 4 5 6 7 904 +-+-+-+-+-+-+-+-+ 905 |L| | 906 +-+-+-+-+-+-+-+-+ 908 where: 910 L-bit - If the L-bit is set, then the segment path is 911 designated as 'loose'. Otherwise, the segment path is 912 designated as 'strict'. The terms 'loose' and 'strict' are 913 defined for RSVP subobjects in [RFC3209] 915 Router-ID: Router-ID of the next-hop. 917 Interface ID: The identifier assigned to the link by the router 918 specified by the Router-ID. 920 6.2.3. IPv4 Backup ERO Sub-TLV 922 IPv4 Prefix Backup ERO Sub-TLV is a Sub-TLV of the SID/Label Binding 923 Sub-TLV. 925 The IPv4 Backup ERO Sub-TLV describes a path segment using IPv4 926 Address style of encoding. Its semantics have been borrowed from 927 [RFC3209]. 929 0 1 2 3 930 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 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Type | Length | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Flags | Reserved | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | IPv4 Address (4 octets) | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 IPv4 Backup ERO Sub-TLV format 941 where: 943 Type: TBD, suggested value 6 945 Length: 8 octets 947 Flags: Single octet field containing the following flags: 949 0 1 2 3 4 5 6 7 950 +-+-+-+-+-+-+-+-+ 951 |L| | 952 +-+-+-+-+-+-+-+-+ 954 where: 956 L-bit - If the L-bit is set, then the segment path is 957 designated as 'loose'. Otherwise, the segment path is 958 designated as 'strict'. The terms 'loose' and 'strict' are 959 defined for RSVP subobjects in [RFC3209] 961 IPv4 Address - The address of the explicit route hop. 963 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV 965 The Unnumbered Interface ID Backup ERO Sub-TLV is a Sub-TLV of the 966 SID/Label Binding Sub-TLV. 968 The appearance and semantics of the 'Unnumbered Interface ID' have 969 been borrowed from [RFC3477]. 971 The Unnumbered Interface-ID Backup ERO Sub-TLV describes a path 972 segment that includes an unnumbered interface. Unnumbered interfaces 973 are referenced using the interface index. Interface indices are 974 assigned local to the router and are therefore not unique within a 975 domain. All elements in an ERO path need to be unique within a 976 domain and hence need to be disambiguated with specification of the 977 domain unique Router-ID. 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Type | Length | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Flags | Reserved | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Router ID | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Interface ID | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 Unnumbered Interface ID Backup ERO Sub-TLV format 993 where: 995 Type: TBD, suggested value 7 997 Length: 12 octets 999 Flags: Single octet field containing the following flags: 1001 0 1 2 3 4 5 6 7 1002 +-+-+-+-+-+-+-+-+ 1003 |L| | 1004 +-+-+-+-+-+-+-+-+ 1006 where: 1008 L-bit - If the L-bit is set, then the segment path is 1009 designated as 'loose'. Otherwise, the segment path is 1010 designated as 'strict'. 1012 Router-ID: Router-ID of the next-hop. 1014 Interface ID: The identifier assigned to the link by the router 1015 specified by the Router-ID. 1017 7. Adjacency Segment Identifier (Adj-SID) 1019 An Adjacency Segment Identifier (Adj-SID) represents a router 1020 adjacency in Segment Routing. 1022 7.1. Adj-SID Sub-TLV 1024 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 1025 [RFC7684]. It MAY appear multiple times in the Extended Link TLV. 1026 Examples where more than one Adj-SID may be used per neighbor are 1027 described in section 4 of 1028 [I-D.filsfils-spring-segment-routing-use-cases]. The Adj-SID Sub-TLV 1029 has the following format: 1031 0 1 2 3 1032 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Type | Length | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Flags | Reserved | MT-ID | Weight | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | SID/Label/Index (variable) | 1039 +---------------------------------------------------------------+ 1041 where: 1043 Type: TBD, suggested value 2. 1045 Length: Variable. 1047 Flags: Single octet field containing the following flags: 1049 0 1 2 3 4 5 6 7 1050 +-+-+-+-+-+-+-+-+ 1051 |B|V|L|G|P| | 1052 +-+-+-+-+-+-+-+-+ 1054 where: 1056 B-Flag: Backup Flag. If set, the Adj-SID refers to an 1057 adjacency that is eligible for protection (e.g.: using IPFRR or 1058 MPLS-FRR) as described in section 3.5 of 1059 [I-D.ietf-spring-segment-routing]. 1061 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 1062 an absolute value. If not set, then the Adj-SID carries an 1063 index. 1065 The L-Flag: Local/Global Flag. If set, then the value/index 1066 carried by the Adj-SID has local significance. If not set, 1067 then the value/index carried by this Sub-TLV has global 1068 significance. 1070 The G-Flag: Group Flag. When set, the G-Flag indicates that 1071 the Adj-SID refers to a group of adjacencies (and therefore MAY 1072 be assigned to other adjacencies as well). 1074 P-Flag. Persistent flag. When set, the P-Flag indicates that 1075 the Adj-SID is persistently allocated, i.e., the Adj-SID value 1076 remains consistent across router restart and/or interface flap. 1078 Other bits: Reserved. These MUST be zero when sent and are 1079 ignored when received. 1081 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1083 Weight: Weight used for load-balancing purposes. The use of the 1084 weight is defined in [I-D.ietf-spring-segment-routing]. 1086 SID/Index/Label: According to the V and L flags, it contains 1087 either: 1089 A 32-bit index defining the offset in the SID/Label space 1090 advertised by this router. 1092 A 24-bit label where the 20 rightmost bits are used for 1093 encoding the label value. 1095 An SR capable router MAY allocate an Adj-SID for each of its 1096 adjacencies and set the B-Flag when the adjacency is eligible for 1097 protection by an FRR mechanism (IP or MPLS) as described in section 1098 3.5 of [I-D.ietf-spring-segment-routing]. 1100 An SR capable router MAY allocate more than one Adj-SID to an 1101 adjacency 1103 An SR capable router MAY allocate the same Adj-SID to different 1104 adjacencies 1106 When the P-flag is not set, the Adj-SID MAY be persistent. When the 1107 P-flag is set, the Adj-SID MUST be persistent. 1109 7.2. LAN Adj-SID Sub-TLV 1111 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 1112 in [RFC7684]. It MAY appear multiple times in the Extended-Link TLV. 1113 It is used to advertise a SID/Label for an adjacency to a non-DR 1114 router on a broadcast, NBMA, or hybrid [RFC6845] network. 1116 0 1 2 3 1117 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 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Type | Length | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Flags | Reserved | MT-ID | Weight | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Neighbor ID | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | SID/Label/Index (variable) | 1126 +---------------------------------------------------------------+ 1128 where: 1130 Type: TBD, suggested value 3. 1132 Length: Variable. 1134 Flags: Single octet field containing the following flags: 1136 0 1 2 3 4 5 6 7 1137 +-+-+-+-+-+-+-+-+ 1138 |B|V|L|G|P| | 1139 +-+-+-+-+-+-+-+-+ 1141 where: 1143 B-Flag: Backup-flag. If set, the LAN-Adj-SID refers to an 1144 adjacency that is eligible for protection (e.g.: using IPFRR or 1145 MPLS-FRR) as described in section 3.5 of 1146 [I-D.ietf-spring-segment-routing]. 1148 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 1149 carries an absolute value. If not set, then the Prefix-SID 1150 carries an index. 1152 The L-Flag: Local/Global Flag. If set, then the value/index 1153 carried by the Prefix-SID has local significance. If not set, 1154 then the value/index carried by this Sub-TLV has global 1155 significance. 1157 The G-Flag: Group Flag. When set, the G-Flag indicates that 1158 the LAN-Adj-SID refers to a group of adjacencies (and therefore 1159 MAY be assigned to other adjacencies as well). 1161 P-Flag. Persistent flag. When set, the P-Flag indicates that 1162 the Adj-SID is persistently allocated, i.e., the Adj-SID value 1163 remains consistent across router restart and/or interface flap. 1165 Other bits: Reserved. These MUST be zero when sent and are 1166 ignored when received. 1168 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1170 Weight: Weight used for load-balancing purposes. The use of the 1171 weight is defined in [I-D.ietf-spring-segment-routing]. 1173 Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- 1174 SID is advertised. 1176 SID/Index/Label: According to the V and L flags, it contains 1177 either: 1179 A 32-bit index defining the offset in the SID/Label space 1180 advertised by this router. 1182 A 24-bit label where the 20 rightmost bits are used for 1183 encoding the label value. 1185 When the P-flag is not set, the Adj-SID MAY be persistent. When 1186 the P-flag is set, the Adj-SID MUST be persistent. 1188 8. Elements of Procedure 1190 8.1. Intra-area Segment routing in OSPFv2 1192 An OSPFv2 router that supports segment routing MAY advertise Prefix- 1193 SIDs for any prefix to which it is advertising reachability (e.g., a 1194 loopback IP address as described in Section 5). 1196 If multiple routers advertise a Prefix-SID for the same prefix, then 1197 the Prefix-SID MUST be the same. This is required in order to allow 1198 traffic load-balancing when multiple equal cost paths to the 1199 destination exist in the OSPFv2 routing domain. 1201 Prefix-SID can also be advertised by the SR Mapping Servers (as 1202 described in [I-D.filsfils-spring-segment-routing-ldp-interop]). The 1203 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 1204 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 1205 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 1206 MUST be advertised by all of them. The flooding scope of the OSPF 1207 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 1208 could be either area scoped or AS scoped and is determined based on 1209 the configuration of the SR Mapping Server. 1211 The SR Mapping Server MUST use OSPF Extended Prefix Range TLV when 1212 advertising SIDs for prefixes. Prefixes of different route-types can 1213 be combined in a single OSPF Extended Prefix Range TLV advertised by 1214 the SR Mapping Server. 1216 Area-scoped OSPF Extended Prefix Range TLV are propagated between 1217 areas. Similar to propagation of prefixes between areas, an ABR only 1218 propagates the OSPF Extended Prefix Range TLV that it considers to be 1219 the best from the set it received. The rules used to pick the best 1220 OSPF Extended Prefix Range TLV are described in Section 4. 1222 When propagating an OSPF Extended Prefix Range TLV between areas, 1223 ABRs MUST set the IA-Flag, that is used to prevent redundant flooding 1224 of the OSPF Extended Prefix Range TLV between areas as described in 1225 Section 4. 1227 8.2. Inter-area Segment routing in OSPFv2 1229 In order to support SR in a multi-area environment, OSPFv2 must 1230 propagate Prefix-SID information between areas. The following 1231 procedure is used to propagate Prefix SIDs between areas. 1233 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 1234 prefix to all its connected areas, it will also originate an Extended 1235 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 1236 the Extended Prefix Opaque LSA type will be set to area-scope. The 1237 route-type in the OSPF Extended Prefix TLV is set to inter-area. The 1238 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1239 value will be set as follows: 1241 The ABR will look at its best path to the prefix in the source 1242 area and find the advertising router associated with the best path 1243 to that prefix. 1245 The ABR will then determine if such router advertised a Prefix-SID 1246 for the prefix and use it when advertising the Prefix-SID to other 1247 connected areas. 1249 If no Prefix-SID was advertised for the prefix in the source area 1250 by the router that contributes to the best path to the prefix, the 1251 originating ABR will use the Prefix-SID advertised by any other 1252 router when propagating the Prefix-SID for the prefix to other 1253 areas. 1255 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 1256 route to all its connected areas, it will also originate an Extended 1257 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 1258 the Extended Prefix Opaque LSA type will be set to area-scope. The 1259 route-type in OSPF Extended Prefix TLV is set to inter-area. The 1260 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1261 will be set as follows: 1263 The ABR will look at its best path to the prefix in the backbone 1264 area and find the advertising router associated with the best path 1265 to that prefix. 1267 The ABR will then determine if such router advertised a Prefix-SID 1268 for the prefix and use it when advertising the Prefix-SID to other 1269 connected areas. 1271 If no Prefix-SID was advertised for the prefix in the backbone 1272 area by the ABR that contributes to the best path to the prefix, 1273 the originating ABR will use the Prefix-SID advertised by any 1274 other router when propagating the Prefix-SID for the prefix to 1275 other areas. 1277 8.3. SID for External Prefixes 1279 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1280 SR, generates Type-5 LSAs, it should also originate Extended Prefix 1281 Opaque LSAs, as described in [RFC7684]. The flooding scope of the 1282 Extended Prefix Opaque LSA type is set to AS-scope. The route-type 1283 in the OSPF Extended Prefix TLV is set to external. The Prefix-SID 1284 Sub-TLV is included in this LSA and the Prefix-SID value will be set 1285 to the SID that has been reserved for that prefix. 1287 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 1288 also advertise the Prefix-SID for the prefix. The NSSA ABR 1289 determines its best path to the prefix advertised in the translated 1290 Type-7 LSA and finds the advertising router associated with that 1291 path. If the advertising router has advertised a Prefix-SID for the 1292 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 1293 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 1294 router will be used. 1296 8.4. Advertisement of Adj-SID 1298 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1299 using the Adj-SID Sub-TLV as described in Section 7. 1301 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 1303 An Adj-SID MAY be advertised for any adjacency on a P2P link that is 1304 in neighbor state 2-Way or higher. If the adjacency on a P2P link 1305 transitions from the FULL state, then the Adj-SID for that adjacency 1306 MAY be removed from the area. If the adjacency transitions to a 1307 state lower then 2-Way, then the Adj-SID advertisement MUST be 1308 removed from the area. 1310 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1312 Broadcast, NBMA or or hybrid [RFC6845] networks in OSPF are 1313 represented by a star topology where the Designated Router (DR) is 1314 the central point to which all other routers on the broadcast, NBMA, 1315 or hybrid network connect. As a result, routers on the broadcast, 1316 NBMA, or hybrid network advertise only their adjacency to the DR. 1317 Routers that do not act as DR do not form or advertise adjacencies 1318 with each other. They do, however, maintain 2-Way adjacency state 1319 with each other and are directly reachable. 1321 When Segment Routing is used, each router on the broadcast or NBMA 1322 network MAY advertise the Adj-SID for its adjacency to the DR using 1323 the Adj-SID Sub-TLV as described in Section 7.1. 1325 SR capable routers MAY also advertise an LAN-Adj-SID for other 1326 neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA or hybrid 1327 network using the LAN-ADJ-SID Sub-TLV as described in Section 7.2. 1329 9. IANA Considerations 1331 This specification updates several existing OSPF registries. 1333 9.1. OSPF OSPF Router Information (RI) TLVs Registry 1335 o 8 (IANA Preallocated) - SR-Algorithm TLV 1337 o 9 (IANA Preallocated) - SID/Label Range TLV 1339 o 12 - SR Local Block Sub-TLV 1341 o 13 - SRMS Preference Sub-TLV 1343 9.2. OSPF Extended Prefix LSA TLV Registry 1345 Following values are allocated: 1347 o 2 - OSPF Extended Prefix Range TLV 1349 9.3. OSPF Extended Prefix LSA Sub-TLV Registry 1351 Following values are allocated: 1353 o 1 - SID/Label Sub-TLV 1354 o 2 - Prefix SID Sub-TLV 1356 o 3 - SID/Label Binding Sub-TLV 1358 o 4 - IPv4 ERO Sub-TLV 1360 o 5 - Unnumbered Interface ID ERO Sub-TLV 1362 o 6 - IPv4 Backup ERO Sub-TLV 1364 o 7 - Unnumbered Interface ID Backup ERO Sub-TLV 1366 o 8 - ERO Metric Sub-TLV 1368 9.4. OSPF Extended Link LSA Sub-TLV Registry 1370 Following initial values are allocated: 1372 o 1 - SID/Label Sub-TLV 1374 o 2 - Adj-SID Sub-TLV 1376 o 3 - LAN Adj-SID/Label Sub-TLV 1378 10. Implementation Status 1380 An implementation survey with seven questions related to the 1381 implementer's support of OSPFv2 Segment Routing was sent to the OSPF 1382 WG list and several known implementers. This section contains 1383 responses from two implementers who completed the survey. No 1384 external means were used to verify the accuracy of the information 1385 submitted by the respondents. The respondents are considered experts 1386 on the products they reported on. Additionally, responses were 1387 omitted from implementers who indicated that they have not 1388 implemented the function yet. 1390 Responses from Nokia (former Alcatel-Lucent): 1392 Link to a web page describing the implementation: 1393 https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/ 1394 3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Un 1395 icast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf 1397 The implementation's level of maturity: Production. 1399 Coverage: We have implemented all sections and have support for the 1400 latest draft. 1402 Licensing: Part of the software package that needs to be purchased. 1404 Implementation experience: Great spec. We also performed inter- 1405 operability testing with Cisco's OSPF Segment Routing implementation. 1407 Contact information: wim.henderickx@nokia.com 1409 Responses from Cisco Systems: 1411 Link to a web page describing the implementation: 1413 www.segment-routing.net/home/tutorial 1415 The implementation's level of maturity: Production. 1417 Coverage: All sections, except the section 6 (SID/Label Binding Sub- 1418 TLV) have been implemented according to the latest draft. 1420 Licensing: Part of a commercial software package. 1422 Implementation experience: Many aspects of the draft are result of 1423 the actual implementation experience, as the draft evolved from its 1424 initial version to the current one. Interoperability testing with 1425 Alcatel-Lucent was performed, which confirmed the draft's ability to 1426 serve as a reference for the implementors. 1428 Contact information: ppsenak@cisco.com 1430 Responses from Juniper: 1432 The implementation's name and/or a link to a web page describing the 1433 implementation: 1435 Feature name is OSPF SPRING 1437 The implementation's level of maturity: To be released in 16.2 1438 (second half of 2016) 1440 Coverage: All sections implemented except Sections 4, and 6. 1442 Licensing: JUNOS Licensing needed. 1444 Implementation experience: NA 1446 Contact information: shraddha@juniper.net 1448 11. Security Considerations 1450 Implementations must assure that malformed TLV and Sub-TLV 1451 permutations do not result in errors which cause hard OSPF failures. 1453 12. Contributors 1455 The following people gave a substantial contribution to the content 1456 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1457 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1458 Saku Ytti. 1460 13. Acknowledgements 1462 We would like to thank Anton Smirnov for his contribution. 1464 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1465 contribution on earlier definition of the "Binding / MPLS Label TLV". 1467 Thanks to Acee Lindem for the detail review of the draft, 1468 corrections, as well as discussion about details of the encoding. 1470 14. References 1472 14.1. Normative References 1474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1475 Requirement Levels", BCP 14, RFC 2119, 1476 DOI 10.17487/RFC2119, March 1997, 1477 . 1479 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1480 DOI 10.17487/RFC2328, April 1998, 1481 . 1483 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1484 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1485 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1486 . 1488 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1489 in Resource ReSerVation Protocol - Traffic Engineering 1490 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1491 . 1493 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1494 (TE) Extensions to OSPF Version 2", RFC 3630, 1495 DOI 10.17487/RFC3630, September 2003, 1496 . 1498 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1499 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1500 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1501 . 1503 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1504 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 1505 July 2008, . 1507 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 1508 and Point-to-Multipoint Interface Type", RFC 6845, 1509 DOI 10.17487/RFC6845, January 2013, 1510 . 1512 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1513 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1514 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1515 2015, . 1517 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1518 S. Shaffer, "Extensions to OSPF for Advertising Optional 1519 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1520 February 2016, . 1522 14.2. Informative References 1524 [I-D.filsfils-spring-segment-routing-ldp-interop] 1525 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1526 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1527 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1528 "Segment Routing interoperability with LDP", draft- 1529 filsfils-spring-segment-routing-ldp-interop-02 (work in 1530 progress), September 2014. 1532 [I-D.filsfils-spring-segment-routing-use-cases] 1533 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1534 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1535 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1536 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1537 spring-segment-routing-use-cases-01 (work in progress), 1538 October 2014. 1540 [I-D.ietf-spring-conflict-resolution] 1541 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 1542 "Segment Routing Conflict Resolution", draft-ietf-spring- 1543 conflict-resolution-01 (work in progress), June 2016. 1545 [I-D.ietf-spring-segment-routing] 1546 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1547 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1548 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 1549 spring-segment-routing-00 (work in progress), December 1550 2014. 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 1582 Hannes Gredler 1583 RtBrick Inc. 1585 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