idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-term-12.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 762. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 768. 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 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 (August 2007) is 6098 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-bmwg-igp-dataplane-conv-app-12 == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-meth-12 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 INTERNET-DRAFT 3 Expires in: August 2007 4 Intended Status: Informational 5 Scott Poretsky 6 Reef Point Systems 8 Brent Imhoff 9 Juniper Networks 11 February 2007 13 Terminology for Benchmarking 14 IGP Data Plane Route Convergence 16 18 Intellectual Property Rights (IPR) statement: 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Status of this Memo 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 ABSTRACT 46 This document describes the terminology for benchmarking Interior 47 Gateway Protocol (IGP) Route Convergence. The terminology is to 48 be used for benchmarking IGP convergence time through externally 49 observable (black box) data plane measurements. The terminology 50 can be applied to any link-state IGP, such as ISIS and OSPF. 52 IGP Data Plane Route Convergence 54 Table of Contents 55 1. Introduction .................................................2 56 2. Existing definitions .........................................3 57 3. Term definitions..............................................3 58 3.1 Convergence Event.........................................3 59 3.2 Route Convergence.........................................4 60 3.3 Network Convergence.......................................4 61 3.4 Full Convergence..........................................5 62 3.5 Convergence Packet Loss...................................5 63 3.6 Convergence Event Instant.................................6 64 3.7 Convergence Recovery Instant..............................6 65 3.8 Rate-Derived Convergence Time.............................7 66 3.9 Convergence Event Transition..............................7 67 3.10 Convergence Recovery Transition..........................8 68 3.11 Loss-Derived Convergence Time............................8 69 3.12 Sustained Forwarding Convergence Time....................9 70 3.13 Restoration Convergence Time.............................9 71 3.14 Packet Sampling Interval.................................10 72 3.15 Local Interface..........................................11 73 3.16 Neighbor Interface.......................................11 74 3.17 Remote Interface.........................................11 75 3.18 Preferred Egress Interface...............................12 76 3.19 Next-Best Egress Interface...............................12 77 3.20 Stale Forwarding.........................................13 78 3.21 Nested Convergence Events................................13 79 4. IANA Considerations...........................................13 80 5. Security Considerations.......................................14 81 6. Acknowledgements..............................................14 82 7. Normative References..........................................14 83 8. Author's Address..............................................15 85 1. Introduction 86 This draft describes the terminology for benchmarking Interior 87 Gateway Protocol (IGP) Route Convergence. The motivation and 88 applicability for this benchmarking is provided in [Po07a]. The 89 methodology to be used for this benchmarking is described in [Po07m]. 90 The methodology and terminology to be used for benchmarking Route 91 Convergence can be applied to any link-state IGP such as ISIS [Ca90] 92 and OSPF [Mo98]. The data plane is measured to obtain black-box 93 (externally observable) convergence benchmarking metrics. The 94 purpose of this document is to introduce new terms required to 95 complete execution of the IGP Route Convergence Methodology [Po07m]. 96 These terms apply to IPv4 and IPv6 traffic and IGPs. 98 An example of Route Convergence as observed and measured from the 99 data plane is shown in Figure 1. The graph in Figure 1 shows 100 Forwarding Rate versus Time. Time 0 on the X-axis is on the far 101 right of the graph. The Offered Load to the ingress interface of 102 the DUT SHOULD equal the measured maximum Throughput [Ba99][Ma98] 103 of the DUT and the Forwarding Rate [Ma98] is measured at the egress 104 interfaces of the DUT. The components of the graph and the metrics 105 are defined in the Term Definitions section. 107 IGP Data Plane Route Convergence 109 Convergence Convergence 110 Recovery Event 111 Instant Instant Time = 0sec 112 Forwarding Rate = ^ ^ ^ Offered Load = 113 Offered Load --> ------\ Packet /-------- <---Max Throughput 114 \ Loss /<----Convergence 115 Convergence------->\ / Event Transition 116 Recovery Transition \ / 117 \_____/<------Maximum Packet Loss 118 X-axis = Time 119 Y-axis = Forwarding Rate 121 Figure 1. Convergence Graph 123 2. Existing definitions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in BCP 14, RFC 2119 127 [Br97]. RFC 2119 defines the use of these key words to help make the 128 intent of standards track documents as clear as possible. While this 129 document uses these keywords, this document is not a standards track 130 document. The term Throughput is defined in [Ba91] and [Ba99]. 132 3. Term Definitions 133 3.1 Convergence Event 135 Definition: 136 The occurrence of a planned or unplanned action in the network 137 that results in a change in the egress interface of the Device 138 Under Test (DUT) for 139 routed packets. 141 Discussion: 142 Convergence Events include link loss, routing protocol session 143 loss, router failure, configuration change, and better next-hop 144 learned via a routing protocol. 146 Measurement Units: 147 N/A 149 Issues: 150 None 152 See Also: 153 Convergence Packet Loss 154 Convergence Event Instant 155 IGP Data Plane Route Convergence 157 3.2 Route Convergence 159 Definition: 160 Recovery from a Convergence Event indicated by the DUT 161 Throughput equal to the offered load. 163 Discussion: 164 Route Convergence is the action of all components of the router 165 being updated with the most recent route change(s) including the 166 Routing Information Base (RIB) and Forwarding Information Base 167 (FIB), along with software and hardware tables. Route 168 Convergence can be observed externally by the rerouting of data 169 Traffic to a new egress interface. 171 Measurement Units: 172 N/A 174 Issues: 175 None 177 See Also: 178 Network Convergence 179 Full Convergence 180 Convergence Event 182 3.3 Network Convergence 184 Definition: 185 The completion of updating of all routing tables, including the 186 FIB, in all routers throughout the network. 188 Discussion: 189 Network Convergence is bounded by the sum of Route Convergence 190 for all routers in the network. Network Convergence can be 191 determined by recovery of the Throughput to equal the offered 192 load, with no Stale Forwarding, and no blenders [Ca01][Ci03]. 194 Measurement Units: 195 N/A 197 Issues: 198 None 200 See Also: 201 Route Convergence 202 Stale Forwarding 203 IGP Data Plane Route Convergence 205 3.4 Full Convergence 206 Definition: 207 Route Convergence for an entire FIB. 209 Discussion: 210 When benchmarking convergence, it is useful to measure 211 the time to converge an entire FIB. For example, 212 a Convergence Event can be produced for an OSPF table of 213 5000 routes so that the time to converge routes 1 through 214 5000 is measured. Full Convergence is externally observable 215 from the data plane when the Throughput of the data 216 plane traffic on the Next-Best Egress Interface equals the 217 offered load. 219 Measurement Units: 220 N/A 222 Issues: None 224 See Also: 225 Network Convergence 226 Route Convergence 227 Convergence Event 229 3.5 Convergence Packet Loss 231 Definition: 232 The amount of packet loss produced by a Convergence Event 233 until Route Convergence occurs. 235 Discussion: 236 Packet loss can be observed as a reduction of forwarded traffic 237 from the maximum Throughput. Convergence Packet Loss 238 includes packets that were lost and packets that were delayed 239 due to buffering. The maximum Convergence Packet Loss observed 240 in a Packet Sampling Interval may or may not reach 100% during 241 Route Convergence (see Figure 1). 243 Measurement Units: 244 number of packets 246 Issues: None 248 See Also: 249 Route Convergence 250 Convergence Event 251 Rate-Derived Convergence Time 252 Loss-Derived Convergence Time 253 Packet Sampling Interval 254 IGP Data Plane Route Convergence 256 3.6 Convergence Event Instant 258 Definition: 259 The time instant that a Convergence Event becomes observable in 260 the data plane. 262 Discussion: 263 Convergence Event Instant is observable from the data 264 plane as the precise time that the device under test begins 265 to exhibit packet loss. 267 Measurement Units: 268 hh:mm:ss:nnn, where 'nnn' is milliseconds 270 Issues: 271 None 273 See Also: 274 Convergence Event 275 Convergence Packet Loss 276 Convergence Recovery Instant 278 3.7 Convergence Recovery Instant 280 Definition: 281 The time instant that Full Convergence is measured 282 and then maintained for an interval of duration equal to 283 the Sustained Forwarding Convergence Time 285 Discussion: 286 Convergence Recovery Instant is measurable from the data 287 plane as the precise time that the device under test 288 achieves Full Convergence. 290 Measurement Units: 291 hh:mm:ss:uuu 293 Issues: 294 None 296 See Also: 297 Sustained Forwarding Convergence Time 298 Convergence Packet Loss 299 Convergence Event Instant 300 IGP Data Plane Route Convergence 302 3.8 Rate-Derived Convergence Time 303 Definition: 304 The amount of time for Convergence Packet Loss to persist upon 305 occurrence of a Convergence Event until occurrence of Route 306 Convergence. 308 Rate-Derived Convergence Time can be measured as the time 309 difference from the Convergence Event Instant to the 310 Convergence Recovery Instant, as shown with Equation 1. 312 Equation 1 - 313 Rate-Derived Convergence Time = 314 Convergence Recovery Instant - Convergence Event Instant. 316 Discussion: 317 Rate-Derived Convergence Time should be measured at the maximum 318 Throughput. Failure to achieve Full Convergence results in 319 a Rate-Derived Convergence Time benchmark of infinity. 321 Measurement Units: 322 seconds/milliseconds 324 Issues: 325 None 327 See Also: 328 Convergence Packet Loss 329 Convergence Recovery Instant 330 Convergence Event Instant 331 Full Convergence 333 3.9 Convergence Event Transition 334 Definition: 335 The characteristic of a router in which Throughput 336 gradually reduces to zero after a Convergence Event. 338 Discussion: 339 The Convergence Event Transition is best observed for 340 Full Convergence. The Convergence Event Transition may 341 not be linear. 343 Measurement Units: 344 seconds/milliseconds 346 Issues: 347 None 349 See Also: 350 Convergence Event 351 Rate-Derived Convergence Time 352 Convergence Packet Loss 353 Convergence Recovery Transition 354 IGP Data Plane Route Convergence 356 3.10 Convergence Recovery Transition 358 Definition: 359 The characteristic of a router in which Throughput 360 gradually increases to equal the offered load. 362 Discussion: 363 The Convergence Recovery Transition is best observed for 364 Full Convergence. The Convergence Event Transition may 365 not be linear. 367 Measurement Units: 368 seconds/milliseconds 370 Issues: None 372 See Also: 373 Full Convergence 374 Rate-Derived Convergence Time 375 Convergence Packet Loss 376 Convergence Event Transition 378 3.11 Loss-Derived Convergence Time 380 Definition: 381 The amount of time it takes for Route Convergence to 382 to be achieved as calculated from the Convergence Packet 383 Loss. Loss-Derived Convergence Time can be calculated 384 from Convergence Packet Loss that occurs due to a 385 Convergence Event and Route Convergence as shown with 386 Equation 2. 388 Equation 2 - 389 Loss-Derived Convergence Time = 390 Convergence Packets Loss / Offered Load 391 NOTE: Units for this measurement are 392 packets / packets/second = seconds 394 Discussion: 395 Loss-Derived Convergence Time gives a better than 396 actual result when converging many routes simultaneously. 397 Rate-Derived Convergence Time takes the Convergence Recovery 398 Transition into account, but Loss-Derived Convergence Time 399 ignores the Route Convergence Recovery Transition because 400 it is obtained from the measured Convergence Packet Loss. 402 Ideally, the Convergence Event Transition and Convergence 403 Recovery Transition are instantaneous so that the 404 Rate-Derived Convergence Time = Loss-Derived Convergence Time. 405 However, router implementations are less than ideal. 406 For these reasons the preferred reporting benchmark for IGP 407 Route Convergence is the Rate-Derived Convergence Time. 409 IGP Data Plane Route Convergence 411 Guidelines for reporting Loss-Derived Convergence Time are 412 provided in [Po07m]. 414 Measurement Units: 415 seconds/milliseconds 417 Issues: 418 None 420 See Also: 421 Route Convergence 422 Convergence Packet Loss 423 Rate-Derived Convergence Time 424 Convergence Event Transition 425 Convergence Recovery Transition 427 3.12 Sustained Forwarding Convergence Time 429 Definition: 430 The amount of time for which Full Convergence is maintained 431 without additional packet loss. 433 Discussion: 434 The purpose of the Sustained Forwarding Convergence Time is to 435 produce Convergence benchmarks protected against fluctuation 436 in Throughput after Full Convergence is observed. The 437 Sustained Forwarding Convergence Time to be used is calculated 438 as shown in Equation 3. 440 Equation 3 - 441 Sustained Forwarding Convergence Time = 442 5*(Convergence Packet Loss/Offered Load) 443 units are packets/pps = sec 445 for which at least one packet per route in the FIB for all 446 routes in the FIB MUST be offered to the DUT per second. 448 Measurement Units: 449 seconds or milliseconds 451 Issues: None 453 See Also: 454 Full Convergence 455 Convergence Recovery Instant 457 3.13 Restoration Convergence Time 458 Definition: 459 The amount of time for the router under test to restore 460 traffic to the original outbound port after recovery from 461 a Convergence Event. 463 IGP Data Plane Route Convergence 465 Discussion: 466 Restoration Convergence Time is the amount of time for routes 467 to converge to the original outbound port. This is achieved 468 by recovering from the Convergence Event, such as restoring 469 the failed link. Restoration Convergence Time is measured 470 using the Rate-Derived Convergence Time calculation technique, 471 as provided in Equation 1. It is possible to have the 472 Restoration Convergence Time differ from the Rate-Derived 473 Convergence Time. 475 Measurement Units: 476 seconds or milliseconds 478 Issues: 479 None 481 See Also: 482 Convergence Event 483 Rate-Derived Convergence Time 485 3.14 Packet Sampling Interval 486 Definition: 487 The interval at which the tester (test equipment) polls to make 488 measurements for arriving packet flows. 490 Discussion: 491 Metrics measured at the Packet Sampling Interval MUST include 492 Forwarding Rate and Convergence Packet Loss. 494 Measurement Units: 495 seconds or milliseconds 497 Issues: 498 Packet Sampling Interval can influence the Convergence Graph. 499 This is particularly true when implementations achieve Full 500 Convergence in less than 1 second. The Convergence Event 501 Transition and Convergence Recovery Transition can become 502 exaggerated when the Packet Sampling Interval is too long. 503 This will produce a larger than actual Rate-Derived 504 Convergence Time. The recommended value for configuration 505 of the Packet Sampling Interval is provided in [Po07m]. 507 See Also: 508 Convergence Packet Loss 509 Convergence Event Transition 510 Convergence Recovery Transition 511 IGP Data Plane Route Convergence 513 3.15 Local Interface 514 Definition: 515 An interface on the DUT. 517 Discussion: 518 None 520 Measurement Units: 521 N/A 523 Issues: 524 None 526 See Also: 527 Neighbor Interface 528 Remote Interface 530 3.16 Neighbor Interface 532 Definition: 533 The interface on the neighbor router or tester that is 534 directly linked to the DUT's Local Interface. 536 Discussion: 537 None 539 Measurement Units: 540 N/A 542 Issues: 543 None 545 See Also: 546 Local Interface 547 Remote Interface 549 3.17 Remote Interface 551 Definition: 552 An interface on a neighboring router that is not directly 553 connected to any interface on the DUT. 555 Discussion: 556 None 558 Measurement Units: 559 N/A 561 Issues: 562 None 563 IGP Data Plane Route Convergence 565 See Also: 566 Local Interface 567 Neighbor Interface 569 3.18 Preferred Egress Interface 571 Definition: 572 The outbound interface from the DUT for traffic routed to the 573 preferred next-hop. 575 Discussion: 576 The Preferred Egress Interface is the egress interface prior 577 to a Convergence Event. 579 Measurement Units: 580 N/A 582 Issues: 583 None 585 See Also: 586 Next-Best Egress Interface 588 3.19 Next-Best Egress Interface 590 Definition: 591 The outbound interface from the DUT for traffic routed to the 592 second-best next-hop. It is the same media type and link speed 593 as the Preferred Egress Interface 595 Discussion: 596 The Next-Best Egress Interface becomes the egress interface 597 after a Convergence Event. 599 Measurement Units: 600 N/A 602 Issues: 603 None 605 See Also: 606 Preferred Egress Interface 607 IGP Data Plane Route Convergence 609 3.20 Stale Forwarding 611 Definition: 612 Forwarding of traffic to route entries that no longer exist 613 or to route entries with next-hops that are no longer preferred. 615 Discussion: 616 Stale Forwarding can be caused by a Convergence Event and is 617 also known as a "black-hole" since it may produce packet loss. 618 Stale Forwarding exists until Network Convergence is achieved. 620 Measurement Units: 621 N/A 623 Issues: 624 None 626 See Also: 627 Network Convergence 629 3.21 Nested Convergence Events 631 Definition: 632 The occurrence of a Convergence Event while the route 633 table is converging from a prior Convergence Event. 635 Discussion: 636 The Convergence Events for a Nested Convergence Event 637 MUST occur with different neighbors. A common 638 observation from a Nested Convergence Event will be 639 the withdrawal of routes from one neighbor while the 640 routes of another neighbor are being installed. 642 Measurement Units: 643 N/A 645 Issues: 646 None 648 See Also: 649 Convergence Event 651 4. IANA Considerations 653 This document requires no IANA considerations. 655 IGP Data Plane Route Convergence 657 5. Security Considerations 659 Documents of this type do not directly affect the security of 660 Internet or corporate networks as long as benchmarking 661 is not performed on devices or systems connected to production 662 networks. 664 6. Acknowledgements 665 Thanks to Sue Hares, Al Morton, Kevin Dubray, and participants of 666 the BMWG for their contributions to this work. 668 7. References 669 7.1 Normative References 671 [Ba91] Bradner, S. "Benchmarking Terminology for Network 672 Interconnection Devices", RFC1242, July 1991. 674 [Ba99] Bradner, S. and McQuaid, J., "Benchmarking 675 Methodology for Network Interconnect Devices", 676 RFC 2544, March 1999. 678 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", RFC 2119, March 1997 681 [Ca90] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 682 Environments", RFC 1195, December 1990. 684 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 685 Switching Devices", RFC 2285, February 1998. 687 [Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 689 [Po07a] Poretsky, S., "Benchmarking Applicability for IGP Data Plane 690 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-12, 691 work in progress, February 2007. 693 [Po07m] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 694 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-12, 695 work in progress, February 2007. 697 7.2 Informative References 699 [Ca01] S. Casner, C. Alaettinoglu, and C. Kuan, "A Fine-Grained View 700 of High Performance Networking", NANOG 22, June 2001. 702 [Ci03] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized 703 Active Measurements on a Tier 1 IP Backbone", IEEE 704 Communications Magazine, pp90-97, May 2003. 706 IGP Data Plane Route Convergence 708 8. Author's Address 710 Scott Poretsky 711 Reef Point Systems 712 8 New England Executive Park 713 Burlington, MA 01803 714 USA 716 Phone: + 1 508 439 9008 717 EMail: sporetsky@reefpoint.com 719 Brent Imhoff 720 Juniper Networks 721 1194 North Mathilda Ave 722 Sunnyvale, CA 94089 723 USA 725 Phone: + 1 314 378 2571 726 EMail: bimhoff@planetspork.com 728 Full Copyright Statement 730 Copyright (C) The IETF Trust (2007). 732 This document is subject to the rights, licenses and restrictions 733 contained in BCP 78, and except as set forth therein, the authors 734 retain all their rights. 736 This document and the information contained herein are provided 737 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 738 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 739 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 740 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 741 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 742 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 743 FOR A PARTICULAR PURPOSE. 745 IGP Data Plane Route Convergence 747 Intellectual Property 748 The IETF takes no position regarding the validity or scope of any 749 Intellectual Property Rights or other rights that might be claimed to 750 pertain to the implementation or use of the technology described in 751 this document or the extent to which any license under such rights 752 might or might not be available; nor does it represent that it has 753 made any independent effort to identify any such rights. Information 754 on the procedures with respect to rights in RFC documents can be 755 found in BCP 78 and BCP 79. 757 Copies of IPR disclosures made to the IETF Secretariat and any 758 assurances of licenses to be made available, or the result of an 759 attempt made to obtain a general license or permission for the use of 760 such proprietary rights by implementers or users of this 761 specification can be obtained from the IETF on-line IPR repository at 762 http://www.ietf.org/ipr. 764 The IETF invites any interested party to bring to its attention any 765 copyrights, patents or patent applications, or other proprietary 766 rights that may cover technology that may be required to implement 767 this standard. Please address the information to the IETF at ietf- 768 ipr@ietf.org. 770 Acknowledgement 771 Funding for the RFC Editor function is currently provided by the 772 Internet Society.