Christopher Morrow писал 2020-04-22 14:05:
a question about the data types here... So, a neighbor with no downstream ASN could be filtered directly with ROA == prefixlist-content. A neighbor with a downstream ASN has to be ROA (per asn downstream) == prefixlist-content.
So you'd now have to do some calculations which are more complicated than just; "is roa for this prefix here and valid" to construct a prefix-list. correct?
Sorry, and this sidesteps the intent of the peer as well. For instance you may have a peer with 2 'downstream' asn, only 1 of which they wish to provide transit to you (from you?) for... how would you know this intent/policy from the peer's perspective? today you know that (most likely) from IRR data.
is your answer ASPA / AS-Cone ?
ASPA/As-Cone is a concept about whole as-path verification afaik, but I may be mistaken. ROA validation prevents hijacking but doesn't prevent route-leaks. If my transit providers already do ROV, effect of doing it in local network will be limited to direct peers only and expected to be considerably small. For route-leaks prevention we still have to rely on IRR and filters configured directly on routers. Maintaining filters on routers is quite intensive task and they took a lot of space in the configuration. Adopting validation or similar mechanism for it could make it more dynamic and less resources-consuming. Or maybe I'm trying to invent a bicycle? Kind regards, Andrey