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

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

On Wed, Feb 20, 2008 at 8:11 PM, Robin Whittle <rw@firstpr.com.au> wrote:
>  If the entire Net changed to add some small delay, then this would
>  not be a barrier to adoption of the new map-encap scheme.  However,
>  as I and others have written, if the new address space performs
>  worse, in a way which really matters to end-users or which could be
>  construed by marketing people as such, then it will be very hard to
>  get widespread adoption of the map-encap scheme.

Robin,

In the unlikely event that marketing folk convince users that a slice
of PA space is better than map-encap PI space, the RIB scalability
problem is solved and our job is done. The reason we're having this
discussion is that folks -aren't- satisfied with slices of PA space
and have been impinging on the RIB in any way they can connive.


>  TRRP has a similar delay problem, which would occur frequently
>  enough to be significant.  The ITR has to sequentially query and get
>  responses from several DNS-like servers in order to find the
>  authoritative server with the mapping information.  Unless you
>  anycast those intermediate servers (which does not scale well) then
>  there will be significant delays in quite a few circumstances.

Few if any of which will have a more meaningful impact than a DNS
query today. The users have spoken clearly on pull-style lookup
delays. Given a choice between reference by name and reference by IP
address, they have consistently favored convenience over the extra
edge in speed.

While none of us has collected direct data on this point, the
circumstantial data is not the slightest bit ambiguous. According to
users' behavior with the DNS, brief lookup delays solely at the front
of a series of transactions are A-OK.


>  This
>  seems to be far worse with IPv6, where each level in the DNS-like
>  hierarchy is a smaller number of bits, and there are more bits in
>  the EID address than with IPv4.

There is no causative correlation whatsoever between IP address length
and DNS lookup depth. Lookup depth correlates with administrative
subdivision which looks no different for IPv6 than it does for IPv4.

This is a factor which is easily tunable at an operations level if
needed to meet the system's speed requirements. The lookup depth is
not bound to the number of elements in the name.
t.u.v.w.x.y.z.dirtside.com only has a lookup depth of 3.
a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.x.y.z.dirtside.com and
0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.x.y.z.dirtside.com
have the same lookup depth: 3. But that's not the end of the story:
you almost always have the first stop (.com) cached, so the actual
experienced lookup depth is rarely more than 2. Should it prove
operationally desirable, a map-pull system can easily accommodate that
degree of flatness in the hierarchy.



>  I argue that the new map-encap space must be equally attractive to
>  large and small end-users, including those with current BGP-managed
>  PI space:

Nonsense. The map-encap scheme must be sufficiently attractive to a
large enough subset of the user base that they're willing to pay for
it to be deployed. No more and no less.

I argue that if you avoid schemes which disrupt "everybody else,"
you'll get much further with a map-encap scheme that well-accommodates
a small subset of the users than you will with one that poorly
accommodates a wide swath.



>  > I can tell you
>  > without reservation that one-size-fits-all never does.
>
>  Ah yes, but many folks are establishing their nook in the Net with
>  the intention of growing enormously.  We need them to adopt
>  map-encap space - which means they need to be confident it will
>  still the best arrangement when they are bigger.

No fundamental character of map-encap requires this. TRRP has no such
requirement inherent in its architecture. It doesn't require wide
adoption to begin delivering valuable results. Indeed, the theoretical
deployment timeline shows it producing valuable results with only a
handful of users.



>  > 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.
>
>  This might work to some extent, but not if the price of BGP-managed
>  PI space comes down.

If the price of BGP-managed PI space comes down, the problem is solved
and we can all go home. The assumption we're working under, correct or
not, is that fundamental limitations in the technology will cause the
cost of BGP-managed prefixes to level off in a log-normal fashion at
some price which is still too high for the kind of granular
multihoming and mobility that you and I desire.

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