NTAC Peering Working Group

[Nicholas Buraglio <>]

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