Hello all (special call out to network operators), Suppose a network operator (AS) makes an error in the creation of their ASPA - they did not include the AS of one of their providers. Perhaps this would be rare.
If you are a provider and this error was by your customer's customer or earlier in the path, then there is no issue. The ASPA verification method at your AS will evaluate the route as Invalid. That is fine. Consider the case when this error was made by your *direct customer*, and you can see it is a mistake. In your border router, you have configured them as a customer. You may have also confirmed it by exchanging BGP Role with the customer [RFC 9234]. The existing ASPA algorithm determines the customer-to-provider relationship by your local configuration and does not pay attention to the immediate customer's ASPA. This is because the locally configured BGP role has precedence and the creation of ASPA is informed or driven by that. So, by using the existing ASPA algorithm, your AS will not flag the customer routes as Invalid due to the above-mentioned error in their ASPA. Is the above fine with you (as the provider)? The advantage is as follows: Say, the customer is in good standing with an established BGP session. They may be stub/single homed AS (a significant % of ASes in the Internet). You have provided connectivity to them over time and then one day they create their ASPA with an error (forgetting to include you). You do not immediately cut them off from the Internet (based on the current ASPA algorithm). Instead, you maintain reachability for them and fix their ASPA error out-of-band. You detect, notify, and help fix the error out-of-band (OOB) by a suitable operational procedure. Only those neighbors of yours who are your provider or lateral peer and doing ASPA will detect the route as Invalid but all other neighbors (including all you customers and their customers) will not be affected by the error and will continue have reachability to your customer and their customers. Of course, when the ASPA error is fixed (hopefully quickly), everyone would be fine. The idea is not to ignore the error in the immediate customer's ASPA. OOB procedures would be in place to help the customer fix it quickly. Also, when ASPA deployment starts to gain momentum, the network operators would likely have automated tools to check their ASPA while they are registering and discover any errors. This could make the probability of ASPA errors negligible or zero. The alternative is for the designers (authors/WG) to bend over backwards and make some substantial changes in the ASPA verification algorithm to strictly go by the ASPA and give it precedence over the local configuration set by you (the provider). The erring customer's routes will be rejected by you. Also, the resulting more complex procedure in this case does not give you a choice to override the ASPA verification outcome and maintain connectivity for the well-established but erring customer. OTOH, if the existing ASPA algorithm is kept unchanged, then the provider still has the option to detect the ASPA error OOB and terminate the BGP session if they wish to use that approach to force the customer to fix the ASPA error. Should IETF specification go the extra mile to have more complex in-band procedures to compensate for operational (or implementation) errors or it is better to have OOB operational procedures to catch and deal with such errors? Sriram
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
