On Thu, Sep 26, 2013 at 11:07 AM, John Curran <jcurran@istaff.org> wrote:
On Sep 26, 2013, at 4:52 AM, bmanning@vacation.karoshi.com wrote:
sounds just like folks in 1985, talking about IPv4...
If there were ever were a need for an market/settlement model, it is with respect to routing table slots. That's not to say that establishing a framework for externalizing routing costs would be easy; it's a complicated and twisted matter, and also fraught with various legal & competitive aspects.
From my research a few years ago, a reasonable rate would be around 3 to 4 cents per year per advertised route per BGP-carrying router in
Hi John, That's putting it mildly. Establishing such a framework would be an immense challenge. Here are some ideas I've heard: 1. The International Clearinghouse Every BGP participant files with a clearinghouse, specifying: a. How much they charge to carry 1 route b. Whether or not they are a leaf node c. Whether or not they are a transit-free network. Any network which is not transit free must implement a default route which leads to a big transit-free network in order to maintain full connectivity. The BGP participants then publish the exact routes they intend to announce to the clearinghouse and for each one select which networks they'll pay to carry the route. The route must still reach each network via BGP; payment just means that the network won't filter the route out. The clearinghouse then collects payments from everybody and makes payments to everybody, as well as providing each participant a list of the routes that are paid for. Sellers are expected to promptly incorporate new paid routes into their BGP filters. the organization. A couple billion dollars per year if the routing table maintained its current size. 2. The partial routing scenario Large service providers put bids in to the RIRs for the right to announce /8 covering routes for each /8 delegated to the RIR. Each /8 matches exactly one service provider. Smaller BGP system participants make private arrangements with a small (20 to 30) set of networks (including their direct ISPs) to carry their advertised routes through a reasonably redundant number of pathways to (and including) the winning bidder for the /8 they inhabit. For the sake of performance, they may also pay additional large networks to shortcut the traffic towards them rather than let it dump at the /8 advertiser. For the folks you don't pay via the clearinghouse, many end-user systems and the majority of transit systems simply don't carry your route unless yours is among the handful of systems critically important to their customers. Instead, traffic to your network follows the /8 advertisement until it reaches a network which carries your specific route. With the routing costs suitably reduced, settlement for the remaining routes becomes moot. This is usually within a few percent of the routing efficiency that would have been achieved with total route propagation. 3. The routing overlay Establish a semi-stateless tunneling system. Each BGP participant sets up a tunnel ingress node and links a default route to it. Packets for a destination not found in the routing table follow the default route to the tunnel ingress. The tunnel device then looks up an tunnel exit node via a mapping protocol. Both the map server and the exit node have to be hosted on IP addresses reachable via the normal routing table. Having found an exit node, the original packet is encapsulated into a tunnel packet and sent to the exit node. The exit node is in a part of the network that carries an explicit route to the destination. Then, move the definition of threshold size. Except for whitelisted critical infrastructure, /24 advertisements would no longer carry an expectation of universal distribution. To maintain connectivity, folks at the bottom of the chain would need to establish or subscribe to tunnel exit nodes that have a route back to them. With the routing costs suitably reduced, settlement for the remaining routes becomes moot. The IRTF Routing Research Group studied such protocols a few years ago and have pretty well fleshed out how to make one work with all the tangled issues involving path mtu, dead path detection and so on. Multiple designs sit on a shelf waiting for a promise that the technology will be purchased if built. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004