Thus spake Tom Samplonius (t...@samplonius.org) on Mon, Nov 20, 2023 at 07:02:52PM -0800: > > On Nov 17, 2023, at 6:58 AM, Christopher Morrow <morrowc.li...@gmail.com> > > wrote: > > IRR filters provide control over whom is provided reachability through > > a particular peering/path. > > How does that work? IRR import: and export: parameters are poorly > implemented. Is anyone actually validating more than the origin with IRR?
I think "validating" is the wrong verb for IRR. "Provisioning" may be more accurate. As an example, my AS293 peers with AS6509. In the AS-SET that they publish, AS6509:AS-CANARIE, the "members:" field for instance lists AS271:AS-BCNET-MEMBERS which then lists AS271 in it's members. An inverse query to an IRR whois server from such a tool as 'bgpq4' walks this tree to generate a list of prefixes applicable to in effect, a given path presuming you know what IRR object to start with. That is where import/export typically comes into play. RPSL's 'import:' and 'export:' (and the mp-variants) are problematic at best to use programmatically. Our provisioning system for example doesn't bother and uses the IRR object specified in PeeringDB for filter generation by default. Dale
