idnits 2.17.1 draft-song-ship-edge-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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 20, 2020) is 1281 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC7775' is defined on line 520, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Song 3 Internet-Draft Futurewei Technologies 4 Intended status: Experimental October 20, 2020 5 Expires: April 23, 2021 7 Using Short Hierarchical IP Addresses at Edge Networks 8 draft-song-ship-edge-00 10 Abstract 12 To mitigate the IPv6 header overhead in edge networks, this draft 13 proposes to use short hierarchical addresses excluding the network 14 prefix within edge networks. An edge network can be organized into a 15 hierarchical architecture containing one or more levels of networks. 16 The border routers for each hierarchical level are responsible for 17 address augmenting and pruning. Specifically, the top-level border 18 routers convert the internal IP header to and from the standard IPv6 19 header. This draft presents an incrementally deployable scheme 20 allowing packet header to be effectively compressed in edge networks 21 without affecting the network interoperability. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in BCP 28 14 [RFC2119][RFC8174] when, and only when, they appear in all 29 capitals, as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 23, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Short Hierarchical Address in Edge Networks . . . . . . . . . 3 67 2.1. Edge Network Hierarchy . . . . . . . . . . . . . . . . . 3 68 2.2. Address Fields . . . . . . . . . . . . . . . . . . . . . 5 69 2.3. Router Roles and Function . . . . . . . . . . . . . . . . 6 70 3. Deployment and Interoperability Consideration . . . . . . . . 9 71 3.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 9 72 3.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 11 73 3.3. Using NAT for the edge network . . . . . . . . . . . . . 11 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 79 7.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 Internet of Things (IoT) and 5G introduce to the Internet a huge 85 number of addressable entities (e.g., sensors, machines, vehicles, 86 and robots). The transition to IPv6 is inevitable. While the 87 128-bit address of IPv6 was considered large enough and future-proof, 88 the long IP addresses inflate the packet header size. 80% of a basic 89 IPv6 header is consumed by addresses. 91 In IoT networks, thing-to-thing communication through wireless 92 connections is dominant, which presents several distinct 93 characteristics. (1) The communication pattern is often frequent 94 short-message exchanges (e.g., industry robots and networked 95 vehicles). (2) The communication is usually energy sensitive (e.g., 96 battery-powered sensors). (3) The communication often requires low 97 latency (e.g., industry control). (4) The precious wireless channels 98 demand high bandwidth utilization (e.g., ZigBee, Bluetooth, Wi-Fi, 99 and 5G). These characteristics render a large header overhead 100 unfavorable and even prohibitive. 102 The address overhead also takes its toll on Data Center Networks 103 (DCN), especially when large scale containers are deployed, the east- 104 west traffic is dominant, and the prevailing communications are 105 comprised of short messages (e.g., key-value pairs) and conducted 106 through virtual switches. 108 On the other hand, in IoT and DCN, most communications happen between 109 adjacent and related entities. It is a good practice to locally 110 confine communication, computing, and storage due to performance, 111 efficiency, and security considerations, as advocated by Edge 112 Computing. Such a communication pattern provides an opportunity to 113 mitigate the IPv6 header overhead problem due to the long addresses. 115 When an IPv6 address block is allocated to an edge network, all the 116 entities in the edge network share the same address prefix. When 117 these entities communicate with each other, they can ignore the 118 common prefix. Only when they needs to communicate with entities 119 outside of the edge network, the full addresses are needed. However, 120 even in this case, the entities in the edge network do not need to 121 know the prefix. It is sufficient for the gateway routers at the 122 network border to manipulate the addresses (i.e., augmenting or 123 pruning the address) to meet the address requirement. 125 Following this line of thought, an edge network can be further 126 partitioned into multiple hierarchical levels, which supports 127 flexible sub-networking. The result is that an end entity needs to 128 maintain an even shorter address as its identifier. For 129 communication cross network levels, the address manipulation is done 130 at each gateway router on the path recursively. 132 2. Short Hierarchical Address in Edge Networks 134 2.1. Edge Network Hierarchy 136 In this draft, we define an edge network as a stub network with an 137 assigned IPv6 address block which does not support traffic transit 138 service. In this sense, a data center network in cloud can also be 139 considered as an edge network. An edge network usually falls under a 140 single network administration domain. 142 The address block assigned to an edge network is identified by a 143 prefix P. The remaining s = 128-length(P) bits can be used to assign 144 addresses to the entities in this network. A key observation is: the 145 entities in this network do not need to be aware of P's length and 146 value at all. We can further partition the edge network into 147 multiple hierarchical levels, making a tree architecture. The root 148 represents the entire edge network. Each other node represents a 149 lower level network occupying a sub address space owned by its parent 150 node. A leaf node represents a lowest level network. We name the 151 root level network the L_0 network. Its children are all L_1 152 networks, and so on so forth. 154 The network hierarchy partitions the s-bit address into multiple 155 sections. Assume an entity is in an L_n network. The s-bit address 156 is partitioned into n+1 sections. The entity only needs to keep the 157 last section of the s-bit address as its ID. The gateways routers 158 for each level of network maintain one section of the s-bit address. 159 Specifically, the gateway routers of L_i (i>0) keep the i-th section 160 of the s-bit address, and the gateway routers of L_0 keep the 161 assigned IPv6 address block prefix P. 163 Figure 1 shows an edge network example, in which are three network 164 levels. The edge network A is assigned a 96-bit IPv6 address prefix 165 (2001:0db8:ac10:fe01::0001), which means it owns a 32-bit address 166 space. In this space, two L_1 networks are created: B with a 16-bit 167 prefix (0xaaaa) and C with a 24-bit prefix (0xcccccc). Note that the 168 prefixes at the same level must not overlap in order to guarantee 169 entities in the edge network are uniquely addressable. Network B 170 contains two entities x and y, and Network C contains one entity z. 171 In network B, an L_2 network C is created with a 8-bit prefix (0xbb). 172 In this example, an entity in C or D (e.g., m and z) only need to 173 keep a 8-bit address, an entity in B but not in D (e.g., x and y) 174 needs to keep a 16-bit address, and an entity in A but not in B and C 175 needs to keep a 32-bit address. Each entity in A still logically 176 owns a unique IPv6 address (e.g., the IPv6 address of the entity m in 177 D with ID of 5 is 2001:0db8:ac10:fe01::0001:aaaa:bb05), although the 178 entity m is only aware of its local ID (0x05). 180 +------+ 181 | L0:A | 2001:0db8:ac10:fe01::0001/96 182 +-+--+-+ 183 | | 184 +------+ +-------+ 185 | | 186 +---+--+ +--+---+ 187 (x,y) | L1:B | aaaa/16 | L1:C | cccccc/24 188 +---+--+ +------+ 189 | (z) 190 +---+--+ 191 (m) | L2:D | bb/8 192 +------+ 194 Figure 1: A Hierarchical Edge Network 196 2.2. Address Fields 198 The edge networks adopting the short and variable size address scheme 199 need a new type of IP header, which is referred as IPvn in this 200 draft. Apart from the IP version, the major difference between IPvn 201 and IPv6 headers is the address fields. IPvn replaces IPv6's 128-bit 202 source address field and 128-bit destination address field with the 203 four fields shown in Figure 2. 205 +------------+------------+ 206 | SAL | DAL | 207 +------------+------------+ 208 | SA (variable length) | 209 +-------------------------+ 210 | DA (variable length) | 211 +-------------------------+ 213 Figure 2: IPvn Address Fields 215 The Source Address Length (SAL) and the Destiantion Address Length 216 (DAL) fields have fixed length, while the Source Address (SA) and the 217 Destination Address (DA) fields are variable length. To simplify the 218 implementation, SA and DA are preferred to be byte-aligned. It is 219 possible to define the length of address in the unit of byte, nibble, 220 or bit. Each has its own pros and cons. The unit of byte can help 221 reduce the size of the SAL/DAL but results in coarse network 222 granularity which might be inefficient in address allocation. For 223 example, a 3-bit SAL/DAL is enough to encode 8 possible address 224 lengths (one to eight bytes) for networks. In this design, each 225 higher level network's address space expands 256 times. On the other 226 extreme, the unit of bit allows fine network granularity but requires 227 more space for SAL/DAL. For example, 6-bit SAL and DAL can support 228 an address length up to 64 bits (8 bytes) and each higher level 229 network is only twice larger. With a few bits, it is also possible 230 to design a more sophisticated encoding scheme that supports variable 231 address length steps and adapts to the ideal network sizes at 232 different levels. 234 Assuming SA and DA are 2 bytes each, and SAL and DAL are 4 bits each, 235 the address fields are only 5 bytes in total. Comparing to IPv6, the 236 size of the address fields reduces 84%. 238 2.3. Router Roles and Function 240 In the edge network hierarchy, each network has one or more Level 241 Gateway Routers (LGR) which are responsible for forwarding packets in 242 or out of this network. The LGRs are the only interface between a 243 network and its parent network. 245 A network can be in a single L2 domain, which means all the entities 246 in this network (excluding those in its child networks) and all the 247 network devices (including the LGRs to the parent network and the 248 child networks) are L2 reachable. A network can also be a pure L3 249 network in which no L2 device is allowed. Each entity in a network 250 is directly connected to either an LGR or some internal routers named 251 Intra-Level Router (ILR) which is solely responsible for packet 252 forwarding within the network. In this case, the entities need to 253 partially participate in the routing process (e.g., advertising its 254 address). 256 The scale of an intra-level network can be used to guide the L2/L3 257 selection. Small networks prefer the L2-based solution and large 258 networks prefer the L3-based solution. In the higher level networks, 259 since the number of entities is usually small, it is free to choose 260 between L2 or L3-based solution. The leaf level networks are usually 261 L2-based. 263 Unlike IPv4 and IPv6, the address related fields in IPvn header can 264 be modified by LGRs. An LGR of a network keeps a prefix that can 265 augment the SAs from this network to an address in the parent 266 network. If an LGR needs to forward an internal packet outside 267 (i.e., DAL>SAL), it augments the packet's SA and updates its SAL 268 accordingly. Reversely, if an LGR receives a packet from the parent 269 network destined for the child network it serves as a gateway(i.e., 270 the parent network prefix matches the DA's prefix), it strips off the 271 parent network prefix from the packet's DA and updates its DAL 272 accordingly. 274 In contrast, within an L3-based level network, ILRs do not modify the 275 address fields. An ILR can decide the packet forwarding direction by 276 examining the DAL. If DAL > SAL, the packet needs to be forwarded to 277 an LGR of this network; otherwise, the packet needs to be forwarded 278 within the current network, and possibly into a lower-level child 279 network. 281 The LGR of the top-level network (i.e., the L0 network) is special. 282 In addition to the address manipulation, it is also responsible for 283 converting the internal IP header to and from the standard IPv6 284 header to support the Internet interoperability. We name such a 285 router IP Translator (IPT). 287 We use the edge network shown in Figure 1 to illustrate some packet 288 forwarding examples. The details for the involved entities are 289 summarized in Figure 3. In the IPvn packet header, we use 4 bits to 290 encode the address length. In particular, 0b0000 is used to indicate 291 the address is 16 bytes long (i.e., a complete IPv6 address). 293 +------+------+------+-----+-------+------------+ 294 |Entity| ID |Length|Level|Network| Prefix | 295 +------+------+------+-----+-------+------------+ 296 | x |0x0001| | | | | 297 +------+------|2bytes| 1 | B |0xaaaa/16 | 298 | y |0x0002| | | | | 299 +------+------+------+-----+-------+------------+ 300 | z |0x01 |1byte | 1 | C |0xcccccc/24 | 301 +------+------+------+-----+-------+------------+ 302 | m |0x08 |1byte | 2 | D |0xbb/8 | 303 +------+------+------+-----+-------+------------+ 305 Figure 3: Forward within a network level 307 The first example in Figure 4 shows how packets are forwarded from x 308 to y within the network B. In this case, the source address and 309 destination address have the same length. 311 +-----------------+ +-----------------+ +-----------------+ 312 | IPvn Header | | IPvn Header | | IPvn Header | 313 +--------+--------+ +--------+--------+ +--------+--------+ 314 |SAL:0x2 |DAL:0x2 | |SAL:0x2 |DAL:0x2 | |SAL:0x2 |DAL:0x2 | 315 +--------+--------+ +--------+--------+ +--------+--------+ 316 |SA: 0x0001 | |SA: 0x0001 | |SA: 0x0001 | 317 +-----------------+ +-----------------+ +-----------------+ 318 |DA: 0x0002 | |DA: 0x0002 | |DA: 0x0002 | 319 +-----------------+ +-----------------+ +-----------------+ 320 Entity x ------> ILR in B ------> Entity y 322 Figure 4: Forward within a network in the edge 324 The second example in Figure 5 shows how packets are forwarded from x 325 in B to z in C. At LGR of B, the source address is augmented, and at 326 the LGR of C, the destination address is pruned. Since x and z's 327 nearest common ancestor network is A, so the packets never need to 328 leave network A, so A's prefix is oblivious throughout the 329 communication. 331 +---------------+ +---------------+ +---------------+ +---------------+ 332 | IPvn Header | | IPvn Header | | IPvn Header | | IPvn Header | 333 +-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+ 334 |SAL:0x2|DAL:0x4| |SAL:0x4|DAL:0x4| |SAL:0x4|DAL:0x1| |SAL:0x4|DAL:0x1| 335 +-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+ 336 |SA: 0x0001 | |SA: 0xaaaa0001 | |SA: 0xaaaa0001 | |SA: 0xaaaa0001 | 337 +---------------+ +---------------+ +---------------+ +---------------+ 338 |DA: 0xcccccc01 | |DA: 0xcccccc01 | |DA: 0x01 | |DA: 0x01 | 339 +---------------+ +---------------+ +---------------+ +---------------+ 340 Entity x -----> LGR of B -----> LGR of C -----> Entity z 342 Figure 5: Forward to another network in the edge 344 The last example in Figure 6 shows how packets are forwarded from x 345 in B to a host in IPv6 domain. In the IPT of A, the IP header is 346 converted to an IPv6 header. 348 +---------------+ +---------------+ +---------------+ +---------------+ 349 | IPvn Header | | IPvn Header | | IPv6 Header | | IPv6 Header | 350 +-------+-------+ +-------+-------+ +---------------+ +---------------+ 351 |SAL:0x2|DAL:0x0| |SAL:0x4|DAL:0x0| |SA: 2001:0db8 | |SA: 2001:0db8 | 352 +-------+-------+ +-------+-------+ | ac10:fe01: | | ac10:fe01: | 353 |SA: 0x0001 | |SA: 0xaaaa0001 | | 0000:0001: | | 0000:0001: | 354 +---------------+ +---------------+ | aaaa:0001 | | aaaa:0001 | 355 |DA: 2001:0db8: | |DA: 2001:0db8: | +---------------+ +---------------+ 356 | 85a3:0000: | | 85a3:0000: | |DA: 2001:0db8: | |DA: 2001:0db8: | 357 | 0000:8a2e: | | 0000:8a2e: | | 85a3:0000: | | 85a3:0000: | 358 | 0370:7334 | | 0370:7334 | | 0000:8a2e: | | 0000:8a2e: | 359 +---------------+ +---------------+ | 0370:7334 | | 0370:7334 | 360 +---------------+ +---------------+ 362 Entity x -----> LGR of B -----> IPT of A -----> Entity n 364 Figure 6: Forward out of the edge network 366 3. Deployment and Interoperability Consideration 368 3.1. Control Plane 370 Within the edge networks where IPvn is applied, all the control plane 371 functions and protocols need to be modified or redesigned due to the 372 hierarchical network architecture of IPvn. Fortunately, the updates 373 are often incremental and the results are usually simpler than their 374 counterparts in IPv4 and IPv6. We briefly discuss a few essential 375 protocols that enables the operation of IPvn. 377 DHCP: An entity can be manually configured or dynamically acquire 378 its address when booting up. Each network in the edge network 379 hierarchy may contain a Dynamic Host Configuration Protocol (DHCP) 380 server responsible for assigning addresses (or IDs) to the 381 entities in the same network. The protocol is almost identical to 382 that for IPv4 and IPv6, except that the assigned address length is 383 adaptive to the allocated network size. 385 DNS: For an entity to acquire the address of a peer entity in order 386 to initiate a communication, Domain Name System (DNS) is the 387 prominent approach but with a new service model. Any network in 388 the hierarchy can provide name service. Each entity is configured 389 with the address of the closest DNS server on the path to the root 390 network. The hierarchical network architecture allows a scoped 391 domain name service. That is, a name registered in a network is 392 only valid in this network and its child networks. It is possible 393 that a same name is registered in two networks and one network is 394 the other's ancestor. Such name conflict is not a bug but a 395 feature for name reuse, which is transparent to the name query 396 process. In this case, the name resolved from the closer DNS 397 server is used. 399 Each network may contain a DNS server (the notation is only 400 logical. The actual implementation may follow the same 401 hierarchical and distributed architecture of today's DNS). Each 402 DNS server knows the nearest DNS server in a higher level network 403 and the nearest DNS servers in lower level networks. This 404 essentially organizes the DNS servers in the same tree structure 405 as the hierarchical network. Each named entity in a network is 406 registered with the DNS server that covers its scope, which is 407 basically a subtree. 409 We have several methods to populate the name to support the scoped 410 name queries, each with different storage and performance trade- 411 off: 1) register the name in all the DNS servers in its scope 412 (i.e., all the subtree nodes); 2) recursively register the name in 413 every parent DNS server until the scope root; and 3) register the 414 name only in the DNS server in its scope root. The address for a 415 name returned by a DNS server is on a "need-to-know" basis. In a 416 network, if the address's prefix matches the query's address 417 prefix, the prefix is removed. This can be easily done by the 418 original or the relay DNS servers. If a query cannot be resolved 419 by the DNS server in the L0 network, the query, after the IP 420 protocol translation is done, exits the IPvn domain and enters 421 into the IPv4/IPv6 domain to a public DNS server. When the 422 response comes back and enters the edge network, the result can be 423 cached by the DNS servers on the path. 425 ARP: In a L2-based network, the operation of Address Resolution 426 Protocol (ARP) or Neighbor Discovery Protocol (NDP) is almost 427 identical to that for IPv4 and IPv6. In an L2- based network, 428 each immediate entity should be configured with a default gateway 429 address to its parent network. If no default gateway is 430 configured, a network LGR should be configured as an ARP proxy to 431 respond to all internal ARP requests for addresses out of the 432 network. Similarly, the LGRs to any child network of this network 433 are also needed to be configured as ARP proxy to response all ARP 434 requests for addresses in that network. Due to the multi-homing 435 gateway routers, an ARP request may receive multiple responses. 436 It is up to the requester to determine which one to cache. 438 Routing Protocol: The entire edge network may belong to a single AS, 439 so the interior gateway routing protocols (IGP) such as OSPF and 440 IS-IS can be used. Other child networks in this network can be 441 considered OSPF stub areas or IS-IS levels. A simpler way is that 442 each network run an independent instance of OSPF or IS-IS. 444 Specially, an LGR at a network border runs two OSPF/IS-IS 445 instances: one for the upper-level network and the other for the 446 lower-level network. The hierarchical architecture solves the 447 routing protocol scalability issue, and simplifies the protocol 448 implementation by removing unnecessary features. The clean 449 routing scope helps to secure the infrastructure and troubleshoot 450 the networks. 452 3.2. Data Plane 454 IPvn Socket for End Entities: To enable IPvn as a new network layer 455 protocol in end entities, we need to add the protocol 456 implementation in the OS Kernel and allow applications to invoke 457 the socket API using the address family parameter AF_INETN. The 458 L4-L7 protocol stack and the application logic remains the same, 459 allowing direct communication between entities in IPvn domain and 460 in IPv4/IPv6 domain. 462 Forwarding Table Lookups in Networks: The short hierarchical address 463 simplifies the router forwarding table structure in L3-based 464 networks. A forwarding table only contains the addresses to local 465 entities and the prefixes to the child networks. Since there is 466 no nested prefixes, the Longest Prefix Matching (LPM) is not 467 necessary. The small number of unique prefix lengths allows the 468 prefixes to be grouped on lengths and each group to be implemented 469 as a hash table. A lookup can search all the hash tables in 470 parallel, and at most one table can result a positive match. This 471 design avoids the use of expensive TCAM or other complex trie- 472 based algorithms. 474 An LGR between an L_i network and an L_(i+1) network has two types 475 of interfaces: one faces the L_i network and the other faces the 476 L_(i+1) network. One LGR may serve more than one L_(i+1) network. 477 Hence, an LGR may contain multiple logical forwarding tables, with 478 each for a network. For a packet in LGR, once its target network 479 is determined and the address related fields are processed, the 480 proper forwarding table can be searched. 482 3.3. Using NAT for the edge network 484 To expand the address space of the edge network, the IPT of the edge 485 network can also support functions similar to NAT. In this case, the 486 edge network is assigned one or more public IPv4/IPv6 addresses. The 487 entities in IPvn domain use private addresses. The IPT maintains the 488 mapping table between the private address and public address. 490 4. Security Considerations 492 The addressing scheme and architecture allow a securer edge network. 494 5. IANA Considerations 496 The proposal requires to use a new IP version and define a new IP 497 header which can be converted to/from an equivalent IPv6 header. 499 6. Acknowledgments 501 We acknowledge the technical contributions, suggestions and comments 502 from Yingzhe Qu, Zhaobo Zhang, James Guichard, Toerless Eckert, 503 Stewart Bryant, and Michael McBride. 505 7. References 507 7.1. Normative References 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", BCP 14, RFC 2119, 511 DOI 10.17487/RFC2119, March 1997, 512 . 514 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 515 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 516 May 2017, . 518 7.2. Informative References 520 [RFC7775] Ginsberg, L., Litkowski, S., and S. Previdi, "IS-IS Route 521 Preference for Extended IP and IPv6 Reachability", 522 RFC 7775, DOI 10.17487/RFC7775, February 2016, 523 . 525 Author's Address 527 Haoyu Song 528 Futurewei Technologies 529 Santa Clara 530 USA 532 Email: haoyu.song@futurewei.com