That seems like an elegant solution.

I was thinking about automating the building of filters. Describing the objects in a notes field or an aut-num object I assume would need a human to interpret. 

Looking up peeringdb, testing if they have a "-NREN-TRANSIT" version of their AS-SET, using that if it exists, otherwise fall back on the value listed in peeringdb should be fairly simple.

Dylan
From: Steven Wallace <ssw@internet2.edu>
Sent: Thursday, 28 March 2024 1:01 AM
To: Dylan Hall <dylan.hall@reannz.co.nz>; routing-wg@lists.gna-g.net <routing-wg@lists.gna-g.net>
Cc: Paul Howell <phowell@internet2.edu>; Ryan Harden <rharden@internet2.edu>; Jeff Bartig <jbartig@internet2.edu>; Chris Wilkinson <cwilkinson@internet2.edu>
Subject: Re: [Routing-wg] looking at published customer cones vs. ground truth..
 
[You don't often get email from ssw@internet2.edu. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

It may be helpful to adopt a standard naming convention for as-sets that represent an NREN’s customers Plus NREN transit. Perhaps a standard suffix like “NREN-TRANSIT”.

AS-NAME-ENDING-WITH-NREN-TRANSIT

On 27 Mar 2024, at 7:48, Steven Wallace wrote:

> On 26 Mar 2024, at 23:38, Dylan Hall wrote:
>
>> At REANNZ we maintain an AS-SET with all our customers. We use this for commodity peering, transit, etc and this is recorded in peeringdb.
>> However, it doesn't include NREN transit/backup. I don't really want to add NREN transit to that AS-SET as I have no intention of announcing those prefixes to my commodity peers and not including them provides some protection against making a mistake and leaking them.
>>
>> What I would like to do is maintain a second AS-SET that points to my regular AS-SET as well as the list of NREN AS or AS-SETs I might provide transit to. The problem I see is where to record this? Peeringdb doesn't have a suitable field other than notes.
>>
>> Example:
>> AS-REANNZ-MEMBERS => AS38022,AS38299,...  (used for commodity)
>> AS-REANNZ-NREN => AS-REANNZ-MEMBERS,AS7575:AS-CUSTOMER,AS6360,...  (used for NREN)
>>
>> My second thought, where do we record our AS-SET's and other objects?
>> We currently use RADB because I can create proxy records for my customers who don't generally do a great job of maintaining their own records in APNIC. That said, if I want to push them towards using RPKI they'll need to use APNIC, so maybe the answer isn't to rely on RADB.
>>
>> Dylan
>>
>
> One possibility would be to use the export field on the aut-num to designate which as-set to use, as Rob Evans describes. For example:
> export to:AS11537 AS-CONE-THAT-INCLUDES-RE-TRANSIT
>
>
> Another option would be for the global R&E community to maintain a common list of as-set to use. Perhaps there are other options?
>
> I have the same thoughts concerning encouraging Internet2 downstream to create/maintain ROAs.
>
> Steve
>
>
>
> _______________________________________________
> Routing-wg mailing list -- routing-wg@lists.gna-g.net
> To unsubscribe send an email to routing-wg-leave@lists.gna-g.net