Re: [External] Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Hunter Fuller]

On Wed, Sep 30, 2020 at 4:43 AM Mark Tinka  wrote:
> So if your peer or provider sent you a link to a web site where they
> published all of their support BGP communities, you'd find that onerous
> to deploy across them?

I'd find it to require more effort than just applying the same
route-maps we already applied to the other peers/providers, and thus,
less desirable.

--
Hunter Fuller (they)
Router Jockey
VBH Annex B-5
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering

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

[Owen DeLong]

Sounds like you need a template based configuration management system and 
better automation more than you need to inflict an ad-hoc standardization of 
additional communities on the world.

Owen


> On Sep 9, 2020, at 12:21 AM, Robert Raszuk via NANOG  wrote:
> 
> Mark,
> 
> Nope .. it is the other way around.
> 
> It is all easy if you look from your network centric view.
> 
> But if I am connected to 10 ISPs in each POP I have to build 10 different 
> egress policies, each embedding custom policy, teach NOC to understand it 
> etc...
> 
> I think if there is a defined way to express prepend N times to my ISP peers 
> across all uplinks or lower local pref in my ISP network in a same way to 
> group of ISPs I see the value.
> 
> Best Regards,
> R.
> 
> 
> On Wed, Sep 9, 2020, 06:36 Mark Tinka via NANOG  > wrote:
> 
> 
> On 8/Sep/20 23:22, Douglas Fischer via NANOG wrote:
> 
>> Exactly Mike!
>> 
>> The Idea would be to define some base levels, to make the creations of 
>> route-filtering simpler to everyone in the world.
>> And what comes beyond that, is in charge of each autonomous system.
>> 
>> It would make the scripting and templates easier and would avoid fat-fingers.
> 
> Are we saying that what individual operators design for their own networks is 
> "complicated", and that coalescing around a single "de facto" standard would 
> simplify that?
> 
> Mark.

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

[Owen DeLong]

In my comments, it’s more about avoiding de facto “standards” in favor of 
having actual “standards” or following existing actual “standards”. There are 
RFCs that cover what the OP wants. There is an IANA well-known Communities 
registry that can be expanded to record any additional functionality OP wants 
from communities without creating de facto standards. The problem with 
so-called “de facto standards” is that there’s an open question of who decides 
what the standard is and how much credibility they have and/or can maintain 
over time. There’s also the problem that nothing prevents someone who doesn’t 
like someone else’s “de facto standard” from creating one of their own. In some 
cases, everyone yawns and ignores the new standard. In other cases, the old 
standard fades in favor of the new. In most cases, the community fractures, 
both standards gain some traction and neither standard wins creating more chaos 
than standard in the end.

IMHO, that’s a real document-able reason.

YMMV.

Owen


> On Sep 8, 2020, at 1:06 PM, Mike Hammett via NANOG  wrote:
> 
> Is there more desire to be flexible because people are snowflakes and their 
> idea is the only way it should be or real, document-able reasons?
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com 
> 
> Midwest-IX
> http://www.midwest-ix.com 
> 
> From: "Tom Beecher" mailto:beec...@beecher.cc>>
> To: "Mike Hammett" mailto:na...@ics-il.net>>
> Cc: "NANOG" mailto:nanog@nanog.org>>, "Douglas Fischer" 
> mailto:fischerdoug...@gmail.com>>
> Sent: Tuesday, September 8, 2020 3:02:37 PM
> Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
> reserved to "export-only-to"?'
> 
> I also get that intent from the OP. However I disagree that there should be a 
> 'de facto' standard created for such things. All flavors of BGP community 
> specifications are designed to be flexible so that different networks can 
> design a system that is tailored to their needs. 
> 
> Having 'de facto' standards does not simplify in my opinion. I believe it 
> just creates more work for operators trying to navigate around different 
> opinions of what 'de facto' means. 
> 
> 
> 
> 
> On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett  > wrote:
> How I see the OP's intent is to create a BCP of what defined communities have 
> what effect instead of everyone just making up whatever they draw out of a 
> hat, simplifying this process for everyone.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com 
> 
> Midwest-IX
> http://www.midwest-ix.com 
> 
> From: "Tom Beecher via NANOG" mailto:nanog@nanog.org>>
> To: "Douglas Fischer"  >
> Cc: "NANOG" mailto:nanog@nanog.org>>
> Sent: Tuesday, September 8, 2020 1:30:19 PM
> Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
> reserved to "export-only-to"?'
> 
> BGP Large Communities ( https://tools.ietf.org/html/rfc8195 
>  ) already provides for anyone to define 
> the exact handling you wish. 
> 
> 
> 
> On Tue, Sep 8, 2020 at 11:57 AM 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:
> 
> 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: as "no-export-to" 
> standard?
> 
> 2 - What about reserving some 16-bits ASN to use : 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 / 1 or so.
> 
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação

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

[Owen DeLong]

> Using 2-byte communities in today's age of explosive "assignment" of
> 4-byte ASN's is similar to the price-hike of IPv4 space. In the long
> term. Standard BGP communities and IPv4 will not be worth the required
> effort/investment (unless you want to "cripple" yourself from the
> get-go). And IPv6 and Large BGP Communities is "slowly" gaining traction
> as the way to go.

There are no 2-octet communities. There have never been 2-octet communities.

Minimum 4 octets, which allows for a 2-octet ASN and a 2-octet community 
identifier.

Owen

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

[Owen DeLong]

Yes, but with large communities, that’s called RFC-8092 and in general, 
RFC-8642 has some good data.

There’s also BGP extended communities (RFC-7153 and the IANA registry it 
creates).

Creating an ad hoc BCP vs. using the existing RFC process seems ill-advised.

Owen

> On Sep 8, 2020, at 11:35 AM, Mike Hammett via NANOG  wrote:
> 
> How I see the OP's intent is to create a BCP of what defined communities have 
> what effect instead of everyone just making up whatever they draw out of a 
> hat, simplifying this process for everyone.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> Midwest-IX
> http://www.midwest-ix.com
> 
> From: "Tom Beecher via NANOG" 
> To: "Douglas Fischer" 
> Cc: "NANOG" 
> Sent: Tuesday, September 8, 2020 1:30:19 PM
> Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
> reserved to "export-only-to"?'
> 
> BGP Large Communities ( https://tools.ietf.org/html/rfc8195 
>  ) already provides for anyone to define 
> the exact handling you wish. 
> 
> 
> 
> On Tue, Sep 8, 2020 at 11:57 AM 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:
> 
> 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: as "no-export-to" 
> standard?
> 
> 2 - What about reserving some 16-bits ASN to use : 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 / 1 or so.
> 
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação
> 

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

[Owen DeLong]

> On Sep 8, 2020, at 9:22 AM, Mark Tinka via NANOG  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:
>> 
>> 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: as "no-export-to" 
>> standard?
>> 
>> 2 - What about reserving some 16-bits ASN to use : 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 / 1 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: 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

Re: [External] Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mark Tinka]

On 11/Sep/20 20:58, Hunter Fuller wrote:


Hey Mark, I am here. At 10364 we have 7 network people, 3 of whom have
an understanding of BGP deeper than surface level. We have 3 peers and
2 transit providers total.

When we go to implement external-facing BGP policy, the #1 concern is
"What are most people doing?". When we turn up a session with a peer
or provider (which we will be doing much more frequently in the near
future), it would be really wonderful if they could say "We support
RFC-style communities" and we would know what that means. And if
RFC exists then we will implement it when it's needed, just like
we do no-export. I don't spend all day on BGP and so I like to defer
to people who have learned from the "school of hard knocks" where
possible.

The last thing we want to do is to have a nonstandard or
difficult-to-understand policy or configuration, because there are
only 3 total people who could possibly understand it, and all of us
have many, many other job responsibilities so we basically have to
"page it back in" every time we go to look at it. The ideal situation
is that we can google "RFC-compliant config" and get something
that helps us get in line with best practices as smoothly as possible.


So if your peer or provider sent you a link to a web site where they 
published all of their support BGP communities, you'd find that onerous 
to deploy across them?


Mark.

Re: [External] Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Hunter Fuller]

On Wed, Sep 9, 2020 at 11:05 AM Mark Tinka via NANOG  wrote:
>> Circling back to earlier where I said there are almost 70k ASNs in use on 
>> the public Internet. Most of those operators don't have complex 
>> configurations. I'd be surprised if less than half of them had anything more 
>> than the most minimal default route configuration.
> I don't know. If they are here, they can chime in.

