idnits 2.17.1 draft-chunduri-lsr-ospf-preferred-path-routing-03.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 (May 16, 2019) is 1800 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 831, but not defined == Outdated reference: A later version (-08) exists of draft-chunduri-lsr-isis-preferred-path-routing-02 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-18 == Outdated reference: A later version (-07) exists of draft-li-ospf-ospfv3-srv6-extensions-03 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: November 17, 2019 R. White 6 Juniper Networks 7 J. Tantsura 8 Apstra Inc. 9 L. Contreras 10 Telefonica 11 May 16, 2019 13 Preferred Path Routing (PPR) in OSPF 14 draft-chunduri-lsr-ospf-preferred-path-routing-03 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 further extensions along the paths. Preferred path routing is 24 achieved through the addition of path descriptions to the OSPF 25 advertised prefixes, and mapping those to a PPR data-plane 26 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 November 17, 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 . . . . . . . . . . . . . . . . . 11 78 3. OSPFv3 PPR TLV . . . . . . . . . . . . . . . . . . . . . . . 12 79 3.1. OSPFv3 PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . 13 80 3.2. OSPFv3 PPR-ID Sub-TLVs . . . . . . . . . . . . . . . . . 14 81 3.3. OSPFv3 PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . 16 82 3.4. OSPFv3 PPR-Attributes Sub-TLV . . . . . . . . . . . . . . 19 83 4. Other Considerations . . . . . . . . . . . . . . . . . . . . 19 84 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 89 8.2. Informative References . . . . . . . . . . . . . . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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 Preferred path routing cab be described as a) enabling route 108 computation based on the specific path described along with the 109 prefix as opposed to shortest path towards the prefix and b) 110 forwarding based on the abstracted path identifier as opposed to the 111 individual segments on the packet. This also further described in 112 Section 2 of [I-D.chunduri-lsr-isis-preferred-path-routing]. 114 Any prefix advertised with a path description from any node in the 115 network is called PPR. A PPR could be an SR path, an explicitly 116 provisioned Fast Re-Route (FRR) path or a service chained path. A 117 PPR can be signaled by any node, which receives the SR path computed 118 by a central controller, or by statically configuring the same on a 119 node in the network. 121 The issues caused by the large SID depth, and existing methods for 122 mitigation are introduced in 123 [I-D.chunduri-lsr-isis-preferred-path-routing] in Appendix A.1 and 124 A.2. To mitigate these issues and also to facilitate forwarding 125 plane extensibility, this draft proposes a new OSPFv2 PPR TLV 126 (Section 2), OSPFv3 PPR TLV (Section 3) to use the path with a 127 corresponding data plane identifier. 129 1.1. Acronyms 131 EL - Entropy Label 133 ELI - Entropy Label Indicator 135 MPLS - Multi Protocol Label Switching 137 MSD - Maximum SID Depth 139 MTU - Maximum Transferrable Unit 140 PPR - Preferred Path Route 142 SID - Segment Identifier 144 SPF - Shortest Path First 146 SR - Segment Routing 148 SRH - Segment Routing Header 150 SR-MPLS - Segment Routing with MPLS data plane 152 SRv6 - Segment Routing with Ipv6 data plane with SRH 154 SRH - IPv6 Segment Routing Header 156 TE - Traffic Engineering 158 2. OSPFv2 PPR TLV 160 Extended Prefix Opaque LSAs defined in [RFC7684] are used for 161 advertisements of PPRs. This section describes the encoding of PPR 162 TLV. This TLV can be seen as having 4 logical section viz., encoding 163 of the OSPFv2 Prefix, encoding of PPR-ID, encoding of path 164 description with an ordered PDE Sub-TLVs and a set of optional PPR 165 attribute Sub-TLVs, which can be used to describe one or more 166 parameters of the path. Multiple OSPF PPR TLVs MAY be advertised in 167 each OSPF Extended Prefix Opaque LSA, but all TLVs included in a 168 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 169 scope. 171 The PPR TLV has Type TBD (suggested value xxx), and has the following 172 format: 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Type | Length | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | PPR-Flags | AF | Reserved | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | PPR-Prefix Sub-TLV (variable size) | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | PPR-ID Sub-TLV (variable size) | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | PPR-PDE Sub-TLVs (variable) | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | PPR-Attribute Sub-TLVs(variable) | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Figure 1: OSPFV2 PPR TLV Format 192 o Type - TBD (IANA)from OSPF Extended Prefix Opaque LSA registry. 194 o Length - Total length of the value field in bytes (variable). 196 o PPR-Flags - 2 Octet flags for this TLV are described below. 198 o AF - Address family for the prefix. Currently, the only supported 199 value is 0 for IPv4 unicast. The inclusion of address family in 200 this TLV allows for future extension. 202 o Reserved - 1 Octet reserved bits for future use. Reserved bits 203 MUST be reset on transmission and ignored on receive. 205 o PPR-Prefix - This is a variable size Sub-TLV, which represents the 206 prefix for which path description is being attached to. This is 207 defined in Section 2.2. 209 o PPR-ID - This is a variable size Sub-TLV, which represents the 210 data plane or forwarding identifier of the PPR. This is defined 211 in Section 2.3. 213 o PPR-PDEs - Variable number of ordered PDE Sub-TLVs which 214 represents the path. This is defined in Section 2.4. 216 o PPR-Attributes - Variable number of PPR-Attribute Sub-TLVs which 217 represent the path attributes. These are defined in Section 2.5. 219 2.1. PPR-Flags 221 Flags: 2 octet field of PPR TLV has following flags defined: 223 PPR TLV Flags Format 224 0 1 2 3 4 5 6 7 15 225 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 226 |IA|A | Reserved | 227 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 229 w=Where: 231 IA-Flag: Inter-Area flag. If set, advertisement is of inter-area 232 type. An Area Boarder Router (ABR) that is advertising the OSPF 233 PPR TLV between areas MUST set this bit. 235 A: The originator of the PPR TLV MUST set the A bit in order to 236 signal that the prefixes and PPR-IDs advertised in the PPR TLV are 237 directly connected to the originators. If this bit is not set, 238 this allows any other node in the network advertise this TLV on 239 behalf of the originating node of the "OSPF Prefix". If PPR TLV 240 is propagated to other areas the A-flag MUST be cleared. In case 241 if the originating node of the prefix has to be disambiguated for 242 any reason including, if it is a Multi Homed Prefix (MHP) or 243 propagated to a different OSPF area, then PPR-Attribute Sub-TLV 244 Source Router ID SHOULD be included. 246 Reserved: Reserved bits for future use. Reserved bits MUST be 247 reset on transmission and ignored on receive. 249 PPR path description for each OSPF area is computed and given to one 250 of the nodes in that area for dissemination. Similarly path 251 information when crossing the area boundaries MUST be relevant to the 252 destination area. If there is no path information available for the 253 destination area, PPR TLV MUST NOT be leaked regardless of the IA bit 254 status. 256 2.2. PPR-Prefix Sub-TLV 258 The structure of PPR-Prefix, for which path description is attached 259 to is as follows: 261 0 1 2 3 262 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type | Length | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | MT-ID | Prefix Length | Mask Length | Reserved | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 // OSPFv2 Prefix (variable) // 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | PPR-Prefix Sub-TLVs (variable) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 2: PPR-Prefix Sub-TLV Format 275 o Type - 1 (suggested value, IANA TBD) from OSPFv2 PPR TLV Section 2 276 Sub-TLV registry. 278 o Length - Total length of the value field in bytes (variable). 280 o MT-ID - Multi-Topology ID (as defined in [RFC4915]). 282 o Prefix Len - contains the length of the OSPF prefix being encoded 283 in bytes. 285 o Mask Length - The length of the prefix in bits. Only the most 286 significant octets of the Prefix are encoded. 288 o OSPFv2 Prefix - represents the OSPFv2 prefix at the tail-end of 289 the advertised PPR. For the address family IPv4 unicast, the 290 prefix itself is encoded as a 32-bit value. The default route is 291 represented by a prefix of length 0. 293 o PPR-Prefix Sub-TLVs have2 octet type, 2 octet length and value 294 field is defined per type. 296 2.3. PPR-ID Sub-TLV 298 This represents the actual data plane identifier in the packet and 299 could be of any data plane as defined in PPR-ID-type field. Both 300 OSPF Prefix and PPR-ID MUST belong to a same node in the network. 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Type | Length | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | PPR-ID Flags | PPR-ID Type | PPR-ID Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 |PPR-ID Mask Len| Algo | PPR-ID // 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 // PPR-ID (cont., variable size) // 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Figure 3: PPR-ID Sub-TLV Format 316 o Type - 2 (suggested value, IANA TBD) from OSPFv2 PPR TLV Section 2 317 Sub-TLV registry. 319 o Length - Total length of the value field in bytes (variable). 321 o PPR-ID Type - Data plane type of PPR-ID. This is a new registry 322 (TBD IANA) for this Sub-TLV and the defined types are as follows: 324 Type: 1 SR-MPLS SID/Label 326 Type: 2 Native IPv4 Address/Prefix 328 o PPR-ID Flags - 2 Octet field for PPR-ID flags: 330 PPR-ID Flags Format 332 0 1 2 3 4 5 6 7 15 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Reserved | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Reserved - Reserved bits for future use. Reserved bits MUST be 338 reset on transmission and ignored on receive. 340 o PPR-ID Type - Data plane type of PPR-ID. Values are defined in 341 [I-D.chunduri-lsr-isis-preferred-path-routing]. Only Type 1 and 342 Type 2 are applicable here. 344 o PPR-ID Length - Length of the PPR-ID field in octets and this 345 depends on the PPR-ID type. See PPR-ID below for the length of 346 this field and other considerations. 348 o PPR-ID Mask Len - It is applicable for only for PPR-ID Type 2. 349 For Type 1 this value MUST be set to zero. It contains the length 350 of the PPR-ID Prefix in bits. Only the most significant octets of 351 the Prefix are encoded. This is needed, if PPR-ID followed is an 352 IPv4 Prefix instead of 4 octet Address respectively. 354 o Algo - 1 octet value represents the SPF algorithm. Algorithm 355 registry is as defined in 356 [I-D.ietf-ospf-segment-routing-extensions]. 358 o PPR-ID - This is the Preferred Path forwarding identifier that 359 would be on the data packet. The value of this field is variable 360 and it depends on the PPR-ID Type - for Type 1, this is encoded as 361 SR-MPLS SID/Label. For Type 2 this is a 4 byte IPv4 address 362 encoded similar to PPR-Prefix. 364 2.4. PPR-PDE Sub-TLV 366 This is a new Sub-TLV type in PPR TLV Section 2 and is called as PPR 367 Path Description Element (PDE). PPR-PDEs are used to describe the 368 path in the form of set of contiguous and ordered Sub-TLVs, where 369 first Sub-TLV represents (the top of the stack in MPLS data plane or) 370 first node/segment of the path. These set of ordered Sub-TLVs can 371 have both topological SIDs and non-topological SIDs (e.g., service 372 segments). 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type | Length | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | PPR-PDE Type | PDE-ID Type | PDE-ID Len | Reserved | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | PPR-PDE Flags | PDE-ID Value // 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 // PDE-ID Value (Contd., Variable size) // 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | PPR-PDE Sub-TLVs (variable) | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Figure 4: PPR-PDE Sub-TLV Format 390 o Type - 3 (TBD IANA, suggested value) from OSPFv2 PPR TLV Section 2 391 Sub-TLV registry. 393 o Length - Total length of the value field in bytes (variable). 395 o PPR-PDE Type - This is a new registry (TBD IANA) for this Sub-TLV 396 and the defined types are as follows: 398 Type: 1 Topological 400 Type: 2 Non-Topological 402 o PDE-ID Type - 1 Octet PDE-forwarding IDentifier Type. This is a 403 new registry (TBD IANA) for this Sub-TLV and the defined types and 404 corresponding PDE-ID Len, PDE-ID Value are as follows: 406 Type 0: This value MUST be set only when PPR-PDE Type is Non- 407 Topological. PDE-ID Len specified in bytes and encoded in NBO 408 in PDE-ID Value field which can represent a service/function. 409 This information is provisioned on the immediate topological PDE 410 preceding to this PDE based on the 'E' bit. 412 Type 1: SID/Label Sub-TLV as defined in 413 [I-D.ietf-ospf-segment-routing-extensions]. PDE-ID Len and PDE- 414 ID Value fields are per Section 2.1 of the referenced document. 416 Type 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are 417 same as Type 1. 419 Type 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are 420 same as Type 1. 422 Type 4: IPv4 Node Address. PDE-ID Len is 4 bytes and PDE-ID 423 Value is 4 bytes IPv4 address encoded similar to IPv4 Prefix 424 described in Section 2.2. 426 Type 5: IPv4 P2P interface Address. PDE-ID Len is 4 bytes and 427 PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4 428 Prefix described in Section 2.2. 430 Type 6: IPv4 LAN interface Address. PDE-ID Len is 4 bytes and 431 PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4 432 Prefix described in Section 2.2. This type MUST have OSPF 433 Neighbor ID sub-TLV in the PDE. 435 o PDE-ID Len - 1 Octet. Length of PDE-ID field. 437 o Reserved - 1 Octet reserved bits for future use. Reserved bits 438 MUST be reset on transmission and ignored on receive. 440 o PPR-PDE Flags - 2 Octet flags for this TLV are described below: 442 PPR-PDE Flags Format 444 0 1 2 3 4 5 6 7... 15 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 |L|D|E| Reserved | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 L: Loose Bit: This bit indicates the type of next "Topological 450 PDE-ID" in the path description. If set, the next PDE is Loose. 451 If this flag is unset, the next Topological PDE is Strict Type. 453 D: Destination Bit: By default this bit MUST be unset. This bit 454 MUST be set only for PPR-PDE Type is Topological and this PDE 455 represents the PDE-ID corresponding to the PPR-Prefix 456 Section 2.2. 458 E: Egress Bit. By default this bit MUST be unset. This bit MUST 459 be set only for PPR-PDE Type is 2 i.e., Non-Topological and the 460 service needs to be applied on the egress side of the 461 topological PDE preceding this PDE. 463 Reserved: Reserved bits for future use. Reserved bits MUST be 464 reset on transmission and ignored on receive. 466 o PPR-PDE Sub-TLVs have 2 octet type, 2 octet length and value field 467 is defined per type. 469 o PPR-PDE Sub-TLV: Type 4 (IANA TBD), Length Total length of value 470 field in bytes, Value: The Router ID of the neighbor for which the 471 LAN interface is advertised. This Sub-TLV MUST NOT be present, if 472 the PPR-PDE Type is not equal to 1 i.e., Topological PDE and PDE- 473 ID Type 6. 475 2.5. PPR-Attributes Sub-TLV 477 PPR-Attribute Sub-TLVs describe the attributes of the path. The 478 following Sub-TLVs draw from a new registry for Sub-TLV numbers; this 479 registry is to be created by IANA, and administered using the first 480 come first serve process: 482 o Type 1 (Suggested Value, IANA TBD): PPR-Metric Sub-TLV. Length 4 483 bytes, and Value is metric of this path represented through the 484 PPR-ID. Different nodes can advertise the same PPR-ID for the 485 same Prefix with a different set of PPR-PDE Sub-TLVs and the 486 receiving node MUST consider the lowest metric value. 488 3. OSPFv3 PPR TLV 490 The OSPFv3 PPR TLV s a top level TLV of the following LSAs defined in 491 [I-D.ietf-ospf-ospfv3-lsa-extend]. 493 E-Intra-Area-Prefix-LSA 495 E-Inter-Area-Prefix-LSA 497 E-AS-External-LSA 499 E-Type-7-LSA 501 Multiple OSPFv3 PPR TLVs MAY be advertised in each LSA mentioned 502 above. The OSPFv3 PPR TLV has the following format: 504 0 1 2 3 505 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 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Type | Length | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | PPR-Flags | AF | Reserved | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | OSPFv3 PPR-Prefix Sub-TLV (variable size) | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | PPR-ID Sub-TLV (variable size) | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | PPR-PDE Sub-TLVs (variable) | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | PPR-Attribute Sub-TLVs(variable) | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Figure 5: OSPFv3 PPR TLV Format 522 o Type - TBD (IANA)from OSPF Extended Prefix Opaque LSA registry. 524 o Length - Total length of the value field in bytes (variable). 526 o PPR-Flags - 2 Octet flags for this TLV are described below. 528 o AF: Address family for the prefix. 530 AF: 0 - IPv4 unicast 532 AF: 1 - IPv6 unicast 534 o Reserved - 1 Octet reserved bits for future use. Reserved bits 535 MUST be reset on transmission and ignored on receive. 537 Flags: 2 octet field. The following flags are defined: 539 OSPFv3 PPR TLV Flags Format 541 0 1 2 3 4 5 6 7 15 542 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 543 |IA|A | Reserved | 544 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 546 IA-Flag: Inter-Area flag. If set, advertisement is of inter-area 547 type. An ABR that is advertising the OSPF PPR TLV between areas 548 MUST set this bit. 549 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 551 A: The originator of the PPR TLV MUST set the A bit in order to 552 signal that the prefixes and PPR-IDs advertised in the PPR TLV are 553 directly connected to the originators. If this bit is not set, 554 this allows any other node in the network advertise this TLV on 555 behalf of the originating node of the "OSPF Prefix". If PPR TLV 556 is propagated to other areas the A-flag MUST be cleared. In case 557 if the originating node of the prefix has to be disambiguated for 558 any reason including, if it is a Multi Homed Prefix (MHP) or 559 propagated to a different OSPF area, then PPR-Attribute Sub-TLV 560 Source Router ID SHOULD be included. 562 Reserved - reserved bits for future use. Reserved bits MUST be 563 reset on transmission and ignored on receive. 565 PPR path description for each OSPF area is computed and given to one 566 of the nodes in that area for dissemination. Similarly path 567 information when crossing the area boundaries MUST be relevant to the 568 destination area. If there is no path information available for the 569 destination area, PPR TLV MUST NOT be leaked regardless of the IA bit 570 status. 572 3.1. OSPFv3 PPR-Prefix Sub-TLV 574 The structure of OSPFv3 PPR-Prefix, for which path description is 575 attached to is as follows: 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Type | Length | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Prefix Length | Mask Length | Reserved | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 // OSPFv3 Prefix (variable) // 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | PPR-Prefix Sub-TLVs (variable) | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 Figure 6: OSPFv3 PPR-Prefix Sub-TLV Format 591 o Type - 1 (suggested value, IANA TBD) from OSPFv3 PPR TLV Section 3 592 Sub-TLV registry. 594 o Length - Total length of the value field in bytes (variable). 596 o Prefix Len - contains the length of the prefix in bits. Only the 597 most significant octets of the Prefix are encoded. 599 o Mask Length - The length of the prefix in bits. Only the most 600 significant octets of the Prefix are encoded. 602 o OSPFv3 Prefix - represents the OSPFv3 prefix at the tail-end of 603 the advertised PPR. For the address family IPv4 unicast, the 604 prefix itself is encoded as a 32-bit value. The default route is 605 represented by a prefix of length 0. For the address family (AF 606 in OSPFv3 PPR TLV) in IPv6 unicast, the prefix, encoded as an even 607 multiple of 32-bit words, padded with zeroed bits as necessary. 608 This encoding consumes ((PrefixLength + 31) / 32) 32-bit words. 610 o PPR-Prefix Sub-TLVs have2 octet type, 2 octet length and value 611 field is defined per type. 613 3.2. OSPFv3 PPR-ID Sub-TLVs 615 This represents the actual data plane identifier in the packet and 616 could be of any data plane as defined in PPR-ID-type field. Both 617 OSPF Prefix and PPR-ID MUST belong to a same node in the network. 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Type | Length | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | PPR-ID Flags | PPR-ID Type | PPR-ID Length | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 |PPR-ID Mask Len| Algo | PPR-ID // 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 // PPR-ID (cont, variable size) // 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Figure 7: OSPFv3 PPR-ID Sub-TLV Format 633 o Type - 2 (suggested value, IANA TBD) from OSPFv3 PPR TLV Section 3 634 Sub-TLV registry. 636 o Length - Total length of the value field in bytes (variable). 638 o PPR-ID Type - Data plane type of PPR-ID. This is a new registry 639 (TBD IANA) for this Sub-TLV and the defined types are as follows: 641 Type: 1 SR-MPLS SID/Label 643 Type: 2 Native IPv4 Address/Prefix 645 Type: 3 Native IPv6 Address/Prefix 647 Type: 4 IPv6 SID in SRv6 with SRH 649 o PPR-ID Flags - 2 Octet field for PPR-ID flags: 651 PPR-ID Flags Format 653 0 1 2 3 4 5 6 7 15 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 |L|A| Reserved | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 Reserved - Reserved bits for future use. Reserved bits MUST be 659 reset on transmission and ignored on receive. 661 o PPR-ID Length - Length of the PPR-ID field in octets and this 662 depends on the PPR-ID type. See PPR-ID below for the length of 663 this field and other considerations. 665 o PPR-ID Mask Len - It is applicable for only for PPR-ID Type 2, 3 666 and 4. For Type 1 this value MUST be set to zero. It contains 667 the length of the PPR-ID Prefix in bits. Only the most 668 significant octets of the Prefix are encoded. This is needed, if 669 PPR-ID followed is an IPv4/IPv6 Prefix instead of 4/16 octet 670 Address respectively. 672 o Algo - 1 octet value represents the SPF algorithm. Algorithm 673 registry is as defined in 674 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 676 o PPR-ID - This is the Preferred Path forwarding identifier that 677 would be on the data packet. The value of this field is variable 678 and it depends on the PPR-ID Type - for Type 1, this is encoded as 679 SR-MPLS SID/Label. For Type 2 this is encoded as 4 byte IPv4 680 address. For Type 3 this is encoded as 16 byte IPv6 address. For 681 Type 2 and Type 3 encoding is similar to OSPF Prefix as specified 682 in Section 2.2. For Type 4, this is encoded as 16 byte IPv6 SID. 684 3.3. OSPFv3 PPR-PDE Sub-TLV 686 This is a new Sub-TLV type in PPR TLV Section 3 and is called as PPR 687 Path Description Element (PDE). PPR-PDEs are used to describe the 688 path in the form of set of contiguous and ordered Sub-TLVs, where 689 first Sub-TLV represents (the top of the stack in MPLS data plane or) 690 first node/segment of the path. These set of ordered Sub-TLVs can 691 have both topological SIDs and non-topological SIDs (e.g., service 692 segments). 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Type | Length | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | PPR-PDE Type | PDE-ID Type | PDE-ID Len | Reserved | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | PPR-PDE Flags | PDE-ID Value // 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 // PDE-ID Value (Contd., Variable size) // 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | PPR-PDE Sub-TLVs (variable) | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 Figure 8: OSPFv3 PPR-PDE Sub-TLV Format 710 o Type - 3 (suggested value, IANA TBD) from OSPFv3 PPR TLV Section 3 711 Sub-TLV registry. 713 o Length - Total length of the value field in bytes (variable). 715 o PPR-PDE Type - This is a new registry (TBD IANA) for this Sub-TLV 716 and the defined types are as follows: 718 Type: 1 Topological 720 Type: 2 Non-Topological 722 o PDE-ID Type - 1 Octet PDE-forwarding IDentifier Type. This is a 723 new registry (TBD IANA) for this Sub-TLV and the defined types and 724 corresponding PDE-ID Len, PDE-ID Value are as follows: 726 Type 0: This value MUST be set only when PPR-PDE Type is Non- 727 Topological. PDE-ID Len specified in bytes and encoded in NBO 728 in PDE-ID Value field which can represent a service/function. 729 This information is provisioned on the immediate topological PDE 730 preceding to this PDE based on the 'E' bit. 732 Type 1: SID/Label Sub-TLV as defined in 733 [I-D.ietf-ospf-segment-routing-extensions]. PED-ID Len and PDE- 734 ID Value fields are per Section 2.1 of the referenced document. 736 Type 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are 737 same as Type 1. 739 Type 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are 740 same as Type 1. 742 Type 4: IPv4 Node Address. PDE-ID Len is 4 bytes and PDE-ID 743 Value is 4 bytes IPv4 address encoded similar to IPv4 Prefix 744 described in Section 2.2. 746 Type 5: IPv4 P2P interface Address. PDE-ID Len is 4 bytes and 747 PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4 748 Prefix described in Section 2.2. 750 Type 6: IPv4 LAN interface Address. PDE-ID Len is 4 bytes and 751 PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4 752 Prefix described in Section 2.2. This type MUST have OSPF 753 Neighbor ID Sub-TLV in the PDE. 755 Type 7: IPv6 Node Address. PDE-ID Len is 16 bytes and PDE-ID 756 Value is 16 bytes IPv6 address encoded similar to IPv6 Prefix 757 described in Section 2.2. 759 Type 8: IPv6 P2P interface Address. PDE-ID Len is 16 bytes and 760 PDE-ID Value is 16 bytes IPv6 address encoded similar to IPv6 761 Prefix described in Section 2.2. 763 Type 9: IPv6 LAN interface Address. PDE-ID Len is 16 bytes and 764 PDE-ID Value is 16 bytes IPv6 address encoded similar to IPv6 765 Prefix described in Section 2.2. This type MUST have OSPF 766 Neighbor ID Sub-TLV in the PDE. 768 Type 10: SRv6 Node SID as defined in 769 [I-D.li-ospf-ospfv3-srv6-extensions]. PDE-ID Len and PDE-ID 770 Value are as defined in SRv6 SID. 772 Type 11: SRv6 Adjacency-SID. PDE-ID Len and PDE-ID Value are as 773 defined in Type 6. 775 o PDE-ID Len - 1 Octet. Length of PDE-ID field. 777 o Reserved - 1 Octet reserved bits for future use. Reserved bits 778 MUST be reset on transmission and ignored on receive. 780 o PPR-PDE Flags - 2 Octet flags for this TLV are described below: 782 PPR-PDE Flags Format 784 0 1 2 3 4 5 6 7... 15 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 |L|D|E| Reserved | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 L: Loose Bit. This bit indicates the type of next "Topological 790 PDE-ID" in the path description and overrides the L bit in 791 Section 3.2. If set, the next PDE is Loose. If this flag is 792 unset, the next Topological PDE is Strict Type. 794 D: Destination Bit. By default this bit MUST be unset. This bit 795 MUST be set only for PPR-PDE Type is Topological and this PDE 796 represents the PDE-ID corresponding to the PPR-Prefix 797 Section 3.1. 799 E: Egress Bit. By default this bit MUST be unset. This bit MUST 800 be set only for PPR-PDE Type is 2 i.e., Non-Topological and the 801 service needs to be applied on the egress side of the 802 topological PDE preceding this PDE. 804 Reserved - Reserved bits for future use. Reserved bits MUST be 805 reset on transmission and ignored on receive. 807 o PPR-PDE Sub-TLVs have 2 octet type, 2 octet length and value field 808 is defined per type. 810 o PPR-PDE Sub-TLV: Type 4 (IANA TBD), Length Total length of value 811 field in bytes, Value: The Router ID of the neighbor for which the 812 LAN interface is advertised. This Sub-TLV MUST NOT be present, if 813 the PPR-PDE Type is not equal to 1 i.e., Topological PDE and PDE- 814 ID Type 6/9. 816 3.4. OSPFv3 PPR-Attributes Sub-TLV 818 PPR-Attribute Sub-TLVs describe the attributes of the path. The 819 following Sub-TLVs draw from a new registry for Sub-TLV numbers; this 820 registry is to be created by IANA, and administered using the first 821 come first serve process: 823 o Type 1 (suggested value, IANA TBD): PPR-Metric Sub-TLV. Length 4 824 bytes, and Value is metric of this path represented through the 825 PPR-ID. Different nodes can advertise the same PPR-ID for the 826 same Prefix with a different set of PPR-PDE Sub-TLVs and the 827 receiving node MUST consider the lowest metric value. 829 4. Other Considerations 831 Please refer to [I-D.chunduri-isis-preferred-path-routing] section 4, 832 5, 6 and 7. 834 5. Acknowledgements 836 Thanks to Richard Li, Alex Clemm, Padma Pillay-Esnault, Toerless 837 Eckert, Kiran Makhijani and Lin Han for initial discussions on this 838 topic. Thanks to Kevin Smith and Stephen Johnson for various 839 deployment scenarios applicability from ETSI WGs perspective. 840 Authors also acknowledge Alexander Vainshtein for detailed 841 discussions and suggestions on this topic. 843 Earlier versions of draft-ietf-ospf-segment-routing-extensions have a 844 mechanism to advertise EROs through Binding SID. 846 6. IANA Considerations 848 This document requests the following new TLV in IANA OSPFv2 and 849 OSPFv3 TLV code-point registry as specified in Section 2 Section 3 850 respectively . 852 TLV # Name 853 ----- -------------- 854 TBD PPR TLV 856 This document also requests IANA to create new registries for PPR TLV 857 Flags field, PPR Flags, and PPR Sub-TLVs in PPR TLV as described in 858 Section 2 and Section 3. 860 7. Security Considerations 862 Existing security extensions as described in [RFC2328] and [RFC7684] 863 apply to the extensions specified in this document. While OSPF is 864 under a single administrative domain, there can be deployments where 865 potential attackers have access to one or more networks in the OSPF 866 routing domain. In these deployments, stronger authentication 867 mechanisms such as those specified in [RFC7474] SHOULD be used. 869 Advertisement of the additional information defined in this document 870 introduces no new security concerns in OSPF protocol. However as 871 this extension is related to SR-MPLS and SRH data planes as defined 872 in [I-D.ietf-spring-segment-routing], those particular data plane 873 security considerations does apply here. 875 8. References 877 8.1. Normative References 879 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 880 Requirement Levels", BCP 14, RFC 2119, 881 DOI 10.17487/RFC2119, March 1997, 882 . 884 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 885 DOI 10.17487/RFC2328, April 1998, 886 . 888 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 889 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 890 May 2017, . 892 8.2. Informative References 894 [I-D.chunduri-lsr-isis-preferred-path-routing] 895 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 896 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 897 draft-chunduri-lsr-isis-preferred-path-routing-02 (work in 898 progress), February 2019. 900 [I-D.ietf-6man-segment-routing-header] 901 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 902 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 903 (SRH)", draft-ietf-6man-segment-routing-header-18 (work in 904 progress), April 2019. 906 [I-D.ietf-ospf-ospfv3-lsa-extend] 907 Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. 908 Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- 909 lsa-extend-23 (work in progress), January 2018. 911 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 912 Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment 913 Routing", draft-ietf-ospf-ospfv3-segment-routing- 914 extensions-23 (work in progress), January 2019. 916 [I-D.ietf-ospf-segment-routing-extensions] 917 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 918 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 919 Extensions for Segment Routing", draft-ietf-ospf-segment- 920 routing-extensions-27 (work in progress), December 2018. 922 [I-D.ietf-spring-segment-routing] 923 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 924 Litkowski, S., and R. Shakir, "Segment Routing 925 Architecture", draft-ietf-spring-segment-routing-15 (work 926 in progress), January 2018. 928 [I-D.li-ospf-ospfv3-srv6-extensions] 929 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 930 "OSPFv3 Extensions for SRv6", draft-li-ospf- 931 ospfv3-srv6-extensions-03 (work in progress), March 2019. 933 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 934 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 935 RFC 4915, DOI 10.17487/RFC4915, June 2007, 936 . 938 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 939 "Security Extension for OSPFv2 When Using Manual Key 940 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 941 . 943 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 944 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 945 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 946 2015, . 948 Authors' Addresses 950 Uma Chunduri 951 Huawei USA 952 2330 Central Expressway 953 Santa Clara, CA 95050 954 USA 956 Email: uma.chunduri@huawei.com 958 Yingzhen Qu 959 Huawei USA 960 2330 Central Expressway 961 Santa Clara, CA 95050 962 USA 964 Email: yingzhen.qu@huawei.com 966 Russ White 967 Juniper Networks 968 Oak Island, NC 28465 969 USA 971 Email: russ@riw.us 973 Jeff Tantsura 974 Apstra Inc. 975 333 Middlefield Road 976 Menlo Park, CA 94025 977 USA 979 Email: jefftant.ietf@gmail.com 981 Luis M. Contreras 982 Telefonica 983 Sur-3 building, 3rd floor 984 Madrid 28050 985 Spain 987 Email: luismiguel.contrerasmurillo@telefonica.com