Document: draft-ietf-idr-bgp-implementation Reviewer: Mary Barnes Date: July 21, 2004 I think this draft is ready for publication as an Informational draft, with the correction and clarification of a few points and provided, of course, that the companion protocol document is deemed ready, since this is based on an explicit version of the BGP 4 draft. The proposed detailed changes/nits are identified by [MB] in the attachment. There was one point that might require further discussion in that the security section has the general: "This document does not address any security issues." However, section 3.53 "Security Considerations" does highlight that RFC2385 is a MUST authentication mechanism. For completeness, it might be useful to highlight in the security considerations section that all the implementations, as reported, did satisfy the security requirements. Also, I should clarify that I did not validate the requirements against the BGP 4 protocol draft nor double check the validity of the RFC 2119 strengths associated with the requirements (i.e. I'm assuming that those accurately reflect that document and would have been caught by the responders of the survey). If that's not a reasonable assumption, let me know and I'll backtrack through the other document (with the caveat that I am not a routing/BGP 4 expert, at all). Mary. --------------------------------- Interdomain Working Group Internet Draft S. Hares Document: draft-ietf-idr-bgp-implementation-01.txt NextHop A. Retana Cisco Expires: August 2004 July 2004 [MB] Expiration date needs correcting. BGP 4 Implementation Report Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt . [MB] Per the latest guidelines, there should be an additional statement pointing to the shadow site in this section. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Abstract This document provides a survey of the BGP-4 implementation draft- ietf-idr-bgp4-24.txt. After a brief summary, each response is listed. The editor makes no claim as to the accuracy of the information provided. [MB] I think that last statement needs to be clarified that the "information provided" is referring to the results as provided by the implementors and not to the information provided by this document itself (i.e. the assessment). This is quite clearly stated in the introduction, thus I would suggest replacing that last sentence above with the following: " The editor makes no claim as to the accuracy of the reported information used to produce this document. " Hares & RetanaExpires - November !Undefined Bookmark, SAVEDATE[Page 1] [MB] Expiration date needs correcting. ^L draft-ietf-idr-bgp-implementation-01 July 2004 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. [MB] References in this document follow the format [RFC2119] (there is no reference [1]). 2. Results of Survey Significant Differences For every item listed (259 questions), the respondents indicated whether their implementation supports the Functionality/Description or not (Y/N) indicated by the RFC2199 [RFC2119] language. Of the 259 questions in the survey, had two implementations giving an affirmative response(two "y" or "y" and "O") except the following: [MB] Need to fix the RFC 2119 reference and clarify the wording above, therefore suggest the following rewording: " or not (Y/N/O) indicated by the RFC 2119 [RFC2119] language. Of the 259 questions in the survey, at least two implementations provided an affirmative response(either two "Y"s or one "Y" and one "O") except the following: " c) SHOULD - 2 in appendix F (questions 257, 258) Three vendors said no, one vendor said yes to question 257. All four vendors indicated no to question 258. (Please note that Appendix F is text section for optional support. [MB] need a ")" at the end of that last sentence above. 2.1 Differences The following section provides a list of sections where all answers were not "yes". This section is provided to allow the reader a short cut to the interesting points. Differences are found in Subsections: Hares & Retana Expires - January 2005 [Page 5] ^L draft-ietf-idr-bgp-implementation-01 July 2004 MUST 97, 106, 107, 111, 122, 125, 138, 141, 213 [MB] There is one missing from the above list: 98 SHALL 233, 239 SHALL NOT 228 SHOULD 42, 117, 132, 146, 152, 155, 156, 157, 158, 159, 160, 161, 163, 164, 165, 169, 170, 171, 173, 174, 175, 202, 225, 250, 255, 256 [MB] 257 and 258 are missing from the list above SHOULD NOT 226 MAY 67, 94, 121, 143, 180, 223, 247, 254 [MB] 135 is missing from the list above Other 236, 238 Linked Questions 212/213 3. BGP4 Implementation Report For every item listed, the respondents indicated whether their implementation supports the Functionality/Description or not (Y/N) according to the RFC2119 [2] language indicated. Any respondent [MB] Fix reference (i.e. there is no reference 2, this should be [RFC 2119]) comments are included. If appropriate, the respondents indicated with O the fact that the support is neither Y/N (an alternate behavior, for example). Refer to the appropriate sections in [BGP4] for additional details. 2.18.86 Bad Message Length Functionality/Description: The Data field MUST contain the erroneous Lentgh field [MB] "Lentgh" -> "Length" RFC2119: MUST Alcatel Y/N/O/Comments: Y Cisco Y/N/O/Comments: Y Laurel Y/N/O/Comments: Y NextHop Y/N/O/Comments: Y 2.45.225 Fast Convergence Functionality/Description: MinRouteAdvertisementIntervalTimer used for internal peers SHOULD be shorter than the MinRouteAdvertisementIntervalTimer used for external peers, or [MB] Delete extraneous ", or". RFC2119: SHOULD Alcatel Y/N/O/Comments: O Configurable on per peer basis. Cisco Y/N/O/Comments: Y Laurel Y/N/O/Comments: N they are same for ebgp and ibgp NextHop Y/N/O/Comments: Y Configuration option allows to set the time per peer.