BGP Route Reflector with Next Hop Self
draft-ietf-idr-bgp-fwd-rr-03
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
Expired & archived
|
|
|---|---|---|---|
| Authors | Kaliraj Vairavakkalai , Natrajan Venkataraman | ||
| Last updated | 2025-03-21 (Latest revision 2024-09-17) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Expired | |
| Consensus boilerplate | Unknown | ||
| 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
The procedures in BGP Route Reflection (RR) spec RFC4456 primarily deal with scenarios where the RR is reflecting BGP routes with next hop unchanged. In some deployments like Inter-AS Option C (Section 10, RFC4364), the ABRs may perform RR functionality with nexthop set to self. If adequate precautions are not taken, the RFC4456 procedures can result in traffic forwarding loop in such deployments. This document illustrates one such looping scenario, and specifies approaches to minimize possiblity of traffic forwarding loop in such deployments. An example with Inter-AS Option C (Section 10, RFC4364) deployment is used, where RR with next hop self is used at redundant ABRs when they re-advertise BGP transport family routes between multiple IGP domains.
Authors
Kaliraj Vairavakkalai
Natrajan Venkataraman
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)