Hi Shunwan, Please see the comments below marked with [KS].
>> 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. >> .... [SW] IMO, this idea essentially solves the problem of ASPA verification. [KS] Please see the previous message I posted on the list. [SW] 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? [KS] p2p relationship is not signed/registered in ASPA. The way it works is... if a hop ASx-ASy is such that ASx has signed ASPA but has not included ASy as a Provider, then that means that ASy is "attested not Provider" of ASx. In turn, that means that ASy is a customer or lateral peer of ASx. [SW] 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? [KS] I don't see it that way. A provider may send any available routes to a customer but lateral peers (p2p) may send only their customer routes to each other. Thank you. Sriram _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
