It seems that trading off the work that a PE has to do to parse the routes that have been sourced by itself needs to be weighed against the added complexity and additional work a RR must do to ensure that it does not send the routes back to said PE. I would guess that the RR would need to maintain multiple data structures associated with each client peer, have multiple update groups etc... The main point is which network device should do the work? My approach has always been to minimize the work on the RR as it is most important to the viability of the entire service/network.. The RR infrastructure is more critical and important than any single PE...
Jim Uttaro -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Danny McPherson Sent: Thursday, March 26, 2009 3:40 PM To: John G. Scudder Cc: [email protected] Subject: Re: [GROW] RR reflection to clients On Mar 26, 2009, at 1:06 PM, John G. Scudder wrote: > I think the comment in quotes above demonstrates that at worst, > ACCEPT_OWN is tangential to your RR beef. Unless implementations change their behavior to support this, which is why I keep associating it. But yes, in general, I agree. > Suppose the RR spec was changed to mandate suppression of own routes > being sent back to their originators -- in that case I think we'd be > happy to update the ACCEPT_OWN spec as you describe, to explicitly > permit sending just the special routes back to their originators. > Of course it was unnecessary to spec this in the ACCEPT_OWN doc > since as you point out, reality is that the routes are sent anyway. Agreed.. > So, I agree with Robert (and I think you do too) that this is a > distraction from your primary point. Noted. -danny _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
