Job, Nick, Thank you for the inputs.
To be perfectly clear, an UPDATE with an AS_SET will never get a 'Valid' or even 'Unknown' result from ASPA validation. It can only get an 'Invalid' or 'Unverifiable' result. The 'Unverifiable' is considered equivalent to 'Invalid' (Section 5.3) for route selection but differentiated for possible diagnostic use. Definitions: 'Valid' means there is no route leak in the UPDATE; 'Invalid' means a route leak is detected; 'Unknown' means there are missing ASPAs and hence inadequate info to tell if it is Valid or Invalid; 'Unverifiable' means that there is an AS_SET present and the UPDATE would be otherwise Valid or Unknown if we ignore the AS hop(s) involving the AS_SET. For an UPDATE with an AS_SET, the algorithm gives an ‘Invalid’ result if the AS hops not involving the AS_SET point to an Invalid result. But gives Unverifiable result if the AS hops not involving the AS_SET point to a 'Valid' or 'Unknown' result. <Job> In the spirit of RFC6472, any route with an AS_SET in it should not be considered valid (by ASPA-based validation). Yes, this is fine. The algorithm does that. <Job> If the route contains an AS_SET and a covering ASPA object exists for the origin ASN of the route, then the route must be marked with an Invalid status. This seems not well worded. If an AS_SET exists rightmost (i.e., towards the origin), then the actual origin AS in not determinable and hence the first hop (rightmost in the AS_PATH) is unverifiable. It doesn't seem you are suggesting that the presence of an AS_SET should always result in 'Invalid' result for the UPDATE (in the algorithm design). Are you happy with either 'Invalid' or 'Unverifiable' result when an AS_SET is present? In this thread, the only thing I am trying to point out is that if we assume there is never an AS_SET in the middle, then the algorithm description needs somewhat fewer words. In any case, we would be firm about the above-stated design philosophy with regard to AS_SETs. Treating an UPDATE with an AS_SET as always 'Invalid' may be reasonable and simplifies the algorithm description except the diagnostic value of the 'Unverifiable' flavor is lost. Sriram _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
