Re: mail admins?

[John Osmon]

On Wed, Apr 22, 2020 at 08:05:39AM +0300, Töma Gavrichenkov wrote:
> On Wed, Apr 22, 2020, 12:45 AM Randy Bush  wrote:
> 
> > sad.  http://nanog.org used to be the brilliant example of a fully
> > featured web site sans javascript, flash, ...
> >
> 
> That was long ago now.  It was using Cvent for everything meeting-related
> for 3 years already, and Cvent doesn't feel good with JS turned off.

Yes -- I think we all understand the technical problems with the site.

Thanks for helping Randy with being precise.

[NANOG-announce] NANOG 79 will be a virtual meeting 

[NANOG Marketing]

*NANOG 79 will now be held as a virtual meeting — the in-person meeting in
Boston has been canceled.*

Due to the COVID-19 global pandemic, the NANOG Board of Directors and Staff
have decided to cancel the in-person meeting in Boston. To ensure the
safety of our community, NANOG 79 
will now be held as a three-day virtual meeting, June 1-3, with an abridged
program. Online registration and meeting details will be posted soon.

Both speakers and attendees will participate remotely. The NANOG Program
Committee is developing a program tailored to an online format, and has
extended the Call For Presentations
 to May 7.

All attendees registered for NANOG 79 in Boston will be issued a full
refund by Friday, April 24, and Marriott Boston Copley Place
 will auto-cancel
any rooms booked under the NANOG 79 hotel-room block. If the hotel does not
cancel your reservation, or if you have further questions, please contact
the hotel directly at +1-617-236-5800.

We will announce when registration opens, and share program topics and
highlights soon. Please contact us with any additional questions or
concerns: nanog-supp...@nanog.org

Sincerely,
The NANOG Board of Directors and Staff
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: "Is BGP safe yet?" test

[Vincent Bernat]

 ❦ 22 avril 2020 12:51 -04, Andrey Kostin:

> BTW, has anybody yet thought/looked into extending RPKI-RTR protocol
> for validation of prefixes received from peer-as to make ingress
> filtering more dynamic and move away prefix filters from the routers?

It could be used as is if the client implementations were a bit more
flexible.

With BIRD, you decide which AS to match. So you can match on the
neighbor AS instead of the origin AS. Then, you can use something like
GoRTR which accepts using JSON files instead of the RPKI as source. BIRD
also allows you to have several ROA tables. So, you can check against
the "real" RPKI as well as against your custom IRR-based RPKI.
-- 
Choose variable names that won't be confused.
- The Elements of Programming Style (Kernighan & Plauger)

Re: "Is BGP safe yet?" test

[Warren Kumari]

On Wed, Apr 22, 2020 at 11:45 AM Danny McPherson  wrote:
>
> On 2020-04-21 12:36, Rubens Kuhl wrote:
> > On Tue, Apr 21, 2020 at 1:10 PM Matt Corallo via NANOG
> >  wrote:
> >
> >> That’s an interesting idea. I’m not sure that LACNIC would want
> >> to issue a ROA for RIPE IP space after RIPE issues an AS0 ROA,
> >> though. And you’d at least need some kind of time delay to give
> >> other RIRs and operators and chance to discuss the matter before
> >> allowing RIPE to issue the AS0 ROA, eg in my example mitigation
> >> strategy.
> >
> > All 5 RIRs can issue ROAs for all the IP address spaces. They don't as
> > a matter of coordinated operations, but that doesn't prevent court
> > orders determining that to be done.
>
>
> Or a miscreant.  [insert-least-favorite-rir] is now part of your attack
> surface.

Or a slip of the keyboard / software ooops / mistake -- but, in spite
of this, I think that RPKI / ROAs / ROV is a good thing; as with
everything, this is an engineering trade off, and to me this feels
well worth it...

I do think that CloudFlare does some great things for the Internet -
they've moved DNSSEC forward immensely, significantly increased the
adoption of HTTPS/TLS, the OctoRPKI/GoRTR stuff is nice and easy,
their hosted RPKI cache, etc -- but their marketing pushes like this
feel overly aggressive.

W

>
>
> -danny



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

Re: "Is BGP safe yet?" test

[Christopher Morrow]

On Wed, Apr 22, 2020 at 2:03 PM Christopher Morrow
 wrote:
