Re: SFI/SBI/Transit - Dumping

[Rod Beck]

I was an Erols customer during that time. What's the story?


From: NANOG  on behalf 
of William Herrin 
Sent: Tuesday, March 16, 2021 1:01 AM
To: Douglas Fischer 
Cc: NANOG 
Subject: Re: SFI/SBI/Transit - Dumping

On Mon, Mar 15, 2021 at 11:35 AM Douglas Fischer
 wrote:
> I'm going a bit deeper into the study of Peering Relationships...
> And one of the possibilities that I'm trying to understand better on the 
> Peering Relationships on the Internet been considered dumping(economy).
>
> The matter here is more on the economic and commercial aspects than on the 
> technical side.

Hi Douglas,

I'm not aware of any examples of Dumping (in the economics sense)
involving backbone BGP peering. Usually the problem is collusive
exclusion.

If you want to cast a wider net, Erols Internet of the 1990s offers an
interesting case study in driving competition out with extended
below-cost pricing. But this was dialup and DSL service, not backbone
peering.

Regards,
Bill Herrin


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

Re: SFI/SBI/Transit - Dumping

[Douglas Fischer]

There is no specific story on the focus.
My objective is to go a bit beyond the technical aspects of Peering, or
De-peering.

At the first moment, I don't mention some cases that I have in mind,
exactly to avoid the polemic and focus on the aspects around the cases.

I will give a hypothetic example, with no real names:

---
The "SteveAndEdNet", a CDN Company, decides to extend its branchs until
"Kingdom of Far Far Away", and creates a POP there.
Installs itself on "DorisInnDatacenter", connects with some IXPs over
there, connects some PNIs with some nobles.
But, after some time, "SteveAndEdNet" make a deal with "RumpelstiltkinNet"
a Transit provider that operates there.

On that deal "RumpelstiltkinNet" ensure to supply the traffic demanded to
"SteveAndEdNet" POP to be considered technical justifiable...
But it also demands, that "SteveAndEdNet" drain all the traffic to IXPs and
PNIs...
With that, "RumpelstiltkinNet" can be the only one reseller of the content
delivered by "SteveAndEdNet".
---
This is a foggy example that I'm trying to understand better by the point
of view of Economics Dumping.

And then??
Can this be considered an anti-competitive act?



If anyone feels more comfortable reaching me privately, no issues with that.


Em ter., 16 de mar. de 2021 às 03:33, Rod Beck <
rod.b...@unitedcablecompany.com> escreveu:

> I was an Erols customer during that time. What's the story?
>
> --
> *From:* NANOG 
> on behalf of William Herrin 
> *Sent:* Tuesday, March 16, 2021 1:01 AM
> *To:* Douglas Fischer 
> *Cc:* NANOG 
> *Subject:* Re: SFI/SBI/Transit - Dumping
>
> On Mon, Mar 15, 2021 at 11:35 AM Douglas Fischer
>  wrote:
> > I'm going a bit deeper into the study of Peering Relationships...
> > And one of the possibilities that I'm trying to understand better on the
> Peering Relationships on the Internet been considered dumping(economy).
> >
> > The matter here is more on the economic and commercial aspects than on
> the technical side.
>
> Hi Douglas,
>
> I'm not aware of any examples of Dumping (in the economics sense)
> involving backbone BGP peering. Usually the problem is collusive
> exclusion.
>
> If you want to cast a wider net, Erols Internet of the 1990s offers an
> interesting case study in driving competition out with extended
> below-cost pricing. But this was dialup and DSL service, not backbone
> peering.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>


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

Re: SFI/SBI/Transit - Dumping

[Niels Bakker]

* fischerdoug...@gmail.com (Douglas Fischer) [Tue 16 Mar 2021, 11:32 CET]:

And then??
Can this be considered an anti-competitive act?


I think you're asking this on the wrong list. We're network operators, 
not lawyers with a specialisation in competitive markets regulation.



-- Niels.

Re: DOD prefixes and AS8003 / GRSCORP

[Owen DeLong via NANOG]

> On Mar 15, 2021, at 15:07 , Tom Beecher  wrote:
> 
> I think it’s a general matter of public interest how this reassignment of a 
> massive government-owned block of well over sixteen million IP addresses 
> happened. Even if not fraudulent, the public has a right to know who is 
> behind this huge transfer of wealth.
> 
> Don’t you?

> On Mon, Mar 15, 2021 at 3:35 PM Mel Beckman  > wrote:
> Owen,
> 
> I think one cause for concern is why “almost all DOD prefixes 
> (7.0.0.0/8,11.0.0.0/8,22.0.0.0/8  and 
> bunch of /22s) are now announced under AS8003 <> (GRSCORP) which was just 
> formed a few months ago,” which, according to ARIN WHOIS, had a source 
> registry of “DoD Network Information Center”. 

Somehow, I’m of the impression that DoD is quite capable of defending their own 
property if necessary. I’m also not of the same belief as you that GRSCORP was 
just formed a few months ago. It seems to have bounced back and forth between 
Florida and Delaware one or more times, but that’s not all that uncommon for a 
corporation physically located in Florida. Corporations change their state of 
incorporation somewhat regularly for a variety of legal forum shopping 
purposes, including but not limited to tax advantages, court jurisdictional 
advantages, etc.


