RE: Wildfires: Clear fuel from hilltop and remote area communications towers

[Don Gould]

Eric they have the same issues in Australia.   You might want to join aunog, if 
you haven't already, I'm sure you'll find endorsement for these issues.Fuel 
management is a problem. Finding the right balance between management and 
ecological issues is political and complex with many vested interests driving 
the narrative. D-- Don Gould5 Cargill PlaceRichmondChristchurch, New 
ZealandMobile/Telegram: + 64 21 114 0699www.bowenvale.co.nz
 Original message From: Eric Kuhnke  
Date: 12/09/20  10:14 am  (GMT+12:00) To: "nanog@nanog.org list" 
 Subject: Wildfires: Clear fuel from hilltop and remote area 
communications towers Over the past week I think I've seen about 20 to 30 
photos of burnt out communications sites in Oregon and California.Due to the 
often remote and unstaffed nature of many of these sites, there's a natural 
tendency for brush, shrubs, grass and small trees to grow close to the tower 
compounds on many hilltop sites.Many of these sites also support emergency 
communications services.In the subject line I'm using "fuel" as defined by 
firefighters, not literally meaning petroleum fuels, but anything flammable. In 
some places there are ecological or political concerns with maintaining a 
cleared perimeter around telecom tower sites. This might be a time to re-visit 
the logical purpose of some of these policies, if allowing fuel to grow right 
up to the tower and telecom equipment shelters greatly increases the likelihood 
of the whole thing going up in flames.

Wildfires: Clear fuel from hilltop and remote area communications towers

[Eric Kuhnke]

Over the past week I think I've seen about 20 to 30 photos of burnt out
communications sites in Oregon and California.

Due to the often remote and unstaffed nature of many of these sites,
there's a natural tendency for brush, shrubs, grass and small trees to grow
close to the tower compounds on many hilltop sites.

Many of these sites also support emergency communications services.

In the subject line I'm using "fuel" as defined by firefighters, not
literally meaning petroleum fuels, but anything flammable.

In some places there are ecological or political concerns with maintaining
a cleared perimeter around telecom tower sites. This might be a time to
re-visit the logical purpose of some of these policies, if allowing fuel to
grow right up to the tower and telecom equipment shelters greatly increases
the likelihood of the whole thing going up in flames.

Re: Wildfires: Reminder smart devices don't include emergency warnings while streaming

[Gary E. Miller]

Yo ITechGeek!

On Fri, 11 Sep 2020 16:11:48 -0400
ITechGeek  wrote:

> At least cell phones have a reliable way to know where they are at any
> given moment.

Only when the cell towers are working.  Early on in the Santiam Fire
the cell towers went down early.  With the telephone poles.

The Santiam Canyon is steep and narrow, the telco feed up the river was
an early single point of failure.  

Ditto for the fire on the Holiday Farm fire on the Mckenzie river.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin


pgpL3XLDYWNTn.pgp
Description: OpenPGP digital signature

Re: Wildfires: Reminder smart devices don't include emergency warnings while streaming

[Aaron C. de Bruyn via NANOG]

I would trust it more than not getting an alert.
Especially if it started with something along the lines of "There is a
tornado warning for Springfield and North Haberbrook" and I had enough
brain cells to know what city I was in.

-A

On Fri, Sep 11, 2020 at 1:14 PM ITechGeek  wrote:

> At least cell phones have a reliable way to know where they are at any
> given moment.  Would you really trust providers sending out emergency
> notifications based on something like GeoIP or based on the zipcode on the
> account?
>
>
> ---
> -ITG (ITechGeek)  |  i...@itechgeek.com
> i...@secure.itg.nu (Protonmail) (Fingerprint: 7d1a160f)
> https://keybase.io/itechgeek  |  https://itg.nu/
> Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook:
> http://fb.me/Jbwa.Net
>
>
> On Fri, Sep 11, 2020 at 3:49 PM Sean Donelan  wrote:
>
>> On Fri, 11 Sep 2020, William Herrin wrote:
>> > tl;dr: keep your cell phone on and with you 'cause only a few things
>> > get emergency alerts and only when they're turned on.
>>
>> You sound like the CTIA in the 2000s when it was opposed to requiring
>> emergency alerts on cell phones.  "Its unnecessary to require cell phones
>> have emergency alerts, because people get emergency alerts other ways."
>>
>> The problem was all the consumer electronic industry groups always point
>> at "someone else."  The cable industry said it was unnecessary in the
>> 1980s because local TV stations had emergency alerts.  The TV industry
>> said it was unnecessary in the 1970s because local radio stations had
>> emergency alerts.  Etc. etc. etc.
>>
>> The reason your cell phone has emergency alerts, is the FCC required them.
>>
>

how would draft-ymbk-opsawg-finding-geofeeds work in noam

[Randy Bush]

would folk familiar with the north american RIR and IRR registries be
kind enough to suggest how this might adapt?  thanks.

A new version of I-D, draft-ymbk-opsawg-finding-geofeeds-02.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.

Name:   draft-ymbk-opsawg-finding-geofeeds
Revision:   02
Title:  Finding and Using Geofeed Data
Document date:  2020-09-11
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/id/draft-ymbk-opsawg-finding-geofeeds-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-ymbk-opsawg-finding-geofeeds/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds
Htmlized:   
https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds-02
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ymbk-opsawg-finding-geofeeds-02

Abstract:
   This document describes how to find and authenticate geofeed data.

Re: Wildfires: Reminder smart devices don't include emergency warnings while streaming

[ITechGeek]

At least cell phones have a reliable way to know where they are at any
given moment.  Would you really trust providers sending out emergency
notifications based on something like GeoIP or based on the zipcode on the
account?

---
-ITG (ITechGeek)  |  i...@itechgeek.com
i...@secure.itg.nu (Protonmail) (Fingerprint: 7d1a160f)
https://keybase.io/itechgeek  |  https://itg.nu/
Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook:
http://fb.me/Jbwa.Net


On Fri, Sep 11, 2020 at 3:49 PM Sean Donelan  wrote:

> On Fri, 11 Sep 2020, William Herrin wrote:
> > tl;dr: keep your cell phone on and with you 'cause only a few things
> > get emergency alerts and only when they're turned on.
>
> You sound like the CTIA in the 2000s when it was opposed to requiring
> emergency alerts on cell phones.  "Its unnecessary to require cell phones
> have emergency alerts, because people get emergency alerts other ways."
>
> The problem was all the consumer electronic industry groups always point
> at "someone else."  The cable industry said it was unnecessary in the
> 1980s because local TV stations had emergency alerts.  The TV industry
> said it was unnecessary in the 1970s because local radio stations had
> emergency alerts.  Etc. etc. etc.
>
> The reason your cell phone has emergency alerts, is the FCC required them.
>

Re: Wildfires: Reminder smart devices don't include emergency warnings while streaming

[Sean Donelan]

On Fri, 11 Sep 2020, William Herrin wrote:

tl;dr: keep your cell phone on and with you 'cause only a few things
get emergency alerts and only when they're turned on.


You sound like the CTIA in the 2000s when it was opposed to requiring 
emergency alerts on cell phones.  "Its unnecessary to require cell phones 
have emergency alerts, because people get emergency alerts other ways."


The problem was all the consumer electronic industry groups always point 
at "someone else."  The cable industry said it was unnecessary in the 
1980s because local TV stations had emergency alerts.  The TV industry 
said it was unnecessary in the 1970s because local radio stations had 
emergency alerts.  Etc. etc. etc.


The reason your cell phone has emergency alerts, is the FCC required them.

Re: Wildfires: Reminder smart devices don't include emergency warnings while streaming

[Jason Kuehl]

Amazon Fire TV, Apple TV and Alphabet Android TV executives don't see a
need to support emergency alerts on their products.

You can enable severe weather alerts on both google home and Alexia. But I
get the point.

