Route Target Constrained Distribution of Routes with no Route Targets
draft-rosen-idr-rtc-no-rt-01

Document Type Replaced Internet-Draft (idr WG)
Last updated 2015-10-14 (latest revision 2014-10-16)
Replaced by draft-ietf-idr-rtc-no-rt
Stream IETF
Intended RFC status Proposed Standard
Formats
Expired & archived
plain text pdf html bibtex
Stream WG state Adopted by a WG
Document shepherd No shepherd assigned
IESG IESG state Replaced by draft-ietf-idr-rtc-no-rt
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-rosen-idr-rtc-no-rt-01.txt

Abstract

BGP routes sometimes carry an "Extended Communities" path attribute. An Extended Communities path attribute can contain one or more "Route Targets" (RTs). By means of a procedure known as "RT Constrained Distribution" (RTC), a BGP speaker can send BGP UPDATE messages that express its interest in a particular set of RTs. Generally, RTC has been applied only to address families whose routes always carry RTs. When RTC is applied to such an address family, a BGP speaker expressing its interest in a particular set of RTs is indicating that it wants to receive all and only the routes of that address family that have at least one of the RTs of interest. However, there are scenarios in which the originator of a route chooses not to include any RTs at all, assuming that the distribution of a route with no RTs at all will be unaffected by RTC. This has led to interoperability problems in the field, where the originator of a route assumes that RTC will not affect the distribution of the route, but intermediate BGP speakers refuse to distribute that route because it does not carry any RT of interest. The purpose of this document is to clarify the effect of the RTC mechanism on routes that do not have any RTs.

Authors

Eric Rosen (erosen@juniper.net)
Keyur Patel (keyupate@cisco.com)
Jeffrey Haas (jhaas@juniper.net)
Robert Raszuk (robert@raszuk.net)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)