Hello Sriram and all, Thank you for raising this important operational scenario. As a protocol designer (not a network operator), I believe intrinsic detection of ASPA registration errors should be within the verification framework itself – especially for direct customers. My rationale is threefold:
1. Early error detection is critical – *Out-of-band solutions increase complexity* The core issue is: *How does a provider proactively discover a customer’s ASPA registration error? * Under today’s algorithm, providers have no *in-band mechanism* to detect missing ASPA entries from direct customers. This creates "silent failures" where reachability degradation (from peers/providers) might go unnoticed until complaints arise. By revising the verification algorithm (e.g., prepending the local AS and perform egress verification), providers gain immediate visibility into misconfigurations. An automated *out-of-band solution for detecting registration errors obviously increases the complexity of deployment*. 2. *Not the ideal connectivity while masking the errors* When a customer’s ASPA omits their provider (e.g., local AS), today’s algorithm creates a validation gap: Local AS sees no error locally (BGP role takes precedence), But upstream ASes flag the route as Invalid due to ASPA checks. This gap causes asymmetric reachability: Local AS ───[BGP: Valid]───>>> Customer │ │ ASPA check by others ▼ Upstream ASes ───[ASPA: Invalid]───✘ Customer (Silent drop) Result: The customer is "connected" to local AS but disconnected from peers/providers – * not the ideal connectivity that operators expect, while also masking the issue*. 3. ASPA's Internal Safeguards *Preserve Connectivity While Enforcing Correctness * If partial connectivity is critical for network operators, strict ASPA checks need not result in immediate disconnection. We can: (1) Treat *"Invalid" at egress* as a soft alarm – Flag errors but allow traffic flow. Network operators can choose for themselves whether to strictly filter "Invalid" routes or just treat them as alerts; this is a simple deployment and configuration approach. (2) Set up a short-term whitelist until the registration issue is resolved. These thoughts reflect my perspective as a protocol designer. Thank you, Sriram, for raising this issue. I'm particularly keen to hear feedback from network operators. Best regards, Jia Zhongguancun Laboratory
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
