nanog mailing list archives
Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size)
From: Scott Brim <scott.brim () gmail com>
Date: Thu, 26 Sep 2013 17:05:02 -0400
Oh this sure will be fun. For a good time, see how GSMA handles connectivity with IPXs. On Sep 26, 2013 1:28 PM, "William Herrin" <bill () herrin us> wrote:
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 iswith respectto routing table slots. That's not to say that establishing a framework for externalizingrouting costs wouldbe easy; it's a complicated and twisted matter, and also fraught withvarious legal &competitive aspects.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. 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 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
Current thread:
- Re: minimum IPv6 announcement size, (continued)
- Re: minimum IPv6 announcement size bmanning (Sep 30)
- Re: minimum IPv6 announcement size bmanning (Sep 26)
- Re: minimum IPv6 announcement size Ben (Sep 30)
- Fwd: minimum IPv6 announcement size Alexander Neilson (Sep 30)
- Re: minimum IPv6 announcement size Valdis . Kletnieks (Sep 30)
- RE: minimum IPv6 announcement size Lustgraaf, Paul J [ITNET] (Sep 30)
- Message not available
- Filter-based routing table management (was: Re: minimum IPv6 announcement size) John Curran (Sep 26)
- Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size) William Herrin (Sep 26)
- Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size) Randy Bush (Sep 26)
- Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size) John Curran (Sep 27)
- Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size) Scott Brim (Sep 26)
- Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size) William Herrin (Sep 27)
- Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size) Steven Bellovin (Sep 28)
- Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size) Blake Dunlap (Sep 28)
- Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size) John Curran (Sep 30)
- RE: minimum IPv6 announcement size Steve Bertrand (Sep 24)
- Re: minimum IPv6 announcement size Nathanael C. Cariaga (Sep 24)
- Re: minimum IPv6 announcement size Nurul Islam (Sep 24)
- Re: minimum IPv6 announcement size Nathanael C. Cariaga (Sep 24)