RFC 3765 (rfc3765) - Page 2 of 7
NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control
Alternative Format: Original Text Document
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