Considerations for Route Reflection and EBGP
draft-scudder-idr-ebgp-rr-02
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | John Scudder | ||
| Last updated | 2013-04-21 (Latest revision 2012-10-18) | ||
| RFC stream | (None) | ||
| Intended RFC status | (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 updates RFC 4456 by explaining 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.)