Dave,

I’ll update the document to be clearer. I’m suggesting that AS11537:AS-NREN-PEERS contains the ASNs of Internet2’s NREN peers, not their customer cones. For example, AS11537:AS-NREN-PEERS would contain AS20965 (GEANT), among others. It wouldn’t contain AS20965:AS-CUSTOMERS or AS20965:AS-NREN-PEERS.

Steve


On 1 Apr 2024, at 11:40, David Farmer wrote:

Steve,

In rereading it, in your example for Internet2, do you anticipate AS11537:AS-NREN-PEERS to be made up of the customer cones of the NRENs Internet2 will provide transit too?

For example, AS11537:AS-NREN-PEERS = AS7575:AS-CUSTOMER, AS6509:AS-CANARIE, AS-CERNEXT, ...

I ask because there are limits to the depth of how many references to references to references can be made for most RPSL tooling.

So you should probably cover that issue in the discussion.

Thanks

On Mon, Apr 1, 2024 at 9:23 AM David Farmer <farmer@umn.edu> wrote:
The document should recommend consistency in what NRENs announce to each other and peer NRENs and other policy goals we have in common. I have seen it several times where an NREN doesn't announce a prefix to one peer but does to another peer, causing traffic to go the wrong way around the globe. Actually, documenting the prefixes and the relationships will go a long way to resolving many of these issues. Nevertheless, we should recognize and document our common policy goals in addition to the mechanisms used to achieve the goals.  

Thanks


On Mon, Apr 1, 2024 at 9:10 AM Steven Wallace <ssw@internet2.edu> wrote:
Mark,

That’s a great suggestion. I believe Internet2 used to publish a set of community tags that attempted to provide this capability. I’m looking through old records to see if there is anything worth reusing or learning from.

Steve


On 1 Apr 2024, at 9:58, Mark Prior wrote:

> On 1/4/2024 20:40, Steven Wallace wrote:
>> Based on the feedback from this list, I’ve put together a rough draft of a best practice. Anyone can add comments to the Google Doc. If you’d like to edit the document directly, please send me your email, and I’ll add you to the document’s authors.
>>
>
> I would suggest that you develop a mutual set of communities to indicate if a prefix is a customer or a transit receiving peer, and which continent the prefix lives on so that some sensible pruning could be attempted. As an example it would probably be helpful for Géant to know if Internet2 is sending prefixes from South America or Africa as they possibly have a better path to those locations and would want to depreference an Internet2 version even if the AS path was shorter. If there are regions with limited connectivity options than enumerating them might be helpful.
>
> Mark.



Steven Wallace
Director - Routing Integrity
Internet2
ssw@internet2.edu
_______________________________________________
Routing-wg mailing list -- routing-wg@lists.gna-g.net
To unsubscribe send an email to routing-wg-leave@lists.gna-g.net


--
===============================================
David Farmer               Email:farmer@umn.edu
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               Email:farmer@umn.edu
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
===============================================

Steven Wallace
Director - Routing Integrity
Internet2
ssw@internet2.edu