On Sun, Mar 17, 2024 at 12:24:27AM +0000, Job Snijders wrote: > On Sat, Mar 16, 2024 at 08:19:42PM -0400, Jeffrey Haas wrote: > > > Moreover, we know at least another IXP that dropped support for > > Extended Communities 2 years ago with big success, thus adopting > > such a practice from other fellow IXPs shouldn’t be of > > an issue as long as support for Large Communities is in place. > > > > So, this includes things like RPKI validation signaled by RFC 8097 done by > > the IXP RS? > > The RFC 8097 communities are non-transitive, right? It would seem > strange to ingest those via an EBGP session from the Route Server?
That's a largely correct observation, and overlapping debate partially covered by https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/ Tersely: It's ambiguous in the base extended bgp specification whether you're allowed to "originate" a non-transitive extended community into an adjacent AS. RSes are one of the perfect cases for non-transitive origination. That said, it's not the critical bit of my opinion about extended communities at IXPs. > Additionally, I think there are issues with signaling RPKI validation states > via EBGP, it can cause needless churn. We tried to capture that here: > https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-avoid-rpki-state-in-bgp I'll read this in detail later, but at a quick scan I'm generally supportive of the high level points I'm seeing in it. That said, it's another place where scare text about the "memory" that communities take is used. If you're on an implementation that is that poor about communities for this to be a primary consideration... that's unfortunate. That said, cleaning up communities to reduce the clutter in your table that also have security considerations is quite reasonable. -- Jeff _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