> I think it’s a general matter of public interest how this reassignment of a 
> massive government-owned block of well over sixteen million IP addresses 
> happened. Even if not fraudulent, the public has a right to know who is 
> behind this huge transfer of wealth.

I don’t see a transfer of wealth. I see DOD finally having a contractor 
originate their prefixes in order to make life more difficult for squatters, 
hijackers, and other miscreants. About time, if you ask me. I mean, I’m sure 
that in order to provide that level of sink-hole, GRSCORP is having to pay some 
hefty transit bills and maintain some significant infrastructure and likely 
passing all that cost along to DoD at a hefty markup, so I suppose that’s some 
level of transfer of wealth, but as DoD contracts go, I somehow don’t think 
this one would be regarded as “significant”.

Owen

> 
> Don’t you?
> 
>  -mel beckman
> 
>> On Mar 15, 2021, at 12:23 PM, Owen DeLong via NANOG > > wrote:
>> 
>>  According to the timeline posted to this list (by you, Siyuan), Globl 
>> Resource Systems, LLC was registered in Delaware on September 8, 2020.
>> Your timeline also shows the resources being issued to GRS by ARIN on 
>> September 11, september 14, 2020
>> It looks to me like they subsequently registered the corporation in Florida 
>> and moved the company address there.
>> 
>> I don’t see anything suspicious here based on your own statements, so I’m a 
>> bit confused what you are on about.
>> 
>> Owen
>> 
>>> On Mar 12, 2021, at 03:34 , Siyuan Miao >> > wrote:
>>> 
>>> Hi John,
>>> 
>>> My biggest concern is why the AS8003 was assigned to the company (GLOBAL 
>>> RESOURCE SYSTEMS, LLC) even before its existence.
>>> 
>>> When we were requesting resources or transfers, ARIN always asked us to 
>>> provide a Certificate of Good Standing and we had to pay the state to order 
>>> it.
>>> 
>>> However, it appears that a Certificate of Good Standing is not required or 
>>> ARIN didn't validate it in this case. 
>>> 
>>> Regards,
>>> Siyuan
>>> 
>>> On Fri, Mar 12, 2021 at 7:17 PM John Curran >> > wrote:
>>> On 11 Mar 2021, at 7:56 AM, Siyuan Miao >> > wrote:
 
 Hi Folks,
 
 Just noticed that almost all DOD prefixes (7.0.0.0/8,11.0.0.0/8,22.0.0.0/8 
  and bunch of /22s)  are now 
 announced under AS8003 (GRSCORP) which was just formed a few months ago.
 
 It looks so suspicious. Does anyone know if it's authorized?
>>> 
>>> Siyuan - 
>>> 
>>> If you have concerns, you can confirm whether these IP address blocks are 
>>> being routed as intended by verification with their listed technical 
>>> contacts - e.g. https://search.arin.net/rdap/?query=22.0.0.0 
>>>   
>>> 
>>> As I noted on this list several weeks back - "lack of routing history is 
>>> not at all a reliable indicator of the potential for valid routing of a 
>>> given IPv4 block in the future, so best practice suggest that allocated 
>>> address space should not be blocked by others without specific cause. Doing 
>>> otherwise opens one up to unexpected surprises when issued space suddenly 
>>> becomes more active in routing and is yet is inexplicably unreachable for 
>>> some destinations."
>>> 
>>> Thanks!
>>> /John
>>> 
>>> John Curran
>>> President and CEO
>>> American Registry for Internet Numbers
>>> 
>> 

ARIN-NONAUTH IRR final retirement set for 31 March 2022 (was: ARIN-NONAUTH data ARIN-NONAUTH dataFwd: [ARIN-consult] ACSP Consultation 2021.1: Future of ARIN’s Unauthenticated IRR is now Closed)

[John Curran]

NANOGers -
FYI - Outcome of the community consultation on the Future of ARIN’s 
Unauthenticated IRR.
/John

John Curran
President and CEO
American Registry for Internet Numbers

Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [ARIN-consult] ACSP Consultation 2021.1: Future of ARIN’s 
Unauthenticated IRR is now Closed
Date: 15 March 2021 at 4:27:04 PM EDT
To: mailto:arin-cons...@arin.net>>

I would like to thank everyone who provided valuable feedback during this 
consultation on the future of ARIN’s unauthenticated IRR. Input provided by the 
community is a vital part of our planning processes at ARIN, and after 
reviewing responses to the consultation, we are making a few significant 
adjustments in our path forward.

One concern raised during the consultation was that six months was not enough 
time for organizations that currently depend on data in ARIN’s unauthenticated 
IRR to make changes to their systems. As a result, we will be extending the 
availability of ARIN’s non-authenticated IRR for an additional six months with 
final retirement set for 31 March 2022.

The second major suggestion was that ARIN conduct proactive engagement to 
notifying customers who currently use our unauthenticated IRR. We have already 
initiated this outreach, and for the next twelve months, we will continue this 
direct outreach to customers who have records in ARIN’s non-authenticated IRR 
to inform them of their options and provide necessary assistance.

We will also provide regular reminders and updates to our community and 
organizations making use of the outdated and non-authenticated IRR data stream 
so they can be ready for when we cease publishing the ARIN-NONAUTH data stream. 
These reminders leading up to the retirement of ARIN’s non-authenticated IRR 
will include statistics on the number of records remaining in that system and 
related routing coverage.

