Re: [RRG] Re: Map-encap space for "server" vs. "client" end-users?

["William Herrin" <bill@herrin.us>]

On Wed, Feb 20, 2008 at 8:00 AM, Robin Whittle <rw@firstpr.com.au> 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 herrin@dirtside.com bill@herrin.us
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com 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