>
> On Wed, Apr 22, 2020 at 1:32 PM Danny McPherson  wrote:
> >
> > On 2020-04-22 12:51, Andrey Kostin wrote:
> >
> > >
> > > BCP38 website doesn't proclaim anybody in person to be unsafe, but if
> > > it would be possible to make such test it'd be more useful than that
> > > RPKI test.
> > >
> > > BTW, has anybody yet thought/looked into extending RPKI-RTR protocol
> > > for validation of prefixes received from peer-as to make ingress
> > > filtering more dynamic and move away prefix filters from the routers?
> >
> > Do you really want those things in soft-state and not with some giant
> > operational buffer to absorb all the brokenness that's sure to arise?
>
> a question about the data types here...
> So, a neighbor with no downstream ASN could be filtered directly with
> ROA == prefixlist-content.
> A neighbor with a downstream ASN has to be ROA (per asn downstream) ==
> prefixlist-content.
>
> So you'd now have to do some calculations which are more complicated
> than just; "is roa for this prefix here and valid" to construct a
> prefix-list.
> correct?

Sorry, and this sidesteps the intent of the peer as well. For instance
you may have
a peer with 2 'downstream' asn, only 1 of which they wish to provide
transit to you
(from you?) for... how would you know this intent/policy from the
peer's perspective?
today you know that (most likely) from IRR data.

is your answer ASPA / AS-Cone ?

Re: "Is BGP safe yet?" test

[Christopher Morrow]

On Wed, Apr 22, 2020 at 1:32 PM Danny McPherson  wrote:
>
> On 2020-04-22 12:51, Andrey Kostin wrote:
>
> >
> > BCP38 website doesn't proclaim anybody in person to be unsafe, but if
> > it would be possible to make such test it'd be more useful than that
> > RPKI test.
> >
> > BTW, has anybody yet thought/looked into extending RPKI-RTR protocol
> > for validation of prefixes received from peer-as to make ingress
> > filtering more dynamic and move away prefix filters from the routers?
>
> Do you really want those things in soft-state and not with some giant
> operational buffer to absorb all the brokenness that's sure to arise?

a question about the data types here...
So, a neighbor with no downstream ASN could be filtered directly with
ROA == prefixlist-content.
A neighbor with a downstream ASN has to be ROA (per asn downstream) ==
prefixlist-content.

So you'd now have to do some calculations which are more complicated
than just; "is roa for this prefix here and valid" to construct a
prefix-list.
correct?

Re: "Is BGP safe yet?" test

[Danny McPherson]

On 2020-04-22 12:51, Andrey Kostin wrote:



BCP38 website doesn't proclaim anybody in person to be unsafe, but if
it would be possible to make such test it'd be more useful than that
RPKI test.

BTW, has anybody yet thought/looked into extending RPKI-RTR protocol
for validation of prefixes received from peer-as to make ingress
filtering more dynamic and move away prefix filters from the routers?


Do you really want those things in soft-state and not with some giant 
operational buffer to absorb all the brokenness that's sure to arise?




-danny

Re: "Is BGP safe yet?" test

[Andrey Kostin]

Jay R. Ashworth писал 2020-04-22 11:02:



Well, given how little the BCP38 website below has moved that football, 
you're

not likely in much danger... :-)

Cheers,
-- jra


BCP38 website doesn't proclaim anybody in person to be unsafe, but if it 
would be possible to make such test it'd be more useful than that RPKI 
test.


BTW, has anybody yet thought/looked into extending RPKI-RTR protocol for 
validation of prefixes received from peer-as to make ingress filtering 
more dynamic and move away prefix filters from the routers?


Kind regards,
Andrey

Re: "Is BGP safe yet?" test

[Danny McPherson]

On 2020-04-21 12:36, Rubens Kuhl wrote:

On Tue, Apr 21, 2020 at 1:10 PM Matt Corallo via NANOG
 wrote:


That’s an interesting idea. I’m not sure that LACNIC would want
to issue a ROA for RIPE IP space after RIPE issues an AS0 ROA,
though. And you’d at least need some kind of time delay to give
other RIRs and operators and chance to discuss the matter before
allowing RIPE to issue the AS0 ROA, eg in my example mitigation
strategy.


All 5 RIRs can issue ROAs for all the IP address spaces. They don't as
a matter of coordinated operations, but that doesn't prevent court
orders determining that to be done.



Or a miscreant.  [insert-least-favorite-rir] is now part of your attack 
surface.



-danny

Re: "Is BGP safe yet?" test

[Jay R. Ashworth]

