|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: using IRR tools for BGP route filtering
> 2. most large isps aren't going to be happy about config'ing their > routers off of another provider's registry. so, every provider would > in theory need to run their own registry. A fine idea. If I may be permitted to flog a dead horse, the "right" way is to encode RPSL data in the in-addr.arpa or ip6.int tree. > problems: > > a. the independant registries generally store a local copy of the > other registries for config use. this was fine when there were > a few [like ripe, mci, ans] but not so fine when N grows unbounded. > co-ordination could very quickly become a nightmare. Not a real problem. You manage the data in the prefixes that are delegated to you. Coordination is managed as the DNS is managed. > b. who "owns" the local registry/config generator in the ISP? [noc, > install IS, neteng, security?] when its interfacing with customer > databases, responsible for config'ing the entire network, affects > peering, and is a publically accessible server, everyone is gonna > want a piece of it. bureaucracy is great for insuring nothing gets > done. thats assuming the resources [money, people, time] are > available to create & maintain this database server anyway. The folks doing the DNS. Coordinating w/ the other interested parties in the company. > c. uh, who is responsible for "bad" data? remember the 0.0.0.0/0 > object? [followup: why was it put in?] how is this any different > than just announcing bad data? is someone going to verify by hand > all of the data registered? since there is no authoritative 1 to 1 > mapping between ownership and routing, how can it truly be verified? Bad data should only occur if you intentionally spoof the DNS. "Interesting" data in the existing IRR came from a small handful of engineers who wanted to point out weaknesses in the RA policies. If you place the RPSL constructs in the delegation tree, its much easier to track the mapping of delegation & announcement. (There is no ownership here) > > 3. given variances in systems, theres going to be variances in > propgation. remember when ans only updated their router filters twice > a week? but mci was updating once a day? will your customers hold > _you_ responsible if joebob isp decides to only update once > a week? > > > ---------- > > its much easier to attack this problem at the edge, as was pointed out > while i was composing this. verifying and changing filters per customer > is really much better than verifying and changing filters *per peer*. > [per week, day, hour, what?] > > build in safegaurds in the peering agreements, if you must. at some point, > i believe it is cheaper [in terms of resources, politics, and network > flexibility] to trust peers to the extent one can [in either preventing > or resolving issues]. > > and if you can't trust 'em at all? maybe one shouldn't peer with them. > oh, wait. that's another can of worms. but hey, the net changes so fast, > maybe they'll be bought, sold, or vanish next week. > > ymmv. > > _k > > > > > > > > >
|