NTAC Peering Working Group

[David Farmer <>]

First, I for one appreciate you proving access to your L-Root instance as a community service.  My suggestion is we accept DNS Root Server anycast routes from Connectors into the R&E route table. However, I'd like to suggest Internet2 tag them with a special set of BGP communities, maybe by region or ingress router as well as an overall tag for Root Servers. The idea is to make it easy to filter them or set them to a normal local preference when appropriate, the east coast guys may not want to accept west coast anycast routes for instance.

Thanks.

On Tue, Apr 10, 2018 at 6:32 PM, Brad Fleming <> wrote:

If the community prefers I’m 100% happy filtering the L-Root instance at KanREN from our advertisements to I2 R&E, I2 TR-CPS, and/or GPN. I’d never thought through our advertisement causing issues on fellow regional or state networks due to (typically) elevated local-pref for R&E-learned prefixes. If that’s the case, please let me know and accept my apologies; we’ll get it fixed quickly!

I’m good with Dave’s #2 policy suggestion. I’d never thought about this topic so thanks to those smarter for helping point it out.

--
Brad Fleming
Assistant Director for Technology
Kansas Research and Education Network

On Apr 10, 2018, at 2:17 PM, David Farmer <> wrote:

I have previously mentioned Anycast DNS Root Servers, on the NTAC list, I'm including an email below and highlighted the most relevant part to this discussion;

---------- Forwarded message ----------

From: David Farmer <>

Date: Fri, Nov 10, 2017 at 9:08 AM

Subject: DNS Root Servers via R&E (Was: Re: DNS Serving Stale to the rescue?)

To:

Cc: Brad Fleming <>, Dave Diller <>, Akbar Kara <>, Bill Owens <>, NTAC <>, Kim Milford <>

Based on my local evaluation of DNS root server routes available to me, I have dropped several such routes learned via our Internet2 R&E peering, but not all of them. In several cases, I am utilizing alternate routes learned via Internet2 TR-CPS, that were significantly better than the route available from Internet2 R&E, but that were not preferred because of the higher local preference we give to R&E routes. Other cases I'm utilizing routes learned via direct local peering or Internet transit.

For the record, I'm only accepting B, H, and L roots via Internet2 R&E, I'm dropping (by origin ASN) all other DNS root servers learned via our Internet2 R&E peering. Note the B and H roots currently only have two servers each, therefore the Internet2 R&E peering provides as good or better connectivity to those roots as any other path available to me. 

Further, we have a separate direct peering with GPN and learn and prefer the KanREN L-root via that path. However, in addition, I'm keeping the path learned via Internet2 R&E as a backup path to that node for robustness.

Based on my local evaluation, I have two recommendations;

1. Each regional network and/or campus should evaluate whether or not root sever routes learned via their R&E peering should be preferred over other options they likely have.

2. The NTAC should consider a policy for what root server routes to accept into the Internet2 R&E route table.  My recommendation is to not accept DNS root server anycast routes for nodes that are not hosted on the north american continent, particularly from International Partner R&E networks.

I believe all root servers operators have at least one node hosted somewhere on the north american continent.  Therefore, there is no advantage provided by accepting off-continent DNS root server routes into the Internet2 R&E route table, because there will always be a better alternate route available.

See http://root-servers.org/   

Thanks

On Tue, Apr 10, 2018 at 1:49 PM, Nicholas Buraglio <> wrote:

I brought this up in another forum of NRENs in an attempt to suss out what others policies are and in a perfect world perhaps agree to a common set of policies.  

nb

ᐧ

---
Nick Buraglio
Energy Sciences Network; AS293
Lawrence Berkeley National Laboratory

+1 (510) 995-6068

On Tue, Apr 10, 2018 at 5:38 AM, Matt Mullins <> wrote:

We talked about this issue extensively yesterday. We have a course of action we are working on and would like to discuss at next week’s P&R WG call.

We want to evaluate Internet2’s commercial as-path configuration for R&E and TRCPS. We believe they should be slightly different between the two networks. The as-path configuration is used in our import policy to reject advertisements with one of the listed ASNs in the path. At next weeks call, we would like to go over the proposed as-path list and deployment timeline. 

Thank you,

Matt Mullins

Internet2 Network Operations Center

GlobalNOC at Indiana University

317-278-6622

