idnits 2.17.1 draft-chen-bgp-cease-subcode-survey-00.txt: ** The Abstract section seems to be numbered 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 == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 3) being 81 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-idr-cease-subcode-05 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Enke Chen 2 Internet Draft Redback Networks 3 Expiration Date: October 2004 Editor 5 BGP Cease Subcode - Implementation Report 7 draft-chen-bgp-cease-subcode-survey-00.txt 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 2. Abstract 32 This document provides an implementation report for the BGP Cease 33 Subcodes. 35 3. Summary 37 This document provides an implementation report for the BGP Cease 38 Subcodes [1]. Each response is listed. The editor makes no claim as 39 to the accuracy of the information provided. 41 The following organizations reported having implementations of the 42 BGP Cease Subcodes: Hyperchip, Juniper Networks, and Redback 43 Networks. 45 4. Implementation Forms 47 4.1. Hyperchip 49 Person filling out this form: Jean Dube (jdube@hyperchip.com) 51 Does your implementation recognize all the subcodes defined in 52 the document? (If not, list the subcodes that your implementation 53 recognizes.) 55 Yes 57 List the subcodes that your implementation may send as part 58 of a NOTIFICATION message. 60 All (1 to 8, still some 0) 62 Does your implementation include the Address Family information 63 and the upper bound in the "Data" field of a NOTIFICATION message 64 for the subcode "maximum number of prefixes reached"? 66 Yes 68 Does your implementation implement a backoff mechanism in re-trying 69 a BGP connection, as recommended in the document? 71 No 73 List other implementations that you have tested for BGP Cease 74 Subcodes interoperability. 76 None 78 4.2. Juniper Networks 80 Person filling out this form: Pedro R. Marques (roque@juniper.net) 82 Does your implementation recognize all the subcodes defined in the 83 document? (If not, list the subcodes that your implementation 84 recognizes.) 86 It recognizes codes [1..7]. Code point 8 is not recognized. 88 List the subcodes that your implementation may send as part of a 89 NOTIFICATION message. 91 1, 4, 5, 6, 7 93 Does your implementation include the Address Family information 94 and the upper bound in the "Data" field of a NOTIFICATION message 95 for the subcode "maximum number of prefixes reached"? 97 Yes. 99 Does your implementation implement a backoff mechanism in 100 re-trying a BGP connection, as recommended in the document? 102 Backoff mechanism exists but is not dependent on this draft. 104 List other implementations that you have tested for BGP Cease 105 Subcodes interoperability. 107 Don't know the answer. Me personally, i have not tested interop. 109 4.3. Redback Networks 111 Person filling out this form: Jenny Yuan (jenny@redback.com) 113 Does your implementation recognize all the subcodes defined in 114 the document? (If not, list the subcodes that your implementation 115 recognizes.) 117 Yes 119 List the subcodes that your implementation may send as part 120 of a NOTIFICATION message. 122 1, 2, 3, 4, 6 124 Does your implementation include the Address Family information 125 and the upper bound in the "Data" field of a NOTIFICATION message 126 for the subcode "maximum number of prefixes reached"? 128 Yes 130 Does your implementation implement a backoff mechanism in re-trying 131 a BGP connection, as recommended in the document? 133 Yes (as part of general backoff mechanism for BGP) 135 List other implementations that you have tested for BGP Cease 136 Subcodes interoperability. 138 Not specifically tested, though can received CEASE subcodes from 139 Juniper, and can send CEASE subcodes to Juniper as well. 141 5. Security Considerations 143 This document does not address any security issues. 145 6. IANA Considerations 147 No parameters are defined in this document. 149 7. References 151 [1] E. Chen and V. Gillet, "Subcodes for BGP Cease Notification 152 Message", draft-ietf-idr-cease-subcode-05.txt, March 2004. 154 8. Author Information 156 Enke Chen 157 Redback Networks, Inc. 158 300 Holger Way 159 San Jose, CA 95134 160 Email: enke@redback.com