On 2 Apr 2024, at 9:38, Steven Wallace wrote:
On 2 Apr 2024, at 10:33, Dale W. Carder wrote:
Thus spake Steven Wallace (ssw@internet2.edu) on Mon, Apr 01, 2024 at 11:49:09AM -0400:
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.
What would be the use case for documenting that particularly in RPSL?
Dale
[Not an RPSL expert] For example, if an NREN that peers with Internet2 wishes to use the as-cone of Internet2 AND the as-cones of the NRENs Internet2 provides transit as a basis for a prefix filter. Am I thinking about this incorrectly?
Steve,
If AS11537:AS-NREN-PEERS only contains the AS numbers of Internet2’s NREN BGP neighbors, then the AS-SET isn’t easily usable by others to create a complete prefix list. For each ASN in the AS-SET you would then need to determine the correct AS-SET to use for that ASN. As you’ve discovered, that can be a challenge.
If a BGP neighbor of AS11537 finds ASxyz in AS11537:AS-NREN-PEERS, there is still the challenge of determining which of ASxyz’s AS-SETs should be used. Even if we got 100% participation in the AS-SET naming you are proposing, one would still not know if ASxyz:AS-CUSTOMERS or ASxyz:AS-NREN-PEERS should be used.
If AS11537 is already using an AS-SET to filter routes from ASxyz, rather than just adding ASxyz to AS11537:AS-NREN-PEERS, wouldn’t it be more helpful to add the AS-SET instead of just adding ASxyz?
Jeff