Hi Robert, I do agree with the other colleagues that setting a list of WKLC for IXP purposes should stay outside of this draft.
However back on September 2019 we did try to set up a draft in GROW group (https://datatracker.ietf.org/doc/html/draft-adkp-grow-ixpcommunities-00) where we try to define some Large Communities for IXP purposes with the aim to unify operations. The draft unfortunately didn’t go through but if the community believes it is relevant, I am happy to resurrect it and go further with that. Kind Regards Stavros From: Robert Raszuk <rob...@raszuk.net> Date: Saturday, 8 June 2024 at 01:05 To: Jeffrey Haas <jh...@pfrc.org> Cc: grow@ietf.org <grow@ietf.org> Subject: [GROW]Re: well known large communities Nick, > [moving this to a new thread as it's unrelated to > draft-ietf-grow-ixp-ext-comms] Well IMO it is very much related as that draft recommends a move from ExtComms to LargeComms. For anyone taking it seriously a new encoding should be provided as a hint. Jeff, Actually what seems to be sort of lost in translation from what I intended to say was not so much well known large communities .. but well know IXP large communities. I think we all agree that IXPs (especially IXP RS policies) are creating their own universe and IMO it is worth to a bit unify that space. Many thx, R. PS. But if GROW WG thinks otherwise I rest my case. It was just light suggestion - no more. On Sat, Jun 8, 2024 at 12:58 AM Jeffrey Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>> wrote: [Not a specific gripe at you, Nick.] > On Jun 7, 2024, at 6:45 PM, Nick Hilliard > <n...@foobar.org<mailto:n...@foobar.org>> wrote: > > [moving this to a new thread as it's unrelated to > draft-ietf-grow-ixp-ext-comms] > > Robert Raszuk wrote on 07/06/2024 22:29: >> True. But we there is clear opportunity to define those scoped for IXP use >> case. >> >> This is BCP so IMO good place to encourage using common encoding for most >> common needs. > > I'm not convinced this is a good plan. The semantics of the existing WKCs > have turned out to be unexpectedly complex in production environments, and > the semantics for candidate route server WKCs that have been discussed by RS > operators are a good deal more so. There have been proposals in the past > about this, but none have ended up with rigorous definitions or sample code. Far more importantly, "well known" needed to have the semantics baked into the spec at the beginning. The torches and pitchforks operator crowd that rammed through large communities in the current form weren't interested in slowing down and discussing how that'd work. Thus, there is no such thing and the term should simply stop being used in this fashion. At best, a registry could be set aside for entries from a specifically allocated AS number and implementors can get special semantics added to their code for the specs over time. Not so much "well known" (and generally supported) as it becomes registered. When it finally gets around to happening, I find it likely that either AS 65535 or 4294967295 get used. -- Jeff (I assert no IPR over this.)
_______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
