Well, I invested 15 minutes passing my eyes on the IDR list archive Joel mentioned(scary!).
You were very concise describing aaaall that discussion in such polide way.
I agree that without combining prefix-list and as-path, the effectiveness of ORF, considering its initial purpose, the pros and cons does not pay themselves.
But (there is always a but), I was imagining a different use for ext-community-orf !
Considering scenarios like:
- Route-Servers of big IXPs, now days with almost 200K routes.
- Transit providers sending its own point of view of DFZ with almos 900K routes.
On both cases, informative communities are an excelente way to decide “what is good for my ASN, and what is not”.
Yes, I know that is possible to filter based on that after receiving those routes.
But it takes computational effort on both sides to do that.
And I imagine that comparing to AS-Path Regex, the needed computational effort and the complexity of the logics to do filtering based on community-list are much smaller.
So, if I could say:
“Hey Mr. Route-Server… how are you?
Could you please not send-me the routes that are tagged with the community RS-ASN:xyz?
And after that, send-me just the routes that are tagged with the community RS-ASN:abc?”
In a Route-Server context, beyond reduce the number of BGP Messages that would be great for the CPU/Memory consumption both, RS and RS-Client.
Or, in a Transit context…
1 - Customer opens a ticket with support team to set the export filter to send only default-route.
2 - Customer, 5 days later, opens a ticket with support team re-adjust the export filter, now sending full-routing.
3 - Customer, on next month, opens another ticket with support team to send only the cone at right of the ASN of ITP.
With a good and public informative communities policy and ext-community-orf, the transit customer could change what his router will receive from the BGP transit Peer, depending only on himself.
Well… I don’t really know how complex is to deal with that again on a WG.
But I would like to see that.