I think a correction is required. Instead of what was said before - #1: An RS client of an RS (transparent or not) includes the RS AS in their SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with whom it connects in the control plane via the RS.
only the following simpler statement is required in the draft: #2: An RS client of an RS (transparent or not) includes the RS AS in their SPAS/ASPA. The reason is as follows. Consider the following topology and Update flow per arrows: AS1 (RS Client) -----> AS2 (RS) -----> AS3 (RS Client) ---p2p (lateral peer) ---> AS4 (validating AS) AS4 is the receiving/validating AS. Regardless of whether the RS inserts its ASN in the AS path or not, the Update is Invalid (route leak) at AS4. Because once the Update transitioned to a downward path after the RS, it cannot be subsequently sent to a provider or lateral peer. But with #1, the Update will be evaluated as Valid (not route leak) by the ASPA verification procedure in case the RS is transparent. But with #2, the Update will be correctly detected as a route leak (whether the RS is transparent or not). Explanation: With #1, the hop AS1-AS3 in the transparent case is evaluated as Valid (C2P) (as part of an ascending up-ramp on the left) by the procedure and that is not good. I.e., the detection of the apex in the AS path at the RS (not visible in the path) and inversion (non-upward flow) after the RS is obscured with #1 (in the transparent case). However, with #2, the hop AS1-AS3 is evaluated as "attested not Provider". That means that the detection of apex/inversion at the RS (though not visible in the path) is effectively not missed out by the procedure with #2. Thank you. Sriram -----Original Message----- From: GROW <[email protected]> On Behalf Of Sriram, Kotikalapudi (Fed) Sent: Tuesday, March 15, 2022 11:34 AM To: Nick Hilliard <[email protected]> Cc: Ben Maddison <[email protected]>; [email protected]; [email protected] Subject: [GROW] ASPA and Route Server (was RE: [Sidrops] IXP Route Server question) Nick (and all), I was also rereading/reviewing Section 5.3 and had similar thoughts about the two options you outlined. As you noted, "the approach in Section 5.3 gives a workable outcome". However... >... the RS should be treated as a provider by the rs client; the rs client >should include the RS ASN in its SPAS; the rs client should evaluate ASPA as >if the RS ASN were included in the path; the rs should evaluate clients as >customers Yes, I agree that "the rs client should include the RS ASN in its SPAS." Alexander and I have talked about this, and he mentioned that this would be added to the draft. Yes, I also feel that it is a better option that the RS client adds the ASN of the transparent RS to the AS path (for ASPA validation purposes only) and applies the downstream ASPA algorithm. Algorithmically this seems more appropriate. This is also better from a diagnostics point of view (if the need ever arises) because in this approach the relevant ASPA is used for validating the hop from the AS just before the RS to the RS. That said, I think there is a bigger issue about transparent RS in the middle of the AS path. Maybe this is what Ben's question was hinting at. I think you are also raising this issue when you say: >RSs do not partake in traffic forwarding, so they are not part of the data >path between two ASNs; they're only part of the signaling path between the two >ASNs. This is a useful hack from a practical point of view, but it causes >algorithmic breakage in places which assume congruency between the data plane >and the signaling plane. One of these places is AS path verification. > ....ASPA verification should proceed as if the two rs-client ASNs were > directly connected and each should treat the other as a provider Based on the above observations from you, I am proposing the following: An RS client of an RS (transparent or not) includes the RS AS in their SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with whom it connects in the control plane via the RS. The idea is that a path segment ASx-RS-ASy (where ASx and ASy are RS-clients connected in BGP via the RS) will be always verifiable with this proposal whether or not the RS is transparent. If the ASPAs are created by ASx and ASy per the proposal above, then the ASx-RS-ASy segment will be evaluated as Valid in either direction. I think this proposal in conjunction with other ideas discussed above takes care of both transparent and non-transparent RSs in the ASPA verification algorithms. Does this seem reasonable? Thank you. Sriram _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
