Route Target Constrained Distribution of Routes with no Route Targets
draft-ietf-idr-rtc-no-rt-12
Document | Type |
Expired Internet-Draft
(idr WG)
Expired & archived
|
|
---|---|---|---|
Authors | Eric C. Rosen , Keyur Patel , Jeffrey Haas , Robert Raszuk | ||
Last updated | 2020-04-03 (Latest revision 2019-10-01) | ||
Replaces | draft-rosen-idr-rtc-no-rt | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | (None) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | Waiting for Implementation | |
Document shepherd | John Scudder | ||
IESG | IESG state | Expired | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | "John Scudder" <jgs@juniper.net> |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
There are a variety of BGP-enabled services in which the originator of a BGP route may attach one or more "Route Targets" to the route. By means of a procedure known as "RT Constrained Distribution" (RTC), a given BGP speaker (call it "B") can announce the set of RTs in which it has interest. The implication is that if a particular route (call it "R") carries any RTs at all, BGP speaker B wants to receive route R if and only if B has announced interest in one of the RTs carried by R. However, if route R does not carry any RTs at all, prior specifications do not make it clear whether B's use of RTC implies that it does not want to receive route R. This has caused interoperability problems in the field, as some implementations of RTC do not allow B to receive R, but some services presuppose that B will receive R. This document updates RFC 4684 by clarifying the effect of the RTC mechanism on routes that do not have any RTs.
Authors
Eric C. Rosen
Keyur Patel
Jeffrey Haas
Robert Raszuk
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)