Thank you again to those who provided valuable feedback on this consultation.

Regards,

John Curran
President and CEO
American Registry for Internet Numbers
___
ARIN-Consult
You are receiving this message because you are subscribed to the ARIN Consult 
Mailing
List (arin-cons...@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN 
Member Services
Help Desk at i...@arin.net if you experience any issues.

Re: SFI/SBI/Transit - Dumping

[Mark Tinka]

On 3/16/21 13:18, Niels Bakker wrote:



I think you're asking this on the wrong list. We're network operators, 
not lawyers with a specialisation in competitive markets regulation.


Well, yes and no...

No, we aren't lawyers, but yes in that there is some merit to the 
question from a network operator standpoint.


Sure, the CDN operator wants to deploy their node with as little cost to 
them as possible, particularly if the target country does not move the 
traffic and $$ needles for the CDN operator, i.e., they want to de-risk 
their investment as much as possible, hopefully until traffic and 
revenue picks up from that specific market.


Getting a local ISP to shoulder that responsibility, likely disguised as 
"content is king, so you benefit" would not be unusual.


It all comes down to how desperate the local market is for the content, 
and how far they are willing to negotiate in or against their favour.


Mark.

Re: ARIN-NONAUTH IRR final retirement set for 31 March 2022 (was: ARIN-NONAUTH data ARIN-NONAUTH dataFwd: [ARIN-consult] ACSP Consultation 2021.1: Future of ARIN’s Unauthenticated IRR is now Closed)

[John Curran]

Job -

You suggest "ARIN can manage cleanup of a select few objects” but alas, 
responsibility for proper routing entry hygiene lies with the individual 
parties that have placed information in the routing registry.

Decisions on ARIN services are ultimately under the authority of the ARIN Board 
of Trustees, who are the elected representatives of the ARIN membership.   More 
information on the ARIN Board of Trustees may be found here - 
https://www.arin.net/about/welcome/board/

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

On 16 Mar 2021, at 8:04 AM, Job Snijders 
mailto:j...@fastly.com>> wrote:

Dear John,

Thank you for extending the deadline with another 6 months. Obviously 6
months amidst a global pandamic would never be enough time. :-)

Both John Sweeting [1] and myself [2] assert there are tens of thousands
of objects for which the relationship between the object's existence and
the state of related routes in the BGP default-free zone routing are not
fully understood.

It appears ARIN has choosen to ignore a specific community suggestion:
please first prove ARIN can manage cleanup of a select few objects,
before proceeding to deprecate the entire ARIN-NONAUTH database.

I'm not convinced mere 'community outreach' is an appropriate and
substantive response to the anteriority of 'Legacy Holders' who might
depend on both ARIN's reverse DNS service and ARIN's (Non Authoritative)
IRR service.

I personally would like to see ARIN postpone any decision on whether to
sunset the ARIN-NONAUTH database in favor of first applying
community-recognised object clean-up mechanisms, and then based on the
'lessons learned' from such a cleanup process, inform future go/no-go
decisions.

Can you share with me what the process would be to appeal the decision
made here and how course can changed?

Kind regards,

Job

[1]: https://lists.arin.net/pipermail/arin-consult/2021-March/001241.html
[2]: https://lists.arin.net/pipermail/arin-consult/2021-March/001237.html

On Tue, Mar 16, 2021 at 11:03:56AM +, John Curran wrote:
NANOGers -
FYI - Outcome of the community consultation on the Future of ARIN’s 
Unauthenticated IRR.
/John

John Curran
President and CEO
American Registry for Internet Numbers

Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [ARIN-consult] ACSP Consultation 2021.1: Future of ARIN’s 
Unauthenticated IRR is now Closed
Date: 15 March 2021 at 4:27:04 PM EDT
To: 
mailto:arin-cons...@arin.net>>

I would like to thank everyone who provided valuable feedback during this 
consultation on the future of ARIN’s unauthenticated IRR. Input provided by the 
community is a vital part of our planning processes at ARIN, and after 
reviewing responses to the consultation, we are making a few significant 
adjustments in our path forward.

One concern raised during the consultation was that six months was not enough 
time for organizations that currently depend on data in ARIN’s unauthenticated 
IRR to make changes to their systems. As a result, we will be extending the 
availability of ARIN’s non-authenticated IRR for an additional six months with 
final retirement set for 31 March 2022.

The second major suggestion was that ARIN conduct proactive engagement to 
notifying customers who currently use our unauthenticated IRR. We have already 
initiated this outreach, and for the next twelve months, we will continue this 
direct outreach to customers who have records in ARIN’s non-authenticated IRR 
to inform them of their options and provide necessary assistance.

We will also provide regular reminders and updates to our community and 
organizations making use of the outdated and non-authenticated IRR data stream 
so they can be ready for when we cease publishing the ARIN-NONAUTH data stream. 
These reminders leading up to the retirement of ARIN’s non-authenticated IRR 
will include statistics on the number of records remaining in that system and 
related routing coverage.

Thank you again to those who provided valuable feedback on this consultation.

Regards,