Hey Mark, I am here. At 10364 we have 7 network people, 3 of whom have
an understanding of BGP deeper than surface level. We have 3 peers and
2 transit providers total.

When we go to implement external-facing BGP policy, the #1 concern is
"What are most people doing?". When we turn up a session with a peer
or provider (which we will be doing much more frequently in the near
future), it would be really wonderful if they could say "We support
RFC-style communities" and we would know what that means. And if
RFC exists then we will implement it when it's needed, just like
we do no-export. I don't spend all day on BGP and so I like to defer
to people who have learned from the "school of hard knocks" where
possible.

The last thing we want to do is to have a nonstandard or
difficult-to-understand policy or configuration, because there are
only 3 total people who could possibly understand it, and all of us
have many, many other job responsibilities so we basically have to
"page it back in" every time we go to look at it. The ideal situation
is that we can google "RFC-compliant config" and get something
that helps us get in line with best practices as smoothly as possible.

--
Hunter Fuller (they)
Router Jockey
VBH Annex B-5
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering

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

[Tom Beecher]

I completely agree that there is value for people sharing different
community structures that they have created for certain use cases. Such
things are generally useful for both operators of any experience level.

On Fri, Sep 11, 2020 at 8:08 AM  wrote:

> Reg the BCP38 vs RFC I guess is point in case (standard or best practice,
> the adoption is still low)
>
>
>
> Reg the community tagging design,
>
> Well it’s daily job of architects/designers to come up with new designs,
> standards and frameworks that can then be adopted by engineering/ops or
> automation system workflows or the business as a whole.
>
> Now would it be useful to have a reference design for various L2VPN
> options, or RR infrastructures, hub-spoke RT allocations, community tagging
> designs, or BGP input sanity checking, if nothing else like food for
> thought, sure…
>
>
>
> adam
>
>
>
> *From:* Jeff Tantsura 
> *Sent:* Wednesday, September 9, 2020 6:01 PM
> *To:* adamv0...@netconsultings.com
> *Cc:* nanog@nanog.org
> *Subject:* Re: BGP Community - AS0 is de-facto "no-export-to" marker -
> Any ASN reserved to "export-only-to"?'
>
>
>
> BCP38 is an RFC, 2827.
>
> It is a grand advise if you can:
>
> -find someone who is actually well versed
>
> -afford that someone.
>
>
>
> Personally - when in early 2000s I had to write complete community tagging
> design for a multi country network, I wish I had  a “how to”
>
> Regards,
>
> Jeff
>
>
>
> On Sep 9, 2020, at 15:35, adamv0...@netconsultings.com wrote:
>
> 
>
> My advice to “someone who is setting up a new ISP and has a very little
> clue as where to start” would be just don’t and instead hire someone who’s
> well versed in this topic.
>
> But I see what you mean, RFC7938 was a good food for thought. But at the
> same time I’m sceptical, for instance would it help if BCP38 was an RFC?
>
> Would be nice for instance if the community could put together a checklist
> of things to consider for ISPs (could be in no particular order) (and
> actually there are such lists albeit concentrated around security)
>
>
>
> adam
>
>
>
> *From:* Jeff Tantsura 
> *Sent:* Wednesday, September 9, 2020 9:52 AM
> *To:* adamv0...@netconsultings.com
> *Cc:* nanog@nanog.org
> *Subject:* Re: BGP Community - AS0 is de-facto "no-export-to" marker -
> Any ASN reserved to "export-only-to"?'
>
>
>
> 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  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:,
> 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  *On
> Behalf Of *Douglas Fischer via NANOG
> *Sent:* Tuesday, September 8, 2020 4:56 PM
> *To:* NANOG 
> *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:
>
>
>
> 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
> 

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

[adamv0025]

Reg the BCP38 vs RFC I guess is point in case (standard or best practice, the 
adoption is still low)

 

Reg the community tagging design, 

Well it’s daily job of architects/designers to come up with new designs, 
standards and frameworks that can then be adopted by engineering/ops or 
automation system workflows or the business as a whole.  

Now would it be useful to have a reference design for various L2VPN options, or 
RR infrastructures, hub-spoke RT allocations, community tagging designs, or BGP 
input sanity checking, if nothing else like food for thought, sure…

 

adam

 

From: Jeff Tantsura  
Sent: Wednesday, September 9, 2020 6:01 PM
To: adamv0...@netconsultings.com
Cc: nanog@nanog.org
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?'

 

BCP38 is an RFC, 2827.

It is a grand advise if you can:

-find someone who is actually well versed

-afford that someone.

 

Personally - when in early 2000s I had to write complete community tagging 
design for a multi country network, I wish I had  a “how to” 

Regards,

Jeff





On Sep 9, 2020, at 15:35, adamv0...@netconsultings.com 
  wrote:



My advice to “someone who is setting up a new ISP and has a very little clue as 
where to start” would be just don’t and instead hire someone who’s well versed 
in this topic.

But I see what you mean, RFC7938 was a good food for thought. But at the same 
time I’m sceptical, for instance would it help if BCP38 was an RFC? 

Would be nice for instance if the community could put together a checklist of 
things to consider for ISPs (could be in no particular order) (and actually 
there are such lists albeit concentrated around security)   

 

adam

 

From: Jeff Tantsura mailto:jefftant.i...@gmail.com> > 
Sent: Wednesday, September 9, 2020 9:52 AM
To: adamv0...@netconsultings.com  
Cc: nanog@nanog.org  
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?'

 

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 mailto:nanog@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:, 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 mailto:nanog-bounces+adamv0025=netconsultings@nanog.org> > On Behalf Of 
Douglas Fischer via NANOG
Sent: Tuesday, September 8, 2020 4:56 PM
To: NANOG mailto:nanog@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:

 

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: as "no-export-to" standard?

 

2 - What about reserving some 16-bits ASN to use : as 
"export-only-to" standard?

2.1 - Is important to be 16 bits, because with (RT) extended communities, 

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

[Jeff Tantsura via NANOG]

BCP38 is an RFC, 2827.
It is a grand advise if you can:
-find someone who is actually well versed
-afford that someone.

Personally - when in early 2000s I had to write complete community tagging 
design for a multi country network, I wish I had  a “how to” 

Regards,
Jeff

> On Sep 9, 2020, at 15:35, adamv0...@netconsultings.com wrote:
> 
> 
> My advice to “someone who is setting up a new ISP and has a very little clue 
> as where to start” would be just don’t and instead hire someone who’s well 
> versed in this topic.
> But I see what you mean, RFC7938 was a good food for thought. But at the same 
> time I’m sceptical, for instance would it help if BCP38 was an RFC?
> Would be nice for instance if the community could put together a checklist of 
> things to consider for ISPs (could be in no particular order) (and actually 
> there are such lists albeit concentrated around security)   
>  
> adam
>  
> From: Jeff Tantsura  
> Sent: Wednesday, September 9, 2020 9:52 AM
> To: adamv0...@netconsultings.com
> Cc: nanog@nanog.org
> Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
> reserved to "export-only-to"?'
>  
> 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  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:, 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  On Behalf 
> Of Douglas Fischer via NANOG
> Sent: Tuesday, September 8, 2020 4:56 PM
> To: NANOG 
> 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:
>  
> 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: as "no-export-to" 
> standard?
>  
> 2 - What about reserving some 16-bits ASN to use : 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 / 1 or so.
>  
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação

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

[Jeff Tantsura via NANOG]

Great excuse ;-)

Regards,
Jeff

