idnits 2.17.1 draft-huston-idr-as4bytes-survey-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 214. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 191. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 198. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 204. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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. ** 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 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 (September 20, 2005) is 6792 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) == Outdated reference: A later version (-13) exists of draft-ietf-idr-as4bytes-10 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission G. Huston 3 Internet-Draft APNIC 4 Expires: March 24, 2006 September 20, 2005 6 BGP support for 4-Byte AS Numbers - Implementation Survey Report 7 draft-huston-idr-as4bytes-survey-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 24, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document provides a survey of BGP-4 4-Byte AS Number support 41 implementations. 43 1. Survey Summary 45 This document provides a survey of BGP-4 4-Byte AS Number Support 46 [ID.4ByteAS] implementations. After a brief summary, each response 47 is listed. The editor, makes no claim as to the accuracy of the 48 information provided. 50 2. Summary Forms 52 2.1. Juniper Networks 54 Organization: Juniper Networks 56 Person filling out this form: 57 Bruno Rijsman 59 Implementation: 60 JUNOSe 4-1-0 and later 62 Does the implementation include all parts of the specification: 63 Yes 65 Are there parts of the specification that are unclear where the 66 implementor had to exercise some judgement that may impact 67 interoperability? 68 * It isn't clear what to do if the information in the old as-path 69 is inconsistent with the information in the new as-path. 70 * There some places where AS numbers are used where it wasn't 71 clear how to deal with 4-octet as-numbers (e.g. extended 72 communities). 73 * It isn't spelled out that this capability cannot be dynamically 74 negotiated. 76 Has there been any interoperability testing? 77 Yes; no problems were discovered. 79 1. NEW / OLD ineroperability testing with: 80 Juniper ERX (older version which does not support draft) 81 Juniper M/T/J 82 Cisco 7500 84 2. NEW / NEW interoperability testing with: 85 Juniper M/T/J 86 Redback SmartEdge 88 3. Most deployed Juniper ERX routers run code which supports 89 4-octet AS-numbers (and the feature is enabled by default). 90 This provides some confidence that the draft does not cause 91 interoperability problems. Note however that the NEW_AS_PATH 92 attribute is not generated unless the AS-path contains at 93 least one AS-number greater than 65535 which is -as far as we 94 know- not yet the case in the Internet today. 96 Has there been testing of the interface between this implementation 97 and the 2-byte BGP implementation on the NEW (4-byte) to OLD (2byte) 98 update path? 99 Yes 101 Has there been testing of the OLD (2-byte) to NEW (4-byte) path? 102 Yes 104 Have there been any issues noted with the mechanism to reconstruct 105 the 4-byte AS path from the NEW_AS-PATH attribute and the 2-byte AS 106 Path on an OLD -NEW BGP update session? 107 It isn't clear what to do if the information in the old as-path is 108 inconsistent with the information in the new as-path. 110 Any other comments regarding the implementation 111 Some older versions of Cisco IOS send an unsupported capability 112 notification (instead of ignoring the capability) when they 113 receive a capability advertisement which they don't recognize and 114 which has non-empty data. The 4-octet as-number capability is 115 such a capability. Our implementation recognizes this 116 notification and stops automatically stops advertising the 4-octet 117 as-numbers capability (and others) until the next hard clear on 118 the BGP session. 120 2.2. Redback 122 Organization: Redback 124 Person filling out this form: 125 Albert Tian 127 Does the implementation include all parts of the specification: 128 Yes 130 Are there parts of the specification that are unclear where the 131 implementor had to exercise some judgement that may impact 132 interoperability? 133 No. 135 Has there been any interoperability testing? 136 Yes 138 Has there been testing of the interface between this implementation 139 and the 2-byte BGP implementation on the NEW (4-byte) to OLD (2byte) 140 update path? 141 Yes (Cisco: 2-byte; Redback: 4 byte). 143 Has there been testing of the OLD (2-byte) to NEW (4-byte) path? 144 Yes. (Cisco: 2-byte; Redback: 4-byte). 146 Have there been any issues noted with the mechanism to reconstruct 147 the 4-byte AS path from the NEW_AS-PATH attribute and the 2-byte AS 148 Path on an OLD -NEW BGP update session? 149 No 151 Have there been any issues noted with the mechanism to reconstruct 152 the 4-byte AS path from the NEW_AS-PATH attribute and the 2-byte AS 153 Path on an OLD -> NEW BGP update session? 154 No. 156 Any other comments regarding the implementation 157 No 159 3. IANA Considerations 161 No IANA considerations are noted in this document 163 4. Security Considerations 165 Security considerations are documented in [ID.4ByteAS]. 167 5. References 169 [ID.4ByteAS] 170 Vohra, Q. and E. Chen, "BGP support for four-octet AS 171 number space", Work in progress, Internet 172 Draft: draft-ietf-idr-as4bytes-10.txt, July 2005. 174 Author's Address 176 Geoff Huston 177 Asia Pacific Network Information Centre 179 Email: gih@apnic.net 180 URI: http://www.apnic.net 182 Intellectual Property Statement 184 The IETF takes no position regarding the validity or scope of any 185 Intellectual Property Rights or other rights that might be claimed to 186 pertain to the implementation or use of the technology described in 187 this document or the extent to which any license under such rights 188 might or might not be available; nor does it represent that it has 189 made any independent effort to identify any such rights. Information 190 on the procedures with respect to rights in RFC documents can be 191 found in BCP 78 and BCP 79. 193 Copies of IPR disclosures made to the IETF Secretariat and any 194 assurances of licenses to be made available, or the result of an 195 attempt made to obtain a general license or permission for the use of 196 such proprietary rights by implementers or users of this 197 specification can be obtained from the IETF on-line IPR repository at 198 http://www.ietf.org/ipr. 200 The IETF invites any interested party to bring to its attention any 201 copyrights, patents or patent applications, or other proprietary 202 rights that may cover technology that may be required to implement 203 this standard. Please address the information to the IETF at 204 ietf-ipr@ietf.org. 206 Disclaimer of Validity 208 This document and the information contained herein are provided on an 209 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 210 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 211 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 212 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 213 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 214 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 216 Copyright Statement 218 Copyright (C) The Internet Society (2005). This document is subject 219 to the rights, licenses and restrictions contained in BCP 78, and 220 except as set forth therein, the authors retain all their rights. 222 Acknowledgment 224 Funding for the RFC Editor function is currently provided by the 225 Internet Society.