draft-ietf-ptomaine-nopeer-03.txt   rfc3765.txt 
Ptomaine G. Huston Network Working Group G. Huston
Internet-Draft Telstra Request for Comments: 3765 Telstra
Expires: November 11, 2003 May 13, 2003 NOPEER Community for Border Gateway Protocol (BGP)
Route Scope Control
NOPEER community for BGP route scope control
draft-ietf-ptomaine-nopeer-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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 November 11, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document describes the use of a scope control BGP community. This document describes the use of a scope control Border Gateway
This well-known advisory transitive community allows an origin AS to Protocol (BGP) community. This well-known advisory transitive
specify the extent to which a specific route should be externally community allows an origin AS to specify the extent to which a
propagated. In particular this community, NOPEER, allows an origin AS specific route should be externally propagated. In particular this
to specify that a route with this attribute need not be advertised community, NOPEER, allows an origin AS to specify that a route with
across bilateral peer connections. this attribute need not be advertised across bilateral peer
connections.
1. Introduction 1. Introduction
BGP today has a limited number of commonly defined mechanisms that BGP today has a limited number of commonly defined mechanisms that
allow a route to be propagated across some subset of the routing allow a route to be propagated across some subset of the routing
system. The NOEXPORT community allows a BGP speaker to specify that system. The NOEXPORT community allows a BGP speaker to specify that
redistribution should extend only to the neighbouring AS. Providers redistribution should extend only to the neighbouring AS. Providers
commonly define a number of communities that allow their neighbours commonly define a number of communities that allow their neighbours
to specify how advertised routes should be re-advertised. Current to specify how advertised routes should be re-advertised. Current
operational practice is that such communities are defined on as AS by operational practice is that such communities are defined on as AS by
skipping to change at page 3, line 21 skipping to change at page 3, line 8
presence of this community as an advisory qualification to presence of this community as an advisory qualification to
readvertisement of a route prefix, permitting an AS not to readvertisement of a route prefix, permitting an AS not to
readvertise the route prefix to all external bilateral peer neighbour readvertise the route prefix to all external bilateral peer neighbour
AS's. It is consistent with these semantics that an AS may filter AS's. It is consistent with these semantics that an AS may filter
received prefixes that are received across a peering session that the received prefixes that are received across a peering session that the
receiver regards as a bilateral peer sessions. receiver regards as a bilateral peer sessions.
3. Motivation 3. Motivation
The size of the BGP routing table has been increasing at an The size of the BGP routing table has been increasing at an
accelerating rate since late 1998. At the time of publication of this accelerating rate since late 1998. At the time of publication of
memo the BGP forwarding table contains over 118,000 entries, and the this memo the BGP forwarding table contains over 118,000 entries, and
three year growth rate of this table shows a trend rate which can be the three year growth rate of this table shows a trend rate which can
correlated to a compound growth rate of no less than 10% per year be correlated to a compound growth rate of no less than 10% per year
[2]. [2].
One of the aspects of the current BGP routing table is the widespread One of the aspects of the current BGP routing table is the widespread
use of the technique of advertising both an aggregate and a number of use of the technique of advertising both an aggregate and a number of
more specific address prefixes. For example, the table may contain a more specific address prefixes. For example, the table may contain a
routing entry for the prefix 10.0.0.0/23 and also contain entries for routing entry for the prefix 10.0.0.0/23 and also contain entries for
the prefixes 10.0.0.0/24 and 10.0.1.0/24. In this example the the prefixes 10.0.0.0/24 and 10.0.1.0/24. In this example the
specific routes fully cover the aggregate announcement. Sparse specific routes fully cover the aggregate announcement. Sparse
coverage of aggregates with more specifics is also observed, where, coverage of aggregates with more specifics is also observed, where,
for example, routing entries for 10.0.0.0/8 and 10.0.1.0/24 both for example, routing entries for 10.0.0.0/8 and 10.0.1.0/24 both
skipping to change at page 3, line 51 skipping to change at page 3, line 38
There are a number of motivations for having both an aggregate route There are a number of motivations for having both an aggregate route
and a number of more specific routes in the routing table, including and a number of more specific routes in the routing table, including
various forms of multi-homed configurations, where there is a various forms of multi-homed configurations, where there is a
requirement to specify a different reachability policy for a part of requirement to specify a different reachability policy for a part of
the advertised address space. the advertised address space.
One of the observed common requirements in the multi-homed network One of the observed common requirements in the multi-homed network
configuration is that of undertaking some form of load balancing of configuration is that of undertaking some form of load balancing of
incoming traffic across a number of external connections to a number incoming traffic across a number of external connections to a number
of different neighbouring ASs. If, for example, an AS wishes to use a of different neighbouring ASs. If, for example, an AS wishes to use
multi-homed configuration for routing-based load balancing and some a multi-homed configuration for routing-based load balancing and some
form of mutual fail over between the multiple access connections for form of mutual fail over between the multiple access connections for
incoming traffic, then one approach is for the AS to advertise the incoming traffic, then one approach is for the AS to advertise the
same aggregate address prefix to a number of its upstream transit same aggregate address prefix to a number of its upstream transit
providers, and then advertise a number of more specifics to providers, and then advertise a number of more specifics to
individual upstream providers. In such a case all of the traffic individual upstream providers. In such a case all of the traffic
destined to the more specific address prefixes will be received only destined to the more specific address prefixes will be received only
over those connections where the more specific has been advertised. over those connections where the more specific has been advertised.
If the neighbour BGP peering session of the more specific If the neighbour BGP peering session of the more specific
advertisement fails, the more specific will cease to be announced and advertisement fails, the more specific will cease to be announced and
incoming traffic will then be passed to the originating network based incoming traffic will then be passed to the originating network based
on the path associated with the advertisement of the encompassing on the path associated with the advertisement of the encompassing
aggregate. In this situation the more specific routes are not aggregate. In this situation the more specific routes are not
automatically subsumed by the presence of the aggregate at any remote automatically subsumed by the presence of the aggregate at any remote
AS. Both the aggregate and the associated more specifics are AS. Both the aggregate and the associated more specific routes are
redistributed across the entire external BGP routing domain. In many redistributed across the entire external BGP routing domain. In many
cases, particularly those associated with desire to undertake traffic cases, particularly those associated with desire to undertake traffic
engineering and service resilience, the more specific routes are engineering and service resilience, the more specific routes are
redistributed well beyond the scope where there is any outcomes in redistributed well beyond the scope where there is any outcomes in
terms of traffic differentiation. terms of traffic differentiation.
To the extent that remote analysis of BGP tables can observe this To the extent that remote analysis of BGP tables can observe this
form of configuration, the number of entries in the BGP forwarding form of configuration, the number of entries in the BGP forwarding
table where more specific entries share a common origin AS with their table where more specific entries share a common origin AS with their
immediately enclosing aggregates comprise some 20% of the total immediately enclosing aggregates comprise some 20% of the total
skipping to change at page 4, line 40 skipping to change at page 4, line 27
aggregate, the number of more specific routes comprises some 14% of aggregate, the number of more specific routes comprises some 14% of
the number of FIB entries. the number of FIB entries.
One protocol mechanism that could be useful in this context is to One protocol mechanism that could be useful in this context is to
allow the originator of an advertisement to state some additional allow the originator of an advertisement to state some additional
qualification on the redistribution of the advertisement, allowing a qualification on the redistribution of the advertisement, allowing a
remote AS to suppress further redistribution under some originator- remote AS to suppress further redistribution under some originator-
specified criteria. specified criteria.
The redistribution qualification condition can be specified either by The redistribution qualification condition can be specified either by
enumeration or by classification. Enumeration would encompass the use enumeration or by classification. Enumeration would encompass the
of a well-known transitive extended community to specify a list of use of a well-known transitive extended community to specify a list
remote AS's where further redistribution is not advised. The weakness of remote AS's where further redistribution is not advised. The
of this approach is that the originating AS would need to constantly weakness of this approach is that the originating AS would need to
revise this enumerated AS list to reflect the changes in inter-AS constantly revise this enumerated AS list to reflect the changes in
topology, as, otherwise, the more specific routes would leak beyond inter-AS topology, as, otherwise, the more specific routes would leak
the intended redistribution scope. An approach of classification beyond the intended redistribution scope. An approach of
allows an originating AS to specify the conditions where further classification allows an originating AS to specify the conditions
redistribution is not advised without having to refer to the where further redistribution is not advised without having to refer
particular AS's where a match to such conditions are anticipated. to the particular AS's where a match to such conditions are
anticipated.
The approach described here to specifying the redistribution boundary The approach described here to specifying the redistribution boundary
condition is one based on the type of bilateral inter-AS peering. condition is one based on the type of bilateral inter-AS peering.
Where one AS can be considered as a customer, and the other AS can be Where one AS can be considered as a customer, and the other AS can be
considered as a contracted agent of the customer, or provider, then considered as a contracted agent of the customer, or provider, then
the relationship is one where the provider, as an agent of the the relationship is one where the provider, as an agent of the
customer, carries the routes and associated policy associated with customer, carries the routes and associated policy associated with
the routes. Where neither AS can be considered as a customer of the the routes. Where neither AS can be considered as a customer of the
other, then the relationship is one of bilateral peering, and neither other, then the relationship is one of bilateral peering, and neither
AS can be considered as an agent of the other in redistributing AS can be considered as an agent of the other in redistributing
skipping to change at page 5, line 14 skipping to change at page 5, line 4
condition is one based on the type of bilateral inter-AS peering. condition is one based on the type of bilateral inter-AS peering.
Where one AS can be considered as a customer, and the other AS can be Where one AS can be considered as a customer, and the other AS can be
considered as a contracted agent of the customer, or provider, then considered as a contracted agent of the customer, or provider, then
the relationship is one where the provider, as an agent of the the relationship is one where the provider, as an agent of the
customer, carries the routes and associated policy associated with customer, carries the routes and associated policy associated with
the routes. Where neither AS can be considered as a customer of the the routes. Where neither AS can be considered as a customer of the
other, then the relationship is one of bilateral peering, and neither other, then the relationship is one of bilateral peering, and neither
AS can be considered as an agent of the other in redistributing AS can be considered as an agent of the other in redistributing
policies associated with routes. This latter arrangement is commonly policies associated with routes. This latter arrangement is commonly
referred to as a "sender keep all peer" relationship, or "peering". referred to as a "sender keep all peer" relationship, or "peering".
This peer boundary can be regarded as a logical point where the This peer boundary can be regarded as a logical point where the
redistribution of additional reachability policy imposed by the redistribution of additional reachability policy imposed by the
origin AS on a route is no longer an imposed requirement. origin AS on a route is no longer an imposed requirement.
This approach allows an originator of a prefix to attach a commonly This approach allows an originator of a prefix to attach a commonly
defined policy to a route prefix, indicate that a route should be defined policy to a route prefix, indicate that a route should be
re-advertised conditionally, based on the characteristics of the re-advertised conditionally, based on the characteristics of the
inter-AS connection. inter-AS connection.
4. IANA considerations 4. IANA Considerations
The IANA should register NOPEER as a well-known community, as The IANA has registered NOPEER as a well-known community, as defined
defined in [1], as having global significance. in [1], as having global significance.
NOPEER (0xFFFFFF04) NOPEER (0xFFFFFF04)
This is an advisory qualification to readvertisement of a route This is an advisory qualification to readvertisement of a route
prefix, permitting an AS not to readvertise the route prefix to all prefix, permitting an AS not to readvertise the route prefix to all
external bilateral peer neighbour AS's. It is consistent with these external bilateral peer neighbour AS's. It is consistent with these
semantics that an AS may filter received prefixes that are received semantics that an AS may filter received prefixes that are received
across a peering session that the receiver regards as a bilateral across a peering session that the receiver regards as a bilateral
peer sessions peer sessions
5. Security considerations 5. Security Considerations
BGP is an instance of a relaying protocol, where route information is BGP is an instance of a relaying protocol, where route information is
received, processed and forwarded. BGP contains no specific received, processed and forwarded. BGP contains no specific
mechanisms to prevent the unauthorized modification of the mechanisms to prevent the unauthorized modification of the
information by a forwarding agent, allowing routing information to be information by a forwarding agent, allowing routing information to be
modified, deleted or false information to be inserted without the modified, deleted or false information to be inserted without the
knowledge of the originator of the routing information or any of the knowledge of the originator of the routing information or any of the
recipients. recipients.
The NOPEER community does not alter this overall situation concerning The NOPEER community does not alter this overall situation concerning
skipping to change at page 6, line 23 skipping to change at page 6, line 15
denial of service attack on the origin AS of the more specific denial of service attack on the origin AS of the more specific
prefix. prefix.
BGP is already vulnerable to a denial of service attack based on the BGP is already vulnerable to a denial of service attack based on the
injection of false routing information. It is possible to use this injection of false routing information. It is possible to use this
community to limit the redistribution of a false route entry such community to limit the redistribution of a false route entry such
that its visibility can be limited and detection and rectification of that its visibility can be limited and detection and rectification of
the problem can be more difficult under the circumstances of limited the problem can be more difficult under the circumstances of limited
redistribution. redistribution.
References 6. References
Normative References: 6.1. Normative References
[1] Chandrasekeran, R., Traina, P. and T. Li, "BGP Communities [1] Chandrasekeran, R., Traina, P. and T. Li, "BGP Communities
Attribute", RFC 1997, August 1996. Attribute", RFC 1997, August 1996.
INformative References: 6.2. Informative References
[2] Huston, G., "Commentary on Inter-Domain Routing in the [2] Huston, G., "Commentary on Inter-Domain Routing in the Internet",
Internet", RFC 3221, December 2001. RFC 3221, December 2001.
Author's Address 7. Author's Address
Geoff Huston Geoff Huston
Telstra Telstra
Intellectual Property Statement EMail: gih@telstra.net
The IETF takes no position regarding the validity or scope of any 8. Full Copyright Statement
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any Copyright (C) The Internet Society (2004). This document is subject
copyrights, patents or patent applications, or other proprietary to the rights, licenses and restrictions contained in BCP 78 and
rights which may cover technology that may be required to practice except as set forth therein, the authors retain all their rights.
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement 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 (C) The Internet Society (2003). All Rights Reserved. Intellectual Property
This document and translations of it may be copied and furnished to The IETF takes no position regarding the validity or scope of any
others, and derivative works that comment on or otherwise explain it Intellectual Property Rights or other rights that might be claimed to
or assist in its implementation may be prepared, copied, published pertain to the implementation or use of the technology described in
and distributed, in whole or in part, without restriction of any this document or the extent to which any license under such rights
kind, provided that the above copyright notice and this paragraph are might or might not be available; nor does it represent that it has
included on all such copies and derivative works. However, this made any independent effort to identify any such rights. Information
document itself may not be modified in any way, such as by removing on the procedures with respect to rights in RFC documents can be
the copyright notice or references to the Internet Society or other found in BCP 78 and BCP 79.
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copies of IPR disclosures made to the IETF Secretariat and any
revoked by the Internet Society or its successors or assignees. 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.
This document and the information contained herein is provided on an The IETF invites any interested party to bring to its attention any
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING copyrights, patents or patent applications, or other proprietary
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING rights that may cover technology that may be required to implement
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION this standard. Please address the information to the IETF at ietf-
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF ipr@ietf.org.
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 25 change blocks. 
101 lines changed or deleted 76 lines changed or added

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