Re: Generally accepted BGP acceptance criteria?

["Dale W. Carder" <dwcarder () es net>]

Thus spake Tom Samplonius (tom () samplonius org) on Mon, Nov 20, 2023 at 07:02:52PM -0800:
> > On Nov 17, 2023, at 6:58 AM, Christopher Morrow <morrowc.lists () 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