draft-ietf-idr-rfc3065bis-05.txt   draft-ietf-idr-rfc3065bis-06.txt 
INTERNET-DRAFT Paul Traina INTERNET-DRAFT Paul Traina
Blissfully Retired
Danny McPherson Danny McPherson
Arbor Networks, Inc. Arbor Networks
John Scudder John Scudder
Cisco Systems, Inc. Juniper Networks
Expires: April 2006 October 2005 Expires: August 2007 February 2007
Autonomous System Confederations for BGP Autonomous System Confederations for BGP
<draft-ietf-idr-rfc3065bis-05.txt> <draft-ietf-idr-rfc3065bis-06.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have applicable patent or other IPR claims of which he or she is aware
been or will be disclosed, and any of which he or she becomes aware have been or will be disclosed, and any of which he or she becomes
will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Border Gateway Protocol (BGP) is an inter-autonomous system The Border Gateway Protocol (BGP) is an inter-autonomous system
routing protocol designed for Transmission Control Protocol/Internet routing protocol designed for Transmission Control Protocol/Internet
Protocol (TCP/IP) networks. BGP requires that all BGP speakers Protocol (TCP/IP) networks. BGP requires that all BGP speakers
within a single autonomous system (AS) must be fully meshed. This within a single autonomous system (AS) must be fully meshed. This
represents a serious scaling problem that has been well documented in represents a serious scaling problem that has been well documented in
a number of proposals. a number of proposals.
This document describes an extension to BGP which may be used to This document describes an extension to BGP which may be used to
create a confederation of autonomous systems that is represented as a create a confederation of autonomous systems that is represented as a
single autonomous system to BGP peers external to the confederation, single autonomous system to BGP peers external to the confederation,
thereby removing the "full mesh" requirement. The intention of this thereby removing the "full mesh" requirement. The intention of this
extension is to aid in policy administration and reduce the extension is to aid in policy administration and reduce the
management complexity of maintaining a large autonomous system. management complexity of maintaining a large autonomous system.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Specification of Requirements . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. AS_CONFED Segment Type Extension . . . . . . . . . . . . . . . 6 3. AS_CONFED Segment Type Extension . . . . . . . . . . . . . . . 6
4. Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. AS_PATH Modification Rules. . . . . . . . . . . . . . . . . 7 4.1. AS_PATH Modification Rules. . . . . . . . . . . . . . . . . 7
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Common Administrative Issues. . . . . . . . . . . . . . . . 9 5.1. Common Administrative Issues. . . . . . . . . . . . . . . . 9
5.2. MED and LOCAL_PREF Handling . . . . . . . . . . . . . . . . 9 5.2. MED and LOCAL_PREF Handling . . . . . . . . . . . . . . . . 9
5.3. AS_PATH and Path Selection. . . . . . . . . . . . . . . . . 10 5.3. AS_PATH and Path Selection. . . . . . . . . . . . . . . . . 10
6. Compatability Considerations . . . . . . . . . . . . . . . . . 10 6. Compatability Considerations . . . . . . . . . . . . . . . . . 10
7. Deployment Considerations. . . . . . . . . . . . . . . . . . . 11 7. Deployment Considerations. . . . . . . . . . . . . . . . . . . 11
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 14
12. Appendix A: Aggregate Routing Information . . . . . . . . . . 15
13. Appendix B: Changes From RFC 3065 . . . . . . . . . . . . . . 15
14. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
As currently defined, BGP requires that all BGP speakers within a As currently defined, BGP requires that all BGP speakers within a
single AS must be fully meshed. The result is that for n BGP single AS must be fully meshed. The result is that for n BGP
speakers within an AS n*(n-1)/2 unique IBGP sessions are required. speakers within an AS n*(n-1)/2 unique IBGP sessions are required.
This "full mesh" requirement clearly does not scale when there are a This "full mesh" requirement clearly does not scale when there are a
large number of IBGP speakers within the autonomous system, as is large number of IBGP speakers within the autonomous system, as is
common in many networks today. common in many networks today.
skipping to change at page 4, line 28 skipping to change at page 4, line 28
BGP", or simply, "BGP Confederations". It has also been observed BGP", or simply, "BGP Confederations". It has also been observed
that BGP Confederations may provide improvements in routing policy that BGP Confederations may provide improvements in routing policy
control. control.
This document is a revision of [RFC 3065], which is itself a revision This document is a revision of [RFC 3065], which is itself a revision
to [RFC 1965]. It includes editorial changes, terminology to [RFC 1965]. It includes editorial changes, terminology
clarifications and more explicit protocol specifications based on clarifications and more explicit protocol specifications based on
extensive implementation and deployment experience with BGP extensive implementation and deployment experience with BGP
Confederations. Confederations.
1.1. Terminology 1.1. Specification of Requirements
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 [RFC 2119].
1.2. Terminology
AS Confederation AS Confederation
A collection of autonomous systems represented and advertised A collection of autonomous systems represented and advertised
as a single AS number to BGP speakers that are not members of as a single AS number to BGP speakers that are not members of
the local BGP confederation. the local BGP confederation.
AS Confederation Identifier AS Confederation Identifier
An externally visible autonomous system number that identifies An externally visible autonomous system number that identifies
skipping to change at page 11, line 22 skipping to change at page 11, line 24
duplication of information will waste system resources, cause duplication of information will waste system resources, cause
unnecessary route flaps, and delay convergence. unnecessary route flaps, and delay convergence.
Care should be taken to manually filter duplicate advertisements Care should be taken to manually filter duplicate advertisements
caused by reachability information being relayed through multiple caused by reachability information being relayed through multiple
Member Autonomous Systems based upon the topology and redundancy Member Autonomous Systems based upon the topology and redundancy
requirements of the confederation. requirements of the confederation.
Additionally, confederations (as well as route reflectors), by Additionally, confederations (as well as route reflectors), by
excluding different reachability information from consideration at excluding different reachability information from consideration at
different locations in a confederation, have been shown [RFC 3365] different locations in a confederation, have been shown [RFC 3365] to
cause permanent oscillation between candidate routes when using the cause permanent oscillation between candidate routes when using the
tie breaking rules required by BGP [BGP-4]. Care must be taken when tie breaking rules required by BGP [BGP-4]. Care must be taken when
selecting MED values and tie breaking policy to avoid these selecting MED values and tie breaking policy to avoid these
situations. situations.
One potential way to avoid this is by configuring inter-Member-AS IGP One potential way to avoid this is by configuring inter-Member-AS IGP
metrics higher than intra-Member-AS IGP metrics and/or using other metrics higher than intra-Member-AS IGP metrics and/or using other
tie breaking policies to avoid BGP route selection based on tie breaking policies to avoid BGP route selection based on
incomparable MEDs. incomparable MEDs.
skipping to change at page 11, line 45 skipping to change at page 12, line 11
This extension to BGP does not change the underlying security issues This extension to BGP does not change the underlying security issues
inherent in the existing BGP protocol, such as those described in inherent in the existing BGP protocol, such as those described in
[RFC 2385] and [BGP-VULN]. [RFC 2385] and [BGP-VULN].
9. Acknowledgments 9. Acknowledgments
The general concept of BGP confederations was taken from IDRP's The general concept of BGP confederations was taken from IDRP's
Routing Domain Confederations [ISO 10747]. Some of the introductory Routing Domain Confederations [ISO 10747]. Some of the introductory
text in this document was taken from [RFC 2796]. text in this document was taken from [RFC 2796].
The authors would like to acknowledge Bruce Cole for his The authors would like to acknowledge Jeffrey Haas for his extensive
implementation feedback and extensive analysis of the limitations of feedback on this document. We'd also like to thank Bruce Cole,
the protocol extensions described in this document and [RFC 3065]. Srihari Ramachandra, Alex Zinin, Naresh Kumar Paliwal, Jeffrey Haas,
We would also like to acknowledge Srihari Ramachandra, Alex Zinin, Cengiz Alaettinoglu, Mike Hollyman and Bruno Rijsman for their
Naresh Kumar Paliwal, Jeffrey Haas, Cengiz Alaettinoglu and Bruno feedback and suggestions.
Rijsman for their feedback and suggestions.
Finally, we'd like to acknowledge Ravi Chandra and Yakov Rekhter for Finally, we'd like to acknowledge Ravi Chandra and Yakov Rekhter for
providing constructive and valuable feedback on earlier versions of providing constructive and valuable feedback on earlier versions of
this specification. this specification.
10. References 10. IANA Considerations
10.1. Normative References This spefication introduces no new IANA considerations and therefore
requires no actions on the part of IANA.
11. References
11.1. Normative References
[BGP-4] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway [BGP-4] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway
Protocol 4", Internet-Draft, "Work in Progress". Protocol 4", RFC 4271.
[RFC 1965] Traina, P. "Autonomous System Confederations for BGP", [RFC 1965] Traina, P. "Autonomous System Confederations for BGP",
RFC 1965, June 1996. RFC 1965, June 1996.
[RFC 3065] Traina, P., McPherson, D. and Scudder, J., "Autonomous [RFC 3065] Traina, P., McPherson, D. and Scudder, J., "Autonomous
System Confederations for BGP", RFC 3065, February 2001. System Confederations for BGP", RFC 3065, February 2001.
10.2. Informative References 11.2. Informative References
[ISO 10747] Kunzinger, C., Editor, "Inter-Domain Routing Protocol", [ISO 10747] Kunzinger, C., Editor, "Inter-Domain Routing Protocol",
ISO/IEC 10747, October 1993. ISO/IEC 10747, October 1993.
[RFC 1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC 1863] Haskin, D., "A BGP/IDRP Route Server alternative to a [RFC 1863] Haskin, D., "A BGP/IDRP Route Server alternative to a
full mesh routing", RFC 1863, October 1995. full mesh routing", RFC 1863, October 1995.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC 2385] Heffernan, A., "Protection of BGP Sessions via the TCP [RFC 2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998. MD5 Signature Option", RFC 2385, August 1998.
[RFC 2796] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection [RFC 2796] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection
An Alternative to Full Mesh IBGP", RFC 2796, April 2000. An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[RFC 3365] McPherson, D., Gill, V., Walton, D., Retana, A., "Border [RFC 3365] McPherson, D., Gill, V., Walton, D., Retana, A., "Border
Gateway Protocol (BGP) Persistent Route Oscillation Condition", Gateway Protocol (BGP) Persistent Route Oscillation Condition",
RFC 3345, August 2002. RFC 3345, August 2002.
[BGP-VULN] Murphy, S., "BGP Security Vulnerabilities Analysis", [BGP-VULN] Murphy, S., "BGP Security Vulnerabilities Analysis",
Internet-Draft, "Work in Progress". Internet-Draft, "Work in Progress".
11. Authors' Addresses 12. Appendix A: Aggregate Routing Information
As a practical matter, aggregation as discussed in [BGP-4] section
9.2.2.2 is not generally employed within confederations. However, in
the event that such aggregation is performed within a confederation,
the rules of [BGP-4] should be followed, making the necessary
substitutions between AS_SET and AS_CONFED_SET and similarly,
AS_SEQUENCE and AS_CONFED_SEQUENCE. Confederation-type segments
(AS_CONFED_SET and AS_CONFED_SEQUENCE) MUST be kept separate from
non-confederation segments (AS_SET and AS_SEQUENCE). An
implementation could also choose to provide a form of aggregation
wherein non-confederation segments are aggregated as discussed in
[BGP-4] section 9.2.2.2 and confederation-type segments are not
aggregated.
Support for aggregation of confederation-type segments is not
mandatory.
13. Appendix B: Changes From RFC 3065
The primary trigger for an update to RFC 3065 was regarding issues
associated with AS path segment handling, in particular what to do
when interacting with BGP peers external to a confederation and to
ensure AS_CONFED_[SET|SEQUENCE] segment types are not propagated to
peers outside of a confederation.
As such, the "Error Handling" section above was added and applies not
only to explicitly call attention to BGP Confederation speakers, but
to all BGP speakers.
Other changes are mostly trivial and surrounding some clarification
and consistency in terminology and denoting that
AS_CONFED_[SET|SEQUENCE] Segment Type handling should be just as it
is in the base BGP specification [BGP-4].
14. Authors' Addresses
Paul Traina Paul Traina
EMail: pst+confed@spamcatcher.bogus.com Blissfully Retired
Email: bgp-confederations <possibly at> st04.pst.org
Danny McPherson Danny McPherson
Arbor Networks, Inc. Arbor Networks
Phone: +1 303.470.9257
EMail: danny@arbor.net EMail: danny@arbor.net
John G. Scudder John G. Scudder
Cisco Systems, Inc. Juniper Networks
170 West Tasman Drive EMail: jgs@juniper.net
San Jose, CA 95134
Phone: +1 734.302.4128
EMail: jgs@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 14, line 46 skipping to change at page 16, line 40
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The IETF Trust (2007).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 27 change blocks. 
58 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/