idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-term-13.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 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 833. 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 (January 2008) is 5939 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-13 == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-meth-13 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: January 2008 4 Intended Status: Informational 5 Scott Poretsky 6 Reef Point Systems 8 Brent Imhoff 9 Juniper Networks 11 July 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..............................................4 58 3.1 Convergence Event.........................................4 59 3.2 Route Convergence.........................................4 60 3.3 Network Convergence.......................................5 61 3.4 Full Convergence..........................................5 62 3.5 Packet Loss...............................................6 63 3.6 Convergence Packet Loss...................................6 64 3.7 Convergence Event Instant.................................7 65 3.8 Convergence Recovery Instant..............................7 66 3.9 Rate-Derived Convergence Time.............................8 67 3.10 Convergence Event Transition.............................8 68 3.11 Convergence Recovery Transition..........................9 69 3.12 Loss-Derived Convergence Time............................9 70 3.13 Sustained Forwarding Convergence Time....................10 71 3.14 Restoration Convergence Time.............................11 72 3.15 Packet Sampling Interval.................................12 73 3.16 Local Interface..........................................12 74 3.17 Neighbor Interface.......................................13 75 3.18 Remote Interface.........................................13 76 3.19 Preferred Egress Interface...............................13 77 3.20 Next-Best Egress Interface...............................14 78 3.21 Stale Forwarding.........................................14 79 3.22 Nested Convergence Events................................15 80 4. IANA Considerations...........................................15 81 5. Security Considerations.......................................15 82 6. Acknowledgements..............................................15 83 7. References....................................................15 84 8. Author's Address..............................................16 86 1. Introduction 87 This draft describes the terminology for benchmarking Interior 88 Gateway Protocol (IGP) Route Convergence. The motivation and 89 applicability for this benchmarking is provided in [Po07a]. The 90 methodology to be used for this benchmarking is described in [Po07m]. 91 The methodology and terminology to be used for benchmarking Route 92 Convergence can be applied to any link-state IGP such as ISIS [Ca90] 93 and OSPF [Mo98]. The data plane is measured to obtain black-box 94 (externally observable) convergence benchmarking metrics. The 95 purpose of this document is to introduce new terms required to 96 complete execution of the IGP Route Convergence Methodology [Po07m]. 97 These terms apply to IPv4 and IPv6 traffic and IGPs. 99 IGP Data Plane Route Convergence 101 An example of Route Convergence as observed and measured from the 102 data plane is shown in Figure 1. The graph in Figure 1 shows 103 Forwarding Rate versus Time. Time 0 on the X-axis is on the far 104 right of the graph. The Offered Load to the ingress interface of 105 the DUT SHOULD equal the measured maximum Throughput [Ba99][Ma98] 106 of the DUT and the Forwarding Rate [Ma98] is measured at the egress 107 interfaces of the DUT. The components of the graph and the metrics 108 are defined in the Term Definitions section. 110 Convergence Convergence 111 Recovery Event 112 Instant Instant Time = 0sec 113 Forwarding Rate = ^ ^ ^ Offered Load = 114 Offered Load --> ------\ Packet /-------- <---Max Throughput 115 \ Loss /<----Convergence 116 Convergence------->\ / Event Transition 117 Recovery Transition \ / 118 \_____/<------Maximum Packet Loss 119 X-axis = Time 120 Y-axis = Forwarding Rate 122 Figure 1. Convergence Graph 124 2. Existing definitions 126 This document uses existing terminology defined in other BMWG 127 work. Examples include, but are not limited to: 129 Latency [Ref.[Ba91], section 3.8] 130 Frame Loss Rate [Ref.[Ba91], section 3.6] 131 Throughput [Ref.[Ba91], section 3.17] 132 Device Under Test (DUT) [Ref.[Ma98], section 3.1.1] 133 System Under Test (SUT) [Ref.[Ma98], section 3.1.2] 134 Out-of-order Packet [Ref.[Po06], section 3.3.2] 135 Duplicate Packet [Ref.[Po06], section 3.3.3] 136 Packet Reordering [Ref.[Mo06], section 3.3] 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in BCP 14, RFC 2119 141 [Br97]. RFC 2119 defines the use of these key words to help make the 142 intent of standards track documents as clear as possible. While this 143 document uses these keywords, this document is not a standards track 144 document. 146 IGP Data Plane Route Convergence 148 3. Term Definitions 149 3.1 Convergence Event 151 Definition: 152 The occurrence of a planned or unplanned action in the network 153 that results in a change in the egress interface of the Device 154 Under Test (DUT) for routed packets. 156 Discussion: 157 Convergence Events include link loss, routing protocol session 158 loss, router failure, configuration change, and better next-hop 159 learned via a routing protocol. 161 Measurement Units: 162 N/A 164 Issues: 165 None 167 See Also: 168 Convergence Packet Loss 169 Convergence Event Instant 171 3.2 Route Convergence 173 Definition: 174 Route Convergence is the action to update all components of the 175 router with the most recent route change(s) including the 176 Routing Information Base (RIB) and Forwarding Information Base 177 (FIB), along with software and hardware tables, such that 178 forwarding is successful for one or more destinations. 180 Discussion: 181 Route Convergence is required after a Convergence Event. 182 Route Convergence can be observed externally by the rerouting 183 of data traffic to the next-best egress interface. Also, 184 Route Convergence may or may not be sustained over time. 186 Measurement Units: 187 N/A 189 Issues: 190 None 192 See Also: 193 Network Convergence 194 Full Convergence 195 Convergence Event 196 IGP Data Plane Route Convergence 198 3.3 Network Convergence 200 Definition: 201 The completion of updating of all routing tables, including the 202 FIB, in all routers throughout the network. 204 Discussion: 205 Network Convergence requires completion of all Route Convergence 206 operations for all routers in the network following a 207 Convergence Event. Network Convergence can be observed by 208 recovery of System Under Test (SUT) Throughput to equal the 209 offered load, with no Stale Forwarding, and no Blenders 210 [Ca01][Ci03]. 212 Measurement Units: 213 N/A 215 Issues: 216 None 218 See Also: 219 Route Convergence 220 Stale Forwarding 222 3.4 Full Convergence 224 Definition: 225 Route Convergence for an entire FIB in which complete recovery 226 from the Convergence Event is indicated by the DUT Throughput 227 equal to the offered load. 229 Discussion: 230 When benchmarking convergence, it is useful to measure 231 the time to converge an entire FIB. For example, 232 a Convergence Event can be produced for an OSPF table of 233 5000 routes so that the time to converge routes 1 through 234 5000 is measured. Full Convergence is externally observable 235 from the data plane when the Throughput of the data 236 plane traffic on the Next-Best Egress Interface equals the 237 offered load. 239 Measurement Units: 240 N/A 242 Issues: None 244 See Also: 245 Network Convergence 246 Route Convergence 247 Convergence Event 248 IGP Data Plane Route Convergence 250 3.5 Packet Loss 252 Definition: 253 The number of packets that should have been forwarded 254 by a DUT under steady state (constant) load that were 255 not forwarded due to lack of resources. 257 Discussion: 258 Packet Loss is a modified version of the term "Frame Loss Rate" 259 as defined in [Ba91]. The term "Frame Loss" is intended for 260 Ethernet Frames while "Packet Loss" is intended for IP packets. 261 Packet Loss can be measured as a reduction in forwarded traffic 262 from the Throughput [Ba91] of the DUT. 264 Measurement units: 265 Number of N-octet offered packets that are not forwarded. 267 Issues: None 269 See Also: 270 Convergence Packet Loss 272 3.6 Convergence Packet Loss 274 Definition: 275 The number of packets lost due to a Convergence Event 276 until Full Convergence occurs. 278 Discussion: 279 Convergence Packet Loss includes packets that were lost and 280 packets that were delayed due to buffering. The Convergence 281 Packet Loss observed in a Packet Sampling Interval may or may 282 not be equal to the number of packets in the offered load 283 during the interval following a Convergence Event (see Figure 284 1). 286 Measurement Units: 287 number of packets 289 Issues: None 291 See Also: 292 Packet Loss 293 Route Convergence 294 Convergence Event 295 Packet Sampling Interval 296 IGP Data Plane Route Convergence 298 3.7 Convergence Event Instant 300 Definition: 301 The time instant that a Convergence Event becomes observable in 302 the data plane. 304 Discussion: 305 Convergence Event Instant is observable from the data 306 plane as the precise time that the device under test begins 307 to exhibit packet loss. 309 Measurement Units: 310 hh:mm:ss:nnn, where 'nnn' is milliseconds 312 Issues: 313 None 315 See Also: 316 Convergence Event 317 Convergence Packet Loss 318 Convergence Recovery Instant 320 3.8 Convergence Recovery Instant 322 Definition: 323 The time instant that Full Convergence is measured 324 and then maintained for an interval of duration equal to 325 the Sustained Forwarding Convergence Time 327 Discussion: 328 Convergence Recovery Instant is measurable from the data 329 plane as the precise time that the device under test 330 achieves Full Convergence. 332 Measurement Units: 333 hh:mm:ss:nnn, where 'nnn' is milliseconds 335 Issues: 336 None 338 See Also: 339 Sustained Forwarding Convergence Time 340 Convergence Packet Loss 341 Convergence Event Instant 342 IGP Data Plane Route Convergence 344 3.9 Rate-Derived Convergence Time 345 Definition: 346 The amount of time for Convergence Packet Loss to persist upon 347 occurrence of a Convergence Event until occurrence of Route 348 Convergence. 350 Rate-Derived Convergence Time can be measured as the time 351 difference from the Convergence Event Instant to the 352 Convergence Recovery Instant, as shown with Equation 1. 354 Equation 1 - 355 Rate-Derived Convergence Time = 356 Convergence Recovery Instant - Convergence Event Instant. 358 Discussion: 359 Rate-Derived Convergence Time should be measured at the maximum 360 Throughput. Failure to achieve Full Convergence results in 361 a Rate-Derived Convergence Time benchmark of infinity. 363 Measurement Units: 364 seconds/milliseconds 366 Issues: 367 None 369 See Also: 370 Convergence Packet Loss 371 Convergence Recovery Instant 372 Convergence Event Instant 373 Full Convergence 375 3.10 Convergence Event Transition 376 Definition: 377 A time interval observed following a Convergence Event in which 378 Throughput gradually reduces to zero. 380 Discussion: 381 The Convergence Event Transition is best observed for Full 382 Convergence. The egress packet rate observed during a 383 Convergence Event Transition may not decrease linearly. Both 384 the offered load and the Packet Sampling Interval influence the 385 observations of the Convergence Event Transition. For example, 386 even if the Convergence Event were to cause the Throughput 387 [Ba91] to drop to zero there would be some number of packets 388 observed, unless the Packet Sampling Interval is exactly 389 aligned with the Convergence Event. This is further discussed 390 with the term "Packet Sampling Interval". 392 IGP Data Plane Route Convergence 394 Measurement Units: 395 seconds/milliseconds 397 Issues: 398 None 400 See Also: 401 Convergence Event 402 Full Convergence 403 Packet Sampling Interval 405 3.11 Convergence Recovery Transition 407 Definition: 408 The characteristic of a router in which Throughput 409 gradually increases to equal the offered load. 411 Discussion: 412 The Convergence Recovery Transition is best observed for 413 Full Convergence. The egress packet rate observed during 414 a Convergence Recovery Transition may not increase linearly. 415 Both the offered load and the Packet Sampling Interval 416 influence the observations of the Convergence Recovery 417 Transition. This is further discussed with the term 418 "Packet Sampling Interval". 420 Measurement Units: 421 seconds/milliseconds 423 Issues: None 425 See Also: 426 Full Convergence 427 Packet Sampling Interval 429 3.12 Loss-Derived Convergence Time 431 Definition: 432 The amount of time it takes for Route Convergence to 433 to be achieved as calculated from the Convergence Packet 434 Loss. Loss-Derived Convergence Time can be calculated 435 from Convergence Packet Loss that occurs due to a 436 Convergence Event and Route Convergence as shown with 437 Equation 2. 439 Equation 2 - 440 Loss-Derived Convergence Time = 441 Convergence Packets Loss / Offered Load 442 NOTE: Units for this measurement are 443 packets / packets/second = seconds 444 IGP Data Plane Route Convergence 446 Discussion: 447 Loss-Derived Convergence Time gives a better than 448 actual result when converging many routes simultaneously. 449 Rate-Derived Convergence Time takes the Convergence Recovery 450 Transition into account, but Loss-Derived Convergence Time 451 ignores the Route Convergence Recovery Transition because 452 it is obtained from the measured Convergence Packet Loss. 454 Ideally, the Convergence Event Transition and Convergence 455 Recovery Transition are instantaneous so that the 456 Rate-Derived Convergence Time = Loss-Derived Convergence Time. 457 However, router implementations are less than ideal. 458 For these reasons the preferred reporting benchmark for IGP 459 Route Convergence is the Rate-Derived Convergence Time. 460 Guidelines for reporting Loss-Derived Convergence Time are 461 provided in [Po07m]. 463 Measurement Units: 464 seconds/milliseconds 466 Issues: 467 None 469 See Also: 470 Convergence Event 471 Convergence Packet Loss 472 Rate-Derived Convergence Time 473 Convergence Event Transition 474 Convergence Recovery Transition 476 3.13 Sustained Forwarding Convergence Time 478 Definition: 479 The amount of time for which Full Convergence is maintained 480 without additional packet loss. 482 Discussion: 483 The purpose of the Sustained Forwarding Convergence Time is to 484 produce Convergence benchmarks protected against fluctuation 485 in Throughput after Full Convergence is observed. The 486 Sustained Forwarding Convergence Time to be used is calculated 487 as shown in Equation 3. 489 IGP Data Plane Route Convergence 491 Equation 3 - 492 Sustained Forwarding Convergence Time = 493 C*(Convergence Packet Loss/Offered Load) 495 where, 496 a. units are packets/pps = sec and 498 b. C is a constant. The RECOMMENDED value for C is 5 as 499 selected from working group consensus. The value 5 was 500 obtained from RFC 2544 [Ba99] which uses 5 seconds as the 501 recommended time for residual frames and DUT restabilization. 503 c. at least one packet per route in the FIB for all 504 routes in the FIB MUST be offered to the DUT per second. 506 Measurement Units: 507 seconds or milliseconds 509 Issues: None 511 See Also: 512 Full Convergence 513 Convergence Recovery Instant 515 3.14 Restoration Convergence Time 517 Definition: 518 The amount of time for the router under test to restore 519 traffic to the original outbound port after recovery from 520 a Convergence Event. 522 Discussion: 523 Restoration Convergence Time is the amount of time for routes 524 to converge to the original outbound port. This is achieved 525 by recovering from the Convergence Event, such as restoring 526 the failed link. Restoration Convergence Time is measured 527 using the Rate-Derived Convergence Time calculation technique, 528 as provided in Equation 1. It is possible to have the 529 Restoration Convergence Time differ from the Rate-Derived 530 Convergence Time. 532 Measurement Units: 533 seconds or milliseconds 535 Issues: 536 None 538 See Also: 539 Convergence Event 540 Rate-Derived Convergence Time 541 IGP Data Plane Route Convergence 543 3.15 Packet Sampling Interval 545 Definition: 546 The interval at which the tester (test equipment) polls to make 547 measurements for arriving packet flows. 549 Discussion: 550 Metrics measured at the Packet Sampling Interval MUST include 551 Forwarding Rate and Convergence Packet Loss. 553 Measurement Units: 554 seconds or milliseconds 556 Issues: 557 Packet Sampling Interval can influence the Convergence Graph. 558 This is particularly true when implementations achieve Full 559 Convergence in less than 1 second. The Convergence Event 560 Transition and Convergence Recovery Transition can become 561 exaggerated when the Packet Sampling Interval is too long. 562 This will produce a larger than actual Rate-Derived 563 Convergence Time. The recommended value for configuration 564 of the Packet Sampling Interval is provided in [Po07m]. 566 See Also: 567 Convergence Packet Loss 568 Convergence Event Transition 569 Convergence Recovery Transition 571 3.16 Local Interface 573 Definition: 574 An interface on the DUT. 576 Discussion: 577 None 579 Measurement Units: 580 N/A 582 Issues: 583 None 585 See Also: 586 Neighbor Interface 587 Remote Interface 588 IGP Data Plane Route Convergence 590 3.17 Neighbor Interface 592 Definition: 593 The interface on the neighbor router or tester that is 594 directly linked to the DUT's Local Interface. 596 Discussion: 597 None 599 Measurement Units: 600 N/A 602 Issues: 603 None 605 See Also: 606 Local Interface 607 Remote Interface 609 3.18 Remote Interface 611 Definition: 612 An interface on a neighboring router that is not directly 613 connected to any interface on the DUT. 615 Discussion: 616 None 618 Measurement Units: 619 N/A 621 Issues: 622 None 624 See Also: 625 Local Interface 626 Neighbor Interface 628 3.19 Preferred Egress Interface 630 Definition: 631 The outbound interface from the DUT for traffic routed to the 632 preferred next-hop. 634 Discussion: 635 The Preferred Egress Interface is the egress interface prior 636 to a Convergence Event. 638 IGP Data Plane Route Convergence 640 Measurement Units: 641 N/A 643 Issues: 644 None 646 See Also: 647 Next-Best Egress Interface 649 3.20 Next-Best Egress Interface 651 Definition: 652 The outbound interface from the DUT for traffic routed to the 653 second-best next-hop. It is the same media type and link speed 654 as the Preferred Egress Interface 656 Discussion: 657 The Next-Best Egress Interface becomes the egress interface 658 after a Convergence Event. 660 Measurement Units: 661 N/A 663 Issues: 664 None 666 See Also: 667 Preferred Egress Interface 669 3.21 Stale Forwarding 671 Definition: 672 Forwarding of traffic to route entries that no longer exist 673 or to route entries with next-hops that are no longer preferred. 675 Discussion: 676 Stale Forwarding can be caused by a Convergence Event and is 677 also known as a "black-hole" since it may produce packet loss. 678 Stale Forwarding exists until Network Convergence is achieved. 680 Measurement Units: 681 N/A 683 Issues: 684 None 686 See Also: 687 Network Convergence 688 IGP Data Plane Route Convergence 690 3.22 Nested Convergence Events 692 Definition: 693 The occurrence of a Convergence Event while the route 694 table is converging from a prior Convergence Event. 696 Discussion: 697 The Convergence Events for a Nested Convergence Event 698 MUST occur with different neighbors. A common 699 observation from a Nested Convergence Event will be 700 the withdrawal of routes from one neighbor while the 701 routes of another neighbor are being installed. 703 Measurement Units: 704 N/A 706 Issues: 707 None 709 See Also: 710 Convergence Event 712 4. IANA Considerations 714 This document requires no IANA considerations. 716 5. Security Considerations 718 Documents of this type do not directly affect the security of 719 Internet or corporate networks as long as benchmarking 720 is not performed on devices or systems connected to production 721 networks. 723 6. Acknowledgements 724 Thanks to Sue Hares, Al Morton, Kevin Dubray, and participants of 725 the BMWG for their contributions to this work. 727 7. References 728 7.1 Normative References 730 [Ba91] Bradner, S. "Benchmarking Terminology for Network 731 Interconnection Devices", RFC1242, July 1991. 733 [Ba99] Bradner, S. and McQuaid, J., "Benchmarking 734 Methodology for Network Interconnect Devices", 735 RFC 2544, March 1999. 737 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", RFC 2119, March 1997 739 IGP Data Plane Route Convergence 741 [Ca90] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 742 Environments", RFC 1195, December 1990. 744 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 745 Switching Devices", RFC 2285, February 1998. 747 [Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 749 [Mo06] Morton, A., et al, "Packet Reordering Metrics", RFC 4737, 750 November 2006. 752 [Po06] Poretsky, S., et al., "Terminology for Benchmarking 753 Network-layer Traffic Control Mechanisms", RFC 4689, 754 November 2006. 756 [Po07a] Poretsky, S., "Benchmarking Applicability for IGP Data Plane 757 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-13, 758 work in progress, July 2007. 760 [Po07m] Poretsky, S. and Imhoff, B., "Benchmarking Methodology for 761 IGP Data Plane Route Convergence", 762 draft-ietf-bmwg-igp-dataplane-conv-meth-13, work in progress, 763 July 2007. 765 7.2 Informative References 767 [Ca01] S. Casner, C. Alaettinoglu, and C. Kuan, "A Fine-Grained View 768 of High Performance Networking", NANOG 22, June 2001. 770 [Ci03] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized 771 Active Measurements on a Tier 1 IP Backbone", IEEE 772 Communications Magazine, pp90-97, May 2003. 774 8. Author's Address 776 Scott Poretsky 777 Reef Point Systems 778 8 New England Executive Park 779 Burlington, MA 01803 780 USA 782 Phone: + 1 508 439 9008 783 EMail: sporetsky@reefpoint.com 785 Brent Imhoff 786 Juniper Networks 787 1194 North Mathilda Ave 788 Sunnyvale, CA 94089 789 USA 791 Phone: + 1 314 378 2571 792 EMail: bimhoff@planetspork.com 793 IGP Data Plane Route Convergence 795 Full Copyright Statement 797 Copyright (C) The IETF Trust (2007). 799 This document is subject to the rights, licenses and restrictions 800 contained in BCP 78, and except as set forth therein, the authors 801 retain all their rights. 803 This document and the information contained herein are provided 804 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 805 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 806 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 807 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 808 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 809 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 810 FOR A PARTICULAR PURPOSE. 812 Intellectual Property 813 The IETF takes no position regarding the validity or scope of any 814 Intellectual Property Rights or other rights that might be claimed to 815 pertain to the implementation or use of the technology described in 816 this document or the extent to which any license under such rights 817 might or might not be available; nor does it represent that it has 818 made any independent effort to identify any such rights. Information 819 on the procedures with respect to rights in RFC documents can be 820 found in BCP 78 and BCP 79. 822 Copies of IPR disclosures made to the IETF Secretariat and any 823 assurances of licenses to be made available, or the result of an 824 attempt made to obtain a general license or permission for the use of 825 such proprietary rights by implementers or users of this 826 specification can be obtained from the IETF on-line IPR repository at 827 http://www.ietf.org/ipr. 829 The IETF invites any interested party to bring to its attention any 830 copyrights, patents or patent applications, or other proprietary 831 rights that may cover technology that may be required to implement 832 this standard. Please address the information to the IETF at ietf- 833 ipr@ietf.org. 835 Acknowledgement 836 Funding for the RFC Editor function is currently provided by the 837 Internet Society.