> From: "Andrey Kostin" 
> 
> Would be interesting to hear your opinion on this:
> https://isbgpsafeyet.com/
> 
> We have cases when residential customers ask support "why is your
> service isn't safe?" pointing to that article. It's difficult to answer
> correctly considering that the asking person usually doesn't know what
> BGP is and what it's used for, save for understanding it's function,
> design and possible misuses.

Well, given how little the BCP38 website below has moved that football, you're
not likely in much danger... :-)

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Are underground utility markers essential workers?

[Josh Luthman]

USIC marked on April 17 (last Friday) here.  At least the email said they
did in the afternoon - we just had to call them back to locate (there were
no red/power flags).

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Tue, Apr 21, 2020 at 4:48 PM Jared Mauch  wrote:

> USIC is not marking on Fridays around here.
>
> URG is marking but only 4 hours a day.
>
> - Jared
>
> > On Apr 21, 2020, at 4:44 PM, Jeff Shultz  wrote:
> >
> > Since in our case they are Outside Plant Tech's who are assigned the
> > duties as needed, they are essential workers.
> >
> > On Tue, Apr 21, 2020 at 11:59 AM Sean Donelan  wrote:
> >>
> >>
> >> Utility markers don't get the recognition they deserve.  If they aren't
> >> essential workers, they should be and get hazard pay.
> >>
> >> They help protect everyone's fiber and cables and pipes that go boom.
> >>
> >>
> >
> >
> > --
> > Jeff Shultz
> >
> > --
> > Like us on Social Media for News, Promotions, and other information!!
> >
> >
> > 
> > 
> > 
> > 
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _ This message
> > contains confidential information and is intended only for the
> individual
> > named. If you are not the named addressee you should not disseminate,
> > distribute or copy this e-mail. Please notify the sender immediately by
> > e-mail if you have received this e-mail by mistake and delete this
> e-mail
> > from your system. E-mail transmission cannot be guaranteed to be secure
> or
> > error-free as information could be intercepted, corrupted, lost,
> destroyed,
> > arrive late or incomplete, or contain viruses. The sender therefore does
> > not accept liability for any errors or omissions in the contents of this
> > message, which arise as a result of e-mail transmission. _
>
>

Re: Are underground utility markers essential workers?

[Bjørn Mork]

Nick Hilliard  writes:

> we have a very poorly-defined idea of what constitutes an "essential
> worker"

I thought "management" was the definition of non-essential workers. Who
else would have a job without being essential/critical for day-to-day
business?


Bjørn

Re: Are underground utility markers essential workers?

[Nick Hilliard]

Sean Donelan wrote on 21/04/2020 19:57:

Utility markers don't get the recognition they deserve.  If they aren't
essential workers, they should be and get hazard pay.

They help protect everyone's fiber and cables and pipes that go boom.


we have a very poorly-defined idea of what constitutes an "essential 
worker", and in the more general case, what constitutes an essential 
supplier.  Supply chains are complex, and disruptions in one place can 
serious downstream ripple effects in another.  There are plenty of 
examples like this at the moment:



https://www.bloomberg.com/news/articles/2020-04-16/broadcom-says-orders-require-six-months-notice-due-to-delays

Nick

Re: xplornet contact or any experience with their satellite service?

[Olav Kvittem via NANOG]

On 21.04.2020 20:59, Brandon Martin wrote:

On 4/21/20 2:35 PM, Brian J. Murrell wrote:

Interesting.  So basically as Mel said, over-sold network.  :-(

This is pretty typical of consumer VSAT and such.  You can of course get better performance...if 
you're willing to pay for it.  If you find the right carrier/re-seller, you can perhaps find one 
whose "system" (to include ground station, terminals, and smarts on the bird) can respect 
DSCP and flag at least your voice traffic appropriately (probably EF) to perhaps lower the jitter 
and make conferencing more palatable.  Finding competent folks at a typical consumer provider's 
helpdesk to talk to about such things is probably the limiting factor.  The higher up the foodchain 
you go towards the folks who "own" the spectrum rather than re-sell will perhaps get you 
more luck on something like this though probably also at higher MRC.

Unfortunately, it's just what happens when you spread an already limited 
resource (transponder bandwidth) out over essentially an entire continent or at 
least substantial portions of it.  Imagine if you had a cable provider with a 
single node for an entire, say, US state.


Could be interesting to do  one-way-delay measurements in parallel to 
see how the packets are travelling


and where and how big the queues are (Bufferbloat).

Likeways if you have a unix system you could look at tcp statistics

to see if you have packet retransmits (netstat -s).

As previously noted TDMA between uploading or even ACK'ing users could 
be a bottleneck for the download speed.



Olav