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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