> On Sep 9, 2020, at 15:16, Mike Hammett via NANOG  wrote:
> 
> 
> If history has taught us anything, everything we do will be ignored by those 
> that most need it.  :-)
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> Midwest-IX
> http://www.midwest-ix.com
> 
> From: "Mark Tinka" 
> To: "Mike Hammett" 
> Cc: nanog@nanog.org
> Sent: Wednesday, September 9, 2020 7:59:55 AM
> Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
> reserved to "export-only-to"?'
> 
> Well, the proposed de facto standard is only useful for what we need to 
> signal outside of the AS.
> 
> Since an operator will still need to design for communities used internal to 
> the AS (which will have nothing to do with the outside world, and be of a 
> higher number), they can accomplish both tasks in one sitting; in lieu of 
> first designing for internal use, and then trying to design again for the 
> external standard.
> 
> At any rate, as Nick said yesterday, if it's taken us over 2 decades to agree 
> on the well-known communities we have today, perhaps the industry should go 
> ahead and standardize this proposal anyway, and then see what happens. If 
> history has taught us anything, folk will do what they want for 23 or so 
> years, and even then, it might not turn out the way we hoped.
> 
> If it were me, I'd spend my time on other things. I can design internal 
> operator-specific communities that also do the right thing externally, if 
> needed. Heck, it's what I've done already. My customers are happy and I have 
> little incentive to fix that. 
> 
> But that's just me :-).
> 
> Mark.
> 
> On 9/Sep/20 14:47, Mike Hammett wrote:
> Exactly. There are far more pressing things when launching a new network than 
> coming up with a BGP community scheme from scratch, learning everyone else's 
> BGP community scheme, etc. If networks used a standard, then there is a very 
> minimal ramp-up.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> Midwest-IX
> http://www.midwest-ix.com
> 
> From: "Mark Tinka" 
> To: "Mike Hammett" 
> Cc: nanog@nanog.org
> Sent: Wednesday, September 9, 2020 6:47:13 AM
> Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
> reserved to "export-only-to"?'
> 
> 
> 
> On 9/Sep/20 13:41, Mike Hammett wrote:
> How is that any different than any other network with minimal connectivity 
> (say a non-ISP such as a school, medium business, local government, etc.)?
> 
> Because the existing flexibility of dis-aggregated BGP community design can 
> be done without any need to be in concert with the rest of the world, and 
> your network won't blow up. There are far more pressing things to consider 
> when launching a new network.
> 
> 
> 
> Also, it would likely help that new ISP in Myanmar learn their limited 
> upstream's communities if there were a standard.
> 
> There used to be a very large global transit network that did not support BGP 
> communities for their customers or peers. I'm not sure if that is still their 
> position in 2020, but back then, it did not stop them from growing quite well.
> 
> Mark.
> 
> 
> 

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

[Mark Tinka via NANOG]

On 9/Sep/20 17:42, Robert Raszuk wrote:
>
> It's not about numbers ... it's about ability to uniformly express
> policy with chain of arguments. 
>
> See even with large communities you can define a policy with an
> unstructured parameter and single action then you need to put it on
> all of your boxes to act upon. 
>
> Is it possible to perhaps express it there to do what you need today
> or what you think is possible today. 
>
> Imagine if you would be sending BGP updates between your internal
> peers and tell each peer how to read the encoding ... Doable - sure.
> Good idea - not quite.

I see your logic.

I'm not sure I want to put that much faith in vendors, to be honest.
Just look at how the RPKI communities were cocked up in not-so-recent
releases of Junos.

Would vendor code shipping with pre-defined, more well-known communities
make life easier? Sure, in theory.

Do I want that and still seek a 3AM snooze when the team decide to run a
revision update? Based on my experience, probably not.

But, if vendors (and enough operators) are horny for this kind of thing,
best thing to do would be to build it and see how it actually fares in
the field.

Mark.

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

[Mark Tinka via NANOG]

On 9/Sep/20 17:52, Mike Hammett wrote:

> No, but most network operators also aren't NANOG members, attend NANOG
> shows, subscribe to NANOG lists.
>
> They're small outfits where there's between 1 - 5 total networking people.

Yeah, I'll steer clear of that one :-)...


>
> Circling back to earlier where I said there are almost 70k ASNs in use
> on the public Internet. Most of those operators don't have complex
> configurations. I'd be surprised if less than half of them had
> anything more than the most minimal default route configuration.

I don't know. If they are here, they can chime in.

Mark.

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

[Mike Hammett via NANOG]

No, but most network operators also aren't NANOG members, attend NANOG shows, 
subscribe to NANOG lists. 


They're small outfits where there's between 1 - 5 total networking people. 


Circling back to earlier where I said there are almost 70k ASNs in use on the 
public Internet. Most of those operators don't have complex configurations. I'd 
be surprised if less than half of them had anything more than the most minimal 
default route configuration. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Wednesday, September 9, 2020 8:13:32 AM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 




On 9/Sep/20 15:06, Mike Hammett wrote: 




More operators don't use communities internally than the number of operators 
that do. 



Do you have some empirical data on that? 

I don't know if it's more, or less. But as Charlton Heston said in "True Lies": 

 
"So far this is not blowing my skirt up, gentlemen. Don't you have anything 
remotely substantial, Harry? Do you have any HARD DATA?" 
 

https://youtu.be/-KHkltl22V4?t=73 

:-)... 

Mark. 

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

[Robert Raszuk via NANOG]

It's not about numbers ... it's about ability to uniformly express policy
with chain of arguments.

See even with large communities you can define a policy with an
unstructured parameter and single action then you need to put it on all of
your boxes to act upon.

Is it possible to perhaps express it there to do what you need today or
what you think is possible today.

Imagine if you would be sending BGP updates between your internal peers and
tell each peer how to read the encoding ... Doable - sure. Good idea - not
quite.

R.






On Wed, Sep 9, 2020 at 5:19 PM Mark Tinka  wrote:

>
>
> On 9/Sep/20 15:25, Robert Raszuk wrote:
>
> That's not quite true.
>
> See the entire idea behind defining a common mechanism for signalling
> policy in communities in a flexible way for both intra and inter-domain use
> is to help you to use the same encoding acros policy engines of many
> vendors.
>
> I would actually risk to say that it could be even more applicable
> intra-domain then inter-domain.
>
> See the crux of the thing is that this is not just about putting bunch of
> type-codes into IANA reg. It is much more about uniform encoding for your
> actions with optional parameters across vendors.
>
> In fact the uphill on the implementation side is not because signalling
> new value in BGP is difficult to encode ... it is much more about taking
> those values and translating those to the run time policies in a
> flexible way.
>
>
> But how does that scale for vendors? Let me speak up for them on this one
> :-).
>
> We are now giving them extra work to write code to standardize communities
> for internal purposes. What extra benefit does that provide in lieu of the
> current method where Juniper send 1234:9876 to Cisco, and Cisco sees
> 1234:9876?
>
> Should a vendor be concerned about what purpose an internal community
> serves, as long as it does what the Autonomous System wants it to do?
>
> Unless I am totally misunderstanding your goal.
>
> Mark.
>

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

[Mark Tinka via NANOG]

On 9/Sep/20 15:25, Robert Raszuk wrote:

> That's not quite true. 
>
> See the entire idea behind defining a common mechanism for signalling
> policy in communities in a flexible way for both intra and
> inter-domain use is to help you to use the same encoding acros policy
> engines of many vendors. 
>
> I would actually risk to say that it could be even more applicable
> intra-domain then inter-domain. 
>
> See the crux of the thing is that this is not just about putting bunch
> of type-codes into IANA reg. It is much more about uniform encoding
> for your actions with optional parameters across vendors. 
>
> In fact the uphill on the implementation side is not
> because signalling new value in BGP is difficult to encode ... it is
> much more about taking those values and translating those to the run
> time policies in a flexible way. 

But how does that scale for vendors? Let me speak up for them on this
one :-).

We are now giving them extra work to write code to standardize
communities for internal purposes. What extra benefit does that provide
in lieu of the current method where Juniper send 1234:9876 to Cisco, and
Cisco sees 1234:9876?

Should a vendor be concerned about what purpose an internal community
serves, as long as it does what the Autonomous System wants it to do?

Unless I am totally misunderstanding your goal.

Mark.

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

[adam via NANOG]

> Chriztoffer Hansen via NANOG
> Sent: Wednesday, September 9, 2020 1:29 PM
> 
> On Wed, 9 Sep 2020 at 06:25, Mark Tinka via NANOG 
> wrote:
> > It's not unlike trusting your customers to send you FlowSpec 
> > instructions. No issues technically, but do you want to do it?
> 
> Why not? As a service offering, it makes total sense.
> 
> Thou, generally I agree with you. Trust, but verify any received 
> announcement conforms to a base-set of expectations. Discard non- 
> conforming.
> 
Yeah right, like you all are limiting max length of as_path, dropping boggon 
ASNs, or limiting max number of communities or striping unused/unsupported 
attributes on ingress to your AS...
Or otherwise test what happens to your border edge (or internet-plane 
route-reflectors/ iBGP infrastructure for that matter) if exposed to these.

adam

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

[adam via NANOG]

My advice to “someone who is setting up a new ISP and has a very little clue as 
where to start” would be just don’t and instead hire someone who’s well versed 
in this topic.

But I see what you mean, RFC7938 was a good food for thought. But at the same 
time I’m sceptical, for instance would it help if BCP38 was an RFC? 

Would be nice for instance if the community could put together a checklist of 
things to consider for ISPs (could be in no particular order) (and actually 
there are such lists albeit concentrated around security)   

 

adam

 

