Jeff, >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. Staying away from carving out ASN space and motivated by your suggestion above, I see two options: A. A single ASN value (say 4294967295) is assigned as Global Admin value to signify WKLC (or "registered LC" as you seem to prefer). Then some bits (one or two octets) from the data parts of the LC can be specified as a Type field to classify different applications (route leak detection, etc.). The rest of the octets in the data parts are available for application use. B. Each application that requests a registered Global Admin value, gets a unique ASN value. Then each application can specify and use the data parts of the LC as it likes. In Option B, more bits (in fact the full 8 octets of the data parts) are available for the application use. Sriram ========================= -----Original Message----- From: Jeffrey Haas <jh...@pfrc.org> Sent: Friday, June 7, 2024 6:58 PM To: Nick Hilliard <n...@foobar.org> Cc: grow@ietf.org Subject: [GROW]Re: well known large communities [Not a specific gripe at you, Nick.] > On Jun 7, 2024, at 6:45 PM, Nick Hilliard <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