John Curran
President and CEO
American Registry for Internet Numbers
___
ARIN-Consult
You are receiving this message because you are subscribed to the ARIN Consult 
Mailing
List 
(arin-cons...@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN 
Member Services
Help Desk at i...@arin.net if you 
experience any issues.

Re: ARIN-NONAUTH IRR final retirement set for 31 March 2022

[Martijn Schmidt via NANOG]

Hi John,

It seems that you are trying to abdicate responsibility, but at the end of the 
day those individual parties are placing information in "better" routing 
registries such as RPKI that you can leverage to clean up the "lesser" 
ARIN-NONAUTH routing registry. So those individuals are taking their 
responsibility, and I am wondering - when will ARIN start taking their cue?

Best regards,
Martijn

On 3/16/21 1:14 PM, John Curran wrote:
Job -

You suggest "ARIN can manage cleanup of a select few objects” but alas, 
responsibility for proper routing entry hygiene lies with the individual 
parties that have placed information in the routing registry.

Decisions on ARIN services are ultimately under the authority of the ARIN Board 
of Trustees, who are the elected representatives of the ARIN membership.   More 
information on the ARIN Board of Trustees may be found here - 
https://www.arin.net/about/welcome/board/

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

On 16 Mar 2021, at 8:04 AM, Job Snijders 
mailto:j...@fastly.com>> wrote:

Dear John,

Thank you for extending the deadline with another 6 months. Obviously 6
months amidst a global pandamic would never be enough time. :-)

Both John Sweeting [1] and myself [2] assert there are tens of thousands
of objects for which the relationship between the object's existence and
the state of related routes in the BGP default-free zone routing are not
fully understood.

It appears ARIN has choosen to ignore a specific community suggestion:
please first prove ARIN can manage cleanup of a select few objects,
before proceeding to deprecate the entire ARIN-NONAUTH database.

I'm not convinced mere 'community outreach' is an appropriate and
substantive response to the anteriority of 'Legacy Holders' who might
depend on both ARIN's reverse DNS service and ARIN's (Non Authoritative)
IRR service.

I personally would like to see ARIN postpone any decision on whether to
sunset the ARIN-NONAUTH database in favor of first applying
community-recognised object clean-up mechanisms, and then based on the
'lessons learned' from such a cleanup process, inform future go/no-go
decisions.

Can you share with me what the process would be to appeal the decision
made here and how course can changed?

Kind regards,

Job

[1]: https://lists.arin.net/pipermail/arin-consult/2021-March/001241.html
[2]: https://lists.arin.net/pipermail/arin-consult/2021-March/001237.html

On Tue, Mar 16, 2021 at 11:03:56AM +, John Curran wrote:
NANOGers -
FYI - Outcome of the community consultation on the Future of ARIN’s 
Unauthenticated IRR.
/John

John Curran
President and CEO
American Registry for Internet Numbers

Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [ARIN-consult] ACSP Consultation 2021.1: Future of ARIN’s 
Unauthenticated IRR is now Closed
Date: 15 March 2021 at 4:27:04 PM EDT
To: 
mailto:arin-cons...@arin.net>>

I would like to thank everyone who provided valuable feedback during this 
consultation on the future of ARIN’s unauthenticated IRR. Input provided by the 
community is a vital part of our planning processes at ARIN, and after 
reviewing responses to the consultation, we are making a few significant 
adjustments in our path forward.

One concern raised during the consultation was that six months was not enough 
time for organizations that currently depend on data in ARIN’s unauthenticated 
IRR to make changes to their systems. As a result, we will be extending the 
availability of ARIN’s non-authenticated IRR for an additional six months with 
final retirement set for 31 March 2022.

The second major suggestion was that ARIN conduct proactive engagement to 
notifying customers who currently use our unauthenticated IRR. We have already 
initiated this outreach, and for the next twelve months, we will continue this 
direct outreach to customers who have records in ARIN’s non-authenticated IRR 
to inform them of their options and provide necessary assistance.

We will also provide regular reminders and updates to our community and 
organizations making use of the outdated and non-authenticated IRR data stream 
so they can be ready for when we cease publishing the ARIN-NONAUTH data stream. 
These reminders leading up to the retirement of ARIN’s non-authenticated IRR 
will include statistics on the number of records remaining in that system and 
related routing coverage.

Thank you again to those who provided valuable feedback on this consultation.

Regards,