From: Jeff Tantsura  
Sent: Wednesday, September 9, 2020 9:52 AM
To: adamv0...@netconsultings.com
Cc: nanog@nanog.org
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?'

 

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 mailto:nanog@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:, 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 mailto:nanog-bounces+adamv0025=netconsultings@nanog.org> > On Behalf Of 
Douglas Fischer via NANOG
Sent: Tuesday, September 8, 2020 4:56 PM
To: NANOG mailto:nanog@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:

 

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: as "no-export-to" standard?

 

2 - What about reserving some 16-bits ASN to use : 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 / 1 or so.

 

-- 

Douglas Fernando Fischer
Engº de Controle e Automação

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

[Robert Raszuk via NANOG]

>
> Well, the proposed de facto standard is only useful for what we need to
> signal outside of the AS.


That's not quite true.

See the entire idea behind defining a common mechanism for signalling
policy in communities in a flexible way for both intra and inter-domain use
is to help you to use the same encoding acros policy engines of many
vendors.

I would actually risk to say that it could be even more applicable
intra-domain then inter-domain.

See the crux of the thing is that this is not just about putting bunch of
type-codes into IANA reg. It is much more about uniform encoding for your
actions with optional parameters across vendors.

In fact the uphill on the implementation side is not because signalling new
value in BGP is difficult to encode ... it is much more about taking those
values and translating those to the run time policies in a flexible way.

Thx,
R.

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

[Mark Tinka via NANOG]

On 9/Sep/20 15:09, Mike Hammett wrote:

> If history has taught us anything, everything we do will be ignored by
> those that most need it.  :-)

Touche :-)...

Mark.

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

[Mark Tinka via NANOG]

On 9/Sep/20 15:06, Mike Hammett wrote:

> More operators don't use communities internally than the number of
> operators that do.

Do you have some empirical data on that?

I don't know if it's more, or less. But as Charlton Heston said in "True
Lies":


"So far this is not blowing my skirt up, gentlemen. Don't you have
anything remotely substantial, Harry? Do you have any HARD DATA?"


    https://youtu.be/-KHkltl22V4?t=73

:-)...

Mark.

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

[Mike Hammett via NANOG]

If history has taught us anything, everything we do will be ignored by those 
that most need it. :-) 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Wednesday, September 9, 2020 7:59:55 AM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 

Well, the proposed de facto standard is only useful for what we need to signal 
outside of the AS. 

Since an operator will still need to design for communities used internal to 
the AS (which will have nothing to do with the outside world, and be of a 
higher number), they can accomplish both tasks in one sitting; in lieu of first 
designing for internal use, and then trying to design again for the external 
standard. 

At any rate, as Nick said yesterday, if it's taken us over 2 decades to agree 
on the well-known communities we have today, perhaps the industry should go 
ahead and standardize this proposal anyway, and then see what happens. If 
history has taught us anything, folk will do what they want for 23 or so years, 
and even then, it might not turn out the way we hoped. 

If it were me, I'd spend my time on other things. I can design internal 
operator-specific communities that also do the right thing externally, if 
needed. Heck, it's what I've done already. My customers are happy and I have 
little incentive to fix that. 

But that's just me :-). 

Mark. 


On 9/Sep/20 14:47, Mike Hammett wrote: 



Exactly. There are far more pressing things when launching a new network than 
coming up with a BGP community scheme from scratch, learning everyone else's 
BGP community scheme, etc. If networks used a standard, then there is a very 
minimal ramp-up. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Wednesday, September 9, 2020 6:47:13 AM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 




On 9/Sep/20 13:41, Mike Hammett wrote: 



How is that any different than any other network with minimal connectivity (say 
a non-ISP such as a school, medium business, local government, etc.)? 


Because the existing flexibility of dis-aggregated BGP community design can be 
done without any need to be in concert with the rest of the world, and your 
network won't blow up. There are far more pressing things to consider when 
launching a new network. 








Also, it would likely help that new ISP in Myanmar learn their limited 
upstream's communities if there were a standard. 



There used to be a very large global transit network that did not support BGP 
communities for their customers or peers. I'm not sure if that is still their 
position in 2020, but back then, it did not stop them from growing quite well. 

Mark. 

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

[Mark Tinka via NANOG]

On 9/Sep/20 14:29, Chriztoffer Hansen wrote:

> Why not? As a service offering, it makes total sense.

Yes, makes total sense.

So why aren't jumping all over it?


>
> Thou, generally I agree with you. Trust, but verify any received
> announcement conforms to a base-set of expectations. Discard
> non-conforming.

This. But as always, the plan is what happens.

Mark.

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

[Mike Hammett via NANOG]

More operators don't use communities internally than the number of operators 
that do. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Wednesday, September 9, 2020 7:59:55 AM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 

Well, the proposed de facto standard is only useful for what we need to signal 
outside of the AS. 

Since an operator will still need to design for communities used internal to 
the AS (which will have nothing to do with the outside world, and be of a 
higher number), they can accomplish both tasks in one sitting; in lieu of first 
designing for internal use, and then trying to design again for the external 
standard. 

At any rate, as Nick said yesterday, if it's taken us over 2 decades to agree 
on the well-known communities we have today, perhaps the industry should go 
ahead and standardize this proposal anyway, and then see what happens. If 
history has taught us anything, folk will do what they want for 23 or so years, 
and even then, it might not turn out the way we hoped. 

If it were me, I'd spend my time on other things. I can design internal 
operator-specific communities that also do the right thing externally, if 
needed. Heck, it's what I've done already. My customers are happy and I have 
little incentive to fix that. 

But that's just me :-). 

Mark. 


On 9/Sep/20 14:47, Mike Hammett wrote: 



Exactly. There are far more pressing things when launching a new network than 
coming up with a BGP community scheme from scratch, learning everyone else's 
BGP community scheme, etc. If networks used a standard, then there is a very 
minimal ramp-up. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Wednesday, September 9, 2020 6:47:13 AM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 




On 9/Sep/20 13:41, Mike Hammett wrote: 



How is that any different than any other network with minimal connectivity (say 
a non-ISP such as a school, medium business, local government, etc.)? 


Because the existing flexibility of dis-aggregated BGP community design can be 
done without any need to be in concert with the rest of the world, and your 
network won't blow up. There are far more pressing things to consider when 
launching a new network. 








Also, it would likely help that new ISP in Myanmar learn their limited 
upstream's communities if there were a standard. 



There used to be a very large global transit network that did not support BGP 
communities for their customers or peers. I'm not sure if that is still their 
position in 2020, but back then, it did not stop them from growing quite well. 

Mark. 

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

[Mark Tinka via NANOG]

Well, the proposed de facto standard is only useful for what we need to
signal outside of the AS.

Since an operator will still need to design for communities used
internal to the AS (which will have nothing to do with the outside
world, and be of a higher number), they can accomplish both tasks in one
sitting; in lieu of first designing for internal use, and then trying to
design again for the external standard.

At any rate, as Nick said yesterday, if it's taken us over 2 decades to
agree on the well-known communities we have today, perhaps the industry
should go ahead and standardize this proposal anyway, and then see what
happens. If history has taught us anything, folk will do what they want
for 23 or so years, and even then, it might not turn out the way we hoped.

If it were me, I'd spend my time on other things. I can design internal
operator-specific communities that also do the right thing externally,
if needed. Heck, it's what I've done already. My customers are happy and
I have little incentive to fix that.

But that's just me :-).

Mark.

On 9/Sep/20 14:47, Mike Hammett wrote:
> Exactly. There are far more pressing things when launching a new
> network than coming up with a BGP community scheme from scratch,
> learning everyone else's BGP community scheme, etc. If networks used a
> standard, then there is a very minimal ramp-up.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> 
> *From: *"Mark Tinka" 
> *To: *"Mike Hammett" 
> *Cc: *nanog@nanog.org
> *Sent: *Wednesday, September 9, 2020 6:47:13 AM
> *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker -
> Any ASN reserved to "export-only-to"?'
>
>
>
> On 9/Sep/20 13:41, Mike Hammett wrote:
>
> How is that any different than any other network with minimal
> connectivity (say a non-ISP such as a school, medium business,
> local government, etc.)?
>
>
> Because the existing flexibility of dis-aggregated BGP community
> design can be done without any need to be in concert with the rest of
> the world, and your network won't blow up. There are far more pressing
> things to consider when launching a new network.
>
>
>
> Also, it would likely help that new ISP in Myanmar learn their
> limited upstream's communities if there were a standard.
>
>
> There used to be a very large global transit network that did not
> support BGP communities for their customers or peers. I'm not sure if
> that is still their position in 2020, but back then, it did not stop
> them from growing quite well.
>
> Mark.
>

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

