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]