idnits 2.17.1 draft-ietf-isis-wg-multi-topology-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 553. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 abstract seems to contain references ([RFC2119]), 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.) -- The document date (October 2005) is 6768 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: 'ISO10589' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 493, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' -- Obsolete informational reference (is this intentional?): RFC 3784 (ref. 'LS01') (Obsoleted by RFC 5305) == Outdated reference: A later version (-07) exists of draft-ietf-isis-ipv6-06 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tony Przygienda 2 Internet Draft Naiming Shen (Cisco) 3 Nischal Sheth (Juniper) 4 October 2005 5 Expires: April 2006 7 M-ISIS: Multi Topology (MT) Routing in IS-IS 9 Status of This Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 This draft describes an optional mechanism within ISIS used today 36 by many ISPs for IGP routing within their clouds. This draft 37 describes how to run within a single ISIS domain a set of 38 independent IP topologies that we call Multi-Topologies (MTs). 39 This MT extension can be used for variety of purposes such as an 40 in-band management network ``on top'' of the original IGP topology, 41 maintain separate IGP routing domains for isolated multicast or 42 IPv6 islands within the backbone, or force a subset of an address 43 space to follow a different topology. 45 Specification of Requirements 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [RFC2119]. 51 1. Introduction 53 Maintaining multiple MTs for ISIS [ISO10589 , RFC1195] in a 54 backwards-compatible manner necessitates several extensions to the 55 packet encoding and additional SPF procedures. The problem can 56 be partitioned into forming of adjacencies, and advertising of 57 prefixes and reachable intermediate systems within each topology. 58 Having put all the necessary additional information in place, it 59 must be properly used by MT capable SPF computation. The following 60 sections describe each of the problems separately. To simplify the 61 text, ``standard'' ISIS topology is defined to be MT ID #0 (zero). 63 2. Maintaining MT Adjacencies 65 Each adjacency formed MUST be classified as belonging to a set of 66 MTs on the interface. This is achieved by adding a new TLV into 67 IIH packets that advertises which topologies the interface belongs 68 to. If MT #0 is the only MT on the interface, it is optional to 69 advertise it in the new TLV. Thus not including such a TLV in the 70 IIH implies MT ID #0 capability only. Through this exchange of MT 71 capabilities, a router is able to advertise the IS TLVs in LSPs 72 with common MT set over those adjacencies. 74 In the case of adjacency contains multiple MTs on an interface, and 75 if there exists overlapping IP address space among the topologies, 76 additional mechanism MAY be used to resolve the topology identity of 77 the incoming IP packets on the interface. 79 2.1. Forming Adjacencies on Point-to-Point Interfaces 81 Adjacencies on point-to-point interfaces are formed as usual with 82 ISIS routers not implementing MT extensions. If local router does 83 not participate in certain MTs, it will not advertise those MTIDs 84 in its IIHs and thus will not include that neighbor within it's 85 LSPs. On the other hand, if a MTID is not detected in remote 86 side's IIHs, the local router MUST NOT include that neighbor 87 within its LSPs. The local router SHOULD NOT form an adjacency if 88 they don't have at least one common MT over the interface. 90 2.2. Forming Adjacencies on Broadcast Interfaces 92 On a LAN, all the routers on the LAN which implement the MT 93 extension MAY advertise their MT capability TLV in their IIHs. 94 If there is at least one adjacency on the LAN interface which 95 belongs to this MT, the MT capable router MUST include the 96 corresponding MT IS Reachable TLV in its LSP, otherwise it MAY 97 include this MT IS Reachable TLV in its LSP if the LAN interface 98 participates in this MT set. 100 Two Routers on a LAN SHALL always establish adjacency regardless 101 whether they have common MT or not. This is to ensure all 102 the routers on the LAN can correctly elect the same DIS. The IS 103 SHOULD NOT include the MT IS TLV in its LSP if none of the 104 adjacencies on the LAN contains this MT. 106 The DIS, CSNP and PSNP functions are not changed by MT extension. 108 3. Advertising MT Reachable Intermediate Systems in LSPs 110 A router MUST include within its LSPs in the Reachable Intermediate 111 Systems TLVs only adjacent nodes that are participating in the 112 corresponding topology and advertise such TLVs only if it 113 participates itself in the corresponding topology. Standard 114 Reachable Intermediate Systems TLV is acting here as MT ID #0 115 equivalent of the newly introduced MT Reachable Intermediate Systems 116 TLV. A router MUST announce the MT IS TLV when there is at least 117 one adjacency on the interface that belongs to this MT, otherwise 118 it MAY announce the MT IS TLV of an adjacency for a given MT if this 119 interface participates in the LAN. 121 Since it is not possible to prevent a router that does not 122 understand MT extensions from being responsible for generation of 123 the according pseudo-node, it is not possible either to introduce 124 special TLVs in the pseudo-node LSPs nor run distinct DIS elections 125 per MT. Therefore, a generated pseudo-node LSP by DIS MUST contain 126 in its IS Reachable TLV all nodes on the LAN as usual regardless 127 of their MT capabilities. In other words, there is no change to the 128 pseudo-node LSP construction. 130 4. MTs and Overload, Partition and Attached Bits 132 A router could for each of the MTs become potentially 133 partitioned, overloaded and attached independently. To prevent 134 unnecessary complexity, MT extensions does not support 135 partition repair. The overload, partition and attached bits in LSP 136 header only reflect the status of the default topology. 138 Attached bit and overload bit are part of the MT TLV being 139 distributed within a node's LSP fragment zero. Since each adjacency 140 can belong to different MTs, it is possible that some MTs are L2 141 attached, and others are not on the same router. The overload 142 bit in the MT TLV can be used to signal the topology being 143 overloaded. A MT based system is considered being overloaded if 144 the overload bit in the MT is set. 146 Route leaking between the levels SHOULD only be performed within 147 the same MT. 149 5. Advertising MT Specific IP Prefixes 151 Each of the MTs commands its own address space so a new TLV is 152 necessary for prefixes stored in MTs other than MT ID #0. To 153 make the encoding less confusing when same prefixes are present in 154 multiple MTs and accelerate SPF per MT, rather than adding a sub-TLV 155 in TE extensions, a new TLV is introduced for that purpose that 156 closely follows TE encoding [LS01]. 158 6. MT SPF Computation 160 Each MT MUST run its own instance of the decision process. 161 The pseudo-node LSPs are used by all topologies during computation. 162 Each non-default topology MAY have it's attached bit and overload 163 bit set in the MT TLV. Reverse connectivity check within SPF MUST 164 follow the according MT to assure the bi-directional reachability 165 within the same MT. 167 The results of each computation SHOULD be stored in a separate RIB 168 in normal cases, otherwise overlapping addresses in different 169 topologies could lead to undesirable routing behavior such as 170 forwarding loops. The forwarding logic and configuration need to 171 ensure the same MT is traversed from the source to the destination 172 for packets. The nexthops derived from the MT SPF MUST belong to 173 the adjacencies conforming to the same MT for correct forwarding. 174 It is recommended for the administrators to ensure consistent 175 configuration of all routers in the domain to prevent undesirable 176 forwarding behavior. 178 No attempt is made in this draft to allow one topology to calculate 179 routes using the routing information from another topology inside 180 SPF. Even though it is possible to redistribute and leak routes 181 from another IS-IS topology or from external sources, and the 182 exact mechanism is beyond the scope of this document. 184 7. Packet Encoding 186 Three new TLVs are added to support MT extensions. One of them is 187 common for the LSPs and IIHs. Encoding of Intermediate System TLV 188 and IPv4 Reachable Prefixes is tied to traffic engineering 189 extensions [LS01] to simplify the implementation effort. The main 190 reasons we choose using new TLVs instead of using sub-TLVs inside 191 existing TLV type-22 and type-135 are: In many cases, 192 multi-topologies are non-congruent, using sub-TLV approach will 193 not save LSP space; Many sub-TLVs are already being used in TLV 194 type-22, and many more are being proposed while there is a maximum 195 limit on the TLV size, from the existing TLVs; If traffic 196 engineering or some other applications are being applied per 197 topology level later, the new TLVs can automatically inherit the 198 same attributes already defined for the ``standard'' IPv4 topology 199 without going through long standard process to redefine them per 200 topology. 202 7.1. Multi-Topology TLV 204 TLV number of this TLV is 229. It contains one or more MTs 205 the router is participating in the following structure: 207 x CODE - 229 208 x LENGTH - total length of the value field, it should be 2 209 times the number of MT components. 210 x VALUE - one or more 2-byte MT components, structured 211 as follows: 212 No. of Octets 213 +--------------------------------+ 214 |O |A |R |R | MT ID | 2 215 +--------------------------------+ 217 Bit O represents the OVERLOAD bit for the MT (only valid 218 in LSP fragment zero for MTs other than ID #0, otherwise 219 should be set to 0 on transmission and ignored on receipt.) 221 Bit A represents the ATTACH bit for the MT (only valid 222 in LSP fragment zero for MTs other than ID #0, otherwise 223 should be set to 0 on transmission and ignored on receipt.) 225 Bits R are reserved, should be set to 0 on transmission 226 and ignored on receipt. 228 MT ID is a 12-bit field containing the ID of the topology 229 being announced. 231 This MT TLV can advertise up to 127 MTs and it can occur multiple 232 times if needed within IIHs and LSP fragment zero. The result MT 233 set should be the union of all the MT TLV occurrence in the packet. 234 Any other ISIS PDU occurrence of this TLV MUST be ignored. Lack 236 of MT TLV in hellos and fragment zero LSP MUST be interpreted as 237 participation of the advertising interface or router in 238 MT ID #0 only. If a router advertises MT TLV, it has to advertise 239 all the MTs it participates in, specifically including topology 240 ID #0 also. 242 7.2. MT Intermediate Systems TLV 244 TLV number of this TLV is 222. It is aligned with extended IS 245 reachability TLV type 22 beside an additional two bytes in front at 246 the beginning of the TLV. 248 x CODE - 222 249 x LENGTH - total length of the value field 250 x VALUE - 2-byte MT membership plus the format of extended IS 251 reachability TLV, structured as follows: 253 No. of Octets 254 +--------------------------------+ 255 |R |R |R |R | MT ID | 2 256 +--------------------------------+ 257 | extended IS TLV format | 11 - 253 258 +--------------------------------+ 259 . . 260 . . 261 +--------------------------------+ 262 | extended IS TLV format | 11 - 253 263 +--------------------------------+ 265 Bits R are reserved, should be set to 0 on transmission 266 and ignored on receipt. 268 MT ID is a 12-bit field containing the non-zero MT ID of the 269 topology being announced. The TLV MUST be ignored if the ID 270 is zero. This is to ensure the consistent view of the standard 271 unicast topology. 273 After the 2-byte MT membership format, the MT IS content is 274 in the same format as extended IS TLV, type 22 [LS01]. It 275 can contain up to 23 neighbors of the same MT if no sub-TLVs 276 are used. 278 This TLV can occur multiple times. 280 7.3. Multi-Topology Reachable IPv4 Prefixes TLV 282 TLV number of this TLV is 235. It is aligned with extended IP 283 reachability TLV type 135 beside an additional two bytes in front. 285 x CODE - 235 286 x LENGTH - total length of the value field 287 x VALUE - 2-byte MT membership plus the format of extended 288 extended IP reachability TLV, structured as follows: 290 No. of Octets 291 +--------------------------------+ 292 |R |R |R |R | MT ID | 2 293 +--------------------------------+ 294 | extended IP TLV format | 5 - 253 295 +--------------------------------+ 296 . . 297 . . 298 +--------------------------------+ 299 | extended IP TLV format | 5 - 253 300 +--------------------------------+ 301 Bits R are reserved, should be set to 0 on transmission 302 and ignored on receipt. 304 MT ID is a 12-bit field containing the non-zero ID of the 305 topology being announced. The TLV MUST be ignored if the ID 306 is zero. This is to ensure the consistent view of the standard 307 unicast topology. 309 After the 2-byte MT membership format, the MT IPv4 content 310 is in the same format as extended IP reachability TLV, 311 type 135 [LS01]. 313 This TLV can occur multiple times. 315 7.4. Multi-Topology Reachable IPv6 Prefixes TLV 317 TLV number of this TLV is 237. It is aligned with IPv6 Reachability 318 TLV type 236 beside an additional two bytes in front. 320 x CODE - 237 321 x LENGTH - total length of the value field 322 x VALUE - 2-byte MT membership plus the format of IPv6 323 Reachability TLV, structured as follows: 325 No. of Octets 326 +--------------------------------+ 327 |R |R |R |R | MT ID | 2 328 +--------------------------------+ 329 | IPv6 Reachability format | 6 - 253 330 +--------------------------------+ 331 . . 332 +--------------------------------+ 333 | IPv6 Reachability format | 6 - 253 334 +--------------------------------+ 336 Bits R are reserved, should be set to 0 on transmission 337 and ignored on receipt. 339 MT ID is a 12-bit field containing the ID of the topology 340 being announced. The TLV MUST be ignored if the ID 341 is zero. 343 After the 2-byte MT membership format, the MT IPv6 context 344 is in the same format as IPv6 Reachability TLV, 345 type 236 [H01]. 347 This TLV can occur multiple times. 349 7.5. Reserved MT ID Values 351 Certain MT topologies are assigned to serve pre-determined purposes: 353 - MT ID #0: Equivalent to the ``standard'' topology. 354 - MT ID #1: Reserved for IPv4 in-band management 355 purposes. 356 - MT ID #2: Reserved for IPv6 routing topology. 357 - MT ID #3: Reserved for IPv4 multicast routing topology. 358 - MT ID #4: Reserved for IPv6 multicast routing topology. 359 - MT ID #5-#3995: Reserved for IETF consensus. 360 - MT ID #3996-#4095: Reserved for development, experimental and 361 proprietary features [RFC3692]. 363 8. MT IP Forwarding Considerations 365 Using MT extension for ISIS routing can result in multiple RIBs 366 on the system. The implementation and configuration MUST make 367 sure the IP packets are only traversed through the nodes and links 368 intended for the topologies and applications. In this section we 369 list some of the known considerations for IP forwarding in various 370 MT scenario. Certain deployment scenarios presented here 371 imply different trade-offs in terms of deployment difficulties 372 and advantages obtained. 374 8.1. Each MT belong to a distinct address family 376 In this case, each MT related routes are installed into a 377 separate RIB. Multiple topologies can share the same ISIS interface 378 on detecting the incoming packet address family. As an example, 379 IPv4 and IPv6 can share the same interface without any further 380 considerations under MT ISIS. 382 8.2. Some MTs belong to the same address family 384 8.2.1. Each interface belongs to one and only one MT 386 In this case, MTs can be used to forward packets from the 387 same address family, even with overlapping addresses. Since the 388 MTs have their dedicated interfaces, and those interfaces can be 389 associated with certain MT RIBs and FIBs. 391 8.2.2. Multiple MTs share an interface with overlapping addresses 393 Some additional mechanism is needed to select the correct RIBs 394 for the incoming IP packets to determine the correct RIB to make 395 a forwarding decision. For example, if the topologies are 396 QoS partitioned, then the DSCP bits in the IP packet header can 397 be utilized to make the decision. Some IP header or even packet 398 data information may be checked to make the forwarding table 399 selection, such as source IP address in the header can be used 400 to determine the desired forwarding behavior. 402 The generic approach of packet to multiple MT RIB mapping over 403 the same inbound interface is outside the scope of this draft. 405 8.2.3. Multiple MTs share an interface with non-overlapping addresses 407 When there is no overlap in the address space among all the MTs, 408 strictly speaking the destination address space classifies the 409 topology a packet belongs to. It is possible to install routes 410 from different MTs into a shared RIB. As an example of such a 411 deployment, a special ISIS topology can be setup for certain 412 EBGP nexthop addresses. 414 8.3 Some MTs are not used for forwarding purpose 416 MT in ISIS may be used even if the resulting RIB is not used for 417 forwarding purposes. As an example, multicast RPF check can be 418 performed on a different RIB than the standard unicast RIB albeit 419 an entirely different RIB is used for the multicast forwarding. 420 However, an incoming packet must be still clearly identified as 421 belonging to a unique topology. 423 9. MT Network Management Considerations 425 When multiple ISIS topologies exist within a domain, some of the 426 routers can be configured to participate in a subset of the MTs 427 in the network. This section discusses some of the options we 428 have to enable operations or the network management stations to 429 access those routers. 431 9.1. Create dedicated management topology to include all the nodes 433 This approach is to setup a dedicated management topology or 434 'in-band' management topology. This 'mgmt' topology will include 435 all the routers need to be managed. The computed routes in the 436 topology will be installed into the 'mgmt' RIB. In the condition 437 of the 'mgmt' topology uses a set of non-overlapping address space 438 with the default topology, those 'mgmt' routes can also be 439 optionally installed into the default RIB. 440 The advantages of duplicate 'mgmt' routes in both RIBs include: 441 the network management utilities on the system does not have to be 442 modified to use specific RIB other than the default RIB; the 'mgmt' 443 topology can share the same link with the default topology if so 444 designed. 446 9.2. Extend the default topology to all the nodes 448 Even in the case default topology is not used on some of the nodes 449 in the IP forwarding, we may want to extend the default topology 450 to those nodes for the purpose of network management. Operators 451 SHOULD set high cost on the links which belong to the extended 452 portion of the default topology. This way the IP data traffic 453 will not be forwarded through those nodes during network topology 454 changes. 456 10. Acknowledgments 458 The authors would like to thank Andrew Partan, Dino Farinacci, 459 Derek Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong, 460 Pekka Savola, Mike Shand, Shankar Vemulapalli and Les Ginsberg 461 for the discussion, their review, comments and contributions to 462 this draft. 464 11. Security Consideration 466 ISIS security applies to the work presented. No specific security 467 issues with the proposed solutions are known. The authentication 468 procedure for ISIS PDUs is the same regardless of MT information 469 inside the ISIS PDUs. 471 12. IANA Considerations 473 IANA is requested to create a new registry, "IS-IS multi-topology ID 474 values" with the assignment listed in Section 7.5 of this document 475 and registration policies for future assignments. 477 IANA is also requested to update the IS-IS codepoint registry 478 (http://www.iana.org/assignments/isis-tlv-codepoints) so that TLV 479 codes 222, 229, 235 and 237 refer to this document's RFC number. 481 [[ note to the RFC-editor: the above paragraph may be removed or 482 reworded prior to RFC publication ]] 484 13. References 486 13.1. Normative References 488 [ISO10589] ISO. Intermediate System to Intermediate System Routing 489 Exchange Protocol for Use in Conjunction with the 490 Protocol for Providing the Connectionless-Mode Network 491 Service. ISO 10589, 1992. 493 [RFC1195] R. Callon. Use of OSI ISIS for Routing in TCP/IP and 494 Dual Environments. RFC 1195, December 1990. 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, March 1997. 499 [RFC3692] Narten, T., "Assigning Experimental and Testing 500 Numbers Considered Useful", BCP 82, RFC 3692, January 501 2004. 503 13.2. Informative References 505 [LS01] T. Li and H. Smit. IS-IS Extensions for Traffic 506 Engineering. RFC 3784, May 2005. 508 [H01] C. Hopps. Routing IPv6 with IS-IS. 509 draft-ietf-isis-ipv6-06.txt, May 2004. (work in progress) 511 14. Authors' Addresses 513 Tony Przygienda 514 Z2 Sagl 515 Via Rovello 32 516 CH-6942 Savosa 517 prz@net4u.ch 519 Naiming Shen 520 Cisco Systems 521 225 West Tasman Drive 522 San Jose, CA, 95134 USA 523 naiming@cisco.com 525 Nischal Sheth 526 Juniper Networks 527 1194 North Mathilda Avenue 528 Sunnyvale, CA 94089 USA 529 nsheth@juniper.net 531 Intellectual Property 533 The IETF takes no position regarding the validity or scope of any 534 Intellectual Property Rights or other rights that might be claimed 535 to pertain to the implementation or use of the technology described 536 in this document or the extent to which any license under such 537 rights might or might not be available; nor does it represent that 538 it has made any independent effort to identify any such rights. 539 Information on the procedures with respect to rights in RFC 540 documents can be found in BCP 78 and BCP 79. 542 Copies of IPR disclosures made to the IETF Secretariat and any 543 assurances of licenses to be made available, or the result of an 544 attempt made to obtain a general license or permission for the use 545 of such proprietary rights by implementers or users of this 546 specification can be obtained from the IETF on-line IPR repository 547 at http://www.ietf.org/ipr. 549 The IETF invites any interested party to bring to its attention any 550 copyrights, patents or patent applications, or other proprietary 551 rights that may cover technology that may be required to implement 552 this standard. Please address the information to the IETF at 553 ietf-ipr@ietf.org. 555 Full Copyright Statement 557 Copyright (C) The Internet Society (2005). This document is subject 558 to the rights, licenses and restrictions contained in BCP 78, and 559 except as set forth therein, the authors retain all their rights. 561 This document and the information contained herein are provided on 562 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 563 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 564 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 565 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 566 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 567 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 568 PARTICULAR PURPOSE. 570 Acknowledgment 572 Funding for the RFC Editor function is currently provided by the 573 Internet Society.