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