[Mike Hammett via NANOG]

Exactly. There are far more pressing things when launching a new network than 
coming up with a BGP community scheme from scratch, learning everyone else's 
BGP community scheme, etc. If networks used a standard, then there is a very 
minimal ramp-up. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Wednesday, September 9, 2020 6:47:13 AM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 




On 9/Sep/20 13:41, Mike Hammett wrote: 



How is that any different than any other network with minimal connectivity (say 
a non-ISP such as a school, medium business, local government, etc.)? 


Because the existing flexibility of dis-aggregated BGP community design can be 
done without any need to be in concert with the rest of the world, and your 
network won't blow up. There are far more pressing things to consider when 
launching a new network. 








Also, it would likely help that new ISP in Myanmar learn their limited 
upstream's communities if there were a standard. 



There used to be a very large global transit network that did not support BGP 
communities for their customers or peers. I'm not sure if that is still their 
position in 2020, but back then, it did not stop them from growing quite well. 

Mark. 

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

[Chriztoffer Hansen via NANOG]

On Wed, 9 Sep 2020 at 06:25, Mark Tinka via NANOG  wrote:
> It's not unlike trusting your customers to send you FlowSpec
> instructions. No issues technically, but do you want to do it?

Why not? As a service offering, it makes total sense.

Thou, generally I agree with you. Trust, but verify any received
announcement conforms to a base-set of expectations. Discard
non-conforming.

-- 

Chriztoffer

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

[Mark Tinka via NANOG]

On 9/Sep/20 13:41, Mike Hammett wrote:
> How is that any different than any other network with minimal
> connectivity (say a non-ISP such as a school, medium business, local
> government, etc.)?

Because the existing flexibility of dis-aggregated BGP community design
can be done without any need to be in concert with the rest of the
world, and your network won't blow up. There are far more pressing
things to consider when launching a new network.


>
> Also, it would likely help that new ISP in Myanmar learn their limited
> upstream's communities if there were a standard.

There used to be a very large global transit network that did not
support BGP communities for their customers or peers. I'm not sure if
that is still their position in 2020, but back then, it did not stop
them from growing quite well.

Mark.

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

[Mike Hammett via NANOG]

How is that any different than any other network with minimal connectivity (say 
a non-ISP such as a school, medium business, local government, etc.)? 


Also, it would likely help that new ISP in Myanmar learn their limited 
upstream's communities if there were a standard. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka via NANOG"  
To: nanog@nanog.org 
Sent: Tuesday, September 8, 2020 11:28:48 PM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 



On 8/Sep/20 22:02, Tom Beecher via NANOG wrote: 

> I also get that intent from the OP. However I disagree that there 
> should be a 'de facto' standard created for such things. All flavors 
> of BGP community specifications are designed to be flexible so that 
> different networks can design a system that is tailored to their needs. 
> 
> Having 'de facto' standards does not simplify in my opinion. I 
> believe it just creates more work for operators trying to navigate 
> around different opinions of what 'de facto' means. 

Indeed. 

Consider a new ISP starting operations in Myanmar, with little or no 
global peering, having to wade through tons of information to design 
their BGP community structure based on a "de facto" standard defined by 
a group of ISP's half-way around the world. 

What's the real value? 

Mark. 

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

[Mike Hammett via NANOG]

I don't think the OP cares about what you do internally. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka via NANOG"  
To: nanog@nanog.org 
Sent: Tuesday, September 8, 2020 11:26:43 PM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 




On 8/Sep/20 20:35, Mike Hammett via NANOG wrote: 




How I see the OP's intent is to create a BCP of what defined communities have 
what effect instead of everyone just making up whatever they draw out of a hat, 
simplifying this process for everyone. 



Which only matters if you are extending a community outside of your own network 
to someone else's. 

If the communities are to be used internally, then it doesn't matter what 
definition an operator uses. 

Mark. 

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

[Jeff Tantsura via NANOG]

Robert,

This is not whether you should do it, but, should you have decided to, how to 
do it in the best possible way, without making mistakes someone else has made 
and learnt from.

Regards,
Jeff

> On Sep 9, 2020, at 11:40, Robert Raszuk  wrote:
> 
> 
> 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  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  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:, 
>>> 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  On 
>>> Behalf Of Douglas Fischer via NANOG
>>> Sent: Tuesday, September 8, 2020 4:56 PM
>>> To: NANOG 
>>> 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:
>>> 
>>>  
>>> 
>>> 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: as "no-export-to" 
>>> standard?
>>> 
>>>  
>>> 
>>> 2 - What about reserving some 16-bits ASN to use : 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 / 1 or so.
>>> 
>>>  
>>> 
>>> --
>>> 
>>> Douglas Fernando Fischer
>>> Engº de Controle e Automação

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

[Nick Hilliard via NANOG]

Jeff Tantsura via NANOG wrote on 09/09/2020 09:03:
De-facto standards are as good as people implementing them, however in 
order to enforce non ambiguous implementations, it has to be de-jure 
(e.g. a standard track RFC).

While I’m sympathetic to the idea, I’m quite skeptical about its viability.
A well written BCP would be much more valuable, and perhaps when we get 
to a critical mass, codification would be a natural process, rather than 
artificially enforcing people doing stuff they don’t see value (ROI) in, 
discussion here perfectly reflects the state of art.


Last year the IETF published RFC 8642, "Policy Behavior for Well-Known 
BGP Communities" which described how the three well-known communities 
defined in RFC1997 ought to be interpreted.  RFC1997 was published in 
1996, 23 years prior, and the definitions looked pretty simple and 
unambiguous.


Here's the opening paragraph:


   The BGP Communities attribute was specified in [RFC1997], which
   introduced the concept of well-known communities.  In hindsight,
   [RFC1997] did not prescribe as fully as it should have how well-known
   communities may be manipulated by policies applied by operators.
   Currently, implementations differ in this regard, and these
   differences can result in inconsistent behaviors that operators find
   difficult to identify and resolve.


I sympathise with the idea of standardised well-known communities, but 
if it takes us 23 years to tie down the semantics of three simple WKCs 
to the point that they behave consistently across vendors and operators, 
it's going to be a real struggle to define anything more complicated to 
the point that they end up doing what we want them to do, which is to 
say that they behave consistently across NOS implementations and 
different operator networks.


Even mixing 16-bit communities and 32-bit communities for stuff like ixp 
route server no-export causes interoperability problems.  Which gets 
evaluated first?  Why?  What happens if you get the order wrong? How can 
you integrate this into an existing routing policy configuration?


These things look a bit academic until something breaks, at which point 
it becomes clear that even simple-looking stuff can be complicated and 
messy when it goes wrong.


Nick

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

[Robert Raszuk via NANOG]

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  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  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:,
> 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  *On
> Behalf Of *Douglas Fischer via NANOG
> *Sent:* Tuesday, September 8, 2020 4:56 PM
> *To:* NANOG 
> *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:
>
>
>
> 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: as "no-export-to"
> standard?
>
>
>
> 2 - What about reserving some 16-bits ASN to use :
> 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 / 1 or so.
>
>
>
> --
>
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
>

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

[Jeff Tantsura via NANOG]

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  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:, 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  On Behalf 
> Of Douglas Fischer via NANOG
> Sent: Tuesday, September 8, 2020 4:56 PM
> To: NANOG 
> 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:
>  
> 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: as "no-export-to" 
> standard?
>  
> 2 - What about reserving some 16-bits ASN to use : 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 / 1 or so.
>  
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação

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

[Mark Tinka via NANOG]

On 9/Sep/20 10:03, Jeff Tantsura via NANOG wrote:

> De-facto standards are as good as people implementing them, however in
> order to enforce non ambiguous implementations, it has to be de-jure
> (e.g. a standard track RFC).
> While I’m sympathetic to the idea, I’m quite skeptical about its
> viability.
> A well written BCP would be much more valuable, and perhaps when we
> get to a critical mass, codification would be a natural process,
> rather than artificially enforcing people doing stuff they don’t see
> value (ROI) in, discussion here perfectly reflects the state of art.

This.

Mark.

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

[Jeff Tantsura via NANOG]

De-facto standards are as good as people implementing them, however in order to 
enforce non ambiguous implementations, it has to be de-jure (e.g. a standard 
track RFC).
While I’m sympathetic to the idea, I’m quite skeptical about its viability.
A well written BCP would be much more valuable, and perhaps when we get to a 
critical mass, codification would be a natural process, rather than 
artificially enforcing people doing stuff they don’t see value (ROI) in, 
discussion here perfectly reflects the state of art.

