[ppml] Bogons etc...

[Michael.Dillon at radianz.com]

>Keep in mind though that the idea is to filter "bad" routes, which means
>BGP4 because that's the mechanism they are handled and this is not going
>to change.

No, no, no.
The idea is to publish authoritative information about IP
address blocks. This is the ARIN public policy mailing list
and we don't do route filtering here.

> So an LDAP-based solution would ultimately have to hook with
> BGP anyway.

Precisely why LDAP is better for publishing the directory than
using BGP4. With BGP4 the temptation is there to plug the 
directory right into core routers. With LDAP you would plug 
it into your ticketing system and some human being would
make a judgement on how quickly the changes should be integrated
into your network.

> Given the fact that the LDAP solution would require one more
> box

It does not *REQUIRE* one more box. If you *choose* to run an
OpenLDAP server (or a Zebra server or a BIND server) then you
might also *choose* to run it on a brand-new standalone box. But
you also might *choose* to write a Python/Perl/TCL/Ruby script
that polls the ARIN directory server periodically looking for
updates. 

> and one more protocol that would need to be managed,

If your company is bigger than a handful of people then you
are probably already running LDAP internally. In any case,
nobody adds staff just because they are running another protocol.
Who manages AIM in your company? ICQ? SOAP? XML-RPC? SIP?

> and that the
> LDAP-to-BGP mechanism does not event exist as of today,

The mechanism exists today. It's called Python/Perl/TCL/Ruby
otherwise known as scripting language glue. And even if we do 
decide to retain BGP4 as the publishing mechanism, a prudent
network operator will still integrate it into their network using
scripting glue, i.e. a BGP-to-BGP mechanism.

> please explain
>me what makes the LDAP solution so superior to the BGP solution 
>that it balances the two pitfalls I just mentioned.

It was designed for the job of publishing directories. It's proven
to be scalable to very large global networks. There is a lot more
LDAP expertise out there if you don't count the router geeks and
I don't count them because they are generally not responsible for
maintaining and integrating servers and systems. Oh, and all the 
major scripting languages have libraries that allow you to add
LDAP client capability to any tools you currently have.

--Michael Dillon