John,
> The fact is that some RFC 1966 (and pre RFC 1966) RR implementations
> *did* reflect routes back to the client, and relied on the client to
> suppress them, because of this:
>
> A BGP speaker SHALL NOT install a route with itself as the next hop.
Isn't the below quote you cite talks about EBGP cases ?
For IBGP AFAIK no one was at that time doing next hop self on ASBRs
hence just per the below sentence reflected routes would end up on the
ASBRs.
In fact 1771 says just below your quote:
" When a BGP speaker advertises the route to a BGP speaker located in
its own autonomous system, the advertising speaker shall not modify
the NEXT_HOP attribute associated with the route."
Cheers,
R.
In the interest of historical accuracy:
On Mar 26, 2009, at 2:19 PM, Danny McPherson wrote:
In RFC 1966 the RRs did not reflect the route back the client
because the client didn't know it was a client, and for
incremental deployment it was required that the RRs not reflect
it back or a routing information loop could occur.
The fact is that some RFC 1966 (and pre RFC 1966) RR implementations
*did* reflect routes back to the client, and relied on the client to
suppress them, because of this:
A BGP speaker SHALL NOT install a route with itself as the next hop.
(That's the RFC 4271 language but 1771 said the same or similar.)
--John
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
