Hi Nick, >Apart from the deprecation in rfc 6472, there's also rfc6907, which has >a complex set of rules for handling routes with an origin which is an >AS_SET. This complexity is already not good, and of dubious practical >use. Replicating something similar to this in ASPA seems like a bad >idea overall.
I am impressed and pleased you looked into rfc6907! Actually, as you know, rfc6811 is what is implemented in routers currently. And rfc6907 only enumerates use cases. I just looked at all the use cases involving AS_SETs in rfc6907 and they are completely consistent with rfc6811 or vice-versa. I hope my previous post responding to your and Job's comments is helpful. It clarifies the design philosophy with ASPA which follows parallel principles as in RFC 6811 except for the addition of 'Unverifiable' outcome in the ASPA algorithm with potential diagnostic value. >The current approach in -09 of marking the route as Unverifiable seems >reasonable. 5.3 states that "Unverifiable" SHOULD be treated as >semantically equivalent to "Invalid". >So yeah, why not just mark as "Invalid" and be done with it? Like I said in the previous post: 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. But if you feel strongly about this, the authors team can discuss this and get back. Thanks again. Sriram _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
