RFC 3765 (rfc3765) - Page 2 of 7

NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control

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