idnits 2.17.1 draft-ietf-idr-bgp-gr-survey-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 an Introduction section. 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 (December 2002) is 7802 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) -- Missing reference section? '1' on line 358 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group John G. Scudder 3 Internet Draft Cisco Systems 4 Expiration Date: May 2003 Editor 5 File name: draft-ietf-idr-bgp-gr-survey-00.txt December 2002 7 BGP Graceful Restart - Implementation Survey 8 draft-ietf-idr-bgp-gr-survey-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 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 months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 This document provides a survey of BGP-4 Graceful Restart 34 implementations. 36 1. Survey Summary 38 This document provides a survey of BGP-4 Graceful Restart [1] 39 implementations. After a brief summary, each response is listed. 40 The editor makes no claim as to the accuracy of the information 41 provided. 43 The following organizations reported having implementations of 44 Graceful Restart: Cisco Systems, IP Infusion, Juniper Networks, 45 Laurel Networks, Redback Networks, Riverstone Networks and Tenor 46 Networks. Andrew Partan responded regarding independent 47 interoperability testing. 49 Respondents reported having tested interoperability between the 50 following: 52 Cisco Juniper Laurel Redback Riverstone 53 Cisco - X X X X 54 Juniper X - X X X 56 In addition to responses from implementors, Andrew Partan 57 reports that he has tested interoperation between 58 Cisco, Juniper and Redback. 60 2. Survey Forms 62 2.1. Cisco Systems, Inc. 64 Person filling out this form: Ruchi Kapoor 66 Does your Graceful Restart implementation do the following as 67 defined in draft-ietf-idr-restart-05.txt? 69 Send the End-of-RIB marker upon completion of initial routing 70 update according to section 4? 72 Yes. 74 Exchange the Graceful Restart capability according to section 75 5? 77 Yes. 79 Restart BGP sessions normally (i.e., a full restart not a 80 Graceful Restart) when terminated with a NOTIFICATION message 81 according to section 6? 83 Yes. 85 Function as a Restarting Speaker according to section 6.1? 87 Yes. 89 Function as a Receiving Speaker according to section 6.2? 91 Yes. 93 List other implementations that you have tested for Graceful 94 Restart interoperability. 96 JunOS. 98 2.2. IP Infusion, Inc. 100 Person filling out this form: Kunihiro Ishiguro 101 , Wei Cao 103 Does your Graceful Restart implementation do the following as 104 defined in draft-ietf-idr-restart-05.txt? 106 Send the End-of-RIB marker upon completion of initial routing 107 update according to section 4? 109 Yes. 111 Exchange the Graceful Restart capability according to section 112 5? 114 Yes, except the "only be a receiver" case. 116 Restart BGP sessions normally (i.e., a full restart not a 117 Graceful Restart) when terminated with a NOTIFICATION message 118 according to section 6? 120 Yes. 122 Function as a Restarting Speaker according to section 6.1? 124 Yes. And we support both planned and unplanned restart. 126 Function as a Receiving Speaker according to section 6.2? 128 Yes. 130 List other implementations that you have tested for Graceful 131 Restart interoperability. 133 None. 135 2.3. Juniper Networks 137 Person filling out this form: Chaitanya Kodeboyina 138 140 Does your Graceful Restart implementation do the following as 141 defined in draft-ietf-idr-restart-05.txt? 142 Graceful restart functionality is not on by default and one 143 has to configure 'graceful-restart' for BGP and other 144 protocols to implement this functionality. So all answers 145 below are conditional on this knob being configured. (There 146 is one knob for all protocols.) 148 Send the End-of-RIB marker upon completion of initial routing 149 update according to section 4? 151 Yes. 153 Exchange the Graceful Restart capability according to section 154 5? 156 Yes. 158 Restart BGP sessions normally (i.e., a full restart not a 159 Graceful Restart) when terminated with a NOTIFICATION message 160 according to section 6? 162 Yes. 164 Function as a Restarting Speaker according to section 6.1? 166 Yes, except that we don't have a capability today (needs a 167 knob at most) to restrict graceful-restart to planned 168 restarts only. But this is an internal matter which has no 169 bearing on interop and I don't see why this paragraph should 170 be part of the draft: 172 If one wants to apply graceful restart only when the 173 restart is planned (as opposed to both planned and 174 unplanned restart), then one way to accomplish this would 175 be to set the Forwarding State bit to 1 after a planned 176 restart, and to 0 in all other cases. Other approaches 177 to accomplish this are outside the scope of this 178 document. 180 Function as a Receiving Speaker according to section 6.2? 182 Yes. 184 List other implementations that you have tested for Graceful 185 Restart interoperability. 187 None. 189 2.4. Laurel Networks, Inc. 191 Person filling out this form: Ardas Cilingiroglu 192 194 Does your Graceful Restart implementation do the following as 195 defined in draft-ietf-idr-restart-05.txt? 197 Send the End-of-RIB marker upon completion of initial routing 198 update according to section 4? 200 Yes. End-of-RIB is generated upon completion of the initial 201 update messages if graceful-restart is configured, even when 202 it's a normal bgp (re)start. 204 Exchange the Graceful Restart capability according to section 205 5? 207 Yes. 209 Restart BGP sessions normally (i.e., a full restart not a 210 Graceful Restart) when terminated with a NOTIFICATION message 211 according to section 6? 213 Yes. 215 Function as a Restarting Speaker according to section 6.1? 217 Yes. We support both planned and unplanned restarts. Also, 218 implemented a configurable upper bound to defer route 219 selection. 221 Function as a Receiving Speaker according to section 6.2? 223 Yes. Implemented a configurable upper bound to retain stale 224 Rib-In routes. 226 List other implementations that you have tested for Graceful 227 Restart interoperability. 229 Cisco and Juniper. 231 2.5. Redback Networks, Inc. 233 Person filling out this form: Jenny Yuan 235 Does your Graceful Restart implementation do the following as 236 defined in draft-ietf-idr-restart-05.txt? 238 Send the End-of-RIB marker upon completion of initial routing 239 update according to section 4? 241 Yes. 243 Exchange the Graceful Restart capability according to section 244 5? 246 Yes. 248 Restart BGP sessions normally (i.e., a full restart not a 249 Graceful Restart) when terminated with a NOTIFICATION message 250 according to section 6? 252 Yes. 254 Function as a Restarting Speaker according to section 6.1? 256 Yes. 258 Function as a Receiving Speaker according to section 6.2? 260 Yes. 262 List other implementations that you have tested for Graceful 263 Restart interoperability. 265 Cisco. 267 2.6. Riverstone Networks 269 Person filling out this form: Greg Hankins 270 272 Does your Graceful Restart implementation do the following as 273 defined in draft-ietf-idr-restart-05.txt? 275 Send the End-of-RIB marker upon completion of initial routing 276 update according to section 4? 277 Yes. 279 Exchange the Graceful Restart capability according to section 280 5? 282 Yes. 284 Restart BGP sessions normally (i.e., a full restart not a 285 Graceful Restart) when terminated with a NOTIFICATION message 286 according to section 6? 288 Yes. 290 Function as a Restarting Speaker according to section 6.1? 292 Yes. 294 Function as a Receiving Speaker according to section 6.2? 296 Yes. 298 List other implementations that you have tested for Graceful 299 Restart interoperability. 301 Cisco, Juniper. 303 Other information: 305 I defined a 'Resync-Time' to cover the following: 307 a) Restarter 309 This timer is started after establishment, and sets an 310 upper limit on time the restarter will wait for EOR 311 markers before sending routes. 313 b) Helper 315 This timer is started at the same point, and is the upper 316 limit on the time taken by the restarter to refresh the 317 'stale' routes. 319 2.7. Tenor Networks 321 Person filling out this form: Jim Tsillas 322 324 Does your Graceful Restart implementation do the following as 325 defined in draft-ietf-idr-restart-05.txt? 327 Send the End-of-RIB marker upon completion of initial routing 328 update according to section 4? 330 Yes 332 Exchange the Graceful Restart capability according to section 333 5? 335 Yes 337 Restart BGP sessions normally (i.e., a full restart not a 338 Graceful Restart) when terminated with a NOTIFICATION message 339 according to section 6? 341 Yes 343 Function as a Restarting Speaker according to section 6.1? 345 Yes 347 Function as a Receiving Speaker according to section 6.2? 349 Yes 351 List other implementations that you have tested for Graceful 352 Restart interoperability. 354 (None given.) 356 3. References 358 [1] Ramachandra, S., Y. Rekhter, R. Fernando, J. Scudder and E. Chen, 359 "Graceful Restart Mechanism for BGP," Work in Progress (draft-ietf- 360 idr-restart-05.txt), June 2002. 362 4. Security Considerations 364 This document does not address any security issues. 366 5. IANA Considerations 368 No parameters are defined in this document. 370 6. Author's Address 372 John G. Scudder 373 Cisco Systems, Inc. 374 100 S. Main Suite 200 375 Ann Arbor, MI 48104 376 Email: jgs@cisco.com 378 7. Full Copyright Statement 380 Copyright (C) The Internet Society (2002). All Rights Reserved. 382 This document and translations of it may be copied and furnished to 383 others, and derivative works that comment on or otherwise explain it 384 or assist in its implementation may be prepared, copied, published 385 and distributed, in whole or in part, without restriction of any 386 kind, provided that the above copyright notice and this paragraph are 387 included on all such copies and derivative works. However, this doc- 388 ument itself may not be modified in any way, such as by removing the 389 copyright notice or references to the Internet Society or other 390 Internet organizations, except as needed for the purpose of develop- 391 ing Internet standards in which case the procedures for copyrights 392 defined in the Internet Standards process must be followed, or as 393 required to translate it into languages other than English. 395 The limited permissions granted above are perpetual and will not be 396 revoked by the Internet Society or its successors or assigns. 398 This document and the information contained herein is provided on an 399 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 400 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 401 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 402 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 403 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.