Cheers,
Jeff

> On Sep 8, 2020, at 17:57, 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:
> 
> 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: as "no-export-to" 
> standard?
> 
> 2 - What about reserving some 16-bits ASN to use : 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 / 1 or so.
> 
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação

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

[adam via NANOG]

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:, 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  On Behalf Of 
Douglas Fischer via NANOG
Sent: Tuesday, September 8, 2020 4:56 PM
To: NANOG 
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:

 

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: as "no-export-to" standard?

 

2 - What about reserving some 16-bits ASN to use : 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 / 1 or so.

 

-- 

Douglas Fernando Fischer
Engº de Controle e Automação

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

[Mark Tinka via NANOG]

On 9/Sep/20 09:21, Robert Raszuk wrote:

> Nope .. it is the other way around.
>
> It is all easy if you look from your network centric view.
>
> But if I am connected to 10 ISPs in each POP I have to build 10
> different egress policies, each embedding custom policy, teach NOC to
> understand it etc...

Well, yes and no.

We, for example, connect to more than one transit provider in at least
one of our PoP's. The outbound policies are exactly the same. The only
difference is the differences in naming for each policy, and how we
signal RTBH into the transit network. Everything else is the same.

Rinse an repeat for all the exchange points we have connected to a
single router, in a single PoP.

I get that no two BGP routing policies are the same between operators,
but I'm not certain standardizing on communities is going to make things
any less complicated than we currently assume they are.


>
> I think if there is a defined way to express prepend N times to my ISP
> peers across all uplinks or lower local pref in my ISP network in a
> same way to group of ISPs I see the value.

These kinds of policies are generally do-and-forget. When you spend time
turning up a new provider, you are dedicating time to setting them up on
your end. An extra 3 minutes to configure communities they have
published is not overly complex, I believe. Moreover, it's not something
you are likely to revisit outside of a communicated change on their end,
or troubleshooting on your end.

I'm all for making many things as standard as possible, but if our goal
is to make signaling of external communities simpler than it is today, I
don't quite see how standardizing said communities will simplify that
process in a practical sense, on a global basis.

As always, I could be wrong...

Mark.

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

[Mark Tinka via NANOG]

On 9/Sep/20 09:15, Robert Raszuk wrote:

> On last point yes. The entire idea behind flow spec is to work
> inter-as to mitigate DDoS as close to a source as possible.

Indeed, that is the original intention. Any reason why we don't see it
happening in this way, today?


> And as far as wide they just let you structure your community in a
> common way. It is both to customers or to others as you choose.
> Nothing there is about trust. It is all about mechanics how you pass
> embedded instructions.

Again, no technical or mechanical limitations at all with trying to get
this done. What I am saying is that the element of trust gets in the
way, for better or worse.

But while on the OP's intent - if you were to provide communities to
peers to signal forwarding in your network, you can simply publish those
communities on your web site. They don't need to follow any standard. At
the same time, if the industry were to agree on standard communities to
signal typical forwarding decisions within our networks, those would
work too, and I dare say that operators would publish them on their web
sites either way, for the avoidance of doubt. Moreover, anyone
implementing those communities would probably double-check with the
intended operator to make sure that what they are going to signal as
an-agreed global standard is supported and will work.

Just like how solar PV inverters are meant to disconnect from the grid
in the case of a utility outage, line workers will still, as a matter of
course, always check the line to see if it's live or not, before
performing any repairs. That line workers can simply trust that PV
inverters are doing the right thing in the event of a grid failure is
not practical. Checking to see if the line is live does not impose any
inconvenience on standard operating procedures.

So if we are able to provide support for remote signaling of forwarding
within our networks to off-net peers via communities, be it with
standard or dis-aggregated community values, either facility is
available and technically feasible today. The better question to ask
would be why this hasn't taken shape outside of provider-customer
relationships.

Mark.

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

[Robert Raszuk via NANOG]

Mark,

Nope .. it is the other way around.

It is all easy if you look from your network centric view.

But if I am connected to 10 ISPs in each POP I have to build 10 different
egress policies, each embedding custom policy, teach NOC to understand it
etc...

I think if there is a defined way to express prepend N times to my ISP
peers across all uplinks or lower local pref in my ISP network in a same
way to group of ISPs I see the value.

Best Regards,
R.


On Wed, Sep 9, 2020, 06:36 Mark Tinka via NANOG  wrote:

>
>
> On 8/Sep/20 23:22, Douglas Fischer via NANOG wrote:
>
> Exactly Mike!
>
> The Idea would be to define some base levels, to make the creations of
> route-filtering simpler to everyone in the world.
> And what comes beyond that, is in charge of each autonomous system.
>
> It would make the scripting and templates easier and would avoid
> fat-fingers.
>
>
> Are we saying that what individual operators design for their own networks
> is "complicated", and that coalescing around a single "de facto" standard
> would simplify that?
>
> Mark.
>

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

[Robert Raszuk via NANOG]

Mark,

On last point yes. The entire idea behind flow spec is to work inter-as to
mitigate DDoS as close to a source as possible.

And if you validate against advertising reachability what's the problem ?

And as far as wide they just let you structure your community in a common
way. It is both to customers or to others as you choose. Nothing there is
about trust. It is all about mechanics how you pass embedded instructions.

Best,
R.






On Wed, Sep 9, 2020, 06:25 Mark Tinka  wrote:

>
>
> On 8/Sep/20 20:15, Robert Raszuk wrote:
>
> > This does not require any more trust for say directly connected peers
> > more then today when you publish communities on the web page.
>
> I'd tend to disagree.
>
> Trusting your direct peer to not send you default or to have a 24/7 NOC
> to handle connectivity issues is not the same level of trust I'd afford
> them to send me a community that told my network what to announce to my
> other eBGP neighbors or not.
>
> Of course, I am probably less trusting than most, so I'm not
> recommending anyone follow my advice :-).
>
>
> > It is not about opening up your network. It is about expressing your
> > policy in a common way in the exact say amount as you would open up
> > your network today.
>
> I can express my policy, publicly. But I can also indicate who has the
> power to implement that expression on my side.
>
>
> > Notice that in addition to common types there is equal amount of
> > space left for operator's define types. It is just that the structure
> > of community can take number of arguments used during execution -
> > that's all.
>
> That is all good and well, and works beautifully within an operator's
> network, which is the point of the capability.
>
> Extending that to non-customer networks is not technically impossible.
> It's just a question of trust.
>
> It's not unlike trusting your customers to send you FlowSpec
> instructions. No issues technically, but do you want to do it?
>
> Mark.
>
>

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

[Mark Tinka via NANOG]

On 8/Sep/20 23:22, Douglas Fischer via NANOG wrote:

> Exactly Mike!
>
> The Idea would be to define some base levels, to make the creations of
> route-filtering simpler to everyone in the world.
> And what comes beyond that, is in charge of each autonomous system.
>
> It would make the scripting and templates easier and would avoid
> fat-fingers.

Are we saying that what individual operators design for their own
networks is "complicated", and that coalescing around a single "de
facto" standard would simplify that?

Mark.

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

[Mark Tinka via NANOG]

On 8/Sep/20 22:02, Tom Beecher via NANOG wrote:

> I also get that intent from the OP. However I disagree that there
> should be a 'de facto' standard created for such things. All flavors
> of BGP community specifications are designed to be flexible so that
> different networks can design a system that is tailored to their needs. 
>
> Having 'de facto' standards does not simplify in my opinion. I
> believe it just creates more work for operators trying to navigate
> around different opinions of what 'de facto' means.

Indeed.

Consider a new ISP starting operations in Myanmar, with little or no
global peering, having to wade through tons of information to design
their BGP community structure based on a "de facto" standard defined by
a group of ISP's half-way around the world.

What's the real value?

Mark.

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

[Mark Tinka via NANOG]

On 8/Sep/20 20:35, Mike Hammett via NANOG wrote:

> How I see the OP's intent is to create a BCP of what defined
> communities have what effect instead of everyone just making up
> whatever they draw out of a hat, simplifying this process for everyone.

Which only matters if you are extending a community outside of your own
network to someone else's.

If the communities are to be used internally, then it doesn't matter
what definition an operator uses.

Mark.

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

[Mark Tinka via NANOG]

On 8/Sep/20 20:15, Robert Raszuk wrote:

> This does not require any more trust for say directly connected peers
> more then today when you publish communities on the web page.

I'd tend to disagree.

