apologies for the encrypted email, pgp acting up.. --- pardon my ignorance, as i may not have the experience _most_ of you do in the SP community.. but, why wouldn't something like formally requiring customers/peers/transits/etc to have radb objects as a 'requirement' for peering/customer bgp services if you are a new customer and you sign up for bgp, it is clearly stated in the contract, the customer/provider requesting this service must maintain objects radb.. in the install process, if the customer does not have radb objects, bgp sessions remain shutdown until the provider verifies this and generates filters with rpsl tool same goes for peers.. if you don't require contracts as not all networks do, just require irr /radb objects, this one may be more of a pain, but thats why we go to scripts and automation.. maybe some more work would need to be done to ensure proper ownership and delegation of number resources in radb, but i dont think that would be so difficult, would it? if larger networks adapted to something like this, i think people would start to follow, as they would have no choice because they would be cut off from certain routes christian On Thu, Aug 14, 2008 at 11:34 AM, Christian Koch <christian@broknrobot.com> wrote:
-----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.8 (Darwin) Comment: http://getfiregpg.org
owFdVAtsFFUUbRdaZRIoQfkUxLzwaRHWbgtIC0RA8YNfsEBAIJTZmbe7r52ZN857 s8tWgSIoUiqoAUUQlE8aAxYrgUpbqKCQEotSykeCKRLoR2qBQspXqN43uy3iJvub ue/cc849dz7q2inGFbtZH3r58It/SbFFnZd5E9OGp2WkD89IHT1iZPoon9/0Z3Hd fIFoeNLWKR+bsqVSA+lhRPwGtWRDwW4kM0SQLoeRQTkKyEGMeAAjPN/EFsFQgbJ0 yngWoj4UpjZSqUQMpwRNnYIUquu2QXg4JUWSvDZ3o1AgjELU1lQjmSNGdcwDxPAj jeRg5KOWLmtaGFn4LZtYcF1SbMahyGIeE4tPDqwY4cyDuYI4jRCyZNWLqDcbK5wJ vjJKjiBgHRs8WQJcJI4DoKcdEHn9JmLYChIFM0kiEfayheG0gUOoo042VOcWA0+Q bQqS4qwbEY4IQ4qGZUsLS4zLHKsoql2hBjBVQK/zL4rlMS0aJCqACnqYcaEc9LN2 IpIOlWA2MTi8OyQJfcLAKDgxoJmmIUAD7gyY+B5oAzPA7P64/uuOW4rIZoxQA4Cx 6IVYwOYqDYE8gxPNwepgGgTbfATwHJ5ghuTHBrZALEM+onEYCgoRHkCWyeAopZok MVnHyC9ItDvPUlIQaQ+ImHx0Ph1GOXMTlEGYZGAeolYOg1o3yhaWtJcTy0KeBwRF eFEDOxn1wheFOgijLJmgzY0gdVAjQwcneoKYCA5TLGJyRxGSbfBN5mAJ0JQkAAIc kc0ImOASySwkA2YMp+G+KnrCT2ww23IMg41A4CKoDRBTEsAq1rDfARaMDFv3OrNn 1LZgciIsQkuEIxGIgioxchzCUqSlQwWpxOcjiq2JDXIuEz7eSa0mW34A7bBMVmWT R0j+b7uEUZCVaAcTU1PD0R6QJ4uLIz6qaTTkLD2kILqpkRgZFCkBCiEFRopsM1hw UXKfpQIiqM+HfBbVkYItJ8IWtbnYLyVgEci7bEjwWu56rHNMrCsmPs4lHjsxUpfu 7U+p2pXdY75SFkw+sun0cy1fr8lM/nxYy8XqtsqB42d7PIfVYxcaugz+YntLQlLL kJwjeyuaTTm9sltXd9PBM32nHm1a96d747WaksYt+/6+caX+6oTzK0mBJOUdLFnU q/fD5rvo6MWGTzJLty8Z8PLc87HNavbapJrcn/tfdI2cdS63Z1v5zSmZcROWZyT0 Oj33UlvtvYlLdi3Ox+xkuPX4zpl3d1c9m/HmjTv6zazc1Y2XTzTUlI1uXVx6+OSq 4s+qV2zdv35m0TjfvarypfUHnnu6esGovWOK59zZU53Xv++oc0m329K7zPhDrs3O rnlm4uC6hvz0D07FVaQeK/zuajCnZMSXiSvrfqnaOzmp6PrQ+cWDzu6c/cqR3AsD 4u9OOr79UM9riwt6lO7Zb259Ku/x0etKEwb3PacU9tbDtn0w0A03DfNuejVYeaso Z/rYK7OW5GZe/SF/w+59q6f1KziwZmBqn22tg25nTGupO3PiypyU4K45aYGCIWWP bk4oWVRc2Hxt16eb0/plNZsnvlk7fE1i2q1izyOX3rlZGfj2cn3F1NCCspcS/Xzc 6t/jY8sXxldU9yx86P15bzTX//jkoaE/uV6L37cjY9l7qQs7xbW2VpV5l45Z9XZt UfeJeuPrfda6zuaFq3L92+zG8tRt10/N80+/x71jd1yy19ecbdqy7vtFckz6zBnm 6X+S5i37sFeP5/NPbazb0Gnhiid8v/72Lw== =TITY -----END PGP MESSAGE-----
On Thu, Aug 14, 2008 at 11:03 AM, Randy Bush <randy@psg.com> wrote:
ok, i can not hold my tongue. sorry.
might there be a formally rigorous approach to this problem? we keep having it. perhaps there is something solid and real we could do, as opposed to temp hack after temp hack.
randy