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

Wed Sep 9 09:39:50 UTC 2020

And use of BGP without IGP left and right when even today bunch of DCs can
do just fine with current IGPs scaling wise is IMO not a good thing.

Thx
R.

On Wed, Sep 9, 2020, 10:55 Jeff Tantsura via NANOG <nanog at nanog.org> wrote:

> I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP,
> example of “ab”use of ASN0 is a de-facto artifact (unfortunate one).
> My goal would be to provide a viable source of information to someone who
> is setting up a new ISP and has a very little clue as where to start. Do’s
> and don’t’s wrt inter-domain communities use.
>
> I really enjoyed the difference RFC7938 (Use of BGP for Routing in
> Large-Scale Data Centers) made, literally 100s of companies have used it
> to educate themselves/ implemented their DC networking.
>
> Cheers,
> Jeff
>
> On Sep 9, 2020, at 10:04, adam via NANOG <nanog at nanog.org> wrote:
>
> 
>
> I don’t agree with the use of reserved ASNs, let alone making it BCP,
> cause it defeats the whole purpose of the community structure.
>
> Community is basically sending a message to an AS. If I want your specific
> AS to interpret the message I set it in format YOUR_ASN:<community value>,
> your AS in the first part of the community means that your rules of how to
> interpret the community value apply.
>
> Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of
> communities (or any other attribute for that matter) just doesn’t sit right
> with me (what’s next? multicast-ASNs that we can subscribe to?).
>
> All the examples in Robert’s draft or wide community RFC, all of them use
> an example AS# the community is addressed to (not some special reserved
> AS#).
>
>
>
> Also should something like this become standard it needs to be properly
> standardized and implemented as a well-known community by most vendors
> (like RFCs defining the wide communities or addition to standard
> communities like no_export/no_advertise/…). This would also eliminate the
> adoption friction from operators rightly claiming “my AS my rules”.
>
>
>
> adam
>
>
>
>
>
> *From:* NANOG <nanog-bounces+adamv0025=netconsultings.com at nanog.org> *On
> Behalf Of *Douglas Fischer via NANOG
> *Sent:* Tuesday, September 8, 2020 4:56 PM
> *To:* NANOG <nanog at nanog.org>
> *Subject:* BGP Community - AS0 is de-facto "no-export-to" marker - Any
> ASN reserved to "export-only-to"?'
>
>
>
> 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.
>
>
>
> --
>
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200909/6b9a3cef/attachment.html>