idnits 2.17.1 draft-chunduri-lsr-ospf-preferred-path-routing-02.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 date (February 14, 2019) is 1895 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) == Missing Reference: 'I-D.chunduri-isis-preferred-path-routing' is mentioned on line 801, but not defined == Outdated reference: A later version (-08) exists of draft-chunduri-lsr-isis-preferred-path-routing-01 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 == Outdated reference: A later version (-07) exists of draft-li-ospf-ospfv3-srv6-extensions-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group U. Chunduri 3 Internet-Draft Y. Qu 4 Intended status: Standards Track Huawei USA 5 Expires: August 18, 2019 R. White 6 Juniper Networks 7 J. Tantsura 8 Apstra Inc. 9 L. Contreras 10 Telefonica 11 February 14, 2019 13 Preferred Path Routing (PPR) in OSPF 14 draft-chunduri-lsr-ospf-preferred-path-routing-02 16 Abstract 18 This document specifies a Preferred Path Routing (PPR), a routing 19 protocol mechanism to simplify the path description of data plane 20 traffic in Segment Routing (SR) deployments with OSPFv2 and OSPFv3 21 protocols. PPR aims to mitigate the MTU and data plane processing 22 issues that may result from SR packet overheads; and also supports 23 traffic measurement, accounting statistics and further attribute 24 extensions along the paths. Preferred Path Routing is achieved 25 through the addition of descriptions to OSPF advertised prefixes, and 26 mapping those to a PPR data-plane identifier. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC2119 [RFC2119], 33 RFC8174 [RFC8174] when, and only when they appear in all capitals, as 34 shown here". 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on August 18, 2019. 53 Copyright Notice 55 Copyright (c) 2019 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. OSPFv2 PPR TLV . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1. PPR-Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 74 2.2. PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . . . . 6 75 2.3. PPR-ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 7 76 2.4. PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . . . . . 9 77 2.5. PPR-Attributes Sub-TLV . . . . . . . . . . . . . . . . . 10 78 3. OSPFv3 PPR TLV . . . . . . . . . . . . . . . . . . . . . . . 11 79 3.1. OSPFv3 PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . 13 80 3.2. OSPFv3 PPR-ID Sub-TLVs . . . . . . . . . . . . . . . . . 13 81 3.3. OSPFv3 PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . 15 82 3.4. OSPFv3 PPR-Attributes Sub-TLV . . . . . . . . . . . . . . 17 83 4. Other Considerations . . . . . . . . . . . . . . . . . . . . 18 84 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 89 8.2. Informative References . . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 92 1. Introduction 94 In a network implementing Segment Routing (SR), packets are steered 95 through the network using Segment Identifiers (SIDs) carried in the 96 packet header. Each SID uniquely identifies a segment as defined in 97 [I-D.ietf-spring-segment-routing]. SR capabilities are defined for 98 MPLS and IPv6 data planes called SR-MPLS and SRv6 respectively. 100 In SR-MPLS, a segment is encoded as a label and an ordered list of 101 segments is encoded as a stack of labels on the data packet. In 102 SRv6, a segment is encoded as an IPv6 address, with in a new type of 103 IPv6 hop-by-hop routing header/extension header (EH) called SRH 104 [I-D.ietf-6man-segment-routing-header], where an ordered list of IPv6 105 addresses/segments is encoded in SRH. 107 The issues caused by the large SID depth, and existing methods for 108 mitigation are introduced in 109 [I-D.chunduri-lsr-isis-preferred-path-routing] section 1.2 and 1.3. 110 To mitigate these issues , and also to facilitate forwarding plane a 111 mechanism to identify the path with a corresponding data plane 112 identifier for accounting of traffic for SR paths, this draft 113 proposes a new OSPFv2 PPR TLV (Section 2), OSPFv3 PPR TLV (Section 3) 114 to use the path with a corresponding data plane identifier. 116 Preferred Path Routing means enabling route computation based on the 117 specific path described along with the prefix as opposed to shortest 118 path towards the prefix. This also further described in Section 2 of 119 [I-D.chunduri-lsr-isis-preferred-path-routing]. 121 Any prefix advertised with a path description from any node in the 122 network is called Preferred Path Route. A PPR could be an SR path, 123 an explicitly provisioned Fast Re-Route (FRR) path or a service 124 chained path. A PPR can be signaled by any node, which receives the 125 SR path computed by a central controller, or by operator by 126 statically configuring the same on a node in the network. 128 With corresponding data plane, Section 4 mechanism as in [I- 129 D.chunduri-isis-preferred-path-routing], reduces the SID stack in the 130 data plane with a single PPR ID. 132 1.1. Acronyms 134 EL - Entropy Label 136 ELI - Entropy Label Indicator 138 MPLS - Multi Protocol Label Switching 139 MSD - Maximum SID Depth 141 MTU - Maximum Transferrable Unit 143 NSP - Non Shortest Path 145 SID - Segment Identifier 147 SPF - Shortest Path First 149 SR - Segment Routing 151 SRH - Segment Routing Header 153 SR-MPLS - Segment Routing with MPLS data plane 155 SRv6 - Segment Routing with Ipv6 data plane with SRH 157 SRH - IPv6 Segment Routing Header 159 TE - Traffic Engineering 161 2. OSPFv2 PPR TLV 163 Extended Prefix Opaque LSAs defined in [RFC7684] are used for 164 advertisements of PPRs. This section describes the encoding of PPR 165 TLV. This TLV can be seen as having 4 logical section viz., encoding 166 of the OSPFv2 Prefix, encoding of PPR-ID, encoding of path 167 description with an ordered PDE Sub-TLVs and a set of optional PPR 168 attribute Sub-TLVs, which can be used to describe one or more 169 parameters of the path. Multiple OSPF PPR TLVs MAY be advertised in 170 each OSPF Extended Prefix Opaque LSA, but all TLVs included in a 171 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 172 scope. 174 The PPR TLV has Type TBD (suggested value xxx), and has the following 175 format: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Type | Length | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | PPR-Flags | AF | Reserved | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | PPR-Prefix Sub-TLV (variable size) | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | PPR-ID Sub-TLV (variable size) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | PPR-PDE Sub-TLVs (variable) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | PPR-Attribute Sub-TLVs(variable) | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 1: OSPFV2 PPR TLV Format 195 o Type - TBD (IANA)from OSPF Extended Prefix Opaque LSA registry. 197 o Length - Total length of the value field in bytes (variable). 199 o PPR-Flags - 2 Octet flags for this TLV are described below. 201 o AF - Address family for the prefix. Currently, the only supported 202 value is 0 for IPv4 unicast. The inclusion of address family in 203 this TLV allows for future extension. 205 o Reserved - 1 Octet reserved bits for future use. Reserved bits 206 MUST be reset on transmission and ignored on receive. 208 o PPR-Prefix - This is a variable size Sub-TLV, which represents the 209 prefix for which path description is being attached to. This is 210 defined in Section 2.2. 212 o PPR-ID - This is a variable size Sub-TLV, which represents the 213 data plane or forwarding identifier of the PPR. This is defined 214 in Section 2.3. 216 o PPR-PDEs - Variable number of ordered PDE Sub-TLVs which 217 represents the path. This is defined in Section 2.4. 219 o PPR-Attributes - Variable number of PPR-Attribute Sub-TLVs which 220 represent the path attributes. These are defined in Section 2.5. 222 2.1. PPR-Flags 224 Flags: 2 octet field of PPR TLV has following flags defined: 226 NSPF ID Flags Format 227 0 1 2 3 4 5 6 7 15 228 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 229 |IA|A | Reserved | 230 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 232 w=Where: 234 IA-Flag: Inter-Area flag. If set, advertisement is of inter-area 235 type. An Area Boarder Router (ABR) that is advertising the OSPF 236 PPR TLV between areas MUST set this bit. 238 A: The originator of the PPR TLV MUST set the A bit in order to 239 signal that the prefixes and PPR-IDs advertised in the PPR TLV are 240 directly connected to the originators. If this bit is not set, 241 this allows any other node in the network advertise this TLV on 242 behalf of the originating node of the "OSPF Prefix". If PPR TLV 243 is propagated to other areas the A-flag MUST be cleared. In case 244 if the originating node of the prefix has to be disambiguated for 245 any reason including, if it is a Multi Homed Prefix (MHP) or 246 propagated to a different OSPF area, then PPR-Attribute Sub-TLV 247 Source Router ID SHOULD be included. 249 Reserved: Reserved bits for future use. Reserved bits MUST be 250 reset on transmission and ignored on receive. 252 2.2. PPR-Prefix Sub-TLV 254 The structure of PPR-Prefix, for which path description is attached 255 to is as follows: 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type | Length | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | MT-ID | Prefix Length | Mask Length | Reserved | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 // OSPFv2 Prefix (variable) // 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | PPR-Prefix Sub-TLVs (variable) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 2: PPR-Prefix Sub-TLV Format 271 o Type - TBD (See IANA for suggested value) from OSPFv2 PPR TLV 272 Section 2 Sub-TLV registry. 274 o Length - Total length of the value field in bytes (variable). 276 o MT-ID - Multi-Topology ID (as defined in [RFC4915]). 278 o Prefix Len - contains the length of the prefix in bits. Only the 279 most significant octets of the Prefix are encoded. 281 o Mask Length - The length of the prefix in bits. Only the most 282 significant octets of the Prefix are encoded. 284 o OSPFv2 Prefix - represents the OSPFv2 prefix at the tail-end of 285 the advertised PPR. For the address family IPv4 unicast, the 286 prefix itself is encoded as a 32-bit value. The default route is 287 represented by a prefix of length 0. 289 o PPR-Prefix Sub-TLVs - TBD. It has 2 octet type, 2 octet length 290 and value field is defined per type. 292 2.3. PPR-ID Sub-TLV 294 This represents the actual data plane identifier in the packet and 295 could be of any data plane as defined in PPR-ID-type field. Both 296 OSPF Prefix and PPR-ID MUST belong to a same node in the network. 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type | Length | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | PPR-ID Flags | PPR-ID Type | PPR-ID Length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 |PPR-ID Mask Len| Algo | PPR-ID // 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 // PPR-ID (cont., variable size) // 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 3: PPR-ID Sub-TLV Format 312 o Type - TBD (See IANA for suggested value) from OSPFv2 PPR TLV 313 Section 2 Sub-TLV registry. 315 o Length - Total length of the value field in bytes (variable). 317 o PPR-ID Type - Data plane type of PPR-ID. This is a new registry 318 (TBD IANA) for this Sub-TLV and the defined types are as follows: 320 a. Type: 1 MPLS SID/Label 322 b. Type: 2 Native IPv4 Address/Prefix 324 o PPR-ID Flags - 2 Octet field for PPR-ID flags: 326 PPR-ID Flags Format 328 0 1 2 3 4 5 6 7 15 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 |L|A| Reserved | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 1. L - If set, the PPR path is a Loose-PPR. If the flag is unset, 334 then the path described is a Strict-PPR. A Strict-PPR lists 335 every single node or adjacency in the path description from 336 source to the destination. 338 2. A - If set, all non-PPR path nodes in the OSPF area MUST add a 339 FIB entry for the PPR-ID with NH set to the shortest path NH for 340 the prefix being advertised. The use of this is TBD. By default 341 this MUST be unset. 343 3. Reserved - Reserved bits for future use. Reserved bits MUST be 344 reset on transmission and ignored on receive. 346 o PPR-ID Length - Length of the PPR-ID field in octets and this 347 depends on the PPR-ID type. See PPR-ID below for the length of 348 this field and other considerations. 350 o PPR-ID Mask Len - It is applicable for only for PPR-ID Type 2. 351 For Type 1 this value MUST be set to zero. It contains the length 352 of the PPR-ID Prefix in bits. Only the most significant octets of 353 the Prefix are encoded. This is needed, if PPR-ID followed is an 354 IPv4 Prefix instead of 4 octet Address respectively. 356 o Algo - 1 octet value represents the SPF algorithm. Algorithm 357 registry is as defined in 358 [I-D.ietf-ospf-segment-routing-extensions]. 360 o PPR-ID - This is the Preferred Path forwarding identifier that 361 would be on the data packet. The value of this field is variable 362 and it depends on the PPR-ID Type - for Type 1, this is and MPLS 363 SID/Label. For Type 2 this is a 4 byte IPv4 address. 365 2.4. PPR-PDE Sub-TLV 367 This is a new Sub-TLV type in PPR TLV Section 2 and is called as PPR 368 Path Description Element (PDE). PPR-PDEs are used to describe the 369 path in the form of set of contiguous and ordered Sub-TLVs, where 370 first Sub-TLV represents (the top of the stack in MPLS data plane or) 371 first node/segment of the path. These set of ordered Sub-TLVs can 372 have both topological SIDs and non-topological SIDs (e.g., service 373 segments). 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type | Length | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | PPR-PDE Type | PDE-ID Type | PDE-ID Len | Reserved | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | PPR-PDE Flags | PDE-ID Value // 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 // PDE-ID Value (Contd., Variable size) // 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | PPR-PDE Sub-TLVs (variable) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Figure 4: PPR-PDE Sub-TLV Format 391 o Type - TBD (See IANA for suggested value) from OSPFv2 PPR TLV 392 Section 2 Sub-TLV registry. 394 o Length - Total length of the value field in bytes (variable). 396 o PPR-PDE Type - This is a new registry (TBD IANA) for this Sub-TLV 397 and the defined types are as follows: 399 a. Type: 1 Topological 401 b. Type: 2 Non-Topological 403 o PDE-ID Type - 1 Octet PDE-forwarding IDentifier Type. This is a 404 new registry (TBD IANA) for this Sub-TLV and the defined types and 405 corresponding PDE-ID Len, PDE-ID Value are as follows: 407 a. Type 1: SID/Label Sub-TLV as defined in 408 [I-D.ietf-ospf-segment-routing-extensions]. PDE-ID Len and PDE- 409 ID Value fields are per Section 2.1 of the referenced document. 411 b. Type 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are same 412 as Type 1. 414 c. Type 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are 415 same as Type 1. 417 d. Type 4: IPv4 Address. PDE-ID Len is 4 bytes and PDE-ID Value is 418 4 bytes IPv4 address encoded similar to IPv4 Prefix described in 419 Section 2.2. 421 o PDE-ID Len - 1 Octet. Length of PDE-ID field. 423 o Reserved - 1 Octet reserved bits for future use. Reserved bits 424 MUST be reset on transmission and ignored on receive. 426 o PPR-PDE Flags - 2 Octet flags for this TLV are described below: 428 PPR-PDE Flags Format 430 0 1 2 3 4 5 6 7... 15 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 |L|D| Reserved | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 1. L: This bit indicates the type of next "Topological PDE-ID" in 436 the path description and overrides the L bit in Section 2.3. If 437 set, the next PDE is Loose. If this flag is unset, the next 438 Topological PDE is Strict Type. 440 2. D: By default this bit MUST be unset. This bit MUST be set only 441 for PPR-PDE Type is Topological and this PDE represents the PDE- 442 ID corresponding to the PPR-Prefix Section 2.2. 444 3. Reserved: Reserved bits for future use. Reserved bits MUST be 445 reset on transmission and ignored on receive. 447 o PPR-PDE Sub-TLVs - TBD. It has 2 octet type, 2 octet length and 448 value field is defined per type. 450 2.5. PPR-Attributes Sub-TLV 452 PPR-Attribute Sub-TLVs describe the attributes of the path. The 453 following Sub-TLVs draw from a new registry for Sub-TLV numbers; this 454 registry is to be created by IANA, and administered using the first 455 come first serve process: 457 o Type 1 (Suggested Value - IANA TBD): This is Packet Traffic 458 accounting Sub-TLV. Length 0 No value field. Specifies to create 459 a counter to count number of packets forwarded on this PPR-ID on 460 each node in the path description. 462 o Type 2 (Suggested Value - IANA TBD): This is Traffic statistics in 463 Bytes Sub-TLV. Length 0 No value field. Specifies to create a 464 counter to count number of bytes forwarded on this PPR-ID 465 specified in the network header (e.g. IPv4, IPv6) on each node in 466 the path description. 468 o Type 3 (Suggested Value - IANA TBD): PPR-Metric Sub-TLV. Length 4 469 bytes, and Value is metric of this path represented through the 470 PPR-ID. Different nodes can advertise the same PPR-ID for the 471 same Prefix with a different set of PPR-PDE Sub-TLVs and the 472 receiving node MUST consider the lowest metric value (TBD more, on 473 what happens when metric is same for two different set of PPR-PDE 474 Sub-TLVs). 476 3. OSPFv3 PPR TLV 478 The OSPFv3 PPR TLV s a top level TLV of the following LSAs defined in 479 [I-D.ietf-ospf-ospfv3-lsa-extend]. 481 E-Intra-Area-Prefix-LSA 483 E-Inter-Area-Prefix-LSA 485 E-AS-External-LSA 487 E-Type-7-LSA 489 Multiple OSPFv3 PPR TLVs MAY be advertised in each LSA mentioned 490 above. The OSPFv3 PPR TLV has the following format: 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Type | Length | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | PPR-Flags | AF | Reserved | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | OSPFv3 PPR-Prefix Sub-TLV (variable size) | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | PPR-ID Sub-TLV (variable size) | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | PPR-PDE Sub-TLVs (variable) | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | PPR-Attribute Sub-TLVs(variable) | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 5: OSPFv3 PPR TLV Format 510 o Type - TBD (IANA)from OSPF Extended Prefix Opaque LSA registry. 512 o Length - Total length of the value field in bytes (variable). 514 o PPR-Flags - 2 Octet flags for this TLV are described below. 516 o AF: Address family for the prefix. 518 o 520 AF: 0 - IPv4 unicast 522 AF: 1 - IPv6 unicast 524 o Reserved - 1 Octet reserved bits for future use. Reserved bits 525 MUST be reset on transmission and ignored on receive. 527 Flags: 2 octet field. The following flags are defined: 529 OSPFv3 PPR Flags Format 531 0 1 2 3 4 5 6 7 15 532 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 533 |IA|A | Rsrvd | 534 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 536 IA-Flag: Inter-Area flag. If set, advertisement is of inter-area 537 type. An ABR that is advertising the OSPF PPR TLV between areas 538 MUST set this bit. 539 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 541 A: The originator of the PPR TLV MUST set the A bit in order to 542 signal that the prefixes and PPR-IDs advertised in the PPR TLV are 543 directly connected to the originators. If this bit is not set, 544 this allows any other node in the network advertise this TLV on 545 behalf of the originating node of the "OSPF Prefix". If PPR TLV 546 is propagated to other areas the A-flag MUST be cleared. In case 547 if the originating node of the prefix has to be disambiguated for 548 any reason including, if it is a Multi Homed Prefix (MHP) or 549 propagated to a different OSPF area, then PPR-Attribute Sub-TLV 550 Source Router ID SHOULD be included. 552 Rsrvd - reserved bits for future use. Reserved bits MUST be reset 553 on transmission and ignored on receive. 555 3.1. OSPFv3 PPR-Prefix Sub-TLV 557 The structure of OSPFv3 PPR-Prefix, for which path description is 558 attached to is as follows: 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Type | Length | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Prefix Length | Mask Length | Reserved | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 // OSPFv3 Prefix (variable) // 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | PPR-Prefix Sub-TLVs (variable) | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 Figure 6: OSPFv3 PPR-Prefix Sub-TLV Format 574 o Type - TBD (See IANA for suggested value) from OSPFv3 PPR TLV 575 Section 3 Sub-TLV registry. 577 o Length - Total length of the value field in bytes (variable). 579 o Prefix Len - contains the length of the prefix in bits. Only the 580 most significant octets of the Prefix are encoded. 582 o Mask Length - The length of the prefix in bits. Only the most 583 significant octets of the Prefix are encoded. 585 o OSPFv3 Prefix - represents the OSPFv3 prefix at the tail-end of 586 the advertised PPR. For the address family IPv4 unicast, the 587 prefix itself is encoded as a 32-bit value. The default route is 588 represented by a prefix of length 0. For the address family (AF 589 in OSPFv3 PPR TLV) in IPv6 unicast, the prefix, encoded as an even 590 multiple of 32-bit words, padded with zeroed bits as necessary. 591 This encoding consumes ((PrefixLength + 31) / 32) 32-bit words. 593 o PPR-Prefix Sub-TLVs - TBD. It has 2 octet type, 2 octet length 594 and value field is defined per type. 596 3.2. OSPFv3 PPR-ID Sub-TLVs 598 This represents the actual data plane identifier in the packet and 599 could be of any data plane as defined in PPR-ID-type field. Both 600 OSPF Prefix and PPR-ID MUST belong to a same node in the network. 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Type | Length | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | PPR-ID Flags | PPR-ID Type | PPR-ID Length | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 |PPR-ID Mask Len| Algo | PPR-ID // 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 // PPR-ID (cont, variable size) // 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Figure 7: OSPFv3 PPR-ID Sub-TLV Format 616 o Type - TBD (See IANA for suggested value) from OSPFv3 PPR TLV 617 Section 3 Sub-TLV registry. 619 o Length - Total length of the value field in bytes (variable). 621 o PPR-ID Type - Data plane type of PPR-ID. This is a new registry 622 (TBD IANA) for this Sub-TLV and the defined types are as follows: 624 a. Type: 1 MPLS SID/Label 626 b. Type: 2 Native IPv4 Address/Prefix 628 c. Type: 3 Native IPv6 Address/Prefix 630 d. Type: 4 IPv6 SID in SRv6 with SRH 632 o PPR-ID Flags - 2 Octet field for PPR-ID flags: 634 PPR-ID Flags Format 636 0 1 2 3 4 5 6 7 15 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 |L|A| Rsrvd | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 1. L - If set, the PPR path is a Loose-PPR. If the flag is unset, 642 then the path described is a Strict-PPR. A Strict-PPR lists 643 every single node or adjacency in the path description from 644 source to the destination. 646 2. A - If set, all non-PPR path nodes in the OSPF area MUST add a 647 FIB entry for the PPR-ID with NH set to the shortest path NH for 648 the prefix being advertised. The use of this is TBD. By default 649 this MUST be unset. 651 3. Reserved - Reserved bits for future use. Reserved bits MUST be 652 reset on transmission and ignored on receive. 654 o PPR-ID Length - Length of the PPR-ID field in octets and this 655 depends on the PPR-ID type. See PPR-ID below for the length of 656 this field and other considerations. 658 o PPR-ID Mask Len - It is applicable for only for PPR-ID Type 2, 3 659 and 4. For Type 1 this value MUST be set to zero. It contains 660 the length of the PPR-ID Prefix in bits. Only the most 661 significant octets of the Prefix are encoded. This is needed, if 662 PPR-ID followed is an IPv4/IPv6 Prefix instead of 4/16 octet 663 Address respectively. 665 o Algo - 1 octet value represents the SPF algorithm. Algorithm 666 registry is as defined in 667 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 669 o PPR-ID - This is the Preferred Path forwarding identifier that 670 would be on the data packet. The value of this field is variable 671 and it depends on the PPR-ID Type - for Type 1, this is and MPLS 672 SID/Label. For Type 2 this is a 4 byte IPv4 address. For Type 3 673 this is a 16 byte IPv6 address. For Type 2 and Type 3 encoding is 674 similar to OSPF Prefix as specified in Section 2.2. For Type 4, 675 it is a 16 byte IPv6 SID. 677 3.3. OSPFv3 PPR-PDE Sub-TLV 679 This is a new Sub-TLV type in PPR TLV Section 3 and is called as PPR 680 Path Description Element (PDE). PPR-PDEs are used to describe the 681 path in the form of set of contiguous and ordered Sub-TLVs, where 682 first Sub-TLV represents (the top of the stack in MPLS data plane or) 683 first node/segment of the path. These set of ordered Sub-TLVs can 684 have both topological SIDs and non-topological SIDs (e.g., service 685 segments). 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Type | Length | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | PPR-PDE Type | PDE-ID Type | PDE-ID Len | Reserved | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | PPR-PDE Flags | PDE-ID Value // 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 // PDE-ID Value (Contd., Variable size) // 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | PPR-PDE Sub-TLVs (variable) | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 Figure 8: OSPFv3 PPR-PDE Sub-TLV Format 703 o Type - TBD (See IANA for suggested value) from OSPFv3 PPR TLV 704 Section 3 Sub-TLV registry. 706 o Length - Total length of the value field in bytes (variable). 708 o PPR-PDE Type - This is a new registry (TBD IANA) for this Sub-TLV 709 and the defined types are as follows: 711 a. Type: 1 Topological 713 b. Type: 2 Non-Topological 715 o PDE-ID Type - 1 Octet PDE-forwarding IDentifier Type. This is a 716 new registry (TBD IANA) for this Sub-TLV and the defined types and 717 corresponding PDE-ID Len, PDE-ID Value are as follows: 719 a. Type 1: SID/Label Sub-TLV as defined in 720 [I-D.ietf-ospf-segment-routing-extensions]. PED-ID Len and PDE- 721 ID Value fields are per Section 2.1 of the referenced document. 723 b. Type 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are same 724 as Type 1. 726 c. Type 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are 727 same as Type 1. 729 d. Type 4: IPv4 Address. PDE-ID Len is 4 bytes and PDE-ID Value is 730 4 bytes IPv4 address encoded similar to IPv4 Prefix described in 731 Section 2.2. 733 e. Type 5: IPv6 Address. PDE-ID Len is 16 bytes and PDE-ID Value is 734 16 bytes IPv6 address encoded similar to IPv6 Prefix described in 735 Section 2.2. 737 f. Type 6: SRv6 Node SID as defined in 738 [I-D.li-ospf-ospfv3-srv6-extensions]. PDE-ID Len and PDE-ID 739 Value are as defined in SRv6 SID. 741 g. Type 7: SRv6 Adjacency-SID. PDE-ID Len and PDE-ID Value are as 742 defined in Type 6. 744 o PDE-ID Len - 1 Octet. Length of PDE-ID field. 746 o Reserved - 1 Octet reserved bits for future use. Reserved bits 747 MUST be reset on transmission and ignored on receive. 749 o PPR-PDE Flags - 2 Octet flags for this TLV are described below: 751 PPR-PDE Flags Format 753 0 1 2 3 4 5 6 7... 15 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 |L|D| Rsrvd | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 1. L - This bit indicates the type of next "Topological PDE-ID" in 759 the path description and overrides the L bit in Section 3.2. If 760 set, the next PDE is Loose. If this flag is unset, the next 761 Topological PDE is Strict Type. 763 2. D - By default this bit MUST be unset. This bit MUST be set only 764 for PPR-PDE Type is Topological and this PDE represents the PDE- 765 ID corresponding to the PPR-Prefix Section 3.1. 767 3. Rsrvd - Reserved bits for future use. Reserved bits MUST be 768 reset on transmission and ignored on receive. 770 o PPR-PDE Sub-TLVs - TBD. It has 2 octet type, 2 octet length and 771 value field is defined per type. 773 3.4. OSPFv3 PPR-Attributes Sub-TLV 775 PPR-Attribute Sub-TLVs describe the attributes of the path. The 776 following Sub-TLVs draw from a new registry for Sub-TLV numbers; this 777 registry is to be created by IANA, and administered using the first 778 come first serve process: 780 o Type 1 (Suggested Value - IANA TBD): This is Packet Traffic 781 accounting Sub-TLV. Length 0 No value field. Specifies to create 782 a counter to count number of packets forwarded on this PPR-ID on 783 each node in the path description. 785 o Type 2 (Suggested Value - IANA TBD): This is Traffic statistics in 786 Bytes Sub-TLV. Length 0 No value field. Specifies to create a 787 counter to count number of bytes forwarded on this PPR-ID 788 specified in the network header (e.g. IPv4, IPv6) on each node in 789 the path description. 791 o Type 3 (Suggested Value - IANA TBD): PPR-Metric Sub-TLV. Length 4 792 bytes, and Value is metric of this path represented through the 793 PPR-ID. Different nodes can advertise the same PPR-ID for the 794 same Prefix with a different set of PPR-PDE Sub-TLVs and the 795 receiving node MUST consider the lowest metric value (TBD more, on 796 what happens when metric is same for two different set of PPR-PDE 797 Sub-TLVs). 799 4. Other Considerations 801 Please refer to [I-D.chunduri-isis-preferred-path-routing] section 4, 802 5, 6 and 7. 804 5. Acknowledgements 806 Thanks to Richard Li, Alex Clemm, Padma Pillay-Esnault, Toerless 807 Eckert, Kiran Makhijani and Lin Han for initial discussions on this 808 topic. Thanks to Kevin Smith and Stephen Johnson for various 809 deployment scenarios applicability from ETSI WGs perspective. 810 Authors also acknowledge Alexander Vainshtein for detailed 811 discussions and suggestions on this topic. 813 Earlier versions of draft-ietf-ospf-segment-routing-extensions have a 814 mechanism to advertise EROs through Binding SID. 816 6. IANA Considerations 818 This document requests the following new TLV in IANA OSPFv2 and 819 OSPFv3 TLV code-point registry as specified in Section 2 Section 3 820 respectively . 822 TLV # Name 823 ----- -------------- 824 TBD PPR TLV 826 This document also requests IANA to create new registries for PPR TLV 827 Flags field, PPR Flags, and PPR Sub-TLVs in PPR TLV as described in 828 Section 2 and Section 3. 830 7. Security Considerations 832 Existing security extensions as described in [RFC2328] and [RFC7684] 833 apply to the extensions specified in this document. While OSPF is 834 under a single administrative domain, there can be deployments where 835 potential attackers have access to one or more networks in the OSPF 836 routing domain. In these deployments, stronger authentication 837 mechanisms such as those specified in [RFC7474] SHOULD be used. 839 Advertisement of the additional information defined in this document 840 introduces no new security concerns in OSPF protocol. However as 841 this extension is related to SR-MPLS and SRH data planes as defined 842 in [I-D.ietf-spring-segment-routing], those particular data plane 843 security considerations does apply here. 845 8. References 847 8.1. Normative References 849 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 850 Requirement Levels", BCP 14, RFC 2119, 851 DOI 10.17487/RFC2119, March 1997, 852 . 854 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 855 DOI 10.17487/RFC2328, April 1998, 856 . 858 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 859 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 860 May 2017, . 862 8.2. Informative References 864 [I-D.chunduri-lsr-isis-preferred-path-routing] 865 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 866 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 867 draft-chunduri-lsr-isis-preferred-path-routing-01 (work in 868 progress), July 2018. 870 [I-D.ietf-6man-segment-routing-header] 871 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 872 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 873 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 874 progress), February 2019. 876 [I-D.ietf-ospf-ospfv3-lsa-extend] 877 Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. 878 Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- 879 lsa-extend-23 (work in progress), January 2018. 881 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 882 Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment 883 Routing", draft-ietf-ospf-ospfv3-segment-routing- 884 extensions-23 (work in progress), January 2019. 886 [I-D.ietf-ospf-segment-routing-extensions] 887 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 888 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 889 Extensions for Segment Routing", draft-ietf-ospf-segment- 890 routing-extensions-27 (work in progress), December 2018. 892 [I-D.ietf-spring-segment-routing] 893 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 894 Litkowski, S., and R. Shakir, "Segment Routing 895 Architecture", draft-ietf-spring-segment-routing-15 (work 896 in progress), January 2018. 898 [I-D.li-ospf-ospfv3-srv6-extensions] 899 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 900 "OSPFv3 Extensions for SRv6", draft-li-ospf- 901 ospfv3-srv6-extensions-02 (work in progress), September 902 2018. 904 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 905 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 906 RFC 4915, DOI 10.17487/RFC4915, June 2007, 907 . 909 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 910 "Security Extension for OSPFv2 When Using Manual Key 911 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 912 . 914 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 915 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 916 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 917 2015, . 919 Authors' Addresses 921 Uma Chunduri 922 Huawei USA 923 2330 Central Expressway 924 Santa Clara, CA 95050 925 USA 927 Email: uma.chunduri@huawei.com 929 Yingzhen Qu 930 Huawei USA 931 2330 Central Expressway 932 Santa Clara, CA 95050 933 USA 935 Email: yingzhen.qu@huawei.com 937 Russ White 938 Juniper Networks 939 Oak Island, NC 28465 940 USA 942 Email: russ@riw.us 944 Jeff Tantsura 945 Apstra Inc. 946 333 Middlefield Road 947 Menlo Park, CA 94025 948 USA 950 Email: jefftant.ietf@gmail.com 952 Luis M. Contreras 953 Telefonica 954 Sur-3 building, 3rd floor 955 Madrid 28050 956 Spain 958 Email: luismiguel.contrerasmurillo@telefonica.com