Browse Prior Art Database

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

IP.com Disclosure Number: IPCOM000027936D
Original Publication Date: 2004-Apr-01
Included in the Prior Art Database: 2004-Apr-13
Document File: 8 page(s) / 16K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

G. Huston: AUTHOR

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 21% of the total text.

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...