On Apr 7, 2018, at 12:18 PM, David Farmer <> wrote:

To be clear I'm not saying it is inappropriate UBUNTU or RENU to have a GGC in their R&E route table, I think that is a great idea for them. However, what I am saying, is that Internet2 should not accept such routes from them. Furthermore, in most cases, we should not advertise such routes to them either. The intent of services like GGC, Akamai, and anycast generally, is to service users as topologically close as possible. Accepting these routes from other NRENs into the Internet2 R&E route table, which most participants local-pref over regular Internet routes, or advertising these routes to other NRENS, defeats that intent and degrades Internet performance, which runs counter to Internet2's goals.

In the case of GGC and Akamai for sure, it would be more effective for Internet2 work with Google and Akamai to get service node placed in developing NRENs than to provide routing for these services. 

Thanks.

On Sat, Apr 7, 2018 at 10:30 AM, Michael H Lambert <> wrote:

In the same vein, I noticed last week that CUDI was leaking PNWGP and CENIC routes (and perhaps others) into the R&E network.  The result was a likely violation of Internet2 AUPs and not just bad routing practices.  The Internet2 NOC put a filter in at least for those ASNs and was reaching out to CUDI.  This was probably the result of broken configuration because the AS paths were "11537 CUDI X Y CUDI Z".

Michael

David Farmer wrote:

FYI, I just sent the following note the Internet2 NOC.  I think we need a set of ASNs that should not be accepted from other NRENs, This should include things like GGC nodes, DNS Root Server anycast nodes, AS112 nodes, global transit providers, etc...

There are several HE(AS6939) routes being leaked into the R&E route table.

*> 42.83.137.0/24 <http://42.83.137.0/24>     146.57.255.241        2735    202      0 11537 22388 7660 4641 4641 6939 24785 8763 8763 8763 8763 24151 i
*> 42.83.138.0/24 <http://42.83.138.0/24>     146.57.255.241        2735    202      0 11537 22388 7660 4641 4641 6939 28917 39134 15835 24406 i
*> 125.208.43.0/24 <http://125.208.43.0/24>    146.57.255.241        2735    202      0 11537 22388 7660 4641 4641 6939 28917 39134 15835 24406 i
*> 125.208.44.0/24 <http://125.208.44.0/24>    146.57.255.241        2735    202      0 11537 22388 7660 4641 4641 6939 28917 39134 15835 24406 i
*> 194.246.96.0/24 <http://194.246.96.0/24>    146.57.255.241        2735    202      0 11537 22388 7660 4641 4641 6939 24785 8763 31529 i
*> 210.2.4.0/24 <http://210.2.4.0/24>       146.57.255.241        2735     202      0 11537 22388 7660 4641 4641 6939 28917 39134 15835 24406 i
*> 216.235.226.0/24 <http://216.235.226.0/24>   146.57.255.241        2142    202      0 11537 40220 11164 6939 26202 i

Thanks

---------- Forwarded message ----------
From: *David Farmer* < <mailto:>>
Date: Sat, Apr 7, 2018 at 9:54 AM
Subject: RENU advertising GGC node
To: Internet2 NOC < <mailto:>>


RENU is advertising a GGC node via UBUNTU into the Internet2 R&E route table. Please stop accepting these routes from them. As these routes are in the R&E route table they were overriding at least one route (104.237.191.0/24 <http://104.237.191.0/24>) I learn from a GGC node in Minneapolis. I have dealt with this in my local route policy, but I suspect others may have an issue too.

Note AS36040 is the ASN Google uses for GGC nodes;
https://peeringdb.com/net/4319
https://peering.google.com/#/options/peering

*> 104.237.175.0/24 <http://104.237.175.0/24>   146.57.255.241        2749    202      0 11537 36944 327687 36040 i
*> 104.237.191.0/24 <http://104.237.191.0/24>   146.57.255.241        2749    202      0 11537 36944 327687 36040 i

Thanks.

--

--
===============================================
David Farmer <mailto:>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

--
Michael H Lambert, GigaPoP Manager             Phone: +1 412 268-4960
Pittsburgh Supercomputing Center/3ROX          FAX:   +1 412 268-5832
300 S Craig St, Pittsburgh, PA  15213 USA     

--

===============================================
David Farmer              
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

--

===============================================
David Farmer              
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

--

===============================================
David Farmer              
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================