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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

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 2004