On Wed, Feb 20, 2008 at 8:00 AM, Robin Whittle <[EMAIL PROTECTED]> wrote: > > By hybrid, I mean a system where the shorter, typically PA > > prefixes continue to be routed via BGP as they are today while > > the longer, frequently PI or TE prefixes are shifted to > > map-n-encap as driven by the system's economics. > > OK - this means the map-encap address space does not completely > replace conventional BGP-managed prefixes. However I am confused > with your use of "PA", "PI" and "TE" here.
Hi Robin, Provider Aggregatable prefixes tend to be short enough that the economics of the current BGP system make sense. Further, everybody who wants to announce a PA prefix already can and does. If it ain't broke, don't fix it. Provider Independent and Traffic Engineering prefixes tend to be longer and there are more of them putting pressure on the system. Worse, engineering an anycast service on a single IP address or providing provider independent space for a small number of servers can't be done at all because of the filtering cutoffs that were necessary to keep the system stable. This is where the system is failing us, ergo this is a part we need to fix. > > I disagree and I'll tell you why: given the option to reference > > subservers by DNS name or by IP address, web site designers have > > overwhelmingly chosen to reference them by name and accept the > > extra lookup delay. This is the preference that the operations > > folk have clearly demonstrated to us with their actions - that on > > initial access to a server, a mild lookup delay is acceptable for > > the sake of convenience. > > OK. Renumbering a bunch of web servers also means having to alter > the records in a bunch of nameservers - not all of which would be > controlled by the hosting company. Yes, this is among the many reasons why provider independent space is such a desirable thing. My point was in a different direction: content publishers already tolerate delays on the same scale as the difference we're talking about between push and pull. They tolerate these delays today solely for the sake of their developers' convenience. There is simply no data to support the conclusion that they wouldn't tolerate the same character and scale of delay for the sake of their system administrator's convenience. The notion that a pull-based map system will necessarily be too slow ain't nothin' but a theory and the theory is both unsupported by any data and apparently contradicted by some of the data that is available. > > If you're placing a /18 on the 'net, we > > can easily accommodate you with the hardware that's already > > deployed, let alone with hardware currently shipping. > > I think you are saying that larger end-users might as well use the > conventional techniques we use today - a BGP advertised prefix. Yes. The worldwide cost of one advertised prefix works out to something in the neighborhood of US $8000/year and falling. The system is only broken for prefixes whose value is less than that. > If map-encap space had deficiencies, such as frequent delays in > initial packets, then the big end-users (who have a choice whether > to adopt it or not) would avoid it like the plague. Only the > smaller end-users, who can't afford or justify one or more /24s of > conventional BGP-managed PI space, would be choosing map-encap space > - because they have no other option. This is a bad thing? As an (er hem) larger gentleman, I can tell you without reservation that one-size-fits-all never does. > Large companies with PI, small with map-encap space? I would put it differently. Just 'cause I can't afford a Porsche doesn't mean I care to ride the bus. Bare BGP prefixes for those who cough up the cash. Map-encap for those who value it less but still want something that isn't as ghetto as slices of PA space. 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
