On Wed, Apr 22, 2020 at 2:03 PM Christopher Morrow <morrowc.li...@gmail.com> wrote: > > On Wed, Apr 22, 2020 at 1:32 PM Danny McPherson <da...@tcb.net> wrote: > > > > On 2020-04-22 12:51, Andrey Kostin wrote: > > > > > > > > BCP38 website doesn't proclaim anybody in person to be unsafe, but if > > > it would be possible to make such test it'd be more useful than that > > > RPKI test. > > > > > > BTW, has anybody yet thought/looked into extending RPKI-RTR protocol > > > for validation of prefixes received from peer-as to make ingress > > > filtering more dynamic and move away prefix filters from the routers? > > > > Do you really want those things in soft-state and not with some giant > > operational buffer to absorb all the brokenness that's sure to arise? > > 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 ?