John Curran
President and CEO
American Registry for Internet Numbers
___
ARIN-Consult
You are receiving this message because you are subscribed to the ARIN Consult 
Mailing
List 
(arin-cons...@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-consult 

Re: Microsoft problems...

[Colin Preston]

https://status.azure.com/en-us/status
SUMMARY OF IMPACT: Starting at approximately 19:15 UTC on 15 Mar 2021, a subset 
of customers may experience issues authenticating into Microsoft services, 
including Microsoft Teams, Office and/or Dynamics, Xbox Live, and the Azure 
Portal.

CURRENT STATUS: Engineering teams have been engaged and are currently 
investigating. The next update will be provided in 60 minutes or as events 
warrant.
This message was last updated at 19:58 UTC on 15 March 2021
 
On Monday, March 15, 2021 01:31 PM PDT, Justin Streiner  
wrote:
 Can you be a bit more specific regarding what you're seeing or not seeing? Are 
you reaching MS through IP transit/peer connections, or are you having issues 
reaching MS cloud services over ExpressRoute circuits? Thank youjms On Mon, Mar 
15, 2021 at 4:04 PM  wrote:Anyone else noticing major 
MAJOR problems with various MS services?

Geoff
 


 

Re: EXTERNAL: Re: Microsoft problems...

[AS212934 - NANOG]

Good afternoon,

I work retail at a tech store in Canada as my day job, and we've been 
experiencing issues today only with activating Microsoft product cards. Unsure 
if it's related to the other Microsoft issues, but it's a good possibility as 
no other product card activations for other vendors are affected. Another 
neighboring retailer is having the same issue as well, so it's definitely a 
possibility.

Regards,
Peter P.

Sent from my Bell Samsung device over Canada’s largest network.


From: NANOG  on behalf of 
nano...@mulligan.org 
Sent: Monday, March 15, 2021 5:03:43 PM
To: Ray Orsini ; Justin Streiner 
Cc: NANOG 
Subject: Re: EXTERNAL: Re: Microsoft problems...

teams is failing, powerbi is failing, azure is failing.  I don't use hotmail, 
so I don't know...

On 3/15/21 2:38 PM, Ray Orsini wrote:

Azure is having outages atm - 
https://twitter.com/MSFT365Status?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor



[OIT Website]
Ray Orsini​
Chief Executive Officer
OIT, LLC
[cid:part4.7AEA18DC.CE47A909@mulligan.com]   305.967.6756 
x1009|  
[cid:part6.7E876534.9BBD70C8@mulligan.com]   305.571.6272
[cid:part8.7BF54727.73AB839A@mulligan.com]   
r...@oit.co   |  [https://www.oit.co] 
   www.oit.co
[cid:part13.67217C5B.09C4EE25@mulligan.com]
 oit.co/ray
[Facebook]
[LinkedIn]
[Twitter]
[YouTube]
How are we doing? We'd love to hear your feedback. https://go.oit.co/review

From: NANOG 
 
On Behalf Of Justin Streiner
Sent: Monday, March 15, 2021 4:32 PM
To: nano...@mulligan.org
Cc: NANOG 
Subject: EXTERNAL: Re: Microsoft problems...



CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you are unsure, please forward this email to 
i...@oit.co for review.



Can you be a bit more specific regarding what you're seeing or not seeing?



Are you reaching MS through IP transit/peer connections, or are you having 
issues reaching MS cloud services over ExpressRoute circuits?



Thank you

jms



On Mon, Mar 15, 2021 at 4:04 PM 
mailto:nano...@mulligan.org>> wrote:

Anyone else noticing major MAJOR problems with various MS services?

Geoff

Re: ARIN-NONAUTH IRR final retirement set for 31 March 2022

[John Curran]

Martin -

ARIN has already taken responsibility by making available authenticated IRR and 
PRKI services as sought by the community, and I concur that individual parties 
are also taking responsibility by placing their routing information in these 
and similar services.

ARIN will encourage such migration, but the responsibility ultimately lies with 
those with the data in the unauthenticated IRR system.

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers

On 16 Mar 2021, at 8:36 AM, Martijn Schmidt 
mailto:martijnschm...@i3d.net>> wrote:

Hi John,

It seems that you are trying to abdicate responsibility, but at the end of the 
day those individual parties are placing information in "better" routing 
registries such as RPKI that you can leverage to clean up the "lesser" 
ARIN-NONAUTH routing registry. So those individuals are taking their 
responsibility, and I am wondering - when will ARIN start taking their cue?

Best regards,
Martijn

On 3/16/21 1:14 PM, John Curran wrote:
Job -

You suggest "ARIN can manage cleanup of a select few objects” but alas, 
responsibility for proper routing entry hygiene lies with the individual 
parties that have placed information in the routing registry.

Decisions on ARIN services are ultimately under the authority of the ARIN Board 
of Trustees, who are the elected representatives of the ARIN membership.   More 
information on the ARIN Board of Trustees may be found here - 
https://www.arin.net/about/welcome/board/

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

On 16 Mar 2021, at 8:04 AM, Job Snijders 
mailto:j...@fastly.com>> wrote:

Dear John,

Thank you for extending the deadline with another 6 months. Obviously 6
months amidst a global pandamic would never be enough time. :-)

Both John Sweeting [1] and myself [2] assert there are tens of thousands
of objects for which the relationship between the object's existence and
the state of related routes in the BGP default-free zone routing are not
fully understood.

It appears ARIN has choosen to ignore a specific community suggestion:
please first prove ARIN can manage cleanup of a select few objects,
before proceeding to deprecate the entire ARIN-NONAUTH database.

I'm not convinced mere 'community outreach' is an appropriate and
substantive response to the anteriority of 'Legacy Holders' who might
depend on both ARIN's reverse DNS service and ARIN's (Non Authoritative)
IRR service.

I personally would like to see ARIN postpone any decision on whether to
sunset the ARIN-NONAUTH database in favor of first applying
community-recognised object clean-up mechanisms, and then based on the
'lessons learned' from such a cleanup process, inform future go/no-go
decisions.

Can you share with me what the process would be to appeal the decision
made here and how course can changed?

Kind regards,

Job

[1]: https://lists.arin.net/pipermail/arin-consult/2021-March/001241.html
[2]: https://lists.arin.net/pipermail/arin-consult/2021-March/001237.html

On Tue, Mar 16, 2021 at 11:03:56AM +, John Curran wrote:
NANOGers -
FYI - Outcome of the community consultation on the Future of ARIN’s 
Unauthenticated IRR.
/John

John Curran
President and CEO
American Registry for Internet Numbers

Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [ARIN-consult] ACSP Consultation 2021.1: Future of ARIN’s 
Unauthenticated IRR is now Closed
Date: 15 March 2021 at 4:27:04 PM EDT
To: 
mailto:arin-cons...@arin.net>>

I would like to thank everyone who provided valuable feedback during this 
consultation on the future of ARIN’s unauthenticated IRR. Input provided by the 
community is a vital part of our planning processes at ARIN, and after 
reviewing responses to the consultation, we are making a few significant 
adjustments in our path forward.

One concern raised during the consultation was that six months was not enough 
time for organizations that currently depend on data in ARIN’s unauthenticated 
IRR to make changes to their systems. As a result, we will be extending the 
availability of ARIN’s non-authenticated IRR for an additional six months with 
final retirement set for 31 March 2022.

The second major suggestion was that ARIN conduct proactive engagement to 
notifying customers who currently use our unauthenticated IRR. We have already 
initiated this outreach, and for the next twelve months, we will continue this 
direct outreach to customers who have records in ARIN’s non-authenticated IRR 
to inform them of their options and provide necessary assistance.

We will also provide regular reminders and updates to our community and 
organizations making use of the outdated and non-authenticated IRR data stream 
so they can be ready for when we cease publishing the ARIN-NONAUTH data stream. 
These reminders leading up to the retirement of ARIN’s non-authenticated IRR 
will include statistics on the 

IPv6 filtering at network edge?

[Pete Ashdown]

I'm tightening up some network-edge filters, and in the process of 
testing filtering with IPv6, I found that there is a lot of ICMP 
link-local (fe80::) to ff02:: activity at an IX.  Is any of this 
necessary?  I am wary of over-filtering that cuts down functionality and 
doesn't increase security.  What of the IANA-reserved IPv6 addresses can 
be safely blocked on ingress/egress at the network edge?

Re: ARIN-NONAUTH IRR final retirement set for 31 March 2022 (was: ARIN-NONAUTH data ARIN-NONAUTH dataFwd: [ARIN-consult] ACSP Consultation 2021.1: Future of ARIN’s Unauthenticated IRR is now Closed)

[Job Snijders via NANOG]

Dear John,

Thank you for extending the deadline with another 6 months. Obviously 6
months amidst a global pandamic would never be enough time. :-)

