BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

Tue Sep 8 16:41:05 UTC 2020

Mark,

> The standard already exists... "NO_EXPORT".

I don't think this is the ask here.

Today NO_EXPORT takes no parameters. I think it would be of benefit to all
to be able to signal NO_EXPORT TO ASN_X in a common (std) way across all of
my peers connected to ASN_X. Moreover policy on all vendors could
understand it too without you worrying to match YOUR_STRING and translate
into some local policy.

That is by no means taking away anything you have at your fingertips .. it
just adds an option to talk common policy language.

Cheers,
R.

On Tue, Sep 8, 2020 at 6:23 PM Mark Tinka via NANOG <nanog at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200908/a0a78825/attachment.html>