1:51 p.m.
On 3 Apr 2024, at 9:33, Mark Prior wrote:
On 2/4/2024 21:38, Steven Wallace wrote:
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(a)internet2.edu
On 2 Apr 2024, at 10:33, Dale W. Carder wrote:
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. Thus spake Steven Wallace (ssw(a)internet2.edu) on
Mon, Apr 01, 2024 at 11:49:09AM -0400:
[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? 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