Both John Sweeting [1] and myself [2] assert there are tens of thousands
of objects for which the relationship between the object's existence and
the state of related routes in the BGP default-free zone routing are not
fully understood.

It appears ARIN has choosen to ignore a specific community suggestion:
please first prove ARIN can manage cleanup of a select few objects,
before proceeding to deprecate the entire ARIN-NONAUTH database.

I'm not convinced mere 'community outreach' is an appropriate and
substantive response to the anteriority of 'Legacy Holders' who might
depend on both ARIN's reverse DNS service and ARIN's (Non Authoritative)
IRR service.

I personally would like to see ARIN postpone any decision on whether to
sunset the ARIN-NONAUTH database in favor of first applying
community-recognised object clean-up mechanisms, and then based on the
'lessons learned' from such a cleanup process, inform future go/no-go
decisions.

Can you share with me what the process would be to appeal the decision
made here and how course can changed?

Kind regards,

Job

[1]: https://lists.arin.net/pipermail/arin-consult/2021-March/001241.html
[2]: https://lists.arin.net/pipermail/arin-consult/2021-March/001237.html

On Tue, Mar 16, 2021 at 11:03:56AM +, John Curran wrote:
> NANOGers -
> FYI - Outcome of the community consultation on the Future of ARIN’s 
> Unauthenticated IRR.
> /John
> 
> John Curran
> President and CEO
> American Registry for Internet Numbers
> 
> Begin forwarded message:
> 
> From: ARIN mailto:i...@arin.net>>
> Subject: [ARIN-consult] ACSP Consultation 2021.1: Future of ARIN’s 
> Unauthenticated IRR is now Closed
> Date: 15 March 2021 at 4:27:04 PM EDT
> To: mailto:arin-cons...@arin.net>>
> 
> I would like to thank everyone who provided valuable feedback during this 
> consultation on the future of ARIN’s unauthenticated IRR. Input provided by 
> the community is a vital part of our planning processes at ARIN, and after 
> reviewing responses to the consultation, we are making a few significant 
> adjustments in our path forward.
> 
> One concern raised during the consultation was that six months was not enough 
> time for organizations that currently depend on data in ARIN’s 
> unauthenticated IRR to make changes to their systems. As a result, we will be 
> extending the availability of ARIN’s non-authenticated IRR for an additional 
> six months with final retirement set for 31 March 2022.
> 
> The second major suggestion was that ARIN conduct proactive engagement to 
> notifying customers who currently use our unauthenticated IRR. We have 
> already initiated this outreach, and for the next twelve months, we will 
> continue this direct outreach to customers who have records in ARIN’s 
> non-authenticated IRR to inform them of their options and provide necessary 
> assistance.
> 
> We will also provide regular reminders and updates to our community and 
> organizations making use of the outdated and non-authenticated IRR data 
> stream so they can be ready for when we cease publishing the ARIN-NONAUTH 
> data stream. These reminders leading up to the retirement of ARIN’s 
> non-authenticated IRR will include statistics on the number of records 
> remaining in that system and related routing coverage.
> 
> Thank you again to those who provided valuable feedback on this consultation.
> 
> Regards,
> 
> John Curran
> President and CEO
> American Registry for Internet Numbers
> ___
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN Consult 
> Mailing
> List (arin-cons...@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN 
> Member Services
> Help Desk at i...@arin.net if you experience any issues.

Re: Microsoft problems...

[Craig]

https://status.office365.com/




On Mon, Mar 15, 2021 at 4:49 PM Nathanael Cariaga 
wrote:

> WVD seems to be affected as well...  tak tsk tsk.  I guess this is part of
> Monday blues? :P
>
> On Tue, Mar 16, 2021, 4:39 AM Andrey Khomyakov, <
> khomyakov.and...@gmail.com> wrote:
>
>> I didn't troubleshoot at all (not my job), but yes, we are having all
>> sorts of issues accessing O365/Teams/etc
>>
>> --Andrey
>>
>>
>> On Mon, Mar 15, 2021 at 1:33 PM Justin Streiner 
>> wrote:
>>
>>> Can you be a bit more specific regarding what you're seeing or not
>>> seeing?
>>>
>>> Are you reaching MS through IP transit/peer connections, or are you
>>> having issues reaching MS cloud services over ExpressRoute circuits?
>>>
>>> Thank you
>>> jms
>>>
>>> On Mon, Mar 15, 2021 at 4:04 PM  wrote:
>>>
 Anyone else noticing major MAJOR problems with various MS services?

 Geoff

Re: IPv6 filtering at network edge?

[Saku Ytti]

Hey,

> I'm tightening up some network-edge filters, and in the process of
> testing filtering with IPv6, I found that there is a lot of ICMP
> link-local (fe80::) to ff02:: activity at an IX.  Is any of this
> necessary?  I am wary of over-filtering that cuts down functionality and

Dunno, ff02::1 would be very necessary (i.e. ND), ff02:: I have no
idea. But you should do yourself favor, before you drop ICMP packets,
allow ND:

set from next-header icmp6
set from icmp-type router-solicit
set from icmp-type router-advertisement
set from icmp-type neighbor-solicit
set from icmp-type neighbor-advertisement
set from hop-limit 255
set then count icmp:nd
set then accept

It doesn't really matter how many times this is mentioned on how many
forums, people will continue to break IPV6 ND by filtering it
incorrectly. I regularly have customers complaining we've broken IPV6,
when ND stops working, due to implementation change in our end using
different combinations of GUA/LL than what their filter permits. And
customers often remain unconvinced, offering 'it works on N other
providers just fine'. IPv6 is too hard, we don't understand how ND
works.


-- 
  ++ytti

Re: IPv6 filtering at network edge?

[Mark Tinka]

On 3/16/21 17:15, Saku Ytti wrote:


Dunno, ff02::1 would be very necessary (i.e. ND), ff02:: I have no
idea. But you should do yourself favor, before you drop ICMP packets,
allow ND:


Not that you should see it over an exchange point, but LDPv6 runs over 
ff02::2. In case that's your style, be careful not break that on your 
core-facing side.


Mark.

Re: SFI/SBI/Transit - Dumping

[Matthew Petach]

On Tue, Mar 16, 2021 at 3:33 AM Douglas Fischer 
wrote:

> There is no specific story on the focus.
> My objective is to go a bit beyond the technical aspects of Peering, or
> De-peering.
>
> At the first moment, I don't mention some cases that I have in mind,
> exactly to avoid the polemic and focus on the aspects around the cases.
>
> I will give a hypothetic example, with no real names:
>
> ---
> The "SteveAndEdNet", a CDN Company, decides to extend its branchs until
> "Kingdom of Far Far Away", and creates a POP there.
> Installs itself on "DorisInnDatacenter", connects with some IXPs over
> there, connects some PNIs with some nobles.
> But, after some time, "SteveAndEdNet" make a deal with "RumpelstiltkinNet"
> a Transit provider that operates there.
>
> On that deal "RumpelstiltkinNet" ensure to supply the traffic demanded to
> "SteveAndEdNet" POP to be considered technical justifiable...
> But it also demands, that "SteveAndEdNet" drain all the traffic to IXPs
> and PNIs...
> With that, "RumpelstiltkinNet" can be the only one reseller of the content
> delivered by "SteveAndEdNet".
> ---
> This is a foggy example that I'm trying to understand better by the point
> of view of Economics Dumping.
>
> And then??
> Can this be considered an anti-competitive act?
>
>
>
> If anyone feels more comfortable reaching me privately, no issues with
> that.
>


Hi Douglas,

I've been involved in negotiations with country-level providers that
engaged in negotiation tactics like that.

>From the content-provider side, such demands (ie, drain all traffic away
from IXPs and other SFI PNIs)
might last a short time, if RSN (RumpleStiltskinNet) undercuts the pricing
so low on their connectivity
that it makes sense to move all the traffic over, or bundles in other
products (power, space, remote
management, etc.) so that the overall package price is lower than it would
be if the IXP and SFI PNIs
were maintained.

However, such relationships tend to fall apart the first time RSN has a
large-scale outage
that negatively impacts the CDN and all its content customers, at which
point the
negotiation table is usually re-opened, and the CDN says "in order to
protect our
customers from your ineptitude, we require alternate pathways for the
content to
be served in your region" -- and the exclusive arrangement goes away.

The simple fact of the matter is that in general, agreeing to single-home
your
content behind a single provider results in reduced availability for the
content, as
a single provider has less redundancy and less diversity than a blend of
multiple
providers, whether paid or settlement free.  And once a major outage
happens
that threatens the top-line revenue numbers for the CDN, saving money on
the
bottom line suddenly becomes much less important than preserving the
top-line
revenue number.

There's a finite and limited benefit RSN can offer by reducing cost
numbers;
but there's a potentially *unlimited* upside risk.  That is, RSN can't
reduce
your cost numbers from what they are today to less than zero; so there's a
maximum benefit they can offer.  But if they have a bad week, and you go
dark, and lose all your customers, you could lose all your revenue--and
there's
no limit on how much you could lose on that end, as your customer base and
revenue numbers go up.

Thus, on balance, such agreements don't last, as either the CDN goes out
of business, and the agreement thus ends, or the CDN becomes more
successful, and the top-line revenue dollar value risk outweighs the
offered cost-reduction saving benefit RSN is bringing to the table,
and the agreement is thus terminated.

I hope this helps clear up the situation for you.   :)

Thanks!

Matt

Re: SFI/SBI/Transit - Dumping

[William Herrin]

On Tue, Mar 16, 2021 at 3:30 AM Douglas Fischer
 wrote:
> ---
> The "SteveAndEdNet", a CDN Company, decides to extend its branchs until 
> "Kingdom of Far Far Away", and creates a POP there.
> Installs itself on "DorisInnDatacenter", connects with some IXPs over there, 
> connects some PNIs with some nobles.
> But, after some time, "SteveAndEdNet" make a deal with "RumpelstiltkinNet" a 
> Transit provider that operates there.
>
> On that deal "RumpelstiltkinNet" ensure to supply the traffic demanded to 
> "SteveAndEdNet" POP to be considered technical justifiable...
> But it also demands, that "SteveAndEdNet" drain all the traffic to IXPs and 
> PNIs...
> With that, "RumpelstiltkinNet" can be the only one reseller of the content 
> delivered by "SteveAndEdNet".
> ---
> This is a foggy example that I'm trying to understand better by the point of 
> view of Economics Dumping.
>
> And then??
> Can this be considered an anti-competitive act?


Hi Douglas,

The words you're using here are very strange but I think you may be
trying to ask if "settlement free peering" can be anticompetitive.
Yes, it can, but from the way you talk about it I think your
understanding of when and how is probably upside down. It has little
or nothing to do with dumping or other forms of cross-subsidy.

Let's start with some terminology.

"Settlement free peering" is business practice in which two
organizations place routers physically next to each other* and trade
network packets which are sourced from one of the organization's users
and destined to the other organization's users. This differs from a
normal business relationship between Internet companies in several
important respects.

1. Both organizations pay their own direct costs to place their
routers next to each other.

2. Neither organization pays the other any money. They do not "settle
up" with each other depending on the packets transmitted, hence the
packet trade is free of any settlement settlement process.

3. Only packets which are from one organization and to the other are
transmitted via the connection. Unlike a normal "transit"
relationship, the settlement free peering connection links neither
organization to the Internet at large. Rather it connects them only to
each other.

The idea is that directly connecting both reduces cost for both
parties and improves the customer's experience by providing faster
data transmission between the parties.

Organizations which engage in settlement free peering generally have a
"peering policy." This policy describes the circumstances in which
they seek to or are willing to establish settlement free peering with
other organizations. Their peering policy is said to be "open" or
"closed" depending on the manner in which they select their peers.

An "open peering policy" is one in which, within reason, an
organization agrees to engage in settlement free peering with every
other organization which asks to do so. The two organizations either
place routers in a mutually agreeable location or the asking party
places a router somewhere that the asked party is already present.

A "closed peering policy" is one in which the organization is very
selective about who they will establish settlement free peering with.
Even if the other organization is willing to place a router next to
theirs, they will only trade packets for free if the other
organization has specific business characteristics which meet with
their approval.

Finally, "paid peering" is exactly like settlement free peering except
that one organization pays the other for the connection.


As you can probably guess from the terminology, it's practically
impossible for an organization with an open peering policy to drive
anticompetitive behavior with settlement free peering. The same
business relationship is open to all seekers; they have but to ask.
The question gets more interesting where one or both have a closed
peering policy and offer paid peering to organizations who do not
qualify for settlement free peering.


Now, moving on from fact to opinion, closed peering policies can be
and often are anticompetitive. The peering policies typically have two
components: high data rates (exclude anyone who isn't already an
industry titan) and comparable bytes in and out (make content
providers who send more than they receive, like Netflix, pay us).
While industry leaders don't negotiate the list of folks they will and
won't peer with, they nevertheless all pretty much arrive at the same
list.

Anyway, hopefully this information is helpful to you.


* The routers don't necessarily have to be physically right next to
each other but that case is easiest to understand and the variants
where they aren't are functionally identical.


On a related note, it's been my experience that while cross-subsidy
exists in the Internet transit industry, it's not one of the critical
sources of anticompetitive behavior. The two primary sources are
things like the subtle collusion involved in closed peering