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 <[email protected]> wrote:

> [Not a specific gripe at you, Nick.]
>
> > On Jun 7, 2024, at 6:45 PM, Nick Hilliard <[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to