> On Sep 8, 2020, at 9:22 AM, Mark Tinka via NANOG <nanog@nanog.org> wrote: > > > > On 8/Sep/20 17:55, Douglas Fischer via NANOG wrote: > >> Most of us have already used some BGP community policy to no-export some >> routes to some where. >> >> On the majority of IXPs, and most of the Transit Providers, the very common >> community tell to route-servers and routers "Please do no-export these >> routes to that ASN" is: >> >> -> 0:<TargetASN> >> >> So we could say that this is a de-facto standard. >> >> >> But the Policy equivalent to "Please, export these routes only to that ASN" >> is very varied on all the IXPs or Transit Providers. >> >> >> With that said, now comes some questions: >> >> 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or >> something like that, that would define 0:<TargetASN> as "no-export-to" >> standard? >> >> 2 - What about reserving some 16-bits ASN to use <ExpOnlyTo>:<TargetASN> as >> "export-only-to" standard? >> 2.1 - Is important to be 16 bits, because with (RT) extended communities, >> any ASN on the planet could be the target of that policy. >> 2.2 - Would be interesting some mnemonic number like 1000 / 10000 or so. > > The standard already exists... "NO_EXPORT". Provided ISP's or exchange points > can publish their own local values to match that within their network, I > believe they can do whatever they want, since it's locally-significant. > > I'm not sure we want to go down the trail of standardizing a "de facto" > usage. Just like QoS, it may be doomed as different operators define what it > means for them. > > Mark.
To the extent that communities are standardized, they’re supposed to be ASN:Community, so 0:<TargetASN> seems like a bad convention to begin with. Further, many of the things people claim they want from odd-ball techniques trying to cram things into 32-bit communities are actually standardized and easily implemented (without hackery) using either Extended Communities, or Large Communities, with the advantage that you can also accommodate 4-octet ASNs without stupid router tricks. Please consider looking at existing standards before making up new ones. Thanks, Owen
