Nick and all, Thank you. What you all shared/discussed is very useful info.
>Almost all RS's are transparent these days. Usually IXPs go to lengths to >ensure that the RS ASN doesn't appear in the AS path. Good to know that. Well, that means there can be an occasional RS that is non-transparent. When there is a non-transparent RS, could there be big ISPs (Tier-1, Tier-2) present there as RS-clients? The ASPA verification draft treats the relationship of RS to RS-client as similar to that of Provider to Customer. Seems reasonable? The AS of an RS client includes the RS's AS in its ASPA as a "Provider". Sriram -----Original Message----- From: Nick Hilliard <n...@foobar.org> Sent: Tuesday, March 8, 2022 4:28 PM To: Sriram, Kotikalapudi (Fed) <kotikalapudi.sri...@nist.gov> Cc: grow@ietf.org; sidr...@ietf.org Subject: Re: [GROW] IXP Route Server question Sriram, Kotikalapudi (Fed) wrote on 08/03/2022 19:36: > This question has relevance to the ASPA method for route leak > detection. > > Is it possible that an ISP AS A peers with a customer AS C via a > non-transparent IXP AS B? > IOW, the AS path in routes propagated by the ISP A for customer C's > prefixes looks like this: A B C. > I.e., can the AS of a non-transparent IXP/RS appear in an AS path in > the middle between an ISP and its customer? Almost all RS's are transparent these days. Usually IXPs go to lengths to ensure that the RS ASN doesn't appear in the AS path. Some organisations provide transit over IXPs, but it's a minority thing. It would be very peculiar if an organisation provided transit over an IXP via an RS. Some organisations provide transit to ASNs over a direct physical connection while maintain peering with their customer over an IXP port. Usually this happens by accident, but occasionally it can happen by design. The answer to your question is that it would be technically possible, but it would be so peculiar and stupid that it should be considered a mistake in the situations where it was intentional. In all other situations, it would be a leak. Generally it would be safe to assume that this sort of configuration was in error. Nick _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