On Fri, Sep 11, 2020 at 2:58 PM Sean Donelan  wrote:

>
> As some of the largest wildfires burn along the West Coast, and over
> 500,000 people evacuate, a reminder that streaming devices do not
> include local emergency alerts. Cord-cutters using Alphabet Android TV,
> Amazon Fire TV, Apple TV "smart" devices should remember they don't have
> emergency alerts while streaming.
>
> FCC requires cellular phones support Wireless Emergency Alerts, including
> when using streaming Apps. But not in-home "smart" devices like smart TVs
> and smart speakers.
>
> You should also have an traditional AM/FM or weather radio at home. And
> your DTV may still have a connection for an over-the-air antenna.
> Nevertheless, while you are watching Netflix or listening to Spotify on
> a non-cell phone smart device, you won't get emergency alerts on those
> streaming devices.
>
> Amazon Fire TV, Apple TV and Alphabet Android TV executives don't see a
> need to support emergency alerts on their products.
>
>

-- 
Sincerely,

Jason W Kuehl
Cell 920-419-8983
jason.w.ku...@gmail.com

Re: Wildfires: Reminder smart devices don't include emergency warnings while streaming

[Matt Erculiani]

Linking relevant past thread about devices that don't alert for
emergencies and, of course, a heated debate on if they should:

https://mailman.nanog.org/pipermail/nanog/2019-March/199721.html



On Fri, Sep 11, 2020 at 1:24 PM William Herrin  wrote:

> On Fri, Sep 11, 2020 at 11:58 AM Sean Donelan  wrote:
> > you won't get emergency alerts on those streaming devices.
> > Amazon Fire TV, Apple TV and Alphabet Android TV executives don't see a
> > need to support emergency alerts on their products.
>
> Also worth noting that you won't get emergency alerts on your stove,
> refrigerator, dish washer, washing machine or dryer. So, when cooking
> or doing laundry make sure you have an alternate source of emergency
> alerts available.
>
> Shockingly, your alarm clock won't automatically turn on when there's
> an emergency alert over the radio either nor will your smoke and fire
> alarms go off except in the immediate presence of smoke and fire, so
> be sure to have an always-on source of alerts while you're sleeping
> too.
>
> tl;dr: keep your cell phone on and with you 'cause only a few things
> get emergency alerts and only when they're turned on.
>
> Regards,
> Bill Herrin
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>


-- 
Matt Erculiani
ERCUL-ARIN

Re: Wildfires: Reminder smart devices don't include emergency warnings while streaming

[William Herrin]

On Fri, Sep 11, 2020 at 11:58 AM Sean Donelan  wrote:
> you won't get emergency alerts on those streaming devices.
> Amazon Fire TV, Apple TV and Alphabet Android TV executives don't see a
> need to support emergency alerts on their products.

Also worth noting that you won't get emergency alerts on your stove,
refrigerator, dish washer, washing machine or dryer. So, when cooking
or doing laundry make sure you have an alternate source of emergency
alerts available.

Shockingly, your alarm clock won't automatically turn on when there's
an emergency alert over the radio either nor will your smoke and fire
alarms go off except in the immediate presence of smoke and fire, so
be sure to have an always-on source of alerts while you're sleeping
too.

tl;dr: keep your cell phone on and with you 'cause only a few things
get emergency alerts and only when they're turned on.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Getting Fiber to My Town by Jared Mauch

[Josh Luthman]

That very well could be.  We pushed/pulled about 2 miles with this stuff.
Took about a day.

Josh Luthman
24/7 Help Desk: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Thu, Sep 10, 2020 at 5:24 PM Jared Mauch  wrote:

