idnits 2.17.1 draft-ce-lsr-ppr-graph-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 (March 8, 2020) is 1502 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5305' is defined on line 482, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-chunduri-lsr-isis-preferred-path-routing-04 == Outdated reference: A later version (-04) exists of draft-chunduri-lsr-ospf-preferred-path-routing-03 Summary: 0 errors (**), 0 flaws (~~), 4 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 T. Eckert 4 Intended status: Standards Track Futurewei 5 Expires: September 9, 2020 March 8, 2020 7 Preferred Path Route Graph Structure 8 draft-ce-lsr-ppr-graph-03 10 Abstract 12 This document defines a graph structure for the Preferred Path Route 13 (PPR) for IS-IS, OSPFv2 and OSPFv3 protocols. This structure helps 14 further scale of the PPR and reduce domain level global entries 15 needed in some data planes. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC2119 [RFC2119], 22 RFC8174 [RFC8174] when, and only when they appear in all capitals, as 23 shown here. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 9, 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. PPR Graph TLVs . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. IS-IS TLVs . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1.1. Branch-ID Sub-TLV . . . . . . . . . . . . . . . . . . 5 64 2.1.2. PPR PDE Sub-TLV . . . . . . . . . . . . . . . . . . . 6 65 2.2. OSPF TLVs . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.2.1. OSPFv2 TLVs . . . . . . . . . . . . . . . . . . . . . 6 67 2.2.2. OSPFv3 TLVs . . . . . . . . . . . . . . . . . . . . . 6 68 3. Encoding and Processing details . . . . . . . . . . . . . . . 6 69 3.1. S And D bits in PDEs . . . . . . . . . . . . . . . . . . 7 70 3.2. Graph processing procedure example . . . . . . . . . . . 8 71 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 5.1. IS-IS IANA . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.2. OSPFv2 IANA . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.3. OSPFv3 IANA . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.4. IGP Parameter IANA . . . . . . . . . . . . . . . . . . . 9 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 7.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 Preferred Path Routing (PPR) is a routing protocol mechanism 86 concerned with the creation of a routing path as specified in the 87 PPR-Path objects. These can be signaled via appropriate IGPs (IS-IS, 88 OSPFv2, OSPFv3) and indicate the path for a data plane identifier 89 (PPR-ID). With this, all PPR capable nodes along that path establish 90 forwarding state for the PPR-ID and any packet destined to the PPR-ID 91 would use that path instead of the IGP computed shortest path to the 92 destination. 94 PPR-Paths and relevant IGP extensions are defined in 95 [I-D.chunduri-lsr-isis-preferred-path-routing] and 96 [I-D.chunduri-lsr-ospf-preferred-path-routing]. In these IGP 97 extensions, PPR-Paths are described as a path structure, which is an 98 ordered linear list of Path Description Elements (PDEs) starting with 99 a sender PDE followed by zero or more transit PDE and finishing with 100 the destination PED. PDEs can indicate the node, a link to the node 101 and services on a node. 103 A separate PPR-ID is required for every possible PPR-Path, even if 104 one is just a subset of another path with the same destination. To 105 provide PPR-Paths from N possible source nodes to one destination 106 node, N PPR-IDs are therefore necessary. To create full-mesh 107 connectivity via PPR-Paths between N nodes, N^2 PPR-Paths and N^2 108 PPR-IDs would be needed. Even if PPR-Paths would only be used for a 109 subset of connections, such as for high-value traffic in larger 110 networks, this scale behavior is less than ideal. 112 To allow scalability, in-terms of number of PPR-IDs needed on the 113 destination nodes, number of forwarding entries needed on the nodes 114 in the paths (for overlapping paths), and to minimize the amount of 115 PPR information needed in the control plane, this document introduces 116 a PPR-Tree structure in Section 2. 118 The terminology in this document uses the more generic term of PPR 119 Graphs instead of PPR Trees because it is extensible. 121 1.1. Acronyms 123 MPLS - Multi Protocol Label Switching 125 MSD - Maximum SID Depth 127 PDE - Path Description Element 129 PPG - Preferred Path Graph 131 PPR - Preferred Path Routing/Route 133 PPR-ID - Preferred Path Route Identifier, a data plane identifier 135 SID - Segment Identifier 137 SPF - Shortest Path First 139 SR-MPLS - Segment Routing with MPLS data plane 141 SRH - Segment Routing Header - IPv6 routing Extension header 143 SRv6 - Segment Routing with Ipv6 data plane with SRH 144 TE - Traffic Engineering 146 2. PPR Graph TLVs 148 2.1. IS-IS TLVs 150 This section describes the encoding of IS-IS PPR Tree TLV. This TLV 151 can be seen as having 4 logical section viz., encoding of the PPR- 152 Prefix (IS-IS Prefix), encoding of PPG-ID, encoding of path 153 description with an ordered PDE (Path Description Element) Sub-TLVs, 154 belonging to one or more Branch-IDs and a set of optional PPR 155 attribute Sub-TLVs, which can be used to describe PPR Graph common 156 parameters. Multiple instances of this TLV MAY be advertised in IS- 157 IS LSPs with different PPG-ID Type and with corresponding Branch-ID/ 158 PDE Sub-TLVS. The PPR Graph TLV has Type TBD (suggested value xxx), 159 and has the following format: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type | Length | Graph-Type | Graph-Flags | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | PPR-Prefix Sub-TLV (variable size) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 |L| Frag-ID | PPG-ID | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 // Branch-ID Sub-TLV and PPR-PDE Sub-TLVs (variable) // 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | PPR-Attribute Sub-TLVs(variable) | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 1: PPR Tree TLV Format 177 o Type - TBD (IANA) from IS-IS top level TLV registry. 179 o Length - Total length of the value field in bytes (variable). 181 o Graph-Type - 1 Octet value (0-255, IANA Registry TBD). Value 0 182 defines a PPR Tree structure (this document). PPR-Paths can also 183 be encoded as PPR-Trees with a single branch. 185 o Graph-Flags - 1 Octet flags for this TLV are described below. 187 o Frag-ID - 1 Octet TLV Fragment-ID, with 7-bit Identifier value 188 (0-127). L bit MUST be set if a graph has only one fragment or if 189 it is the last Fragment of the graph. PPG-ID value for all 190 fragments MUST be the same. 192 o PPG-ID - 3 byte Preferred Path Graph Identifier. Originator of 193 the graph MUST ensure uniqueness across the domain. 195 o Branch-ID Sub-TLV is defined in Section 2.1.1. This represents 196 the branch-id of the structure followed by PDE Sub-TLVs in that 197 branch. Different branches of the graph can be in different 198 fragments of this TLV. However, a complete set of PDE Sub-TLVs 199 MUST be specified in one TLV fragment. 201 o PPR-PDE Sub-TLV defined in 202 [I-D.chunduri-lsr-isis-preferred-path-routing]. Additional 203 information in the PPR-PDE Sub-TLV is described in Section 2.1.2. 205 o PPR-Attribute Sub-TLVs defined in 206 [I-D.chunduri-lsr-isis-preferred-path-routing] are applicable 207 here. 209 PPR-Flags field of PPR TLV has the following flag bits defined. 210 These flags, at this point mostly related to applicability of this 211 TLV in an L1 area or entire IS-IS domain or from where the PPR-Prefix 212 is being originated: 214 PPR Graph-Flags Format 216 0 1 2 3 4 5 6 7 217 +-+-+-+-+-+-+-+-+ 218 |S|D| Reserved | 219 +-+-+-+-+-+-+-+-+ 221 1. S - If set, the PPR Graph TLV MUST be flooded across the entire 222 routing domain. If the S flag is not set, the PPR Graph TLV MUST 223 NOT be leaked between IS-IS levels. This bit MUST NOT be altered 224 during the TLV leaking 226 2. D - when the PPR Graph TLV is leaked from IS-IS level-2 to level- 227 1, the D bit MUST be set. Otherwise, this bit MUST be clear. 228 PPR TLVs with the D bit set MUST NOT be leaked from level-1 to 229 level-2. This is to prevent TLV looping across levels. 231 3. Reserved - reserved bits for future use. Reserved bits MUST be 232 reset on transmission and ignored on receive. 234 2.1.1. Branch-ID Sub-TLV 236 Branch-ID Sub-TLVs represent the branch of the graph described. This 237 is a new Sub-TLV type (IANA TBD) in PPR TLV 238 [I-D.chunduri-lsr-isis-preferred-path-routing]. Type TBD (Suggested 239 Value - IANA TBD), with a length of 1 byte, and Value is the branch 240 identification number in the range of 0 to 255. 242 2.1.2. PPR PDE Sub-TLV 244 PPR PDE Sub-TLV is defined in 245 [I-D.chunduri-lsr-isis-preferred-path-routing]. This document 246 extends the same with the following: 248 1. PPR-PDE Flags (Bit position 2), S: Source Bit. Indicates the PPR 249 head-end and MUST be set if this PDE corresponds to the same. 251 2. PPR-ID Sub-Sub-TLV: Type, length and value fields would be same 252 as PPR-ID Sub-TLV defined in 253 [I-D.chunduri-lsr-isis-preferred-path-routing]. This Sub-Sub-TLV 254 MUST be present only when 'D' flag is set in the PPR-PDE Flags 255 field. 257 PPR-PDE Flags field is defined in PPR-PDE Sub-TLV 258 [I-D.chunduri-lsr-isis-preferred-path-routing]. 260 2.2. OSPF TLVs 262 2.2.1. OSPFv2 TLVs 264 TBD. 266 2.2.2. OSPFv3 TLVs 268 TBD. 270 3. Encoding and Processing details 272 [I-D.chunduri-lsr-isis-preferred-path-routing] describes how a PPR 273 path can be established. This document builds on the same base 274 concept but expands the same with a graph structure as defined in 275 Section 2. The key new encoding element here over prior PPR Paths is 276 the existence of multiple Branches in the PPR Graph description. 278 Each Branch-ID sub-TLV is followed by ordered sequence of PDEs. A 279 PPR Graph can be constructed from one or more PPR Branches. Branches 280 are stitched together by using the same PDE in two branches. To 281 simplify parsing of branches, only the last PDE of a branch can be 282 stitched to another branch. In result, any PDE can only be a non- 283 last PDE in one Branch but last PDE in more than one branch. A PPG- 284 ID field is defined in this document. This MUST be unique in the 285 domain and represents the graph structure as whole. 287 A complete Graph may not fit into maximum allowable size of the IS-IS 288 TLV. To overcome this a 7 bit Frag-ID field is defined (Section 2). 289 With this, a single PPR Graph is represented via one or more 290 fragmented PPR Graph TLVs all having the same PPG-ID. Each Fragment 291 carries the PPG-ID as well as a numeric Frag-ID from 0 to (N-1), when 292 N fragments are needed to describe the PPR Graph (where N>1). In 293 this case Fragment (N-1) MUST set the L bit to indicate it is the 294 last fragment. The optional PPR Attribute Sub-TLVs which describe 295 the Graph overall MUST be included in the last fragment only. 297 3.1. S And D bits in PDEs 299 In PPR Paths as defined in 300 [I-D.chunduri-lsr-isis-preferred-path-routing], currently only a 301 simple linear path structure for a destination node is possible. 302 However, with a bit on path element source and a bit for destination 303 (refer section) - same path ID/PPR-ID can be used to represent 304 multiple paths if some of the nodes are also sources and terminating 305 on the same destination node. 307 1. A Linear Path structure: 308 PDE1 --> PDE2 --> PDE3 --> PDE4 --> PDE5 309 [First PDE always Source and last PDE is always Destination] 311 2. A PPR Graph with S and D bits: 312 PDE1(with-S-bit-set)-->PDE2-->PDE3(with-S-bit-set).. 313 ..-->PDE4(with-D-bit-set)-->PDE5(with-D-bit-Set) 315 ==> PDE1 --> PDE2 --> PDE3 --> PDE4 316 ==> PDE1 --> PDE2 --> PDE3 --> PDE4 --> PDE5 317 ==> PDE3 --> PDE4 318 ==> PDE3 --> PDE4 --> PDE5 320 Figure 2: PPR Graph with S and D bits 322 In the above Figure 2 example, in (1) a linear path list of 5 nodes 323 are described where PDE1 is the source/ingress-point and PDE5 is the 324 destination/egress point of the path. In (2), the path can be 325 defined in this document, where some PDEs can have S(ource) and/or 326 D(estination) bit or both can be set. Here, PDE1 and PDE3 have the 327 Source bit set, PDE4 and PDE5 the Destination bit set. This Branch 328 structure is equivalent to the set of 4 PPR-PDE lists as shown: 329 PDE1->PDE5, PDE1->PDE45, PDE3->PDE4, PDE3->PDE5. This reduces the 330 amount of information that needs to be sent across the IGP and that 331 needs to be processed by each node. 333 If the bits and branch structure were not used, the 4 PPR PDE lists 334 would have required each a unique PPR-ID (and the resulting 335 forwarding entries created), but the Branch requires only 2 PPR-IDs: 336 one for both paths terminating in PDE4, and one for both paths 337 terminating in PDE5. 339 3.2. Graph processing procedure example 341 Brach0 Branch1 Branch2 343 PDE1 PDE12(S-bit) PDE6 344 \ \ / 345 PDE2 PDE11 PDE7 346 \ \ / 347 PDE3 PDE10 PDE8 (S-bit) 348 \ \ / 349 PDE4 PDE9 350 \ / 351 \ / 352 PDE5 353 (D-bit) 355 Figure 3: PPR Graph (Tree) Example 357 With a PPR Tree structure both flooding optimization and reduction in 358 the number of SIDs needed at the destination can be achieved. To do 359 this encoding as specified in Section 2 (a) Every PDE-ID can be non- 360 last-PDE in at most one Branch. It can be last-PDE in one or more 361 Branches (ex: PDE9). (b) Branches form a tree by joining nodes with 362 same PDE-ID (PDE9 and PDE5 in the above example). Leafs of the tree 363 must be S(ources), e.g.: PDE1, PDE12, PDE6. Root of the tree must be 364 the only D(estination) of the tree (e.g.: PDE5). 366 How to build forwarding entry (referring to the Figure 3 above): 368 1. If PPR-ID in PDE of PPR Graph is indicating this node (example: 369 PDE5): This node is D(estination) of this tree. Forwarding state 370 is built for this PPR-Tree like for PPR-Path, no changes. 372 2. If PPR-ID is NOT indicating this node, then this node MAY be 373 source (PDE12, PDE8) or midpoint (PDE9, neither source nor 374 destination): 376 a. Node sequentially examines all branches until it finds a PDE with 377 its own PDE-ID. It then establishes a forwarding entry for the 378 PPR-ID indicated in the PPR header with the next-hop being the 379 next PDE in the current branch. 381 b. This nodes PDE may be the last PDE in a Branch, for example PDE9 382 in Branch1. In this case, the node ignores this branch because 383 it cannot build a complete forwarding entry from it. Instead, it 384 will build the forwarding entry from another branch, e.g.: Node 385 with PDE9 will build forwarding entry for destination PDE5 when 386 it examines Branch2 because there it will have a next hop PDE5. 387 After forwarding entry is built, node can stop examining rest of 388 Branch or further Branches. 390 c. If node does not find its own PDE in any branch it is not on the 391 graph and ignores this PPR-Graph. 393 4. Acknowledgements 395 Thanks to Yingzhen Qu and Richard Li for multiple discussions on this 396 topic. 398 5. IANA Considerations 400 5.1. IS-IS IANA 402 This document requests the following new TLV in IANA IS-IS TLV code- 403 point registry. 405 TLV # Name 406 ----- -------------- 407 TBD PPR Graph TLV 409 This document requests IANA to create a new Sub-TLV registry for PPR 410 TLV Section 2 with the following initial entries (suggested values): 412 Sub-TLV # Sub-TLV Name 413 --------- --------------------------------------------------------- 415 TBD Branch-ID (Section 2) 417 5.2. OSPFv2 IANA 419 5.3. OSPFv3 IANA 421 5.4. IGP Parameter IANA 423 This document requests additional IANA registries in an IANA managed 424 registry "Interior Gateway Protocol (IGP) Parameters" for various PPR 425 TLV parameters. The registration procedure is based on the "Expert 426 Review" as defined in [RFC8126]. The suggested registry names are: 428 o "Graph-Type" - Types are an unsigned 8 bit numbers. Values are as 429 defined in Section 2 of this document. 431 o "Graph-Flags" - 1 Octet. Bits as described in Section 2 of this 432 document. 434 6. Security Considerations 436 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 437 Further security analysis for IS-IS protocol is done in [RFC7645] 438 with detailed analysis of various security threats and why [RFC5304] 439 should not be used in the deployments. 441 OSPF security extensions are described in [RFC2328] and [RFC7684] and 442 these apply to the extensions specified in this document. While OSPF 443 is under a single administrative domain, there can be deployments 444 where potential attackers have access to one or more networks in the 445 OSPF routing domain. In these deployments, stronger authentication 446 mechanisms such as those specified in [RFC7474] SHOULD be used. 448 Advertisement of the additional information defined in this document 449 introduces no new security concerns in IS-IS or OSPF protocols. 451 7. References 453 7.1. Normative References 455 [I-D.chunduri-lsr-isis-preferred-path-routing] 456 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 457 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 458 draft-chunduri-lsr-isis-preferred-path-routing-04 (work in 459 progress), July 2019. 461 [I-D.chunduri-lsr-ospf-preferred-path-routing] 462 Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. 463 Contreras, "Preferred Path Routing (PPR) in OSPF", draft- 464 chunduri-lsr-ospf-preferred-path-routing-03 (work in 465 progress), May 2019. 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, 469 DOI 10.17487/RFC2119, March 1997, 470 . 472 7.2. Informative References 474 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 475 DOI 10.17487/RFC2328, April 1998, 476 . 478 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 479 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 480 2008, . 482 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 483 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 484 2008, . 486 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 487 and M. Fanto, "IS-IS Generic Cryptographic 488 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 489 2009, . 491 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 492 "Security Extension for OSPFv2 When Using Manual Key 493 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 494 . 496 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 497 Authentication for Routing Protocol (KARP) IS-IS Security 498 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 499 . 501 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 502 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 503 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 504 2015, . 506 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 507 Writing an IANA Considerations Section in RFCs", BCP 26, 508 RFC 8126, DOI 10.17487/RFC8126, June 2017, 509 . 511 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 512 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 513 May 2017, . 515 Authors' Addresses 516 Uma Chunduri 517 Futurewei 518 2330 Central Expressway 519 Santa Clara, CA 95050 520 USA 522 Email: umac.ietf@gmail.com 524 Toerless Eckert 525 Futurewei 526 2330 Central Expressway 527 Santa Clara, CA 95050 528 USA 530 Email: tte+ietf@cs.fau.de