idnits 2.17.1 draft-ietf-ospf-ospfv3-segment-routing-extensions-23.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 9, 2019) is 1934 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) == Unused Reference: 'ALGOREG' is defined on line 836, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-mpls' is defined on line 851, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ALGOREG' == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-18 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 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 Cisco Systems, Inc. 4 Intended status: Standards Track S. Previdi, Ed. 5 Expires: July 13, 2019 Individual 6 January 9, 2019 8 OSPFv3 Extensions for Segment Routing 9 draft-ietf-ospf-ospfv3-segment-routing-extensions-23 11 Abstract 13 Segment Routing (SR) allows a flexible definition of end-to-end paths 14 within IGP topologies by encoding paths as sequences of topological 15 sub-paths, called "segments". These segments are advertised by the 16 link-state routing protocols (IS-IS and OSPF). 18 This draft describes the OSPFv3 extensions required for Segment 19 Routing with MPLS data plane. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 25 "OPTIONAL" in this document are to be interpreted as described in 26 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 27 capitals, as shown here. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 13, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 4 66 3.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 67 4. Segment Routing Capabilities . . . . . . . . . . . . . . . . 5 68 5. OSPFv3 Extended Prefix Range TLV . . . . . . . . . . . . . . 5 69 6. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 7 70 7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 11 71 7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 11 72 7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 13 73 8. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 14 74 8.1. Intra-area Segment routing in OSPFv3 . . . . . . . . . . 14 75 8.2. Inter-area Segment routing in OSPFv3 . . . . . . . . . . 15 76 8.3. Segment Routing for External Prefixes . . . . . . . . . . 16 77 8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 16 78 8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 16 79 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 16 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 9.1. OSPFv3 Extended-LSA TLV Registry . . . . . . . . . . . . 17 82 9.2. OSPFv3 Extended-LSA Sub-TLV registry . . . . . . . . . . 17 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 87 12.2. Informative References . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 90 1. Introduction 92 Segment Routing (SR) allows a flexible definition of end-to-end paths 93 within IGP topologies by encoding paths as sequences of topological 94 sub-paths, called "segments". These segments are advertised by the 95 link-state routing protocols (IS-IS and OSPF). Prefix segments 96 represent an ECMP-aware shortest-path to a prefix (or a node), as per 97 the state of the IGP topology. Adjacency segments represent a hop 98 over a specific adjacency between two nodes in the IGP. A prefix 99 segment is typically a multi-hop path while an adjacency segment, in 100 most cases, is a one-hop path. SR's control-plane can be applied to 101 both IPv6 and MPLS data-planes, and does not require any additional 102 signalling (other than IGP extensions). The IPv6 data plane is out 103 of the scope of this specification - OSPFv3 extension for SR with 104 IPv6 data plane will be specified in a separate document. When used 105 in MPLS networks, SR paths do not require any LDP or RSVP-TE 106 signalling. However, SR can interoperate in the presence of LSPs 107 established with RSVP or LDP. 109 This draft describes the OSPFv3 extensions required for Segment 110 Routing with MPLS data plane. 112 Segment Routing architecture is described in [RFC8402]. 114 Segment Routing use cases are described in [RFC7855]. 116 2. Terminology 118 This section lists some of the terminology used in this document: 120 ABR - Area Border Router 122 Adj-SID - Adjacency Segment Identifier 124 AS - Autonomous System 126 ASBR - Autonomous System Boundary Router 128 DR - Designated Router 130 IS-IS - Intermediate System to Intermediate System 132 LDP - Label Distribution Protocol 134 LSP - Label Switched Path 136 MPLS - Multi Protocol Label Switching 137 OSPF - Open Shortest Path First 139 SPF - Shortest Path First 141 RSVP - Resource Reservation Protocol 143 SID - Segment Identifier 145 SR - Segment Routing 147 SRGB - Segment Routing Global Block 149 SRLB - Segment Routing Local Block 151 SRMS - Segment Routing Mapping Server 153 TLV - Type Length Value 155 3. Segment Routing Identifiers 157 Segment Routing defines various types of Segment Identifiers (SIDs): 158 Prefix-SID, Adjacency-SID, and LAN Adjacency SID. 160 3.1. SID/Label Sub-TLV 162 The SID/Label Sub-TLV appears in multiple TLVs or Sub-TLVs defined 163 later in this document. It is used to advertise the SID or label 164 associated with a prefix or adjacency. The SID/Label Sub-TLV has 165 following format: 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Type | Length | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | SID/Label (variable) | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 where: 177 Type: 7 179 Length: Either 3 or 4 octets 181 SID/Label: If length is set to 3, then the 20 rightmost bits 182 represent a label. If length is set to 4, then the value 183 represents a 32-bit SID. 185 The receiving router MUST ignore the SID/Label Sub-TLV if the 186 length is other than 3 or 4. 188 4. Segment Routing Capabilities 190 Segment Routing requires some additional router capabilities to be 191 advertised to other routers in the area. 193 These SR capabilities are advertised in the OSPFv3 Router Information 194 Opaque LSA (defined in [RFC7770]) and specified in 195 [I-D.ietf-ospf-segment-routing-extensions]. 197 5. OSPFv3 Extended Prefix Range TLV 199 In some cases it is useful to advertise attributes for a range of 200 prefixes in a single advertisement. The Segment Routing Mapping 201 Server, which is described in 202 [I-D.ietf-spring-segment-routing-ldp-interop], is an example of where 203 SIDs for multiple prefixes can be advertised. To optimize such 204 advertisement in case of multiple prefixes from a contiguous address 205 range, OSPFv3 Extended Prefix Range TLV is defined." 207 The OSPFv3 Extended Prefix Range TLV is a top-level TLV of the 208 following LSAs defined in [RFC8362]: 210 E-Intra-Area-Prefix-LSA 212 E-Inter-Area-Prefix-LSA 214 E-AS-External-LSA 216 E-Type-7-LSA 218 Multiple OSPFv3 Extended Prefix Range TLVs MAY be advertised in each 219 LSA mentioned above. The OSPFv3 Extended Prefix Range TLV has the 220 following format: 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Type | Length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Prefix Length | AF | Range Size | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Flags | Reserved | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Address Prefix (variable) | 232 | ... | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Sub-TLVs (variable) | 235 +- -+ 236 | | 238 where: 240 Type: 9 242 Length: Variable, in octets, dependent on Sub-TLVs. 244 Prefix length: Length of prefix in bits. 246 AF: Address family for the prefix. 248 AF: 0 - IPv4 unicast 250 AF: 1 - IPv6 unicast 252 Range size: Represents the number of prefixes that are covered by 253 the advertisement. The Range Size MUST NOT exceed the number of 254 prefixes that could be satisfied by the prefix length without 255 including: 257 Addresses from the IPv4 multicast address range (224.0.0.0/3), 258 if the AF is IPv4 unicast 260 Addresses other than the IPv6 unicast addresses, if the AF is 261 IPv6 unicast 263 Flags: Reserved. MUST be zero when sent and are ignored when 264 received. 266 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 267 on reception. 269 Address Prefix: 271 For the address family IPv4 unicast, the prefix itself is 272 encoded as a 32-bit value. The default route is represented by 273 a prefix of length 0. 275 For the address family IPv6 unicast, the prefix, encoded as an 276 even multiple of 32-bit words, padded with zeroed bits as 277 necessary. This encoding consumes ((PrefixLength + 31) / 32) 278 32-bit words. 280 Prefix encoding for other address families is beyond the scope 281 of this specification. Prefix encoding for other address 282 families can be defined in the future standard-track IETF 283 specifications. 285 The range represents the contiguous set of prefixes with the same 286 prefix length as specified by the Prefix Length field. The set 287 starts with the prefix that is specified by the Address Prefix field. 288 The number of prefixes in the range is equal to the Range size. 290 If the OSPFv3 Extended Prefix Range TLVs advertising the exact same 291 range appears in multiple LSAs of the same type, originated by the 292 same OSPFv3 router, the LSA with the numerically smallest Instance ID 293 MUST be used and subsequent instances of the OSPFv3 Extended Prefix 294 Range TLVs MUST be ignored. 296 6. Prefix SID Sub-TLV 298 The Prefix SID Sub-TLV is a Sub-TLV of the following OSPFv3 TLVs as 299 defined in [RFC8362] and in Section 5: 301 Intra-Area Prefix TLV 303 Inter-Area Prefix TLV 305 External Prefix TLV 307 OSPFv3 Extended Prefix Range TLV 309 It MAY appear more than once in the parent TLV and has the following 310 format: 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type | Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Flags | Algorithm | Reserved | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | SID/Index/Label (variable) | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 where: 323 Type: 4 325 Length: 7 or 8 octets, dependent on the V-flag 327 Flags: Single octet field. The following flags are defined: 329 0 1 2 3 4 5 6 7 330 +--+--+--+--+--+--+--+--+ 331 | |NP|M |E |V |L | | | 332 +--+--+--+--+--+--+--+--+ 333 where: 335 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 336 NOT pop the Prefix-SID before delivering packets to the node 337 that advertised the Prefix-SID. 339 M-Flag: Mapping Server Flag. If set, the SID was advertised by 340 a Segment Routing Mapping Server as described in 341 [I-D.ietf-spring-segment-routing-ldp-interop]. 343 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 344 the Prefix-SID originator MUST replace the Prefix-SID with the 345 Explicit-NULL label (0 for IPv4, 2 for IPv6) before forwarding 346 the packet. 348 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 349 an absolute value. If not set, then the Prefix-SID carries an 350 index. 352 L-Flag: Local/Global Flag. If set, then the value/index 353 carried by the Prefix-SID has local significance. If not set, 354 then the value/index carried by this Sub-TLV has global 355 significance. 357 Other bits: Reserved. These MUST be zero when sent and are 358 ignored when received. 360 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 361 on reception. 363 Algorithm: Single octet identifying the algorithm the Prefix-SID 364 is associated with as defined in 365 [I-D.ietf-ospf-segment-routing-extensions]. 367 A router receiving a Prefix-SID from a remote node and with an 368 algorithm value that such remote node has not advertised in the 369 SR-Algorithm Sub-TLV [I-D.ietf-ospf-segment-routing-extensions] 370 MUST ignore the Prefix-SID Sub-TLV. 372 SID/Index/Label: According to the V-Flag and L-Flag, it contains: 374 V-flag is set to 0 and L-flag is set to 0: The SID/Index/Label 375 field is a 4 octet index defining the offset in the SID/Label 376 space advertised by this router 378 V-flag is set to 1 and L-flag is set to 1: The SID/Index/Label 379 field is a 3 octet local label where the 20 rightmost bits are 380 used for encoding the label value. 382 All other combinations of V-flag and L-flag are invalid and any 383 SID advertisement received with an invalid setting for V and L 384 flags MUST be ignored. 386 If an OSPFv3 router advertises multiple Prefix-SIDs for the same 387 prefix, topology, and algorithm, all of them MUST be ignored. 389 When calculating the outgoing label for the prefix, the router MUST 390 take into account, as described below, the E, NP, and M flags 391 advertised by the next-hop router if that router advertised the SID 392 for the prefix. This MUST be done regardless of whether the next-hop 393 router contributes to the best path to the prefix. 395 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 396 Prefix-SIDs allocated to prefixes that are propagated between areas 397 by an ABR based on intra-area or inter-area reachability, unless the 398 advertised prefix is directly attached to such ABR. 400 The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for 401 Prefix-SIDs allocated to redistributed prefixes, unless the 402 redistributed prefix is directly attached to the advertising ASBR. 404 If the NP-Flag is not set, then any upstream neighbor of the Prefix- 405 SID originator MUST pop the Prefix-SID. This is equivalent to the 406 penultimate hop popping mechanism used in the MPLS dataplane. If the 407 NP-flag is not set, then the received E-flag is ignored. 409 If the NP-flag is set then: 411 If the E-flag is not set, then any upstream neighbor of the 412 Prefix-SID originator MUST keep the Prefix-SID on top of the 413 stack. This is useful when the originator of the Prefix-SID needs 414 to stitch the incoming packet into a continuing MPLS LSP to the 415 final destination. This could occur at an ABR (prefix propagation 416 from one area to another) or at an ASBR (prefix propagation from 417 one domain to another). 419 If the E-flag is set, then any upstream neighbor of the Prefix-SID 420 originator MUST replace the Prefix-SID with an Explicit-NULL 421 label. This is useful, e.g., when the originator of the Prefix- 422 SID is the final destination for the related prefix and the 423 originator wishes to receive the packet with the original Traffic 424 Class field [RFC5462]. 426 When the M-Flag is set, the NP-flag and the E-flag MUST be ignored on 427 reception. 429 As the Mapping Server does not specify the originator of a prefix 430 advertisement, it is not possible to determine PHP behavior solely 431 based on the Mapping Server advertisement. However, PHP behavior 432 SHOULD be done in following cases: 434 The Prefix is intra-area type and the downstream neighbor is the 435 originator of the prefix. 437 The Prefix is inter-area type and the downstream neighbor is an 438 ABR, which is advertising prefix reachability and is setting the 439 LA-bit in the Prefix Options as described in [RFC8362]. 441 The Prefix is external type and the downstream neighbor is an 442 ASBR, which is advertising prefix reachability and is setting the 443 LA-bit in the Prefix Options as described in [RFC8362]. 445 When a Prefix-SID is advertised in the OSPFv3 Extended Prefix Range 446 TLV, then the value advertised in the Prefix SID Sub-TLV is 447 interpreted as a starting SID/Label value. 449 Example 1: If the following router addresses (loopback addresses) 450 need to be mapped into the corresponding Prefix SID indexes: 452 Router-A: 2001:DB8::1/128, Prefix-SID: Index 1 453 Router-B: 2001:DB8::2/128, Prefix-SID: Index 2 454 Router-C: 2001:DB8::3/128, Prefix-SID: Index 3 455 Router-D: 2001:DB8::4/128, Prefix-SID: Index 4 457 then the Address Prefix field in the OSPFv3 Extended Prefix Range TLV 458 would be set to 2001:DB8::1, the Prefix Length would be set to 128, 459 the Range Size would be set to 4, and the Index value in the Prefix- 460 SID Sub-TLV would be set to 1. 462 Example 2: If the following prefixes need to be mapped into the 463 corresponding Prefix-SID indexes: 465 2001:DB8:1::0/120, Prefix-SID: Index 51 466 2001:DB8:1::100/120, Prefix-SID: Index 52 467 2001:DB8:1::200/120, Prefix-SID: Index 53 468 2001:DB8:1::300/120, Prefix-SID: Index 54 469 2001:DB8:1::400/120, Prefix-SID: Index 55 470 2001:DB8:1::500/120, Prefix-SID: Index 56 471 2001:DB8:1::600/120, Prefix-SID: Index 57 473 then the Prefix field in the OSPFv3 Extended Prefix Range TLV would 474 be set to 2001:DB8:1::0, the Prefix Length would be set to 120, the 475 Range Size would be set to 7, and the Index value in the Prefix-SID 476 Sub-TLV would be set to 51. 478 7. Adjacency Segment Identifier (Adj-SID) 480 An Adjacency Segment Identifier (Adj-SID) represents a router 481 adjacency in Segment Routing. 483 7.1. Adj-SID Sub-TLV 485 The Adj-SID Sub-TLV is an optional Sub-TLV of the Router-Link TLV as 486 defined in [RFC8362]. It MAY appear multiple times in the Router- 487 Link TLV. The Adj-SID Sub-TLV has the following format: 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Type | Length | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Flags | Weight | Reserved | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | SID/Label/Index (variable) | 497 +---------------------------------------------------------------+ 499 where: 501 Type: 5 503 Length: 7 or 8 octets, dependent on the V flag. 505 Flags: Single octet field containing the following flags: 507 0 1 2 3 4 5 6 7 508 +-+-+-+-+-+-+-+-+ 509 |B|V|L|G|P| | 510 +-+-+-+-+-+-+-+-+ 512 where: 514 B-Flag: Backup Flag. If set, the Adj-SID refers to an 515 adjacency that is eligible for protection (e.g., using IPFRR or 516 MPLS-FRR) as described in section 3.5 of [RFC8402]. 518 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 519 an absolute value. If not set, then the Adj-SID carries an 520 index. 522 The L-Flag: Local/Global Flag. If set, then the value/index 523 carried by the Adj-SID has local significance. If not set, 524 then the value/index carried by this Sub-TLV has global 525 significance. 527 The G-Flag: Group Flag. When set, the G-Flag indicates that 528 the Adj-SID refers to a group of adjacencies (and therefore MAY 529 be assigned to other adjacencies as well). 531 P-Flag. Persistent flag. When set, the P-Flag indicates that 532 the Adj-SID is persistently allocated, i.e., the Adj-SID value 533 remains the same across router restart and/or interface flap. 535 Other bits: Reserved. These MUST be zero when sent and are 536 ignored when received. 538 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 539 on reception. 541 Weight: Weight used for load-balancing purposes. The use of the 542 weight is defined in [RFC8402]. 544 SID/Index/Label: as described in Section 6. 546 An SR-capable router MAY allocate an Adj-SID for each of its 547 adjacencies and set the B-Flag when the adjacency is eligible for 548 protection by an FRR mechanism (IP or MPLS) as described in 549 [RFC8402]. 551 An SR-capable router MAY allocate more than one Adj-SID to an 552 adjacency. 554 An SR-capable router MAY allocate the same Adj-SID to different 555 adjacencies. 557 When the P-flag is not set, the Adj-SID MAY be persistent. When the 558 P-flag is set, the Adj-SID MUST be persistent. 560 7.2. LAN Adj-SID Sub-TLV 562 The LAN Adj-SID Sub-TLV is an optional Sub-TLV of the Router-Link 563 TLV. It MAY appear multiple times in the Router-Link TLV. It is 564 used to advertise a SID/Label for an adjacency to a non-DR router on 565 a broadcast, NBMA, or hybrid [RFC6845] network. 567 0 1 2 3 568 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Type | Length | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Flags | Weight | Reserved | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Neighbor ID | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | SID/Label/Index (variable) | 577 +---------------------------------------------------------------+ 579 where: 581 Type: 6 583 Length: 11 or 12 octets, dependent on V-flag. 585 Flags: same as in Section 7.1 587 Weight: Weight used for load-balancing purposes. The use of the 588 weight is defined in [RFC8402]. 590 Reserved: SHOULD be set to 0 on transmission and MUST be ignored 591 on reception. 593 Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- 594 SID is advertised. 596 SID/Index/Label: as described in Section 6. 598 When the P-flag is not set, the LAN Adj-SID MAY be persistent. 599 When the P-flag is set, the LAN Adj-SID MUST be persistent. 601 8. Elements of Procedure 603 8.1. Intra-area Segment routing in OSPFv3 605 An OSPFv3 router that supports segment routing MAY advertise Prefix- 606 SIDs for any prefix to which it is advertising reachability (e.g., a 607 loopback IP address as described in Section 6). 609 A Prefix-SID can also be advertised by SR Mapping Servers (as 610 described in [I-D.ietf-spring-segment-routing-ldp-interop]). A 611 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 612 in the OSPFv3 routing domain. Multiple Mapping Servers can advertise 613 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 614 MUST be advertised by all of them. The SR Mapping Server could use 615 either area flooding scope or autonomous system flooding scope when 616 advertising Prefix SIDs for prefixes, based on the configuration of 617 the SR Mapping Server. Depending on the flooding scope used, the SR 618 Mapping Server chooses the OSPFv3 LSA type that will be used. If the 619 area flooding scope is needed, an E-Intra-Area-Prefix-LSA [RFC8362] 620 is used. If autonomous system flooding scope is needed, an E-AS- 621 External-LSA [RFC8362] is used. 623 When a Prefix-SID is advertised by the Mapping Server, which is 624 indicated by the M-flag in the Prefix-SID Sub-TLV (Section 6), the 625 route type as implied by the LSA type is ignored and the Prefix-SID 626 is bound to the corresponding prefix independent of the route type. 628 Advertisement of the Prefix-SID by the Mapping Server using an Inter- 629 Area Prefix TLV, External-Prefix TLV, or Intra-Area-Prefix TLV 630 [RFC8362] does not itself contribute to the prefix reachability. The 631 NU-bit [RFC5340] MUST be set in the PrefixOptions field of the LSA 632 which is used by the Mapping Server to advertise SID or SID Range, 633 which prevents the advertisement from contributing to prefix 634 reachability. 636 An SR Mapping Server MUST use the OSPFv3 Extended Prefix Range TLVs 637 when advertising SIDs for prefixes. Prefixes of different route- 638 types can be combined in a single OSPFv3 Extended Prefix Range TLV 639 advertised by an SR Mapping Server. 641 Area-scoped OSPFv3 Extended Prefix Range TLVs are propagated between 642 areas, similar to propagation of prefixes between areas. Same rules 643 that are used for propagating prefixes between areas [RFC5340] are 644 used for the propagation of the prefix ranges. 646 8.2. Inter-area Segment routing in OSPFv3 648 In order to support SR in a multi-area environment, OSPFv3 MUST 649 propagate Prefix-SID information between areas. The following 650 procedure is used to propagate Prefix SIDs between areas. 652 When an OSPFv3 ABR advertises an Inter-Area-Prefix-LSA from an intra- 653 area prefix to all its connected areas, it will also include the 654 Prefix-SID Sub-TLV, as described in Section 6. The Prefix-SID value 655 will be set as follows: 657 The ABR will look at its best path to the prefix in the source 658 area and find the advertising router associated with the best path 659 to that prefix. 661 The ABR will then determine if such router advertised a Prefix-SID 662 for the prefix and use it when advertising the Prefix-SID to other 663 connected areas. 665 If no Prefix-SID was advertised for the prefix in the source area 666 by the router that contributes to the best path to the prefix, the 667 originating ABR will use the Prefix-SID advertised by any other 668 router when propagating the Prefix-SID for the prefix to other 669 areas. 671 When an OSPFv3 ABR advertises Inter-Area-Prefix-LSA LSAs from an 672 inter-area route to all its connected areas, it will also include the 673 Prefix-SID Sub-TLV, as described in Section 6. The Prefix-SID value 674 will be set as follows: 676 The ABR will look at its best path to the prefix in the backbone 677 area and find the advertising router associated with the best path 678 to that prefix. 680 The ABR will then determine if such router advertised a Prefix-SID 681 for the prefix and use it when advertising the Prefix-SID to other 682 connected areas. 684 If no Prefix-SID was advertised for the prefix in the backbone 685 area by the ABR that contributes to the best path to the prefix, 686 the originating ABR will use the Prefix-SID advertised by any 687 other router when propagating the Prefix-SID for the prefix to 688 other areas. 690 8.3. Segment Routing for External Prefixes 692 AS-External-LSAs are flooded domain wide. When an ASBR, which 693 supports SR, originates an E-AS-External-LSA, it SHOULD also include 694 a Prefix-SID Sub-TLV, as described in Section 6. The Prefix-SID 695 value will be set to the SID that has been reserved for that prefix. 697 When an NSSA [RFC3101] ABR translates an E-NSSA-LSA into an E-AS- 698 External-LSA, it SHOULD also advertise the Prefix-SID for the prefix. 699 The NSSA ABR determines its best path to the prefix advertised in the 700 translated E-NSSA-LSA and finds the advertising router associated 701 with that path. If the advertising router has advertised a Prefix- 702 SID for the prefix, then the NSSA ABR uses it when advertising the 703 Prefix-SID for the E-AS-External-LSA. Otherwise, the Prefix-SID 704 advertised by any other router will be used. 706 8.4. Advertisement of Adj-SID 708 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 709 using the Adj-SID Sub-TLV as described in Section 7. 711 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 713 An Adj-SID MAY be advertised for any adjacency on a P2P link that is 714 in neighbor state 2-Way or higher. If the adjacency on a P2P link 715 transitions from the FULL state, then the Adj-SID for that adjacency 716 MAY be removed from the area. If the adjacency transitions to a 717 state lower than 2-Way, then the Adj-SID advertisement MUST be 718 withdrawn from the area. 720 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 722 Broadcast, NBMA, or hybrid [RFC6845] networks in OSPFv3 are 723 represented by a star topology where the DR is the central point to 724 which all other routers on the broadcast, NBMA, or hybrid network 725 connect. As a result, routers on the broadcast, NBMA, or hybrid 726 network advertise only their adjacency to the DR. Routers that do 727 not act as DR do not form or advertise adjacencies with each other. 728 They do, however, maintain 2-Way adjacency state with each other and 729 are directly reachable. 731 When Segment Routing is used, each router on the broadcast, NBMA, or 732 hybrid network MAY advertise the Adj-SID for its adjacency to the DR 733 using the Adj-SID Sub-TLV as described in Section 7.1. 735 SR-capable routers MAY also advertise a LAN-Adj-SID for other 736 neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid 737 network using the LAN-Adj-SID Sub-TLV as described in Section 7.2. 739 9. IANA Considerations 741 This specification updates several existing OSPFv3 registries. 743 9.1. OSPFv3 Extended-LSA TLV Registry 745 Following values are allocated: 747 o 9 - OSPFv3 Extended Prefix Range TLV 749 9.2. OSPFv3 Extended-LSA Sub-TLV registry 751 o 4 - Prefix SID Sub-TLV 753 o 5 - Adj-SID Sub-TLV 755 o 6 - LAN Adj-SID Sub-TLV 757 o 7 - SID/Label Sub-TLV 759 10. Security Considerations 761 With the OSPFv3 segment routing extensions defined herein, OSPFv3 762 will now program the MPLS data plane [RFC3031]. Previously, LDP 763 [RFC5036] or another label distribution mechanism was required to 764 advertise MPLS labels and program the MPLS data plane. 766 In general, the same types of attacks that can be carried out on the 767 IP control plane can be carried out on the MPLS control plane 768 resulting in traffic being misrouted in the respective data planes. 769 However, the latter can be more difficult to detect and isolate. 771 Existing security extensions as described in [RFC5340] and [RFC8362] 772 apply to these segment routing extensions. While OSPFv3 is under a 773 single administrative domain, there can be deployments where 774 potential attackers have access to one or more networks in the OSPFv3 775 routing domain. In these deployments, stronger authentication 776 mechanisms such as those specified in [RFC4552] or [RFC7166] SHOULD 777 be used. 779 Implementations MUST assure that malformed TLV and Sub-TLV defined in 780 this document are detected and do not provide a vulnerability for 781 attackers to crash the OSPFv3 router or routing process. Reception 782 of a malformed TLV or Sub-TLV SHOULD be counted and/or logged for 783 further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be 784 rate-limited to prevent a Denial of Service (DoS) attack (distributed 785 or otherwise) from overloading the OSPFv3 control plane. 787 11. Contributors 789 The following people gave a substantial contribution to the content 790 of this document and should be considered as co-authors: 792 Clarence Filsfils 793 Cisco Systems, Inc. 794 Brussels 795 Belgium 797 Email: cfilsfil@cisco.com 799 Hannes Gredler 800 RtBrick Inc. 801 Austria 803 Email: hannes@rtbrick.com 805 Rob Shakir 806 Google, Inc. 807 1600 Amphitheatre Parkway 808 Mountain View, CA 94043 809 US 811 Email: robjs@google.com 813 Wim Henderickx 814 Nokia 815 Copernicuslaan 50 816 Antwerp 2018 817 BE 819 Email: wim.henderickx@nokia.com 821 Jeff Tantsura 822 Nuage Networks 823 US 825 Email: jefftant.ietf@gmail.com 827 Thanks to Acee Lindem for his substantial contribution to the content 828 of this document. 830 We would like to thank Anton Smirnov for his contribution as well. 832 12. References 834 12.1. Normative References 836 [ALGOREG] "IGP Algorithm Types", . 839 [I-D.ietf-ospf-segment-routing-extensions] 840 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 841 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 842 Extensions for Segment Routing", draft-ietf-ospf-segment- 843 routing-extensions-27 (work in progress), December 2018. 845 [I-D.ietf-spring-segment-routing-ldp-interop] 846 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and 847 S. Litkowski, "Segment Routing interworking with LDP", 848 draft-ietf-spring-segment-routing-ldp-interop-15 (work in 849 progress), September 2018. 851 [I-D.ietf-spring-segment-routing-mpls] 852 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 853 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 854 data plane", draft-ietf-spring-segment-routing-mpls-18 855 (work in progress), December 2018. 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, 859 DOI 10.17487/RFC2119, March 1997, 860 . 862 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 863 Label Switching Architecture", RFC 3031, 864 DOI 10.17487/RFC3031, January 2001, 865 . 867 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 868 RFC 3101, DOI 10.17487/RFC3101, January 2003, 869 . 871 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 872 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 873 October 2007, . 875 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 876 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 877 . 879 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 880 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 881 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 882 2009, . 884 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 885 and Point-to-Multipoint Interface Type", RFC 6845, 886 DOI 10.17487/RFC6845, January 2013, 887 . 889 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 890 S. Shaffer, "Extensions to OSPF for Advertising Optional 891 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 892 February 2016, . 894 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 895 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 896 May 2017, . 898 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 899 F. Baker, "OSPFv3 Link State Advertisement (LSA) 900 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 901 2018, . 903 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 904 Decraene, B., Litkowski, S., and R. Shakir, "Segment 905 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 906 July 2018, . 908 12.2. Informative References 910 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 911 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 912 . 914 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 915 Authentication Trailer for OSPFv3", RFC 7166, 916 DOI 10.17487/RFC7166, March 2014, 917 . 919 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 920 Litkowski, S., Horneffer, M., and R. Shakir, "Source 921 Packet Routing in Networking (SPRING) Problem Statement 922 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 923 2016, . 925 Authors' Addresses 927 Peter Psenak (editor) 928 Cisco Systems, Inc. 929 Eurovea Centre, Central 3 930 Pribinova Street 10 931 Bratislava 81109 932 Slovakia 934 Email: ppsenak@cisco.com 936 Stefano Previdi (editor) 937 Individual 939 Email: stefano.previdi@net