Considerations for Route Reflection and EBGP
draft-scudder-idr-ebgp-rr-00
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
---|---|---|---|
Author | John Scudder | ||
Last updated | 2012-04-26 (Latest revision 2011-10-24) | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Expired | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Although originally conceived of as a purely IBGP device, in some cases a route reflector may function as an EBGP speaker in addition to its role as envisioned in RFC 4456. When it does so, just like any other EBGP speaker it must advertise its routes to its IBGP peers. This document explains what behavior is required of a route reflector that also functions as an EBGP speaker. It also clarifies the use of the ORIGINATOR_ID and CLUSTER_LIST attributes in this environment.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)