12:48 p.m.
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