idnits 2.17.1 draft-ce-lsr-ppr-graph-01.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 (October 23, 2018) is 1984 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 483, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-chunduri-lsr-isis-preferred-path-routing-01 == Outdated reference: A later version (-04) exists of draft-chunduri-lsr-ospf-preferred-path-routing-01 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 Huawei USA 5 Expires: April 26, 2019 October 23, 2018 7 Preferred Path Route Graph Structure 8 draft-ce-lsr-ppr-graph-01 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 April 26, 2019. 42 Copyright Notice 44 Copyright (c) 2018 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 better scale 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 1 (Suggested Value, TBD IANA from the 252 PDE Sub-TLV Registry), length and value fields would be same as 253 PPR-ID Sub-TLV defined in 254 [I-D.chunduri-lsr-isis-preferred-path-routing]. This Sub-Sub-TLV 255 MUST be present only when 'D' flag is set in the PPR-PDE Flags 256 field. 258 PPR-PDE Flags field is defined in PPR-PDE Sub-TLV 259 [I-D.chunduri-lsr-isis-preferred-path-routing]. 261 2.2. OSPF TLVs 263 2.2.1. OSPFv2 TLVs 265 TBD. 267 2.2.2. OSPFv3 TLVs 269 TBD. 271 3. Encoding and Processing details 273 [I-D.chunduri-lsr-isis-preferred-path-routing] describes how a PPR 274 path can be established. This document builds on the same base 275 concept but expands the same with a graph structure as defined in 276 Section 2. The key new encoding element here over prior PPR Paths is 277 the existence of multiple Branches in the PPR Graph description. 279 Each Branch-ID sub-TLV is followed by ordered sequence of PDEs. A 280 PPR Graph can be constructed from one or more PPR Branches. Branches 281 are stitched together by using the same PDE in two branches. To 282 simplify parsing of branches, only the last PDE of a branch can be 283 stitched to another branch. In result, any PDE can only be a non- 284 last PDE in one Branch but last PDE in more than one branch. A PPG- 285 ID field is defined in this document. This MUST be unique in the 286 domain and represents the graph structure as whole. 288 A complete Graph may not fit into maximum allowable size of the IS-IS 289 TLV. To overcome this a 7 bit Frag-ID field is defined (Section 2). 290 With this, a single PPR Graph is represented via one or more 291 fragmented PPR Graph TLVs all having the same PPG-ID. Each Fragment 292 carries the PPG-ID as well as a numeric Frag-ID from 0 to (N-1), when 293 N fragments are needed to describe the PPR Graph (where N>1). In 294 this case Fragment (N-1) MUST set the L bit to indicate it is the 295 last fragment. The optional PPR Attribute Sub-TLVs which describe 296 the Graph overall MUST be included in the last fragment only. 298 3.1. S And D bits in PDEs 300 In PPR Paths as defined in 301 [I-D.chunduri-lsr-isis-preferred-path-routing], currently only a 302 simple linear path structure for a destination node is possible. 303 However, with a bit on path element source and a bit for destination 304 (refer section) - same path ID/PPR-ID can be used to represent 305 multiple paths if some of the nodes are also sources and terminating 306 on the same destination node. 308 1. A Linear Path structure: 309 PDE1 --> PDE2 --> PDE3 --> PDE4 --> PDE5 310 [First PDE always Source and last PDE is always Destination] 312 2. A PPR Graph with S and D bits: 313 PDE1(with-S-bit-set)-->PDE2-->PDE3(with-S-bit-set).. 314 ..-->PDE4(with-D-bit-set)-->PDE5(with-D-bit-Set) 316 ==> PDE1 --> PDE2 --> PDE3 --> PDE4 317 ==> PDE1 --> PDE2 --> PDE3 --> PDE4 --> PDE5 318 ==> PDE3 --> PDE4 319 ==> PDE3 --> PDE4 --> PDE5 321 Figure 2: PPR Graph with S and D bits 323 In the above Figure 2 example, in (1) a linear path list of 5 nodes 324 are described where PDE1 is the source/ingress-point and PDE5 is the 325 destination/egress point of the path. In (2), the path can be 326 defined in this document, where some PDEs can have S(ource) and/or 327 D(estination) bit or both can be set. Here, PDE1 and PDE3 have the 328 Source bit set, PDE4 and PDE5 the Destination bit set. This Branch 329 structure is equivalent to the set of 4 PPR-PDE lists as shown: 330 PDE1->PDE5, PDE1->PDE45, PDE3->PDE4, PDE3->PDE5. This reduces the 331 amount of information that needs to be sent across the IGP and that 332 needs to be processed by each node. 334 If the bits and branch structure were not used, the 4 PPR PDE lists 335 would have required each a unique PPR-ID (and the resulting 336 forwarding entries created), but the Branch requires only 2 PPR-IDs: 337 one for both paths terminating in PDE4, and one for both paths 338 terminating in PDE5. 340 3.2. Graph processing procedure example 342 Brach0 Branch1 Branch2 344 PDE1 PDE12(S-bit) PDE6 345 \ \ / 346 PDE2 PDE11 PDE7 347 \ \ / 348 PDE3 PDE10 PDE8 (S-bit) 349 \ \ / 350 PDE4 PDE9 351 \ / 352 \ / 353 PDE5 354 (D-bit) 356 Figure 3: PPR Graph (Tree) Example 358 With a PPR Tree structure both flooding optimization and reduction in 359 the number of SIDs needed at the destination can be achieved. To do 360 this encoding as specified in Section 2 (a) Every PDE-ID can be non- 361 last-PDE in at most one Branch. It can be last-PDE in one or more 362 Branches (ex: PDE9). (b) Branches form a tree by joining nodes with 363 same PDE-ID (PDE9 and PDE5 in the above example). Leafs of the tree 364 must be S(ources), e.g.: PDE1, PDE12, PDE6. Root of the tree must be 365 the only D(estination) of the tree (e.g.: PDE5). 367 How to build forwarding entry (referring to the Figure 3 above): 369 1. If PPR-ID in PDE of PPR Graph is indicating this node (example: 370 PDE5): This node is D(estination) of this tree. Forwarding state 371 is built for this PPR-Tree like for PPR-Path, no changes. 373 2. If PPR-ID is NOT indicating this node, then this node MAY be 374 source (PDE12, PDE8) or midpoint (PDE9, neither source nor 375 destination): 377 a. Node sequentially examines all branches until it finds a PDE with 378 its own PDE-ID. It then establishes a forwarding entry for the 379 PPR-ID indicated in the PPR header with the next-hop being the 380 next PDE in the current branch. 382 b. This nodes PDE may be the last PDE in a Branch, for example PDE9 383 in Branch1. In this case, the node ignores this branch because 384 it cannot build a complete forwarding entry from it. Instead, it 385 will build the forwarding entry from another branch, e.g.: Node 386 with PDE9 will build forwarding entry for destination PDE5 when 387 it examines Branch2 because there it will have a next hop PDE5. 388 After forwarding entry is built, node can stop examining rest of 389 Branch or further Branches. 391 c. If node does not find its own PDE in any branch it is not on the 392 graph and ignores this PPR-Graph. 394 4. Acknowledgements 396 Thanks to Yingzhen Qu and Richard Li for multiple discussions on this 397 topic. 399 5. IANA Considerations 401 5.1. IS-IS IANA 403 This document requests the following new TLV in IANA IS-IS TLV code- 404 point registry. 406 TLV # Name 407 ----- -------------- 408 TBD PPR Graph TLV 410 This document requests IANA to create a new Sub-TLV registry for PPR 411 TLV Section 2 with the following initial entries (suggested values): 413 Sub-TLV # Sub-TLV Name 414 --------- --------------------------------------------------------- 416 TBD Branch-ID (Section 2) 418 5.2. OSPFv2 IANA 420 5.3. OSPFv3 IANA 422 5.4. IGP Parameter IANA 424 This document requests additional IANA registries in an IANA managed 425 registry "Interior Gateway Protocol (IGP) Parameters" for various PPR 426 TLV parameters. The registration procedure is based on the "Expert 427 Review" as defined in [RFC8126]. The suggested registry names are: 429 o "Graph-Type" - Types are an unsigned 8 bit numbers. Values are as 430 defined in Section 2 of this document. 432 o "Graph-Flags" - 1 Octet. Bits as described in Section 2 of this 433 document. 435 6. Security Considerations 437 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 438 Further security analysis for IS-IS protocol is done in [RFC7645] 439 with detailed analysis of various security threats and why [RFC5304] 440 should not be used in the deployments. 442 OSPF security extensions are described in [RFC2328] and [RFC7684] and 443 these apply to the extensions specified in this document. While OSPF 444 is under a single administrative domain, there can be deployments 445 where potential attackers have access to one or more networks in the 446 OSPF routing domain. In these deployments, stronger authentication 447 mechanisms such as those specified in [RFC7474] SHOULD be used. 449 Advertisement of the additional information defined in this document 450 introduces no new security concerns in IS-IS or OSPF protocols. 452 7. References 454 7.1. Normative References 456 [I-D.chunduri-lsr-isis-preferred-path-routing] 457 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 458 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 459 draft-chunduri-lsr-isis-preferred-path-routing-01 (work in 460 progress), July 2018. 462 [I-D.chunduri-lsr-ospf-preferred-path-routing] 463 Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. 464 Contreras, "Preferred Path Routing (PPR) in OSPF", draft- 465 chunduri-lsr-ospf-preferred-path-routing-01 (work in 466 progress), July 2018. 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, 470 DOI 10.17487/RFC2119, March 1997, 471 . 473 7.2. Informative References 475 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 476 DOI 10.17487/RFC2328, April 1998, 477 . 479 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 480 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 481 2008, . 483 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 484 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 485 2008, . 487 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 488 and M. Fanto, "IS-IS Generic Cryptographic 489 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 490 2009, . 492 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 493 "Security Extension for OSPFv2 When Using Manual Key 494 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 495 . 497 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 498 Authentication for Routing Protocol (KARP) IS-IS Security 499 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 500 . 502 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 503 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 504 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 505 2015, . 507 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 508 Writing an IANA Considerations Section in RFCs", BCP 26, 509 RFC 8126, DOI 10.17487/RFC8126, June 2017, 510 . 512 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 513 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 514 May 2017, . 516 Authors' Addresses 517 Uma Chunduri 518 Huawei USA 519 2330 Central Expressway 520 Santa Clara, CA 95050 521 USA 523 Email: uma.chunduri@huawei.com 525 Toerless Eckert 526 Huawei USA 527 2330 Central Expressway 528 Santa Clara, CA 95050 529 USA 531 Email: tte+ietf@cs.fau.de