idnits 2.17.1 draft-chunduri-ospf-lsr-preferred-path-routing-00.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 == Line 262 has weird spacing: '...-Prefix sub-T...' == Line 573 has weird spacing: '...-Prefix sub-T...' -- The document date (June 18, 2018) is 2138 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: 'RFC 7794' is mentioned on line 801, but not defined == Missing Reference: 'I-D.chunduri-isis-preferred-path-routing' is mentioned on line 813, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-13 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-13 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-25 == Outdated reference: A later version (-07) exists of draft-li-ospf-ospfv3-srv6-extensions-01 Summary: 0 errors (**), 0 flaws (~~), 9 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: December 20, 2018 R. White 6 LinkedIn 7 J. Tantsura 8 Nuage Networks 9 L. Contreras 10 Telefonica 11 June 18, 2018 13 Preferred Path Routing (PPR) in OSPF 14 draft-chunduri-ospf-lsr-preferred-path-routing-00 16 Abstract 18 This document specifies a Preferred Path Routing (PPR) mechanism to 19 simplify the path description of data plane traffic in Segment 20 Routing (SR) deployments with OSPFv2 and OSPFv3 protocols. PPR aims 21 to mitigate the MTU and data plane processing issues that may result 22 from SR packet overheads; and also supports traffic measurement, 23 accounting statistics and further attribute extensions along the 24 paths. Preferred Path Routing is achieved through the addition of 25 descriptions to OSPF advertised prefixes, and mapping those to a PPR 26 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]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 20, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. OSPFv2 PPR TLV . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1. PPR-Flags . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.2. PPR-Prefix sub-TLV . . . . . . . . . . . . . . . . . . . 6 72 2.3. PPR-ID sub-TLV . . . . . . . . . . . . . . . . . . . . . 7 73 2.4. PPR-PDE sub-TLV . . . . . . . . . . . . . . . . . . . . . 8 74 2.5. PPR-Attributes sub-TLV . . . . . . . . . . . . . . . . . 10 75 3. OSPFv3 PPR TLV . . . . . . . . . . . . . . . . . . . . . . . 11 76 3.1. OSPFv3 PPR-Prefix sub-TLV . . . . . . . . . . . . . . . . 13 77 3.2. OSPFv3 PPR-ID sub-TLVs . . . . . . . . . . . . . . . . . 14 78 3.3. OSPFv3 PPR-PDE sub-TLV . . . . . . . . . . . . . . . . . 16 79 3.4. OSPFv3 PPR-Attributes sub-TLV . . . . . . . . . . . . . . 18 80 4. Other Considerations . . . . . . . . . . . . . . . . . . . . 18 81 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 86 8.2. Informative References . . . . . . . . . . . . . . . . . 20 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 89 1. Introduction 91 In a network implementing Segment Routing (SR), packets are steered 92 through the network using Segment Identifiers (SIDs) carried in the 93 packet header. Each SID uniquely identifies a segment as defined in 94 [I-D.ietf-spring-segment-routing]. SR capabilities are defined for 95 MPLS and IPv6 data planes called SR-MPLS and SRv6 respectively. 97 In SR-MPLS, a segment is encoded as a label and an ordered list of 98 segments is encoded as a stack of labels on the data packet. In 99 SRv6, a segment is encoded as an IPv6 address, with in a new type of 100 IPv6 hop-by-hop routing header/extension header (EH) called SRH 101 [I-D.ietf-6man-segment-routing-header], where an ordered list of IPv6 102 addresses/segments is encoded in SRH. 104 The issues caused by the large SID depth, and existing methods for 105 mitigation are introduced in [I.D. chunduri-lsr-isis-preferred-path- 106 routing] section 1.2 and 1.3. To mitigate these issues , and also to 107 facilitate forwarding plane a mechanism to identify the path with a 108 corresponding data plane identifier for accounting of traffic for SR 109 paths, this draft proposes a new OSPFv2 PPR TLV (Section 2), OSPFv3 110 PPR TLV (Section 3) to use the path with a corresponding data plane 111 identifier. 113 Preferred Path Routing means enabling route computation based on the 114 specific path described along with the prefix as opposed to shortest 115 path towards the prefix. 117 Any prefix advertised with a path description from any node in the 118 network is called Preferred Path Route. A PPR could be an SR path, 119 an explicitly provisioned Fast Re-Route (FRR) path or a service 120 chained path. A PPR can be signaled by any node, which receives the 121 SR path SR path computed by a central controller, or by operator by 122 statically configuring the same on a node in the network. 124 With corresponding data plane, Section 4 mechanism as in [I- 125 D.chunduri-isis-preferred-path-routing], reduces the SID stack in the 126 data plane with a single PPR ID. 128 1.1. Acronyms 130 EL - Entropy Label 132 ELI - Entropy Label Indicator 134 MPLS - Multi Protocol Label Switching 136 MSD - Maximum SID Depth 138 MTU - Maximum Transferrable Unit 140 NSP - Non Shortest Path 142 SID - Segment Identifier 144 SPF - Shortest Path First 145 SR - Segment Routing 147 SRH - Segment Routing Header 149 SR-MPLS - Segment Routing with MPLS data plane 151 SRv6 - Segment Routing with Ipv6 data plane with SRH 153 SRH - IPv6 Segment Routing Header 155 TE - Traffic Engineering 157 2. OSPFv2 PPR TLV 159 Extended Prefix Opaque LSAs defined in [RFC7684] are used for 160 advertisements of PPRs. This section describes the encoding of PPR 161 TLV. This TLV can be seen as having 4 logical section viz., encoding 162 of the OSPFv2 Prefix, encoding of PPR-ID, encoding of path 163 description with an ordered PDE sub-TLVs and a set of optional PPR 164 attribute sub-TLVs, which can be used to describe one or more 165 parameters of the path. Multiple OSPF PPR TLVs MAY be advertised in 166 each OSPF Extended Prefix Opaque LSA, but all TLVs included in a 167 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 168 scope. 170 The PPR TLV has Type TBD (suggested value xxx), and has the following 171 format: 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Type | Length | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | PPR-Flags | AF | Reserved | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | PPR-Prefix sub-TLV (variable size) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | PPR-ID sub-TLV (variable size) | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | PPR-PDE sub-TLVs (variable) | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | PPR-Attribute sub-TLVs(variable) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Figure 1: OSPFV2 PPR TLV Format 191 o Type - TBD (IANA)from OSPF Extended Prefix Opaque LSA registry. 193 o Length - Total length of the value field in bytes (variable). 195 o PPR-Flags - 2 Octet flags for this TLV are described below. 197 o AF - Address family for the prefix. Currently, the only supported 198 value is 0 for IPv4 unicast. The inclusion of address family in 199 this TLV allows for future extension. 201 o Reserved - 1 Octet reserved bits for future use. Reserved bits 202 MUST be reset on transmission and ignored on receive. 204 o PPR-Prefix - This is a variable size sub-TLV, which represents the 205 prefix for which path description is being attached to. This is 206 defined in Section 2.2. 208 o PPR-ID - This is a variable size sub-TLV, which represents the 209 data plane or forwarding identifier of the PPR. This is defined 210 in Section 2.3. 212 o PPR-PDEs - Variable number of ordered PDE sub-TLVs which 213 represents the path. This is defined in Section 2.4. 215 o PPR-Attributes - Variable number of PPR-Attribute sub-TLVs which 216 represent the path attributes. These are defined in Section 2.5. 218 2.1. PPR-Flags 220 Flags: 2 octet field of PPR TLV has following flags defined: 222 NSPF ID Flags Format 223 0 1 2 3 4 5 6 7 15 224 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 225 |IA|A | Rsrvd. | 226 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 228 w=Where: 230 IA-Flag: Inter-Area flag. If set, advertisement is of inter-area 231 type. An Area Boarder Router (ABR) that is advertising the OSPF 232 PPR TLV between areas MUST set this bit. 234 A: The originator of the PPR TLV MUST set the A bit in order to 235 signal that the prefixes and PPR-IDs advertised in the PPR TLV are 236 directly connected to the originators. If this bit is not set, 237 this allows any other node in the network advertise this TLV on 238 behalf of the originating node of the "OSPF Prefix". If PPR TLV 239 is propagated to other areas the A-flag MUST be cleared. In case 240 if the originating node of the prefix has to be disambiguated for 241 any reason including, if it is a Multi Homed Prefix (MHP) or 242 propagated to a different OSPF area, then PPR-Attribute sub-TLV 243 Source Router ID SHOULD be included. 245 Rsrvd: reserved bits for future use. Reserved bits MUST be reset 246 on transmission and ignored on receive. 248 2.2. PPR-Prefix sub-TLV 250 The structure of PPR-Prefix, for which path description is attached 251 to is as follows: 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Type | Length | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | MT-ID | Prefix Length | Mask Length | Reserved | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 // OSPFv2 Prefix (variable) // 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | PPR-Prefix sub-TLVs (variable) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 2: PPR-Prefix sub-TLV Format 267 o Type - TBD (See IANA for suggested value) from OSPFv2 PPR TLV 268 Section 2 sub-TLV registry. 270 o Length - Total length of the value field in bytes (variable). 272 o MT-ID - Multi-Topology ID (as defined in [RFC4915]). 274 o Prefix Len - contains the length of the prefix in bits. Only the 275 most significant octets of the Prefix are encoded. 277 o Mask Length - The length of the prefix in bits. Only the most 278 significant octets of the Prefix are encoded. 280 o OSPFv2 Prefix - represents the OSPFv2 prefix at the tail-end of 281 the advertised PPR. For the address family IPv4 unicast, the 282 prefix itself is encoded as a 32-bit value. The default route is 283 represented by a prefix of length 0. 285 o PPR-Prefix sub-TLVs - TBD. It has 2 octet type, 2 octet length 286 and value field is defined per type. 288 2.3. PPR-ID sub-TLV 290 This represents the actual data plane identifier in the packet and 291 could be of any data plane as defined in PPR-ID-type field. Both 292 OSPF Prefix and PPR-ID MUST belong to a same node in the network. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type | Length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | PPR-ID Flags | PPR-ID Type | PPR-ID Length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |PPR-ID Mask Len| Algo | PPR-ID // 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 // PPR-ID (cont., variable size) // 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Figure 3: PPR-ID sub-TLV Format 308 o Type - TBD (See IANA for suggested value) from OSPFv2 PPR TLV 309 Section 2 sub-TLV registry. 311 o Length - Total length of the value field in bytes (variable). 313 o PPR-ID Type - Data plane type of PPR-ID. This is a new registry 314 (TBD IANA) for this sub-TLV and the defined types are as follows: 316 a. Type: 1 MPLS SID/Label 318 b. Type: 2 Native IPv4 Address/Prefix 320 o PPR-ID Flags - 2 Octet field for PPR-ID flags: 322 PPR-ID Flags Format 324 0 1 2 3 4 5 6 7 15 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 |L|A| Rsrvd | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 1. L - If set, the PPR path is a Loose-PPR. If the flag is unset, 330 then the path described is a Strict-PPR. A Strict-PPR lists 331 every single node or adjacency in the path description from 332 source to the destination. 334 2. A - If set, all non-PPR path nodes in the OSPF area MUST add a 335 FIB entry for the PPR-ID with NH set to the shortest path NH for 336 the prefix being advertised. The use of this is TBD. By default 337 this MUST be unset. 339 3. Reserved - Reserved bits for future use. Reserved bits MUST be 340 reset on transmission and ignored on receive. 342 o PPR-ID Length - Length of the PPR-ID field in octets and this 343 depends on the PPR-ID type. See PPR-ID below for the length of 344 this field and other considerations. 346 o PPR-ID Mask Len - It is applicable for only for PPR-ID Type 2. 347 For Type 1 this value MUST be set to zero. It contains the length 348 of the PPR-ID Prefix in bits. Only the most significant octets of 349 the Prefix are encoded. This is needed, if PPR-ID followed is an 350 IPv4 Prefix instead of 4 octet Address respectively. 352 o Algo - 1 octet value represents the SPF algorithm. Algorithm 353 registry is as defined in 354 [I-D.ietf-ospf-segment-routing-extensions]. 356 o PPR-ID - This is the Preferred Path forwarding identifier that 357 would be on the data packet. The value of this field is variable 358 and it depends on the PPR-ID Type - for Type 1, this is and MPLS 359 SID/Label. For Type 2 this is a 4 byte IPv4 address. 361 2.4. PPR-PDE sub-TLV 363 This is a new sub-TLV type in PPR TLV Section 2 and is called as PPR 364 Path Description Element (PDE). PPR-PDEs are used to describe the 365 path in the form of set of contiguous and ordered sub-TLVs, where 366 first sub-TLV represents (the top of the stack in MPLS data plane or) 367 first node/segment of the path. These set of ordered sub-TLVs can 368 have both topological SIDs and non-topological SIDs (e.g., service 369 segments). 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Type | Length | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | PPR-PDE Type | PDE-ID Type | PDE-ID Len | Reserved | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | PPR-PDE Flags | PDE-ID Value // 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 // PDE-ID Value (Contd., Variable size) // 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | PPR-PDE sub-TLVs (variable) | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Figure 4: PPR-PDE sub-TLV Format 387 o Type - TBD (See IANA for suggested value) from OSPFv2 PPR TLV 388 Section 2 sub-TLV registry. 390 o Length - Total length of the value field in bytes (variable). 392 o PPR-PDE Type - This is a new registry (TBD IANA) for this sub-TLV 393 and the defined types are as follows: 395 a. Type: 1 Topological 397 b. Type: 2 Non-Topological 399 o PDE-ID Type - 1 Octet PDE-forwarding IDentifier Type. This is a 400 new registry (TBD IANA) for this sub-TLV and the defined types and 401 corresponding PDE-ID Len, PDE-ID Value are as follows: 403 a. Type 1: SID/Label sub-TLV as defined in 404 [I-D.ietf-ospf-segment-routing-extensions]. PDE-ID Len and PDE- 405 ID Value fields are per Section 2.1 of the referenced document. 407 b. Type 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are same 408 as Type 1. 410 c. Type 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are 411 same as Type 1. 413 d. Type 4: IPv4 Address. PDE-ID Len is 4 bytes and PDE-ID Value is 414 4 bytes IPv4 address encoded similar to IPv4 Prefix described in 415 Section 2.2. 417 o PDE-ID Len - 1 Octet. Length of PDE-ID field. 419 o Reserved - 1 Octet reserved bits for future use. Reserved bits 420 MUST be reset on transmission and ignored on receive. 422 o PPR-PDE Flags - 2 Octet flags for this TLV are described below: 424 PPR-PDE Flags Format 426 0 1 2 3 4 5 6 7... 15 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 |L|D| Rsrvd | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 1. L - This bit indicates the type of next "Topological PDE-ID" in 432 the path description and overrides the L bit in Section 2.3. If 433 set, the next PDE is Loose. If this flag is unset, the next 434 Topological PDE is Strict Type. 436 2. D - By default this bit MUST be unset. This bit MUST be set only 437 for PPR-PDE Type is Topological and this PDE represents the PDE- 438 ID corresponding to the PPR-Prefix Section 2.2. 440 3. Rsrvd - Reserved bits for future use. Reserved bits MUST be 441 reset on transmission and ignored on receive. 443 o PPR-PDE sub-TLVs - TBD. It has 2 octet type, 2 octet length and 444 value field is defined per type. 446 2.5. PPR-Attributes sub-TLV 448 PPR-Attribute sub-TLVs represent the attributes of the path 449 described. This is a new sub-TLV type (IANA TBD) in PPR TLV 450 Section 2. The following PPR-Attribute sub-TLVs (Type - IANA TBD) 451 are defined as follows: 453 o Type 4 (Suggested Value - IANA TBD): This is Packet Traffic 454 accounting sub-TLV. Length 0 No value field. Specifies to create 455 a counter to count number of packets forwarded on this PPR-ID on 456 each node in the path description. 458 o Type 5 (Suggested Value - IANA TBD): This is Traffic statistics in 459 Bytes sub-TLV. Length 0 No value field. Specifies to create a 460 counter to count number of bytes forwarded on this PPR-ID 461 specified in the network header (e.g. IPv4, IPv6) on each node in 462 the path description. 464 o Type 6 (Suggested Value - IANA TBD): This is PPR-Prefix 465 originating node's IPv4 Router ID sub-TLV. Length and Value field 466 are as specified in [RFC 7794] (TBD). 468 o Type 7 (Suggested Value - IANA TBD): This is PPR-Prefix 469 originating node's IPv6 Router ID sub-TLV. Length and Value field 470 are as specified in [RFC 7794] (TBD). 472 o Type 8 (Suggested Value - IANA TBD): PPR-Metric sub-TLV. Length 4 473 bytes, and Value is metric of this path represented through the 474 PPR-ID. Different nodes can advertise the same PPR-ID for the 475 same Prefix with a different set of PPR-PDE sub-TLVs and the 476 receiving node MUST consider the lowest metric value (TBD more, on 477 what happens when metric is same for two different set of PPR-PDE 478 sub-TLVs). 480 3. OSPFv3 PPR TLV 482 The OSPFv3 PPR TLV s a top level TLV of the following LSAs defined in 483 [I-D.ietf-ospf-ospfv3-lsa-extend]. 485 E-Intra-Area-Prefix-LSA 487 E-Inter-Area-Prefix-LSA 489 E-AS-External-LSA 491 E-Type-7-LSA 493 Multiple OSPFv3 PPR TLVs MAY be advertised in each LSA mentioned 494 above. The OSPFv3 PPR TLV has the following format: 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Type | Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | PPR-Flags | AF | Reserved | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | OSPFv3 PPR-Prefix sub-TLV (variable size) | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | PPR-ID sub-TLV (variable size) | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | PPR-PDE sub-TLVs (variable) | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | PPR-Attribute sub-TLVs(variable) | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 Figure 5: OSPFv3 PPR TLV Format 514 o Type - TBD (IANA)from OSPF Extended Prefix Opaque LSA registry. 516 o Length - Total length of the value field in bytes (variable). 518 o PPR-Flags - 2 Octet flags for this TLV are described below. 520 o AF: Address family for the prefix. 522 o 524 AF: 0 - IPv4 unicast 526 AF: 1 - IPv6 unicast 528 o Reserved - 1 Octet reserved bits for future use. Reserved bits 529 MUST be reset on transmission and ignored on receive. 531 Flags: 2 octet field. The following flags are defined: 533 OSPFv3 PPR Flags Format 535 0 1 2 3 4 5 6 7 15 536 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 537 |IA|A | Rsrvd | 538 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 540 IA-Flag: Inter-Area flag. If set, advertisement is of inter-area 541 type. An ABR that is advertising the OSPF PPR TLV between areas 542 MUST set this bit. 543 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 545 A: The originator of the PPR TLV MUST set the A bit in order to 546 signal that the prefixes and PPR-IDs advertised in the PPR TLV are 547 directly connected to the originators. If this bit is not set, 548 this allows any other node in the network advertise this TLV on 549 behalf of the originating node of the "OSPF Prefix". If PPR TLV 550 is propagated to other areas the A-flag MUST be cleared. In case 551 if the originating node of the prefix has to be disambiguated for 552 any reason including, if it is a Multi Homed Prefix (MHP) or 553 propagated to a different OSPF area, then PPR-Attribute sub-TLV 554 Source Router ID SHOULD be included. 556 Rsrvd - reserved bits for future use. Reserved bits MUST be reset 557 on transmission and ignored on receive. 559 3.1. OSPFv3 PPR-Prefix sub-TLV 561 The structure of OSPFv3 PPR-Prefix, for which path description is 562 attached to is as follows: 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Type | Length | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Prefix Length | Mask Length | Reserved | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 // OSPFv3 Prefix (variable) // 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | PPR-Prefix sub-TLVs (variable) | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Figure 6: OSPFv3 PPR-Prefix sub-TLV Format 578 o Type - TBD (See IANA for suggested value) from OSPFv3 PPR TLV 579 Section 3 sub-TLV registry. 581 o Length - Total length of the value field in bytes (variable). 583 o Prefix Len - contains the length of the prefix in bits. Only the 584 most significant octets of the Prefix are encoded. 586 o Mask Length - The length of the prefix in bits. Only the most 587 significant octets of the Prefix are encoded. 589 o OSPFv3 Prefix - represents the OSPFv3 prefix at the tail-end of 590 the advertised PPR. For the address family IPv4 unicast, the 591 prefix itself is encoded as a 32-bit value. The default route is 592 represented by a prefix of length 0. For the address family (AF 593 in OSPFv3 PPR TLV) in IPv6 unicast, the prefix, encoded as an even 594 multiple of 32-bit words, padded with zeroed bits as necessary. 595 This encoding consumes ((PrefixLength + 31) / 32) 32-bit words. 597 o PPR-Prefix sub-TLVs - TBD. It has 2 octet type, 2 octet length 598 and value field is defined per type. 600 3.2. OSPFv3 PPR-ID sub-TLVs 602 This represents the actual data plane identifier in the packet and 603 could be of any data plane as defined in PPR-ID-type field. Both 604 OSPF Prefix and PPR-ID MUST belong to a same node in the network. 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Type | Length | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | PPR-ID Flags | PPR-ID Type | PPR-ID Length | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 |PPR-ID Mask Len| Algo | PPR-ID // 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 // PPR-ID (cont, variable size) // 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Figure 7: OSPFv3 PPR-ID sub-TLV Format 620 o Type - TBD (See IANA for suggested value) from OSPFv3 PPR TLV 621 Section 3 sub-TLV registry. 623 o Length - Total length of the value field in bytes (variable). 625 o PPR-ID Type - Data plane type of PPR-ID. This is a new registry 626 (TBD IANA) for this sub-TLV and the defined types are as follows: 628 a. Type: 1 MPLS SID/Label 630 b. Type: 2 Native IPv4 Address/Prefix 632 c. Type: 3 Native IPv6 Address/Prefix 634 d. Type: 4 IPv6 SID in SRv6 with SRH 636 o PPR-ID Flags - 2 Octet field for PPR-ID flags: 638 PPR-ID Flags Format 640 0 1 2 3 4 5 6 7 15 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 |L|A| Rsrvd | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 1. L - If set, the PPR path is a Loose-PPR. If the flag is unset, 646 then the path described is a Strict-PPR. A Strict-PPR lists 647 every single node or adjacency in the path description from 648 source to the destination. 650 2. A - If set, all non-PPR path nodes in the OSPF area MUST add a 651 FIB entry for the PPR-ID with NH set to the shortest path NH for 652 the prefix being advertised. The use of this is TBD. By default 653 this MUST be unset. 655 3. Reserved - Reserved bits for future use. Reserved bits MUST be 656 reset on transmission and ignored on receive. 658 o PPR-ID Length - Length of the PPR-ID field in octets and this 659 depends on the PPR-ID type. See PPR-ID below for the length of 660 this field and other considerations. 662 o PPR-ID Mask Len - It is applicable for only for PPR-ID Type 2, 3 663 and 4. For Type 1 this value MUST be set to zero. It contains 664 the length of the PPR-ID Prefix in bits. Only the most 665 significant octets of the Prefix are encoded. This is needed, if 666 PPR-ID followed is an IPv4/IPv6 Prefix instead of 4/16 octet 667 Address respectively. 669 o Algo - 1 octet value represents the SPF algorithm. Algorithm 670 registry is as defined in 671 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 673 o PPR-ID - This is the Preferred Path forwarding identifier that 674 would be on the data packet. The value of this field is variable 675 and it depends on the PPR-ID Type - for Type 1, this is and MPLS 676 SID/Label. For Type 2 this is a 4 byte IPv4 address. For Type 3 677 this is a 16 byte IPv6 address. For Type 2 and Type 3 encoding is 678 similar to OSPF Prefix as specified in Section 2.2. For Type 4, 679 it is a 16 byte IPv6 SID. 681 3.3. OSPFv3 PPR-PDE sub-TLV 683 This is a new sub-TLV type in PPR TLV Section 3 and is called as PPR 684 Path Description Element (PDE). PPR-PDEs are used to describe the 685 path in the form of set of contiguous and ordered sub-TLVs, where 686 first sub-TLV represents (the top of the stack in MPLS data plane or) 687 first node/segment of the path. These set of ordered sub-TLVs can 688 have both topological SIDs and non-topological SIDs (e.g., service 689 segments). 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Type | Length | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | PPR-PDE Type | PDE-ID Type | PDE-ID Len | Reserved | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | PPR-PDE Flags | PDE-ID Value // 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 // PDE-ID Value (Contd., Variable size) // 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | PPR-PDE sub-TLVs (variable) | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Figure 8: OSPFv3 PPR-PDE sub-TLV Format 707 o Type - TBD (See IANA for suggested value) from OSPFv3 PPR TLV 708 Section 3 sub-TLV registry. 710 o Length - Total length of the value field in bytes (variable). 712 o PPR-PDE Type - This is a new registry (TBD IANA) for this sub-TLV 713 and the defined types are as follows: 715 a. Type: 1 Topological 717 b. Type: 2 Non-Topological 719 o PDE-ID Type - 1 Octet PDE-forwarding IDentifier Type. This is a 720 new registry (TBD IANA) for this sub-TLV and the defined types and 721 corresponding PDE-ID Len, PDE-ID Value are as follows: 723 a. Type 1: SID/Label sub-TLV as defined in 724 [I-D.ietf-ospf-segment-routing-extensions]. PED-ID Len and PDE- 725 ID Value fields are per Section 2.1 of the referenced document. 727 b. Type 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are same 728 as Type 1. 730 c. Type 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are 731 same as Type 1. 733 d. Type 4: IPv4 Address. PDE-ID Len is 4 bytes and PDE-ID Value is 734 4 bytes IPv4 address encoded similar to IPv4 Prefix described in 735 Section 2.2. 737 e. Type 5: IPv6 Address. PDE-ID Len is 16 bytes and PDE-ID Value is 738 16 bytes IPv6 address encoded similar to IPv6 Prefix described in 739 Section 2.2. 741 f. Type 6: SRv6 Node SID as defined in 742 [I-D.li-ospf-ospfv3-srv6-extensions]. PDE-ID Len and PDE-ID 743 Value are as defined in SRv6 SID. 745 g. Type 7: SRv6 Adjacency-SID. PDE-ID Len and PDE-ID Value are as 746 defined in Type 6. 748 o PDE-ID Len - 1 Octet. Length of PDE-ID field. 750 o Reserved - 1 Octet reserved bits for future use. Reserved bits 751 MUST be reset on transmission and ignored on receive. 753 o PPR-PDE Flags - 2 Octet flags for this TLV are described below: 755 PPR-PDE Flags Format 757 0 1 2 3 4 5 6 7... 15 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 |L|D| Rsrvd | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 1. L - This bit indicates the type of next "Topological PDE-ID" in 763 the path description and overrides the L bit in Section 3.2. If 764 set, the next PDE is Loose. If this flag is unset, the next 765 Topological PDE is Strict Type. 767 2. D - By default this bit MUST be unset. This bit MUST be set only 768 for PPR-PDE Type is Topological and this PDE represents the PDE- 769 ID corresponding to the PPR-Prefix Section 3.1. 771 3. Rsrvd - Reserved bits for future use. Reserved bits MUST be 772 reset on transmission and ignored on receive. 774 o PPR-PDE sub-TLVs - TBD. It has 2 octet type, 2 octet length and 775 value field is defined per type. 777 3.4. OSPFv3 PPR-Attributes sub-TLV 779 PPR-Attribute sub-TLVs represent the attributes of the path 780 described. This is a new sub-TLV type (IANA TBD) in PPR TLV 781 Section 3. The following PPR-Attribute sub-TLVs (Type - IANA TBD) 782 are defined as follows: 784 o Type 4 (Suggested Value - IANA TBD): This is Packet Traffic 785 accounting sub-TLV. Length 0 No value field. Specifies to create 786 a counter to count number of packets forwarded on this PPR-ID on 787 each node in the path description. 789 o Type 5 (Suggested Value - IANA TBD): This is Traffic statistics in 790 Bytes sub-TLV. Length 0 No value field. Specifies to create a 791 counter to count number of bytes forwarded on this PPR-ID 792 specified in the network header (e.g. IPv4, IPv6) on each node in 793 the path description. 795 o Type 6 (Suggested Value - IANA TBD): This is PPR-Prefix 796 originating node's IPv4 Router ID sub-TLV. Length and Value field 797 are as specified in [RFC 7794] (TBD). 799 o Type 7 (Suggested Value - IANA TBD): This is PPR-Prefix 800 originating node's IPv6 Router ID sub-TLV. Length and Value field 801 are as specified in [RFC 7794] (TBD). 803 o Type 8 (Suggested Value - IANA TBD): PPR-Metric sub-TLV. Length 4 804 bytes, and Value is metric of this path represented through the 805 PPR-ID. Different nodes can advertise the same PPR-ID for the 806 same Prefix with a different set of PPR-PDE sub-TLVs and the 807 receiving node MUST consider the lowest metric value (TBD more, on 808 what happens when metric is same for two different set of PPR-PDE 809 sub-TLVs). 811 4. Other Considerations 813 Please refer to [I-D.chunduri-isis-preferred-path-routing] section 3, 814 4 and 5. 816 5. Acknowledgements 818 Thanks to Richard Li, Alex Clemm, Toerless Eckert, Kiran Makhijani 819 and Lin Han for initial discussions on this topic. Thanks to Kevin 820 Smith and Stephen Johnson for various deployment scenarios 821 applicability from ETSI WGs perspective. Authors also acknowledge 822 Alexander Vainshtein for detailed discussions and suggestions on this 823 topic. 825 Earlier versions of draft-ietf-ospf-segment-routing-extensions have a 826 mechanism to advertise EROs through Binding SID. 828 6. IANA Considerations 830 This document requests the following new TLV in IANA OSPFv2 and 831 OSPFv3 TLV code-point registry. 833 TLV # Name 834 ----- -------------- 835 TBD PPR TLV 837 This document also requests IANA to create new registries for PPR TLV 838 Flags field, PPR Flags, and PPR sub-TLVs in PPR TLV as described in 839 Section 2 and Section 3. 841 7. Security Considerations 843 Existing security extensions as described in [RFC2328] and [RFC7684] 844 apply to these segment routing extensions. While OSPF is under a 845 single administrative domain, there can be deployments where 846 potential attackers have access to one or more networks in the OSPF 847 routing domain. In these deployments, stronger authentication 848 mechanisms such as those specified in [RFC7474] SHOULD be used. 850 Advertisement of the additional information defined in this document 851 introduces no new security concerns in OSPF protocol. However as 852 this extension is related to SR-MPLS and SRH data planes as defined 853 in [I-D.ietf-spring-segment-routing], those particular data plane 854 security considerations does apply here. 856 8. References 858 8.1. Normative References 860 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 861 Requirement Levels", BCP 14, RFC 2119, 862 DOI 10.17487/RFC2119, March 1997, 863 . 865 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 866 DOI 10.17487/RFC2328, April 1998, 867 . 869 8.2. Informative References 871 [I-D.ietf-6man-segment-routing-header] 872 Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and 873 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 874 (SRH)", draft-ietf-6man-segment-routing-header-13 (work in 875 progress), May 2018. 877 [I-D.ietf-ospf-ospfv3-lsa-extend] 878 Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. 879 Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- 880 lsa-extend-23 (work in progress), January 2018. 882 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 883 Psenak, P., Filsfils, C., Previdi, S., Gredler, H., 884 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 885 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 886 segment-routing-extensions-13 (work in progress), May 887 2018. 889 [I-D.ietf-ospf-segment-routing-extensions] 890 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 891 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 892 Extensions for Segment Routing", draft-ietf-ospf-segment- 893 routing-extensions-25 (work in progress), April 2018. 895 [I-D.ietf-spring-segment-routing] 896 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 897 Litkowski, S., and R. Shakir, "Segment Routing 898 Architecture", draft-ietf-spring-segment-routing-15 (work 899 in progress), January 2018. 901 [I-D.li-ospf-ospfv3-srv6-extensions] 902 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 903 "OSPFv3 Extensions for SRv6", draft-li-ospf- 904 ospfv3-srv6-extensions-01 (work in progress), March 2018. 906 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 907 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 908 RFC 4915, DOI 10.17487/RFC4915, June 2007, 909 . 911 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 912 "Security Extension for OSPFv2 When Using Manual Key 913 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 914 . 916 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 917 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 918 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 919 2015, . 921 Authors' Addresses 923 Uma Chunduri 924 Huawei USA 925 2330 Central Expressway 926 Santa Clara, CA 95050 927 USA 929 Email: uma.chunduri@huawei.com 931 Yingzhen Qu 932 Huawei USA 933 2330 Central Expressway 934 Santa Clara, CA 95050 935 USA 937 Email: yingzhen.qu@huawei.com 939 Russ White 940 LinkedIn 941 Oak Island, NC 28465 942 USA 944 Email: russ@riw.us 946 Jeff Tantsura 947 Nuage Networks 948 755 Ravendale Drive 949 Mountain View, CA 94043 950 USA 952 Email: jefftant.ietf@gmail.com 953 Luis M. Contreras 954 Telefonica 955 Sur-3 building, 3rd floor 956 Madrid 28050 957 Spain 959 Email: luismiguel.contrerasmurillo@telefonica.com