Inter-Domain Routing Y. Ohara Internet-Draft Japan Advanced Institute of Expires: January 7, 2009 Science and Technology K. Nagami INTEC NetCore, Inc. A. Kato Keio University July 6, 2008 Practical Request for BGP Specification and Implementation draft-ohara-idr-practical-request-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 7, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Ohara, et al. Expires January 7, 2009 [Page 1] Internet-Draft Practical Request for BGP July 2008 Abstract In 2007, a large scale incident have occurred multiple ISPs where a number of BGP sessions were disconnected. This happened because of the different implementation of BGP error handling. Therefore, it is necessary to classify the error processing of BGP to achieve stable operation of BGP, and to define it clearly. This document describes to clarify the classification of BGP error handlings. Ohara, et al. Expires January 7, 2009 [Page 2] Internet-Draft Practical Request for BGP July 2008 1. Introduction BGP [1] is used globally as an interdomain routing protocol. Disconnection of a BGP session may result in a loss of connectivity to some destinations and even disconnection from the Internet can happen in some cases. Therefore from the operational point of view, disconnection of the BGP session should not be happen unless it is absolutely necessary. However, disconnection can happen due to a slight inconcistency in the implementations as well as under specification in BGP protocol definition as described in section 2 . This memo intends to clarify some area of the BGP protocol. It also propose a slightly different behavior of BGP session disconnection, which is desired to maintain the connectivity as much as possible. It is expected that this will contribute the stability of the routing system in the Internet. Ohara, et al. Expires January 7, 2009 [Page 3] Internet-Draft Practical Request for BGP July 2008 2. The incident In December 2007, a large scale incident have occurred in multiple Japanese ISPs where a number of BGP sessions were disconnected at relatively the same time. It was triggered by a type-0 attribute originated by an ISP in laten american region. While the type-0 attribute is recognized as well-known since Optional bit is 0, at the same time as non-transitive since Transitive bit is also 0. In the BGP specification this paradoxical invalid attribute type is not anticipated, and is not discussed. The handling of the type-0 atribute currently depends on the implementations. A vendor A's BGP implementation receives the invalid attribute, ignores it, and propagates it further unless the ACL clearly matches not to do so. Another vendor B's BGP implementation sends a Notification message to the peer router which sent the invalid attribute, then disconnects the BGP session. In ISPs which employ Vendor-A's routers, the invalid attribute propagated throughout the entire AS, and all BGP sessions to other ASes which employ Vendor-B's routers were disconnected accidentally. The consequence was that almost all external BGP sessions (except the one that injected the invalid attribute) were disconnected, resulting the large scale incident where the ASes were almost isolated from the Internet. Ohara, et al. Expires January 7, 2009 [Page 4] Internet-Draft Practical Request for BGP July 2008 3. Proposal for improvement BGP operators (and of course the Internet users) desire the continuous and stable Internet connectivity. Thus, unless the error is highly serious and totally unrecoverable one, BGP sessions should not be disconnected. In order to satisfy this demand, it is necessary to further clarify the classification of BGP error handlings, and to remove ambiguities in the BGP specification. 1. BGP specification should anticipate the style of its operation, and should send disconnection request by Notification only when the error truly cannot be recovered. If it is possible to sustain, the BGP session should not be disconnected. The specification should conform to the principle of RFC1958 [2], i.e. "Be strict when sending and tolerant when receiving", and should be reconfirmed that the details of the specification conform to the principle. 2. BGP implementation should not propagate the attributes of which it decided to ignore. Here, to maintain the extendability of BGP, the attributes that are optional transitive and that are not recognized by the implementation are not considered to be ignored. 3. The implementation of BGP should provide grades to reactions for error process, such as: 1. Receive the invalid attribute, and then ignore it. This attribute is not propagated further. 2. Receive the invalid attribute, and propagate it. 3. Reject the invalid attribute, and disconnect the BGP session. Each of these processes is recommended to have abilities to configure it for each peers, and to enable logging of the events. 4. The BGP specification should remove ambiguities not to leave undefined conditions to process. At least, error handling process for the invalid type-0 attributes should be clearly described. Ohara, et al. Expires January 7, 2009 [Page 5] Internet-Draft Practical Request for BGP July 2008 4. Conclusion The disconnection of BGP sessions is a large problem that removes reachabilities and considerably degrades the robustness of the Internet. To realize the stable Internet, it is desired that the parties to specify, to implement, and to operate execute the specific solutions to each problems individually. Moreover, considering that the specification cannot cover all combinations of possible events (since the number is excessively huge), the principle and the rationale behind the specification needs to be described, in order to lead the implementer (even novice) to produce an implementation which enables the robust BGP operation. Ohara, et al. Expires January 7, 2009 [Page 6] Internet-Draft Practical Request for BGP July 2008 5. References [1] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [2] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. Ohara, et al. Expires January 7, 2009 [Page 7] Internet-Draft Practical Request for BGP July 2008 Authors' Addresses Yasuhiro Ohara Japan Advanced Institute of Science and Technology 1-1 Asahidai Nomi, Ishikawa 923-1292 Japan Phone: +81-761-51-1308 Email: yasu@jaist.ac.jp URI: http://www.jaist.ac.jp/ Ken'ichi Nagami INTEC NetCore, Inc. 1-3-3 Shin-suna Koto-ku, Tokyo 135-0075 Japan Phone: +81-3-5665-5069 Email: nagami@inetcore.com URI: http://www.inetcore.com/ Akira Kato Keio University 2-15-45 Mita Minato-ku, Tokyo 108-8345 Japan Phone: +81-3-5418-6419 Email: kato@wide.ad.jp URI: http://www.keio.ac.jp/ Ohara, et al. Expires January 7, 2009 [Page 8] Internet-Draft Practical Request for BGP July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Ohara, et al. Expires January 7, 2009 [Page 9]