On 3 Apr 2024, at 9:33, Mark Prior wrote:
On 2/4/2024 21: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?
The way I read your statement is that an Internet2 peer should expect to see Internet2's NREN peers as well as its customers from a peering but not the customers of those NREN peers.
Mark.
Hi Mark,
I agree. It would make more sense for AS11537:AS-NREN-PEERS to contain the as-cones of I2’s peer. For example, AS11537:AS-NREN-PEERS would include AS-GEANTNRN and AS-GEANTNRENPEERS to accommodate I2 transiting routes from GEANT and its customers.
Is that more consistent with your thinking?
Thanks,
Steve
Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu