Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt

On Apr 30, 2008, at 12:06 PM, Danny McPherson wrote:
> Take, for example, the case where the client doesn't know how
> to handle the new community and some routing information loop
> results.

The nice thing is that the feature is backward compatible and fails  
safe -- if the client doesn't know how to handle the community, then  
it sees itself in the ORIGINATOR_ID and drops the route.  No route, no  
routing information loop.  Granted the behavior of dropping the route  
is undesired, but not horrible.

> I saw this occur in a real network when vendor 'n' changed their
> RR behavior to that of 2796 and reflected routes back to clients
> while the clients, vendor 'm', didn't know they were supposed to
> drop the routes.

Interesting -- one would have expected the vendor 'm' router to drop  
the routes even if it didn't understand ORIGINATOR_ID, due to the  
NEXT_HOP check.  I guess if the NEXT_HOP were getting rewritten...

But in any event this particular case is academic because of the "fail  
safe" behavior discussed above -- any client that interoperates with a  
2796 RR will fail safe.  (Any client that doesn't interoperate with a  
2796 RR is arguably pretty broken at this point.)

> How much configuration overhead is actually being saved
> on the PEs that justifies changing basic BGP specification
> behavior

One of my co-authors may want to address this point.  From my PoV,  
suffice it to say there's real demand for the feature.

> and introducing even more redundant network
> state?

What is the redundant network state you're referring to?  The "address  
family overlays" I snipped out of the quote?  Something else?

--John
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr