Hi Sriram and all, > 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?
[SW] IMO, this idea essentially solves the problem of ASPA verification. Regarding "The RS client also includes in its SPAS/ASPA any AS with whom it connects in the control plane via the RS.", is this equivalent to sign the AS pair of the P2P as-relationship to the ASPA database? Back to Section 5.3, it said "A route received from a RS at IX has much in common with route received from a provider." Actually I also think that "A route received from P2P BGP neighbor has much in common with route received from a provider. (for ASPA validation purposes only)". Does this seem reasonable? Thanks, Shunwan > -----Original Message----- > From: Sidrops [mailto:[email protected]] On Behalf Of Sriram, > Kotikalapudi (Fed) > Sent: Tuesday, March 15, 2022 11:34 PM > To: Nick Hilliard <[email protected]> > Cc: Ben Maddison <[email protected]>; [email protected]; > [email protected] > Subject: [Sidrops] ASPA and Route Server (was RE: [GROW] 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 > > _______________________________________________ > Sidrops mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidrops _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
