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

On Apr 30, 2008, at 11:45 AM, John G. Scudder wrote:
> 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.

Even your draft disagrees with this, else it wouldn't mention
the disabling RFC 1966 behavior (as opposed to the discard
based on ORIGINATOR_ID on the client that RFC 2796
introduced -  for no valid _protocol reason, mind you, which
annoys me considerably).  Along this vein, I would be quite
interested in someone providing an explanation of why this
behavior was changed from 1966 to 2796....

> 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.)

Right, but see my point above...  This assumes all clients employ
the discard behavior of 2796.

> 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.

I'm sure there is demand to make 2547 configuration simpler, but
that doesn't mean it's something we should change fundamental
BGP behavior to facilitate.  I would be interested in here from your
co-authors..

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

No, I've come to accept the AF overlays..   What troubles me is the fact
that we're using BGP to enable a RR to modify an update learned from
a client, and to reflect that update back to that client - just does  
seem
good routing protocol hygiene to me, to save configuration overhead
on the client, when it'll surely be further required on the RRs.

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