> The pulling lube does not work well IMO, the blowing lube made a huge
> difference.
>
> - Jared
>
> > On Sep 10, 2020, at 4:29 PM, Josh Luthman 
> wrote:
> >
> > I believe this is the stuff we used on our project:
> >
> https://www.menards.com/main/electrical/electrical-tools-accessories/wire-conduit-installation/ideal-regyellow-77-wire-pulling-lubricant-5-gallon/31-355/p-133962344-c-6458.htm
>
> >
> > Josh Luthman
> > 24/7 Help Desk: 937-552-2340
> > Direct: 937-552-2343
> > 1100 Wayne St
> > Suite 1337
> > Troy, OH 45373
> >
> >
> > On Thu, Sep 10, 2020 at 4:25 PM Jared Mauch 
> wrote:
> >
> >
> > > On Sep 10, 2020, at 4:10 PM, Jared Geiger  wrote:
> > >
> > > Another Jared with a question. What method did you use to blow the
> fiber through the conduit? You mentioned you had trouble figuring out the
> process relating to lubrication and building a contraption to blow the
> fiber.
> >
> > You need the conduit lube.  The duraline summer blowing lube worked well
> for me.
> >
> > - Jared
>
>

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

Wildfires: Reminder smart devices don't include emergency warnings while streaming

[Sean Donelan]

As some of the largest wildfires burn along the West Coast, and over 
500,000 people evacuate, a reminder that streaming devices do not 
include local emergency alerts. Cord-cutters using Alphabet Android TV, 
Amazon Fire TV, Apple TV "smart" devices should remember they don't have 
emergency alerts while streaming.


FCC requires cellular phones support Wireless Emergency Alerts, including 
when using streaming Apps. But not in-home "smart" devices like smart TVs 
and smart speakers.


You should also have an traditional AM/FM or weather radio at home. And 
your DTV may still have a connection for an over-the-air antenna. 
Nevertheless, while you are watching Netflix or listening to Spotify on 
a non-cell phone smart device, you won't get emergency alerts on those 
streaming devices.


Amazon Fire TV, Apple TV and Alphabet Android TV executives don't see a 
need to support emergency alerts on their products.

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 12 Sep, 2020

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  821585
Prefixes after maximum aggregation (per Origin AS):  312847
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  392371
Total ASes present in the Internet Routing Table: 69335
Prefixes per ASN: 11.85
Origin-only ASes present in the Internet Routing Table:   59579
Origin ASes announcing only one prefix:   24748
Transit ASes present in the Internet Routing Table:9756
Transit-only ASes present in the Internet Routing Table:305
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  47
Max AS path prepend of ASN ( 37385)  44
Prefixes from unregistered ASNs in the Routing Table:   842
Number of instances of unregistered ASNs:   843
Number of 32-bit ASNs allocated by the RIRs:  33414
Number of 32-bit ASNs visible in the Routing Table:   27577
Prefixes from 32-bit ASNs in the Routing Table:  128046
Number of bogon 32-bit ASNs visible in the Routing Table:15
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:452
Number of addresses announced to Internet:   2851880192
Equivalent to 169 /8s, 252 /16s and 61 /24s
Percentage of available address space announced:   77.0
Percentage of allocated address space announced:   77.0
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  275573

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   216134
Total APNIC prefixes after maximum aggregation:   63434
APNIC Deaggregation factor:3.41
Prefixes being announced from the APNIC address blocks:  209910
Unique aggregates announced from the APNIC address blocks:86558
APNIC Region origin ASes present in the Internet Routing Table:   10854
APNIC Prefixes per ASN:   19.34
APNIC Region origin ASes announcing only one prefix:   3052
APNIC Region transit ASes present in the Internet Routing Table:   1595
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 28
Number of APNIC region 32-bit ASNs visible in the Routing Table:   5946
Number of APNIC addresses announced to Internet:  770547072
Equivalent to 45 /8s, 237 /16s and 157 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-141625
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:240717
Total ARIN prefixes after maximum aggregation:   110220
ARIN Deaggregation factor: 2.18
Prefixes being announced from the ARIN address blocks:   238416
Unique aggregates announced from the ARIN address blocks:112601
ARIN Region origin ASes present in the Internet Routing Table:18561
ARIN Prefixes per ASN:12.84
ARIN 

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,