[ppml] "Recommended Practices" procedure
Owen DeLong
owen at delong.com
Tue May 2 02:58:15 EDT 2006
- Previous message: [ppml] "Recommended Practices" procedure
- Next message: [ppml] "Recommended Practices" procedure
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>>>> 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 : http://lists.arin.net/pipermail/ppml/attachments/20060501/581862b6/attachment.bin
- Previous message: [ppml] "Recommended Practices" procedure
- Next message: [ppml] "Recommended Practices" procedure
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list