Trusting your direct peer to not send you default or to have a 24/7 NOC
to handle connectivity issues is not the same level of trust I'd afford
them to send me a community that told my network what to announce to my
other eBGP neighbors or not.

Of course, I am probably less trusting than most, so I'm not
recommending anyone follow my advice :-).


> It is not about opening up your network. It is about expressing your
> policy in a common way in the exact say amount as you would open up
> your network today.

I can express my policy, publicly. But I can also indicate who has the
power to implement that expression on my side.


> Notice that in addition to common types there is equal amount of
> space left for operator's define types. It is just that the structure
> of community can take number of arguments used during execution -
> that's all.

That is all good and well, and works beautifully within an operator's
network, which is the point of the capability.

Extending that to non-customer networks is not technically impossible.
It's just a question of trust.

It's not unlike trusting your customers to send you FlowSpec
instructions. No issues technically, but do you want to do it?

Mark.

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

[Mike Hammett via NANOG]

Per cidr-report.org, there are almost 70k ASes in the public routing table. I 
can't imagine there would be more than 20 different ways those networks should 
use BGP communities to interface with the outside world. The 95th (maybe even 
99th) percentile would probably fit in 1 or 2 ways. 




Also, no one's going to jail for not adopting whatever standard may or may not 
emerge. Hell, we can't even get people to police their own traffic (BCP 38). 



- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mike Hammett via NANOG"  
To: "Tom Beecher"  
Cc: "NANOG"  
Sent: Tuesday, September 8, 2020 5:56:22 PM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 


The operators are snowflakes. Are the networks really snowflakes? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Tom Beecher"  
To: "Mike Hammett"  
Cc: "NANOG" , "Douglas Fischer"  
Sent: Tuesday, September 8, 2020 3:36:22 PM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 


Every network is a snowflake already. Everyone has different needs and 
operational considerations, which will also change over time. My community 
structure would not fit your needs, and yours would not fit mine. The current 
structure of regular and extended allows us to come up with something that 
works well for each of us, which is good. 






On Tue, Sep 8, 2020 at 4:06 PM Mike Hammett < na...@ics-il.net > wrote: 




Is there more desire to be flexible because people are snowflakes and their 
idea is the only way it should be or real, document-able reasons? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



From: "Tom Beecher"  
To: "Mike Hammett" < na...@ics-il.net > 
Cc: "NANOG" < nanog@nanog.org >, "Douglas Fischer" < fischerdoug...@gmail.com > 
Sent: Tuesday, September 8, 2020 3:02:37 PM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 


I also get that intent from the OP. However I disagree that there should be a 
'de facto' standard created for such things. All flavors of BGP community 
specifications are designed to be flexible so that different networks can 
design a system that is tailored to their needs. 


Having 'de facto' standards does not simplify in my opinion. I believe it just 
creates more work for operators trying to navigate around different opinions of 
what 'de facto' means. 








On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett < na...@ics-il.net > wrote: 




How I see the OP's intent is to create a BCP of what defined communities have 
what effect instead of everyone just making up whatever they draw out of a hat, 
simplifying this process for everyone. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



From: "Tom Beecher via NANOG" < nanog@nanog.org > 
To: "Douglas Fischer" < fischerdoug...@gmail.com > 
Cc: "NANOG" < nanog@nanog.org > 
Sent: Tuesday, September 8, 2020 1:30:19 PM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 


BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides 
for anyone to define the exact handling you wish. 






On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG < nanog@nanog.org > 
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: 


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: as "no-export-to" 
standard? 


2 - What about reserving some 16-bits ASN to use : 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 / 1 or so. 


-- 

Douglas Fernando Fischer 
Engº de Controle e Automação 

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

[Mike Hammett via NANOG]

The operators are snowflakes. Are the networks really snowflakes? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Tom Beecher"  
To: "Mike Hammett"  
Cc: "NANOG" , "Douglas Fischer"  
Sent: Tuesday, September 8, 2020 3:36:22 PM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 


Every network is a snowflake already. Everyone has different needs and 
operational considerations, which will also change over time. My community 
structure would not fit your needs, and yours would not fit mine. The current 
structure of regular and extended allows us to come up with something that 
works well for each of us, which is good. 






On Tue, Sep 8, 2020 at 4:06 PM Mike Hammett < na...@ics-il.net > wrote: 




Is there more desire to be flexible because people are snowflakes and their 
idea is the only way it should be or real, document-able reasons? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



From: "Tom Beecher"  
To: "Mike Hammett" < na...@ics-il.net > 
Cc: "NANOG" < nanog@nanog.org >, "Douglas Fischer" < fischerdoug...@gmail.com > 
Sent: Tuesday, September 8, 2020 3:02:37 PM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 


I also get that intent from the OP. However I disagree that there should be a 
'de facto' standard created for such things. All flavors of BGP community 
specifications are designed to be flexible so that different networks can 
design a system that is tailored to their needs. 


Having 'de facto' standards does not simplify in my opinion. I believe it just 
creates more work for operators trying to navigate around different opinions of 
what 'de facto' means. 








On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett < na...@ics-il.net > wrote: 




How I see the OP's intent is to create a BCP of what defined communities have 
what effect instead of everyone just making up whatever they draw out of a hat, 
simplifying this process for everyone. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



From: "Tom Beecher via NANOG" < nanog@nanog.org > 
To: "Douglas Fischer" < fischerdoug...@gmail.com > 
Cc: "NANOG" < nanog@nanog.org > 
Sent: Tuesday, September 8, 2020 1:30:19 PM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 


BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides 
for anyone to define the exact handling you wish. 






On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG < nanog@nanog.org > 
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: 


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: as "no-export-to" 
standard? 


2 - What about reserving some 16-bits ASN to use : 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 / 1 or so. 


-- 

Douglas Fernando Fischer 
Engº de Controle e Automação 

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

[Arnold Nipper via NANOG]

Douglas

On 08.09.2020 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:
> 
> 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: as
> "no-export-to" standard?
> 
> 2 - What about reserving some 16-bits ASN to use :
> 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 / 1 or so.
> 

you may want to have a look at
https://www.euro-ix.net/en/forixps/large-bgp-communities/

Cheers
Arnold
-- 
Keep calm, keep distance, keep connected!

Arnold Nipper
email: arn...@nipper.de
mobile: +49 172 2650958



signature.asc
Description: OpenPGP digital signature

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

[Douglas Fischer via NANOG]

Exactly Mike!

The Idea would be to define some base levels, to make the creations of
route-filtering simpler to everyone in the world.
And what comes beyond that, is in charge of each autonomous system.

It would make the scripting and templates easier and would avoid
fat-fingers.


Em ter., 8 de set. de 2020 às 15:35, Mike Hammett 
escreveu:

> How I see the OP's intent is to create a BCP of what defined communities
> have what effect instead of everyone just making up whatever they draw out
> of a hat, simplifying this process for everyone.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Tom Beecher via NANOG" 
> *To: *"Douglas Fischer" 
> *Cc: *"NANOG" 
> *Sent: *Tuesday, September 8, 2020 1:30:19 PM
> *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker -
> Any ASN reserved to "export-only-to"?'
>
> BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already
> provides for anyone to define the exact handling you wish.
>
>
>
> On Tue, Sep 8, 2020 at 11:57 AM 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:
>>
>> 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: as "no-export-to"
>> standard?
>>
>> 2 - What about reserving some 16-bits ASN to use :
>> 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 / 1 or so.
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>>
>
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação

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

[Tom Beecher via NANOG]

Every network is a snowflake already. Everyone has different needs and
operational considerations, which will also change over time. My community
structure would not fit your needs, and yours would not fit mine. The
current structure of regular and extended allows us to come up with
something that works well for each of us, which is good.



On Tue, Sep 8, 2020 at 4:06 PM Mike Hammett  wrote:

