[ppml] "Recommended Practices" procedure

[Owen DeLong]

>>>> The way out of this mess is a BGP replacement that could
>>>> handle large-scale PI.
>
>>> BGP isn't the issue and devising a replacement for BGP
>>> doesn't attack the fundamental problem.
>
>> Correct.
>
> Wrong, wrong.
[snip]
> It's not a BGP problem you said?
>
Correct... It's not a BGP problem.  BGP is how we trade routing information.
Today, BGP trades prefix data and AS PATH data.  If we find a way that IDR
can be done strictly on AS PATH, then, we can take most of the prefixes
out of BGP and leave all the AS PATH data there, and, BGP hasn't changed.

The problem is not BGP... Yes, some possible solutions involve changing
BGP.  Other possible solutions involve changing the way we use BGP.

>
> The bottom line is: keeping BGP as-is has the same appeal to router
> vendors as PA-only has to established operators. Keeping BGP as-is is
> the guarantee that there will be a need for updates as the routing table
> grows. That's why now they're lobbying to exhume unproven/never deployed
> ID/LOCs from the grave instead of working on a scalable version of BGP
> that could also have features such as secure interface to the RIR's
> databases so we could filter bogons and prefix hijacks right of the bat.
>
Sure.  In the long run, a modified BGP or new routing protocol will be
required.  However, in the short run, I think we can use existing BGP
in concert with a scalable solution which will buy time to do the
changes to the routing protocol for later optimization.

>
>> IETF is definitely not ignorant, but, it is
>> overweighted with vendors
>
>> <vaf at cisco.com>
>> BGP isn't the issue and devising a replacement for BGP
>> doesn't attack the fundamental problem.
>
Vince and I actually agree about this.  This is rare, but, he and
I actually agree that ID/LOC split is the only viable long term
solution that has been presented.

Owen


-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060501/581862b6/attachment.sig>