On Thu, Feb 21, 2008 at 5:20 PM, Brian Dickson <[EMAIL PROTECTED]> wrote: > IMHO, the comparison that needs to be made, is PI vs "foo", for any new > thing "foo". Whether "foo" in some way makes use of PA infrastructure > is irrelevant, really. > It is only that we want to substantially limit the growth of PI space, > to those who cannot live without it.
Brian, It will be hard for any solution we come up with to compare favorably with $8k/yr worth of free service. That's what BGP PI amounts to. On the other hand, there are lots of folk today who can't get PI and want it. For them, our solution doesn't have to compare favorably with BGP PI; it need only compare favorably with PA. I make the modest claim that once a non-BGP solution to PI actually exists, we'll find that the core operators' willingness to tolerate giving away $8k/yr worth of free service quickly dries up... pushing the bottom end of existing PI users into a situation where they too must choose between map-encap PI or BGP PA. > DNS lookups will *block* most applications, until the DNS resolution > succeeds or fails. > > And that has perception in user-space, but no impact to the underlying > protocols. > > However, delays *within* the transport regime, are an entirely different > can of worms. > > Unless the transport itself is modified to handle this, I think it's > best to see if we can avoid this. > I think it is a non-negligible issue. If I correctly understand your criticism, it's that an ongoing transport mustn't pause for an expired DNS TTL. I agree and this is addressed in the TRRP document's section on ITRs. > The problem is a spam-like asymmetry. > > The problem with spam is, one party pays (the ISP delivering mail, and > the end user ultimately) for the benefit of another party (the spammer). That is a remarkably insightful description of BGP PI as it exists today. > You've lost me. Without an ITR (or equivalent host stack modifications), > how do I connect to an EID host? > > And if I'm the server operator, why would I do this (switch to EIDs) > unless *everyone* has the same quality of connectivity > reaching me? > > The benefit for deployment needs to be universal, and absolute, not gradual. TRRP's theoretical deployment description starts with two to three ITRs at one service provider. These ITRs get fed by something along the lines of a /16 anycast-announced into the existing BGP system. Folks who can't have PI space now, either they're too small or their incumbent monopoly telco won't announce their prefix, folks who only need it for a handful of servers, get /28's and /29's off this ITR. Their end is simple: a couple DNS entries and a GRE interface on their Cisco router or Linux server. If there is no market for this, TRRP dies. But if there is a market, it grows and a couple other companies sell a similar tunnel service. Then you get a couple companies who decide that by feeding those routes into their own ITRs rather than following BGP to someone else's ITRs they can get a slight edge on their competition. It grows bit by bit, running as a useful addition to the current BGP system until, at some point, one of the large backbone providers decides it's time to stop giving free FIB slots to the /24's. They put out the word: if you're announcing a /24, implement a TRRP DNS entry and a GRE ETR or you're off our section of the 'net. These being ridiculously cheap things to implement (and /24 announcers having a pretty good idea of the sufferance on which they survive), the provider doesn't get a lot of pushback. That provider realizes a cost savings in his router upgrade cycle, an effect not lost on his competitors. The long version is at http://bill.herrin.us/network/trrp-implementation.html . If you have comments along the lines of, "Where did X come from that you first mentioned here," or "What advantage does this individual get from doing the action you state there?" I'd like to hear them. If there is any step which doesn't represent a realistic possibility given the ones before then I need to do more work on it. > This is a "commons" situation, with our goal being to avert tragedy. > > It is one place where market economies will not do anything to help us, > and in fact are likely > to be something we need to be keenly aware of - doing good often flies > in the face of market pressures. Counterpoint: The routing table is only a commons because we choose to treat it so. It's well within our power to assess the cost of a BGP PI prefix, create a payment clearinghouse and create software tools which allow folks to automatically filter prefixes from those who don't pay. Such an approach requires no changes to the routing architecture at all and it handily solves the RIB/FIB size problem. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
