Hi Job, Well the below draft is a bit related but not what I was proposing. It says pretty much do not use Extended Communities but use Large Communities instead :). And Extended Communities are used for more than to carry VPN RTs.
What I am proposing is to have a freely downloadable machine readable file (could be IANA maintained if IANA registry can accommodate the format) where we list encoding values and say allow or not by default. The aim is to provide a hint to construct BGP outbound policy. Something like this: *message_type, attribute_type, attribute_trans, sub-type, sub-type_trans, allow|deny* Regards, Robert PS. I took a stub and immediately runned into an interesting case in respect to Route-Refresh Message. If I want to allow in BGP policy basic Route-Refresh or Enhanced Route-Refresh messages however I want to filter all ORF messages the way ORF was distinguishing itself from those two vanilla Route Refresh messages is ONLY by the entire message length field. And only very few BGP implementations even allow you to put ORF deny in their BGP policies :) Of course if (in theory) you do not send ORF capability you should not be receiving such ORF messages, but it never hurts to double check on inbound ... On Sat, May 23, 2026 at 3:16 PM Job Snijders <[email protected]> wrote: > Somewhat related, there is this draft > > https://datatracker.ietf.org/doc/draft-ietf-grow-ixp-ext-comms/ > > The scope could be redefined to be broader than just IXP RS > > Kind regards, > > Job > > _______________________________________________ > GROW mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