> Is there more desire to be flexible because people are snowflakes and
> their idea is the only way it should be or real, document-able reasons?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Tom Beecher" 
> *To: *"Mike Hammett" 
> *Cc: *"NANOG" , "Douglas Fischer" <
> fischerdoug...@gmail.com>
> *Sent: *Tuesday, September 8, 2020 3:02:37 PM
> *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker -
> Any ASN reserved to "export-only-to"?'
>
> I also get that intent from the OP. However I disagree that there should
> be a 'de facto' standard created for such things. All flavors of BGP
> community specifications are designed to be flexible so that different
> networks can design a system that is tailored to their needs.
>
> Having 'de facto' standards does not simplify in my opinion. I believe it
> just creates more work for operators trying to navigate around different
> opinions of what 'de facto' means.
>
>
>
>
> On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett  wrote:
>
>> How I see the OP's intent is to create a BCP of what defined communities
>> have what effect instead of everyone just making up whatever they draw out
>> of a hat, simplifying this process for everyone.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>> Midwest-IX
>> http://www.midwest-ix.com
>>
>> --
>> *From: *"Tom Beecher via NANOG" 
>> *To: *"Douglas Fischer" 
>> *Cc: *"NANOG" 
>> *Sent: *Tuesday, September 8, 2020 1:30:19 PM
>> *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker -
>> Any ASN reserved to "export-only-to"?'
>>
>> BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already
>> provides for anyone to define the exact handling you wish.
>>
>>
>>
>> On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG <
>> nanog@nanog.org> 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:
>>>
>>> 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: as "no-export-to"
>>> standard?
>>>
>>> 2 - What about reserving some 16-bits ASN to use :
>>> 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 / 1 or so.
>>>
>>> --
>>> Douglas Fernando Fischer
>>> Engº de Controle e Automação
>>>
>>
>>
>

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

[Mike Hammett via NANOG]

Is there more desire to be flexible because people are snowflakes and their 
idea is the only way it should be or real, document-able reasons? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Tom Beecher"  
To: "Mike Hammett"  
Cc: "NANOG" , "Douglas Fischer"  
Sent: Tuesday, September 8, 2020 3:02:37 PM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 


I also get that intent from the OP. However I disagree that there should be a 
'de facto' standard created for such things. All flavors of BGP community 
specifications are designed to be flexible so that different networks can 
design a system that is tailored to their needs. 


Having 'de facto' standards does not simplify in my opinion. I believe it just 
creates more work for operators trying to navigate around different opinions of 
what 'de facto' means. 








On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett < na...@ics-il.net > wrote: 




How I see the OP's intent is to create a BCP of what defined communities have 
what effect instead of everyone just making up whatever they draw out of a hat, 
simplifying this process for everyone. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



From: "Tom Beecher via NANOG" < nanog@nanog.org > 
To: "Douglas Fischer" < fischerdoug...@gmail.com > 
Cc: "NANOG" < nanog@nanog.org > 
Sent: Tuesday, September 8, 2020 1:30:19 PM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 


BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides 
for anyone to define the exact handling you wish. 






On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG < nanog@nanog.org > 
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: 


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: as "no-export-to" 
standard? 


2 - What about reserving some 16-bits ASN to use : 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 / 1 or so. 


-- 

Douglas Fernando Fischer 
Engº de Controle e Automação 

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

[Tom Beecher via NANOG]

I also get that intent from the OP. However I disagree that there should be
a 'de facto' standard created for such things. All flavors of BGP community
specifications are designed to be flexible so that different networks can
design a system that is tailored to their needs.

Having 'de facto' standards does not simplify in my opinion. I believe it
just creates more work for operators trying to navigate around different
opinions of what 'de facto' means.




On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett  wrote:

> How I see the OP's intent is to create a BCP of what defined communities
> have what effect instead of everyone just making up whatever they draw out
> of a hat, simplifying this process for everyone.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Tom Beecher via NANOG" 
> *To: *"Douglas Fischer" 
> *Cc: *"NANOG" 
> *Sent: *Tuesday, September 8, 2020 1:30:19 PM
> *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker -
> Any ASN reserved to "export-only-to"?'
>
> BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already
> provides for anyone to define the exact handling you wish.
>
>
>
> On Tue, Sep 8, 2020 at 11:57 AM 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:
>>
>> 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: as "no-export-to"
>> standard?
>>
>> 2 - What about reserving some 16-bits ASN to use :
>> 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 / 1 or so.
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>>
>
>

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

[Chriztoffer Hansen via NANOG]

Douglas,

On Tue, 8 Sep 2020 at 17:55, Douglas Fischer via NANOG  wrote:
>
> Most of us have already used some BGP community policy to no-export some 
> routes to somewhere.
>
> 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:
>
> 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: as "no-export-to" 
> standard?
>
> 2 - What about reserving some 16-bits ASN to use : 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 / 1 or so.

Please see:
- https://www.euro-ix.net/en/forixps/large-bgp-communities/
- https://tools.ietf.org/id/draft-adkp-grow-ixpcommunities-00.html

If you use large communities (yes, I know the standard is NOT 100%
unilaterally supported by all vendors just yet).

Using the combination of RS${ASN}:0:0 (Don't announce to any peer) and
RS${ASN}:1:${PEERAS} (Advertise to PEERAS) you can do what you are
asking for. Announcing routes to only select peers.

Most major IXP's will support most of the mentioned large
communities. For ISP's in general. It's thou a different story that is
not mine to speak about.

Using 2-byte communities in today's age of explosive "assignment" of
4-byte ASN's is similar to the price-hike of IPv4 space. In the long
term. Standard BGP communities and IPv4 will not be worth the required
effort/investment (unless you want to "cripple" yourself from the
get-go). And IPv6 and Large BGP Communities is "slowly" gaining traction
as the way to go.

-- 

Cheers,
Chriztoffer

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

[Mike Hammett via NANOG]

How I see the OP's intent is to create a BCP of what defined communities have 
what effect instead of everyone just making up whatever they draw out of a hat, 
simplifying this process for everyone. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Tom Beecher via NANOG"  
To: "Douglas Fischer"  
Cc: "NANOG"  
Sent: Tuesday, September 8, 2020 1:30:19 PM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 


BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides 
for anyone to define the exact handling you wish. 






On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG < nanog@nanog.org > 
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: 


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: as "no-export-to" 
standard? 


2 - What about reserving some 16-bits ASN to use : 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 / 1 or so. 


-- 

Douglas Fernando Fischer 
Engº de Controle e Automação 

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

[Tom Beecher via NANOG]

BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already
provides for anyone to define the exact handling you wish.



On Tue, Sep 8, 2020 at 11:57 AM 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:
>
> 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: as "no-export-to"
> standard?
>
> 2 - What about reserving some 16-bits ASN to use :
> 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 / 1 or so.
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>

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

[Robert Raszuk via NANOG]

Mark,

This does not require any more trust for say directly connected peers more
then today when you publish communities on the web page.

It is not about opening up your network. It is about expressing your policy
in a common way in the exact say amount as you would open up your network
today.

Notice that in addition to common types there is equal amount of space left
for operator's define types. It is just that the structure of community can
take number of arguments used during execution - that's all.

Thx,
R.



On Tue, Sep 8, 2020 at 8:10 PM Mark Tinka  wrote:

>
>
> On 8/Sep/20 18:41, Robert Raszuk wrote:
>
> > 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.
>
> This already happens today, but mostly in a commercial relationship
> (customer and provider).
>
> While not technically impossible, I struggle to see operators opening up
> their networks to peers they hardly personally (or commercially) know
> with such a feature, custom or standardized.
>
> I suppose the bigger question is - can we trust each other, as peers,
> with such access to each other's networks?
>
> Mark.
>

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

[Mark Tinka via NANOG]

On 8/Sep/20 18:41, Robert Raszuk wrote:

> 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.

This already happens today, but mostly in a commercial relationship
(customer and provider).

While not technically impossible, I struggle to see operators opening up
their networks to peers they hardly personally (or commercially) know
with such a feature, custom or standardized.

I suppose the bigger question is - can we trust each other, as peers,
with such access to each other's networks?

Mark.

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

[Robert Raszuk via NANOG]

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  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:
>
> 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: as "no-export-to"
> standard?
>
> 2 - What about reserving some 16-bits ASN to use :
> 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 / 1 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.
>

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

[Mark Tinka via NANOG]

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:
>
> 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: as
> "no-export-to" standard?
>
> 2 - What about reserving some 16-bits ASN to use
> : 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 / 1 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.

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

[Robert Raszuk via NANOG]

Hi Douglas,

Just FYI I have tried to capture most common use cases of communities and
register them as part of a wide-community effort in IANA.

https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02

That draft is pending standardization of wide-communities itself.

You are obviously very welcome to either reuse some of this work or support
it :)

Kind regards,
R.

On Tue, Sep 8, 2020 at 5:58 PM 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:
>
> 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: as "no-export-to"
> standard?
>
> 2 - What about reserving some 16-bits ASN to use :
> 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 / 1 or so.
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>

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

[Douglas Fischer via NANOG]

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:

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: as "no-export-to"
standard?

2 - What about reserving some 16-bits ASN to use : 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 / 1 or so.

-- 
Douglas Fernando Fischer
Engº de Controle e Automação