In general, I don't like the idea of using an extcomm community to convey a prefixes validation state, I think we should deal with this problem natively (e.g., as BGPSEC inter-domain) if we're going to address the problem, in particular if we're not going to address the AS Confederations problem.
Furthermore, I don't like the deployment considerations, in particular because of "privilege escalation attacks" which could easily occur through misconfiguration across multiple attribute mapping functions, or simply because the extcomm was received from an BGP peer that isn't "upgraded to support the extensions defined in this document": "In deployment scenarios where not all the speakers in an autonomous system are upgraded to support the extensions defined in this document, it is necessary to define policies that match on the origin validation extended community and set another BGP attribute [I-D.ietf-sidr-pfx-validate] that influences the best path selection the same way as what would have been enabled by an implementation of this extension." Finally, this should certainly a normative reference in the pfx-validate draft. -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
