Hi Jeff, Thank you. We are now in sync with you. The design focuses only on transparent RS (i.e., the RS ASN does not appear in the AS path in BGP). We are assuming that non-transparent RS is rare/abnormal.
It turns out that the solution that works for transparent RS also works for non-transparent RS with no extra effort. Just an observation, not saying that the non-transparent RS case has any importance. I have a talk in SIDROPS on Friday where the WG discussions will be summarized and a solution presented: "ASPA Verification Procedures: Enhancements and RS Considerations". Sriram From: Jeffrey Haas <[email protected]> Sent: Monday, March 21, 2022 12:43 PM To: Zhuangshunwan <[email protected]> Cc: Jakob Heitz (jheitz) <[email protected]>; Gyan Mishra <[email protected]>; Sriram, Kotikalapudi (Fed) <[email protected]>; Ben Maddison <[email protected]>; [email protected]; [email protected] Subject: Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question) Two comments here: If the BGP Speaker is inserting itself into the AS_PATH, it's not really a Route Server in the traditional sense. A normal BGP Speaker can happily pass along routes via eBGP peering with the nexthop unchanged with all devices that it shares a common nexthop subnet with. My recommendation is to not to try to consider these devices a Route Server. For ASPA purposes, just add the BGP connections to the inputs. If providers are unhappy with having a IXP router's AS in the ASPA data and thus lose the desired ASPA filtering properties, the IXP should install a real route server. -- Jeff _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
