Hi Danny,
AFI/SAFI 1/128 employs also many other functions some of them you may
disagree with.
I don't think we need to blame all SAFI behavior. IMHO if you see a
practical problem with reflecting back paths for the Internet IPv4/IPv6
let's document those and quantify the significance of the problem.
Perhaps the conclusion would be reached that for IPv4 we should not
reflect back to the src. Perhaps we will reach a contrary result that
dropping routes is so cheap and intra-domain bandwith these days of no
issue to worry about it.
But in all of this we could still if there is a valid need reflect back
to the originating PE vpnv4 routes. Speaking of which there is already a
mechanism in place called rt-constrain which does not allow to send all
routes back yet does not break peer-group concept of single update
generation and fast replication to the peers.
Cheers,
R.
On Mar 26, 2009, at 12:27 PM, Robert Raszuk wrote:
Danny,
Please note that tt is perfectly feasible not to reflect back to the
client for one AFI/SAFI and still reflect back for other AFI/SAFIs.
If your main point complains about the change and permission to
reflect back PATHs to the client introduced by RFC 2796 in the scope
of the Internet let's drop even mentioning the ACCEPT_OWN as not
relevant to the topic.
But it is relevant because it employs that function.
As I said below:
"IF ACCEPT_OWN was a function of the RR, and the
routes were only reflected back to the client IF
that community was presented, I'd be perfectly
fine with it."
-danny
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
