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

[Danny McPherson <danny at tcb.net>]

>
> Not so.  The reason for that is to allow RR hierarchy to be used.
> Since the point of the draft is that the route's originator has to see
> it, it's important that RR's transparently pass it through.  I'm at a
> loss to see how you can interpret this as a tacit disagreement with my
> statement above.

Then why the 1966 text at all, that was my point.

> I suggest you take it up with that RFC's authors or check the archives
> -- I don't know the answer.  (I would say that implementability can  
> be  
> a "valid_protocol reason" though.)

Heh, that's the high road :-)

> Well, that OR they properly implement the base spec and drop routes
> which have themselves as NEXT_HOP.
>
> Do you really think that a client which doesn't interoperate with 2796
> RRs is viable in a network at all?  Especially one which also violates
> the base spec by not checking the NEXT_HOP?

I've seen it before in a real network.

> OK, I don't see where this is "redundant network state" to speak of.
> Well, I guess for each route treated in this way there's one extra
> route exported from the RR to the route's originator -- but then again
> that is a route which the RR has to export to the rest of the network
> anyway.  So the RR does in effect no extra work.  The PE receiving the
> route does store a little extra stuff, but then again there would be
> some state for that route if it was locally exported between VRFs
> too.  Seems to me as though state -- both dynamic and configuration --
> is more-or-less a wash.

Well, upon thinking about this a bit more, it also seems silly to
me that a network would be architected in such a way as to allow
problems with an 'upstream' RR to affect connectivity between
two VRFs on the same PE.  I'd think to an operator trying to ensure
availability would be worth the configuration overhead, even if
some folks consider the extra 'state' a wash.

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