idnits 2.17.1 draft-dunbar-trill-directory-assisted-edge-05.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 69 characters in excess of 72. 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 (March 11, 2012) is 4422 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: 'RBridges' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'RBridges-AF' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'ARMD-Problem' is defined on line 493, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RBridges' -- Possible downref: Non-RFC (?) normative reference: ref. 'RBridges-AF' -- Possible downref: Non-RFC (?) normative reference: ref. 'ARMD-Problem' Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL working group L. Dunbar 2 Internet Draft D. Eastlake 3 Intended status: Standard Track Huawei 4 Expires: Sept 2012 Radia Perlman 5 Intel 6 I. Gashinsky 7 Yahoo 8 March 11, 2012 10 Directory Assisted RBridge Edge 11 draft-dunbar-trill-directory-assisted-edge-05.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF). Note that other groups may also distribute 20 working documents as Internet-Drafts. The list of current Internet- 21 Drafts is at http://datatracker.ietf.org/drafts/current/. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 This Internet-Draft will expire on September 11, 2012. 30 Copyright Notice 32 Copyright (c) 2012 IETF Trust and the persons identified as the 33 document authors. All rights reserved. 35 This document is subject to BCP 78 and the IETF Trust's Legal 36 Provisions Relating to IETF Documents 37 (http://trustee.ietf.org/license-info) in effect on the date of 38 publication of this document. Please review these documents 39 carefully, as they describe your rights and restrictions with 40 respect to this document. Code Components extracted from this 41 document must include Simplified BSD License text as described in 42 Section 4.e of the Trust Legal Provisions and are provided without 43 warranty as described in the Simplified BSD License. 45 Abstract 46 RBridge edge nodes currently learn the mapping between MAC addresses 47 and their corresponding RBridge edge nodes by observing the data 48 packets traversed through. When ingress RBridge receives a data 49 packet with its destination address (MAC&VLAN) unknown, the data 50 packet is flooded across RBridge domain. When there are more than 51 one RBridge ports connected to one bridged LAN, only one of them can 52 be designated as AF port for forwarding/receiving traffic for each 53 LAN, the rest have to be blocked for that LAN. 55 This draft describes the framework of using directory assisted 56 RBridge edge to improve TRILL network scalability in data center 57 environment. 59 Conventions used in this document 61 The term ''Subnet'' and ''VLAN'' are used interchangeably in this 62 document because it is common to map one subnet to one VLAN. The 63 term ''TRILL'' and ''RBridge'' are used interchangeably in this 64 document. 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC-2119 0. 70 Table of Contents 72 1. Introduction ................................................ 3 73 2. Terminology ................................................. 3 74 3. Impact on RBridge domain of massive number of hosts in Data 75 Center ......................................................... 4 76 3.1. Issues of Flooding Based Learning in Data Centers ........ 4 77 3.2. Some Examples .......................................... 5 78 4. Benefits of Directory Assisted RBridge Edge in DC Environment . 7 79 5. Generic operation of Directory Assistance.................... 8 80 5.1. Information in Directory Servers for TRILL.............. 8 81 5.2. Push Model ............................................. 8 82 5.3. Pull model: ........................................... 10 83 6. Conclusion and Recommendation............................... 11 84 7. Manageability Considerations................................ 11 85 8. Security Considerations..................................... 11 86 9. IANA Considerations ........................................ 11 87 10. Acknowledgments ........................................... 11 88 11. References ................................................ 12 89 Authors' Addresses ............................................ 12 90 Intellectual Property Statement................................ 13 91 Disclaimer of Validity ........................................ 13 93 1. Introduction 95 Data center networks are different from campus networks in several 96 ways, in particular: 98 1. Data centers, especially Internet or multi-tenant data centers, 99 tend to have large number of hosts with a wide variety of 100 applications. 101 2. Topology is based on racks and rows. 102 Hosts assignment to Servers, Racks, and Rows is orchestrated 103 by Server/VM Management system, not at random. 104 3. Rapid workload shifting in data centers can accelerate the 105 frequency of one physical server being re-loaded with different 106 applications. Sometimes, applications re-loaded to one physical 107 server at different time can belong to different subnets. 108 4. With server virtualization, there is an ever-increasing trend to 109 dynamically create or delete VMs when demand for resource changes, 110 to move VMs from overloaded servers, or to aggregate VMs onto 111 fewer servers when demand is light. 113 Both 3) and 4) above can lead to hosts in one subnet being placed 114 under different locations (racks or rows) or one rack having hosts 115 belonging to different subnets. 117 This draft describes why and how Data Center TRILL networks can be 118 optimized by utilizing a directory assisted approach. 120 2. Terminology 122 AF Appointed Forwarder RBridge port 124 Bridge: IEEE 802.1Q compliant device. In this draft, Bridge is used 125 interchangeably with Layer 2 switch. 127 DA: Destination Address 129 DC: Data Center 131 EoR: End of Row switches in data center. Also known as 132 Aggregation switches in some data centers 134 FDB: Filtering Database for Bridge or Layer 2 switch 135 Host: Application running on a physical server or a virtual 136 machine. A host usually has at least one IP address and at 137 least one MAC address. 139 SA: Source Address 141 STP: Spanning Tree Protocol 143 RSTP: Rapid Spanning Tree Protocol 145 ToR: Top of Rack Switch in data center. It is also known as 146 access switches in some data centers. 148 VM: Virtual Machines 150 3. Impact on RBridge domain of massive number of hosts in Data Center 152 3.1. Issues of Flooding Based Learning in Data Centers 154 It is common for Data Center networks to have multiple tiers of 155 switches, e.g. one or two Access Switches for each server rack 156 (ToR), aggregation switches for some rows (or EoR switches), and 157 some core switches to interconnect the aggregation switches. Many 158 aggregation switches deployed in data centers are high port density 159 switches. It is not uncommon to see aggregation switches 160 interconnecting hundreds of ToR switches. 162 +-------+ +------+ 163 +/------+ | +/-----+ | 164 | Aggr11| + ----- |AggrN1| + EoR Switches 165 +---+---+/ +------+/ 166 / \ / \ 167 / \ / \ 168 +---+ +---+ +---+ +---+ 169 |T11|... |T1x| |T21| ? |T2y| ToR switches 170 +---+ +---+ +---+ +---+ 171 | | | | 172 +-|-+ +-|-+ +-|-+ +-|-+ 173 | |... | | | | ? | | 174 +---+ +---+ +---+ +---+ Server racks 175 | |... | | | | ? | | 176 +---+ +---+ +---+ +---+ 177 | |... | | | | ? | | 178 +---+ +---+ +---+ +---+ 179 Figure 1: Typical Data Center Network Design 181 When TRILL is deployed in a data center with large number of hosts, 182 with the possibility of hosts in one subnet/VLAN being placed under 183 multiple edge RBridges and each edge RBridge having hosts from 184 different subnets/VLANs, the following problems will occur: 186 Unnecessary filling of slots in MAC table of edge RBridges, due 187 to edge RBridge receiving broadcast/multicast traffic (e.g. 188 ARP/ND, cluster multicast, etc.) from hosts under other edge 189 RBridges that are not actually communicating with any hosts 190 attached to the RBridge. 191 Some edge RBridge ports being blocked for user traffic when 192 there are more than one RBridge ports connected to one bridged 193 LAN. When there are multiple RBridge ports connected to a 194 bridged LAN, only one, i.e. the AF port, can forward/receive 195 traffic for that bridged LAN (i.e. VLAN), the rest have to be 196 blocked for forwarding/receiving traffic for that VLAN. When a 197 rack has dual uplinks to two different ToR switches ( RBridge 198 Edges), which is very common in data center environment, some 199 links can't be fully utilized. 200 Packets being flooded across RBridge domain when their DAs are 201 not in ingress RBridge's cache. 202 In an environment where VMs migrates, there is higher chance of 203 cached entries becoming invalid, causing traffic to be black 204 holed or re-flooded by the egress RBridge. If VMs send out 205 gratuitous ARP/ND or IEEE802.1Qbg's VDP upon arriving at new 206 locations, the ingress nodes might not have the MAC entries for 207 the newly arrived VMs, causing more unknown flooding. 209 3.2. Some Examples 211 Consider a data center with 1600 server racks. Each server rack has 212 at least one ToR switch. The ToR switches are further divided to 8 213 groups, with each group being connected by a set of aggregation 214 switches. There could be 4 to 8 aggregation switches in each set to 215 achieve load sharing for traffic to/from server racks. If TRILL is 216 to be deployed in this data center environment, let's consider 217 following two scenarios for the TRILL domain boundary: 219 Scenario #1: TRILL domain boundary starts at ToR switches: 221 If each server rack has one uplink to one ToR, there are 1600 222 edge RBridges. If each rack has dual uplinks to two ToR 223 switches, then there will be 3200 edge RBridges 225 In this scenario, the RBridge domain will have more than 1600 226 (or 3200) + 8*4 (or 8*8) nodes, which is quite a large IS-IS 227 domain. Even though a mesh IS-IS domain can scale up to 228 thousands of nodes, it is very challenging for aggregation 229 switches to handle IS-IS link state advertisement among 230 hundreds of parallel ports. 232 Scenario #2: TRILL domain boundary starts at the aggregation 233 switches: 235 With the same assumption as before, the number of nodes in 236 RBridge domain will be less than 100, and aggregation switches 237 don't have to handle IS-IS link state advisements among 238 hundreds of ports. 240 But in this scenario, aggregation switches' downstream 241 ports/links to ToR switches form the bridged LAN with links 242 from ToR switches to servers. With aggregation switches being 243 the RBridge edge nodes, multiple RBridge edge ports could be 244 connected to one bridged LAN. To avoid potential loops TRILL 245 requires only one of multiple RBridge edge ports connected to 246 one VLAN being designated as Appointed Forwarder (AF port) for 247 forwarding native traffic across RBridge domain for that VLAN. 248 That means other ports/links are blocked for native frames in 249 that VLAN. 251 There is also possibility of loops on the bridged LAN attached 252 to RBridge edge ports unless STP/RSTP is running. Running 253 traditional Layer 2 STP/RSTP on the bridged LAN in this 254 environment may be overkill because the topology among the ToR 255 switches and aggregation switches is very simple. 257 In addition, the number of MAC&VLAN<->RBridgeEdge Mapping 258 entries to be learned and managed by RBridge edge node can be 259 very large. In the example above, each edge RBridge has 200 260 edge ports facing the ToR switches. If each ToR has 40 261 downstream ports facing servers and each server has 10 VMs, 262 there could be 200*40*10 = 80000 hosts attached. If all those 263 hosts belong to 1600 VLANs (i.e. 50 per VLAN) and each VLAN has 264 200 hosts, then under the worst case scenario, the total number 265 of MAC&VLAN entries to be learned by the RBridge edge can be 266 1600*200=320000, which is very large. 268 4. Benefits of Directory Assisted RBridge Edge in DC Environment 270 In data center environment, applications placement to servers, 271 racks, and rows is orchestrated by Server (or VM) Management 272 System(s). I.e. there is a database or multiple ones (distributed 273 model) which have the knowledge of where each host is located. If 274 that host location information can be fed to RBridge edge nodes, in 275 some form of Directory Service, then RBridge edge nodes won't need 276 to flood data frames with unknown DA across RBridge domain. 278 Avoiding unknown DA flooding to RBridge domain is especially 279 valuable in data center environment because there is higher chance 280 of an RBridge edge receiving packets with unknown DA and 281 broadcast/multicast messages due to VM migration and servers being 282 loaded with different applications. When a VM is moved to a new 283 location or a server is loaded with a new application with different 284 IP/MAC addresses, it is more likely that the DA of data packets sent 285 out from those hosts are unknown to their attached RBridge edges. 286 In addition, gratuitous ARP (IPv4) or Unsolicited Neighbor 287 Advertisement (IPv6) sent out from those newly migrated or activated 288 hosts have to be flooded to other RBridge edges which have hosts in 289 the same subnets. 291 The benefits of using directory assistance include: 293 Avoid flooding unknown DA across RBridge domain. The Directory 294 enforced MAC&VLAN <-> RBridgeEdge mapping table can determine 295 if a data packet needs to be forwarded across RBridge domain. 297 When multiple RBridge edge ports are connected via bridged LAN 298 to hosts (servers/VMs), a directory assisted RBridge edge won't 299 need to flood unknown DA data frames to all ports of the 300 RBridge edge. Under this circumstance, there is no chance for 301 those data frames looping among multiple ports of RBridge edge. 302 Therefore, it is no longer necessary to designate one Appointed 303 Forwarder among all the RBridge Edge ports connected to a 304 bridge LAN, which means that all RBridge ports can 305 forward/receive traffic. 307 Reduce flooding decapsulated Ethernet frames with unknown MAC- 308 DA to a bridged LAN connected to RBridge edge ports. 310 When an RBridge receives a TRILL frame whose destination 311 Nickname matches with its own, the normal procedure is for the 312 RBridge to decapsulate the TRILL header and forward the 313 decapsulated Ethernet frame to its directly attached bridged 314 LAN. If the destination MAC is unknown, the decapsulated 315 Ethernet frame is flooded in the LAN. With directory 316 assistance, the RBridge edge can determine if DA in a frame 317 matches with any hosts attached via the bridged LAN. Therefore, 318 frames can be discarded if their DAs do not match. 320 Reduce the amount of MAC&VLAN <-> RBridgeEdge mapping 321 maintained by RBridge edge. There is no need for an RBridge 322 edge to keep the MAC entries for hosts which don't communicate 323 with hosts attached to the RBridge edge. 325 5. Generic operation of Directory Assistance 327 5.1. Information in Directory Servers for TRILL 329 To achieve the benefits of directory service for TRILL, the 330 corresponding directory server will need minimum following 331 attributes: 333 [IP, MAC, attached RBridge nickname, {list of interested RBridges}] 335 The {list of interested RBridges} would get populated when an 336 RBridge queries for information, or pushed down from management 337 systems. The list is used to notify those RBridges if VMs to 338 RBridge's connectivity changes due to VMs migration or link 339 failures. 341 There can be two different models for RBridge edge node to be 342 assisted by Directory Service: Push Model and Pull Model. 344 5.2. Push Model 346 Under this model, Directory Server(s) push down the MAC&VLAN <-> 347 RBridgeEdge mapping for all the hosts which might communicate with 348 hosts attached to an RBridge edge node. With this environment, it is 349 recommended that RBridge edge simply drop a data packet (instead of 350 flooding to RBridge domain) if the packet's destination address 351 can't be found in the MAC&VLAN<->RBridgeEdge mapping table. 353 It may not be necessary for every RBridge edge to get the entire 354 mapping table for all the hosts in a data center. There are many 355 ways to narrow the full set down to a smaller set of remote hosts 356 which communicate with hosts attached to an RBridge edge. A simple 357 approach of only pushing down the mapping for the VLANs which have 358 active hosts under an RBridge edge can reduce the number of mapping 359 entries pushed down. 361 However, it is inevitable that RBridge edge's MAC&VLAN<->RBridgeEdge 362 mapping table will have more entries than they really need under the 363 Push Model. When hosts attached to one RBridge Edge rarely 364 communicate with hosts attached to different RBridge edges even 365 though they are on the same VLAN, the normal process of RBridge 366 edge's unknown DA flooding, learning and cache aging would have 367 removed those MAC&VLAN entries from the RBridge's cache. But it can 368 be difficult for Directory Servers to predict the communication 369 patterns among hosts within one VLAN. Therefore, it is likely that 370 the Directory Servers will push down all the MAC&VLAN entries if 371 there are hosts in the VLAN being attached to the RBridge Edge. This 372 is a major disadvantage of push down model. 374 In push down model, it is necessary to have a message for RBridge 375 node to request directory server(s) to start pushing down the 376 mapping entries. This message should at least include the number 377 VLANs enabled on the RBridge, so that directory server doesn't need 378 to push down the entire mapping entries for all the hosts in the 379 data center. RBridge node can use this message to get mapping 380 entries when it is initialized or restarted. 382 The detailed message format and hand-shake mechanism between RBridge 383 and Directory Server(s) will be described in a separate draft 384 because this draft only focuses on the framework of directory 385 assisted Edge. 387 When directory pushes down the entire mapping to an edge RBridge for 388 the very first time, there usually are many entries. To minimize the 389 number of entries pushed down, summarization should be considered, 390 e.g. with one edge RBridge Nickname being associated with all 391 attached hosts' MAC addresses and VLANs as shown below: 393 +------------+-------+--------------------------------+ 394 | Nickname1 |VID-1 | MAC1, MAC2, ,MACn | 395 | |------ +--------------------------------+ 396 | |VID-2 | MAC1, MAC2, ,MACn | 397 | |------ +--------------------------------+ 398 | |... | MAC1, MAC2, ,MACn | 399 +------------+------ +--------------------------------+ 400 | Nickname2 |VID-1 | MAC1, MAC2, ,MACn | 401 | |------ +--------------------------------+ 402 | |VID-2 | MAC1, MAC2, ,MACn | 403 | |------ +--------------------------------+ 404 | |... | MAC1, MAC2, ,MACn | 405 +------------+------ +--------------------------------+ 406 | ------- |------ +--------------------------------+ 407 | |... | MAC1, MAC2, ,MACn | 408 +------------+------ +--------------------------------+ 409 Table 1: Summarized table pushed down from directory 411 Whenever there is any change in MAC&VLAN <-> RBridgeEdge mapping, 412 which can be triggered by hosts being added, moved, or de- 413 commissioned, an incremental update can be sent to the RBridge edges 414 which are impacted by the change. Therefore, something like sequence 415 number has to be maintained by directory servers and RBridges. 416 Detailed mechanisms will be described in a separate draft. 418 5.3. Pull model: 420 Under this model, ''RBridge'' pulls the MAC&VLAN<->RBridgeEdge mapping 421 entry from the directory server when needed. There are several 422 options to trigger the pulling process. For example, the RBridge 423 edge node can send a pulling request whenever it receives an unknown 424 DA, or RBridge edge node can simply intercept all ARP/ND requests 425 and forward them to the Directory Server(s) that has the information 426 on where each host is located. RBridge ingress node can cache the 427 mapping pulled down from the directory. 429 One advantage of the Pull Model is that RBridge edge can age out 430 MAC&VLAN entries if they haven't been used for a certain period of 431 time. Therefore, each RBridge edge will only keep the entries which 432 are frequently used, i.e. mapping table size can be smaller. RBridge 433 edge would query the Directory Server(s) for unknown DAs in data 434 frames or ARP/ND and cache the response. When hosts attached to one 435 RBridge Edge rarely communicate with hosts attached to different 436 RBridge edges even though they are on the same VLAN, the 437 corresponding MAC&VLAN entries would be aged out from the RBridge's 438 cache. 440 Some people are concerned of the performance with RBridge waiting 441 for response from Directory Servers upon receiving a data frame with 442 unknown DA. Actually this waiting practice is a common router 443 behavior. Most deployed routers today do hold the packets and send 444 an ARP/ND to the target upon receiving a packet with DA not in its 445 IP-MAC cache. When ARP/ND replies are received, the router will send 446 the data frame to the target. This practice is to minimize flooding 447 when targets don't exist in the subnet. 449 When the target doesn't exist in the subnet, routers generally re- 450 send ARP/ND request a few more times before dropping the packets. 451 Therefore, the holding time by routers to wait for ARP/ND response 452 can be longer than the time taken by the Pull Model to get IP-MAC 453 mapping from directory if target doesn't exist in the subnet. 455 A separate draft will describe the detailed messages and mechanism 456 for RBridge edge to pull information from directory server(s). 458 6. Conclusion and Recommendation 460 The traditional RBridge learning approach of observing data plane 461 can no longer keep pace with the ever growing number of hosts in 462 Data center. 464 Therefore, we suggest TRILL consider directory assisted 465 approach(es). This draft only describes the basic framework of using 466 directory assisted approach for RBridge edge nodes. More complete 467 mechanisms will be described in separate drafts. 469 7. Manageability Considerations 471 TBD. 473 8. Security Considerations 475 TBD. 477 9. IANA Considerations 479 TBD 481 10. Acknowledgments 483 This document was prepared using 2-Word-v2.0.template.dot. 485 11. References 487 [RBridges] Perlman, et, al ''RBridge: Base Protocol Specification'', 488 , March, 2010 490 [RBridges-AF] Perlman, et, al ''RBridges: Appointed Forwarders'', 491 , April 2011 493 [ARMD-Problem] Dunbar, et,al, ''Address Resolution for Large Data 494 Center Problem Statement'', Oct 2010. 496 [ARP reduction] Shah, et. al., "ARP Broadcast Reduction for Large Data 497 Centers", Oct 2010 499 Authors' Addresses 501 Linda Dunbar 502 Huawei Technologies 503 5430 Legacy Drive, Suite #175 504 Plano, TX 75024, USA 505 Phone: (469) 277 5840 506 Email: ldunbar@huawei.com 508 Donald Eastlake 509 Huawei Technologies 510 155 Beaver Street 511 Milford, MA 01757 USA 512 Phone: 1-508-333-2270 513 Email: d3e3e3@gmail.com 514 Radia Perlman 515 Intel Labs 516 2200 Mission College Blvd. 517 Santa Clara, CA 95054-1549 USA 518 Phone: +1-408-765-8080 519 Email: Radia@alum.mit.edu 521 Igor Gashinsky 522 Yahoo 523 45 West 18th Street 6th floor 524 New York, NY 10011 525 Email: igor@yahoo-inc.com 527 Intellectual Property Statement 529 The IETF Trust takes no position regarding the validity or scope of 530 any Intellectual Property Rights or other rights that might be 531 claimed to pertain to the implementation or use of the technology 532 described in any IETF Document or the extent to which any license 533 under such rights might or might not be available; nor does it 534 represent that it has made any independent effort to identify any 535 such rights. 537 Copies of Intellectual Property disclosures made to the IETF 538 Secretariat and any assurances of licenses to be made available, or 539 the result of an attempt made to obtain a general license or 540 permission for the use of such proprietary rights by implementers or 541 users of this specification can be obtained from the IETF on-line 542 IPR repository at http://www.ietf.org/ipr 544 The IETF invites any interested party to bring to its attention any 545 copyrights, patents or patent applications, or other proprietary 546 rights that may cover technology that may be required to implement 547 any standard or specification contained in an IETF Document. Please 548 address the information to the IETF at ietf-ipr@ietf.org. 550 Disclaimer of Validity 552 All IETF Documents and the information contained therein are 553 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 554 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 555 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 556 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 557 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 558 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 559 FOR A PARTICULAR PURPOSE. 561 Acknowledgment 563 Funding for the RFC Editor function is currently provided by the 564 Internet Society.