idnits 2.17.1 draft-finn-ppvpn-bridging-vpls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([ANDERSSON], [LASSERRE-VKOMPELLA]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-andersson-ppvpn-l2-framework-00 -- Possible downref: Normative reference to a draft: ref. 'ANDERSSON' == Outdated reference: A later version (-04) exists of draft-lasserre-vkompella-ppvpn-vpls-01 -- Possible downref: Normative reference to a draft: ref. 'LASSERRE-VKOMPELLA' -- Possible downref: Normative reference to a draft: ref. 'SAJASSI' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Provider Provisioned VPN WG N. Finn (Cisco) 3 Internet-draft M. Seaman (Consultant) 4 Expires: December 2002 A. Smith (Consultant) 5 A. Romanow (Cisco) 7 Bridging and VPLS 8 draft-finn-ppvpn-bridging-vpls-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 Layer 2 techniques based on IEEE 802.1Q bridges are in widespread 39 use by Ethernet MAN Service Providers. It is possible to implement 40 the data plane functionality of Service Provider Backbone as 41 described in the framework draft [ANDERSSON] using bridges as the 42 Provider Edge (PE) equipment. There are three small but 43 significant changes to the [LASSERRE-VKOMPELLA] VPLS draft which 44 would make the Service Provider Backbone much more compatible with 45 a bridge-based PE implementation, and which would improve the 46 efficiency of all L2VPN implementations. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Signaling the Need to Unlearn MAC Addresses . . . . . . . 3 52 2.1. Requirement for Unlearning MAC Addresses . . . . . . . . 3 53 2.2. How Bridges Forget MAC Addresses . . . . . . . . . . . . 4 54 2.3. Improved L2VPN Flush Messages . . . . . . . . . . . . . 5 55 3. Send Flush on Recovery, Not Failure . . . . . . . . . . . 5 56 4. Independent vs. Shared Address Learning . . . . . . . . . 8 57 Acknowledgements . . . . . . . . . . . . . . . . . . . . 9 58 References . . . . . . . . . . . . . . . . . . . . . . . 10 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . 10 60 Full Copyright Statement . . . . . . . . . . . . . . . . 11 62 1. Introduction 64 A number of Ethernet Service Providers are currently building their 65 networks using purely L2 technologies, based around bridges. When 66 such an L2-oriented network provider looks at the architecture of 67 [ANDERSSON], the similarity of Provider Edges (PEs) and bridges is 68 unavoidable, and the desirability of constructing a PE based on a 69 bridge is attractive. A bridge-based PE allows the Provider to 70 make use of the extensive capabilities of the current generation of 71 bridges. 73 Trying to base a PE implementation on a bridge raises certain 74 issues with the specification and implementation of L2VPNs which 75 have not been addressed in the drafts, to date. Resolving these 76 issues requires some minor changes to [LASSERRE-VKOMPELLA]. These 77 are: 79 1. Two new "forget MAC addresses" L2VPN control packets are 80 needed. 82 2. "Forget MAC addresses" L2VPN control packets should be sent 83 when backup links become activated, not when links fail. 85 3. It must be possible to configure associations among L2VPN 86 instances such that a group of L2VPNs share a single MAC 87 address database in any given attached device, but different 88 groups of L2VPNs use different databases. 90 This present document assumes the validity of the [ANDERSSON] and 91 [LASSERRE-VKOMPELLA] drafts. We use the terminology of 92 [ANDERSSON], borrowing from [LASSERRE-VKOMPELLA] and [SAJASSI] when 93 needed. 95 Sections 2 and 3 explain the need to have forms of the [LASSERRE- 96 VKOMPELLA] flush message that are compatible with the operation of 97 bridges, and the necessary timing of sending those messages. 98 Section 4 describes a requirement to allow some L2VPNs to share a 99 common MAC address database. 101 2. Signaling the Need to Unlearn MAC Addresses 103 The "flush" message of [LASSERRE-VKOMPELLA] is inadequate to the 104 needs of bridges either serving as PEs or as part of an Access 105 Network [ANDERSSON] in a Provider Network. The two forms of the 106 flush message are, "forget all MAC addresses in this list," and 107 "forget all the MAC addresses you learned from me." There is no 108 way for a bridge to generate an accurate list of MAC addresses for 109 the first message, and no circumstances under which a bridge would 110 issue the second message. 112 The following sub-sections describe the need for unlearning, how 113 the two major spanning tree protocols handle the deliberate 114 forgetting of MAC address information, and the bridge requirements 115 for flush messages. 117 2.1. Requirement for Unlearning MAC Addresses 119 If bridges operate over Psuedo Wires (PWs) such that redundant PEs 120 are provided to improve the availability of the Provider Network, 121 then the possibility arises that changes in an Ethernet Service 122 Provider's Access Network will require packets to take different 123 paths through the Provider Backbone. An obvious example is shown 124 in Figure 1: 126 +-------------+ .1Q +----------+ PW1 +----------+ +-------------+ 127 + PE-bridge 1 +-----+ PE 1 +------+ PE 3 +---+ PE-bridge 2 | 128 +-+---------+-+ +--------+-+ +-+--------+ +-----------+-+ 129 | Ether \ PW2 | Backbone / Ether | 130 | \ .1Q +--------+-+ / | 131 Customer '----+ PE 3 +-----' Customer 132 Station A +----------+ PW3 Station B 134 FIGURE 1: Unlearning MAC addresses in L2VPN due to L2 changes 136 In this diagram, we have five Provider bridges, PE-bridge 1 and 2, 137 and PEs 1 through 3. The PWs of one (data) VLPLS are shown. Keep 138 in mind, however that we are not using spanning tree to select 139 among PWs; the PWs form a full mesh, and split horizon is used to 140 prevent loops within the L2VPN. 142 Spanning tree may, however, be running over the whole network, in 143 which case spanning tree Bridge Protocol Data Units (BPDUs) may be 144 carried as ordinary multicast data over one or more of the PWs. 146 Suppose that the normal path between stations A and B goes through 147 PE 1. PE 3 has learned this fact, and directs its packets destined 148 for station A to PE 1. If the link between PE-bridge 1 and PE 1 149 fails, then it is possible that the redundancy/failover algorithm 150 in use will select PE 2, rather than PE 1, to be the portal to the 151 Backbone. In that case, PE 3 needs to "unlearn" its association 152 between MAC address A and PE 1. 154 2.2. How Bridges Forget MAC Addresses 156 The spanning tree algorithms in [802.1D] and [802.1w] provide two 157 methods for notifying bridges when MAC address information needs to 158 be unlearned. The "classic" Spanning Tree Protocol, STP, defined 159 in [802.1D] describe one way, and the new Rapid Spanning Tree 160 Protocol (RSTP) in [802.1w] behaves another way. 162 In STP, when a topology change occurs, notification of the change 163 is transmitted to the root bridge, which in turn relays the fact to 164 all bridges. The notification is not directional; the root places 165 all bridges in "topology change mode" for a certain length of time, 166 then returns all bridges to normal mode. While in topology change 167 mode, all MAC address information is timed out over a much shorter 168 period than is normally the case. 170 In normal times, the default timeout period for MAC address 171 information is five minutes. During a topology change, that time 172 shortens to a default value of 15 seconds. This time is comparable 173 to the time during which service may be interrupted by a topology 174 change. The shortened timeout period ensures that stale 175 directionality information will not survive the topology change. 176 Note that, if the MAC addresses were instantly forgotten, instead 177 of timed out rapidly, a great deal of traffic otherwise unaffected 178 by the topology change would be unnecessarily flooded. 180 In RSTP, a Topology Change Notification (TCN) is initiated only by 181 a bridge port that has just transitioned from standby to 182 operational status. It is generated only on that newly operational 183 port, and is then relayed along the spanning tree by the other 184 bridges. Thus, RSTP TCNs have a direction of propagation, and 185 bridges "behind" the new link do not receive it. Since RSTP can 186 converge in milliseconds after a topology change, receipt of a TCN 187 causes a bridge to instantly forget many MAC addresses. A bridge 188 does not forget MAC addresses associated with the port on which the 189 TCN was received; one can prove that the MAC address information on 190 that port cannot be affected by any topology change. 192 2.3. Improved L2VPN Flush Messages 194 To be consistent with bridges, the L2VPN learning and forgetting 195 rules must be compatible with the bridge rules described in the 196 previous section. The two specific L2VPN messages required for 197 full compatibility with all standard bridges are: 198 v.IP 1. STP TOPOLOGY CHANGE START/END. Set the timeout 199 period of all learned MAC addresses on this list of L2VPNs to 200 this number of seconds. This message is transmitted with a 201 shortened timeout value at the beginning of a "classic" STP 202 topology change event, and transmitted with the default 203 timeout period after the event ends. 205 2. RSTP TOPOLOGY CHANGE. Immediately delete all MAC address 206 information on this list of L2VPNs except that information 207 learned from the sender of this message. (Note that this is 208 exactly the opposite from the current "flush all you learned 209 from the sender" message.) 211 The first message, which is compatible with the old STP, is of 212 questionable utility, simply because it is needed by a form of STP 213 which takes 10s of seconds to converge after the failure or 214 recovery of a node or link. The Rapid Spanning tree converges much 215 more quickly, and uses the second form. 217 To the best of the authors' knowledge, these two actions are 218 sufficient to meet the needs of all proprietary Layer 2 219 failure/recovery protocols based on spanning tree. If not, 220 suggestions for additional actions are encouraged. 222 3. Send Flush on Recovery, Not Failure 224 In [LASSERRE-VKOMPELLA], a device that notices the failure of a 225 non-PW link is required to transmit the flush message(s) over the 226 Backbone. It is much better to transmit the flush messages at 227 recovery time, that is, when an alternate to the failed link 228 becomes operational, or when a new link is added. In brief, one 229 reason is that frames are best flooded when there is a good chance 230 that their destinations are reachable, and therefore will elicit 231 the replies that will terminate the flooding. The second reason is 232 that link failures cannot reliably be detected, whereas recovery 233 events are sure and certain. 235 In RSTP [802.1w], it is the device that starts using the backup 236 link that generates the flush message(s). 238 "backdoor" _________________________________ 239 link / \ 240 +--+-+ +----+ Y--+----+ +--+-+ 241 | B1 |-----| B2 |-----| B3 |........| B4 +--Z 242 +----+ ___+--+-+ +--+-+,.. ..+----+ 243 \/ | ___/ | : \ / : (Backbone) 244 /\___ | / | : : : 245 +----+ +--+-+ +--+-+;../ \..+----+ 246 X --+ B5 |-----| B6 |-----| B7 |........| B8 | 247 +----+ +----+ +----+ +----+ 249 Figure 2: L2VPN Flush Messages 251 In Figure 2, consider a PE B3 with some form of Ethernet 252 connections on one side, and the Pseudowire world on the other 253 side. If that PE discovers that a link has gone down, say the 254 B5-B2 link, the B2-B3 link, or the Y-B3 link, there are several 255 possibilities for what can be wrong or right about learned MAC 256 address information: 258 1. The link is permanently down. Those MAC addresses will be 259 unreachable for a very long time. 261 2. The link is momentarily down. Those MAC addresses will again 262 be reachable through the same link in a very short time. 264 3. The link is down, but a backup link to this same PE, carrying 265 those same MAC addresses, will very shortly be activated. 267 4 The link is down, but a backup link to another PE, carrying 268 those same MAC addresses, will very shortly be activated. 270 In all of these cases, forgetting the MAC addresses immediately 271 upon failure of the link does not help anything, especially if 272 there are a large number of them associated with the failed link. 273 If the MAC addresses "never" come back, they will eventually time 274 out and be deleted everywhere. Assuming that the link was running 275 at full speed when it failed, all of the traffic already in, queued 276 for transmission to, or about to be sent by the user to the 277 network, will be flooded throughout the L2VPN. Furthermore, this 278 burst of flooding is useless, as it will occur at the very moment 279 when it is the least likely that the flooded frames can reach their 280 destinations. This means, of course, that the out-of-touch 281 stations cannot respond to the flooded frames and put a stop the 282 flooding. The flooding continues until the upper layers decide to 283 wait for responses. 285 In fact, it is when a link transitions from backup to operational 286 status that MAC addresses can be profitably forgotten. Unless or 287 until an alternate path to the lost MAC addresses becomes 288 available, the packets destined for those MAC addresses is best 289 black-holed. If the MAC addresses never come back, then in the 290 usual case, the bridge MAC address timeouts are such that the upper 291 layers will give up on the conversation before the bridges forget 292 the MAC addresses and start flooding the doomed traffic. If the 293 MAC addresses do come back, then old information is deleted as the 294 first thing, and the flooded frames have a good chance of reaching 295 their (new) destinations. This is why RSTP waits until a link 296 comes up to generate a Topology Change Notification. Only when an 297 alternate path is available is there any reason to flood frames 298 everywhere. 300 Looking at Figure 2, suppose that links B5-B2, B2-B3, and the 301 Backbone PWs are the primary links between B5 and B4, and 302 specifically that B5-B6 is kept in reserve. In RSTP parlance, B5's 303 port to B2 is a (forwarding) root port, and B5's port to B6 is a 304 (discarding) alternate port. If the B5-B2 link fails, B5's port to 305 B6 becomes the forwarding root port, and a TCN is sent. Note that, 306 because of the direction of propagation of the TCN, B4 does not 307 forget address Y, because that address cannot possibly have 308 changed; the new link came up "behind" the Y-B3 connection. 309 Interestingly, B3 does have to forget address Z, because it cannot 310 know for certain that the "backdoor" link shown in the diagram has 311 not come into use to deliver frames from Z via B1 and B2. In other 312 words, RSTP does not assume that it knows the global topology. 313 However, any such needlessly flooded frames will reach their 314 destinations and be answered, and so will very quickly be 315 relearned. 317 Many bridges treat MAC addresses attached to configured local 318 access ports, rather than inter-bridge links, as sure knowledge. 319 Those MAC addresses are not deleted from the owning bridge. 321 If the device that brings up the new link knows what MAC addresses 322 it is serving, perhaps by configuration, then the best solution is 323 to transmit a "learn the following MAC addresses" control message. 324 This is ideal, and is provided by [LASSERRE-VKOMPELLA]. In 325 general, however, a bridge does not know this. 327 One should also consider what happens if the failure occurs in a 328 link not directly connected to the PE? What happens if the PE is 329 connected to a shared medium Ethernet, so that the loss of another 330 device's connection is invisible to the PE? (Shared media still 331 exist, new ones such as packet rings are being created, and 332 wireless hubs are very similar in nature.) What happens if only 333 one side of the connection gets a "glitch" and believes that the 334 link has momentarily gone down? 336 The RSTP solution is known to handle all of these cases correctly. 337 It would be better for any L2VPN solution to employ that same 338 technique. In other words: 340 1. As "classic" STP enters and leaves the topology change mode, 341 the bridge responsible for transmitting that fact to the 342 Backbone should also transmit the "accelerate timeouts" L2VPN 343 control message for all affected L2VPNs. {This is not needed 344 if classic STP is not to be supported.) 346 2. When a "rapid" RSTP bridge transmits a TCN BPDU over the 347 Backbone, it should also transmit the "forget all MAC 348 addresses not learned from me" L2VPN control message for the 349 Pseudowires associated with the affected spanning tree 350 instance. 352 3. When some L2 device not utilizing spanning trees, such as the 353 PE-CLE of [SAJASSI], switches to a new PE, it should transmit 354 a control message towards the new PE. This message causes the 355 PE to issue a "forget all MAC addresses not learned from me" 356 L2VPN control message only for the L2VPNs connected to the 357 affected PE-CLE. 359 4. Independent vs. Shared Address Learning 361 In order to be consistent with the current capabilities of [802.1Q] 362 bridges, it must be possible to configure any number of L2VPNs 363 either to use separate MAC address databases, as specified in 364 [LASSERRE-VKOMPELLA], or to use the same MAC address database. If 365 not, we remove a standard bridge capability that is not only 366 expected by a significant fraction of the user community, but one 367 which is actually more useful in the Ethernet Provider space than 368 in the enterprise space. 370 In particular, a bridge which is conformant to [802.1Q] can be 371 configured, for any given pair of VLANs, to store those two VLANs' 372 MAC address information in two different Filtering Databases 373 (Independent VLAN Learning, IVL), or to use the same Filtering 374 Database for both (Shared VLAN Learning, SVL). (It also permits 375 the user to specify "don't care", and let the bridge decide.) That 376 is, MAC addresses learned on one VLAN may or may not, according to 377 the specific configuration of the bridge, be used to forward frames 378 on another VLAN. This fact has been utilized in a great many ways, 379 by a number of bridge vendors and bridge customers, in order to 380 implement a number of useful features. It is a behavior that has 381 been in IEEE 802.1Q since 1998, and in various vendors' bridges 382 long before that date. It cannot be removed without a serious 383 impact on the users of bridged LANs. 385 Given that one VLAN in the Access Network is associated with one 386 L2VPN, we are lead to the conclusion that two or more L2VPNs may be 387 similarly configured to use either IVL or SVL. In other words, two 388 L2VPNs A and B may be configured such that a {MAC address, PW) 389 association learned by a PE on L2VPN A is used when that PE 390 transmits packets to a PW on L2VPN B. Another way to phrase this 391 is that bridges do not remember {MAC, VLAN-ID, port} triplets, but 392 instead, remember {MAC, FID, port} triplets, where "FID" is the 393 Filtering ID, identifying a Filtering Database. The FID is derived 394 from VLAN-ID through a statically configured mapping table. 395 Similarly, L2VPN interfaces must learn {MAC, FID, PW} triplets 396 instead of {MAC, L2VPN-ID, PW} triplets, by means of a configured 397 L2VPN-to-Filtering-Database-ID table. 399 A concrete example of Shared VLAN Learning is the "Spanning Tree 400 Per Bridge" technique which is most useful in a ring of bridges. 401 (This is a more common topology in Ethernet MAN Provider Networks 402 than in enterprise networks.) In a ring with one spanning tree, 403 one link must be blocked, in order to prevent a closed forwarding 404 loop. Traffic between bridges on opposite sides of the blocked 405 link must go the long way around the ring. To avoid this 406 inefficiency, the "Spanning Tree Per Bridge" technique employs n 407 spanning trees, and splits each VLAN into a group of n VLANs, one 408 for each spanning tree. Each bridge associates itself with exactly 409 one spanning tree, selected so that the blocked link of that 410 spanning tree is near the opposite side of the ring. Every frame 411 it sends for a given VLAN group is sent only on the particular VLAN 412 associated with that bridge's spanning tree. Clearly, for this to 413 work, all of the VLANs in one group must share the same Filtering 414 Database. 416 If the user of this "Spanning Tree Per Bridge" technique is a 417 customer of an Ethernet MAN Service Provider, purchasing multiple 418 L2VPNs to make the connections between the customer's bridges, then 419 the provider's L2VPNs must share their learned MAC addresses. 421 Acknowledgements 423 The authors wish to thank Ali Sajassi, Joel Halpern, Steve Phillips 424 and Adam Sweeney for their valuable suggestions, both technical and 425 editorial, for correcting and improving this document, as well as a 426 number of IEEE P802.1 voting members who reviewed it. 428 References 430 [ANDERSSON] 431 "PPVPN L2 Framework", draft-andersson-ppvpn-l2-framework-00.txt 432 (Work in Progress) 434 [LASSERRE-VKOMPELLA] 435 "Virtual Private LAN Services over MPLS", draft-lasserre-vkompella- 436 ppvpn-vpls-01.txt (Work in Progress) 438 [SAJASSI] 439 "VPLS Architectures", draft-sajassi-vpls-architectures-00.txt (Work 440 in Progress) 442 [802.1D] 443 "Information technology. Telecommunications and information 444 exchange between systems. Local and metropolitan area networks. 445 Common specifications. Part 3: Media Access Control (MAC) 446 Bridges", ANSI/IEEE Std 802.1D-1998. 448 [802.1Q] 449 "IEEE Standards for Local and Metropolitan Area Networks: Virtual 450 Bridged Local Area Networks", IEEE Std 802.1Q-1998. 452 [802.1w] 453 "IEEE Standard for Local and metropolitan area networks. Common 454 specifications Part 3: Media Access Control (MAC) Bridges. 455 Amendment 2: Rapid Reconfiguration", IEEE Std 802.1w-2001. 457 Authors' Addresses 459 Norman Finn 460 Cisco Systems 461 170 W Tasman Drive 462 San Jose, CA 95134 463 USA 465 Phone: +1.408.526.4495 466 Email: nfinn@cisco.com 467 Mick Seaman 468 Consultant 469 160 Bella Vista Ave 470 Belvedere 471 CA 94920 473 mick_seaman@ieee.org 475 Andrew Smith 476 Consultant 478 Email: ah_smith@acm.org 479 Fax: +1.415.345.1827 481 Allyn Romanow 482 Cisco Systems 483 170 W Tasman Drive 484 San Jose, CA 95134 485 USA 487 Phone +1.408.525.8836 488 Email: allyn@cisco.com 490 Full Copyright Statement 492 Copyright (C) The Internet Society (2002). All Rights Reserved. 494 This document and translations of it may be copied and furnished to 495 others, and derivative works that comment on or otherwise explain 496 it or assist in its implementation may be prepared, copied, 497 published and distributed, in whole or in part, without restriction 498 of any kind, provided that the above copyright notice and this 499 paragraph are included on all such copies and derivative works. 500 However, this document itself may not be modified in any way, such 501 as by removing the copyright notice or references to the Internet 502 Society or other Internet organizations, except as needed for the 503 purpose of developing Internet standards in which case the 504 procedures for copyrights defined in the Internet Standards process 505 must be followed, or as required to translate it into languages 506 other than English. 508 The limited permissions granted above are perpetual and will not be 509 revoked by the Internet Society or its successors or assigns. 511 This document and the information contained herein is provided on 512 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 513 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 514 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 515 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 516 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.