NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control
RFC 3765
Document | Type | RFC - Informational (April 2004; No errata) | |
---|---|---|---|
Author | Geoff Huston | ||
Last updated | 2015-10-14 | ||
Stream | Independent Submission | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | ISE state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3765 (Informational) | |
Action Holders |
(None)
|
||
Telechat date | |||
Responsible AD | Bert Wijnen | ||
Send notices to | (None) |
Network Working Group G. Huston Request for Comments: 3765 Telstra Category: Informational April 2004 NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes the use of a scope control Border Gateway Protocol (BGP) community. This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections. 1. Introduction BGP today has a limited number of commonly defined mechanisms that allow a route to be propagated across some subset of the routing system. The NOEXPORT community allows a BGP speaker to specify that redistribution should extend only to the neighbouring AS. Providers commonly define a number of communities that allow their neighbours to specify how advertised routes should be re-advertised. Current operational practice is that such communities are defined on as AS by AS basis, and while they allow an AS to influence the re- advertisement behaviour of routes passed from a neighbouring AS, they do not allow this scope definition ability to be passed in a transitive fashion to a remote AS. Advertisement scope specification is of most use in specifying the boundary conditions of route propagation. The specification can take on a number of forms, including as AS transit hop count, a set of target ASs, the presence of a particular route object, or a particular characteristic of the inter-AS connection. Huston Informational [Page 1] RFC 3765 NOPEER April 2004 There are a number of motivations for controlling the scope of advertisement of route prefixes, including support of limited transit services where advertisements are restricted to certain transit providers, and various forms of selective transit in a multi-homed environment. This memo does not attempt to address all such motivations of scope control, and addresses in particular the situation of both multi- homing and traffic engineering. The commonly adopted operational technique is that the originating AS advertises an encompassing aggregate route to all multi-home neighbours, and also selectively advertises a collection of more specific routes. This implements a form of destination-based traffic engineering with some level of fail over protection. The more specific routes typically cease to lever any useful traffic engineering outcome beyond a certain radius of redistribution, and a means of advising that such routes need not to be distributed beyond such a point is of some value in moderating one of the factors of continued route table growth. Analysis of the BGP routing tables reveals a significant use of the technique of advertising more specific prefixes in addition to advertising a covering aggregate. In an effort to ameliorate some of the effects of this practice, in terms of overall growth of the BGP routing tables in the Internet and the associated burden of global propagation of dynamic changes in the reachability of such more specific address prefixes, this memo describes the use of a transitive BGP route attribute that allows more specific route tables entries to be discarded from the BGP tables under appropriate conditions. Specifically, this attribute, NOPEER, allows a remote AS not to advertise a route object to a neighbour AS when the two AS's are interconnected under the conditions of some form of sender keep all arrangement, as distinct from some form of provider / customer arrangement. 2. NOPEER Attribute This memo defines the use a new well-known bgp transitive community, NOPEER. The semantics of this attribute is to allow an AS to interpret the presence of this community as an advisory qualification to readvertisement of a route prefix, permitting an AS not to readvertise the route prefix to all external bilateral peer neighbour AS's. It is consistent with these semantics that an AS may filter received prefixes that are received across a peering session that the receiver regards as a bilateral peer sessions. Huston Informational [Page 2] RFC 3765 NOPEER April 2004Show full document text