Re: [RRG] new draft on " A Taxonomy for New Routing and Addressing Architecture Designs"

[Robin Whittle <rw@firstpr.com.au>]

Hi Lixia,

You wrote, in part:

> In fact I reread your long "critique" msg (dated March 10, 2008 6:42:15
> AM PDT) last weekend, and I wasn't sure our understandings of the
> various proposals are entirely aligned. That's one of the things on my
> list to comment on.
> 
>> On page 1 you seem to indicate that the IPv4 address exhaustion
>> problem has pushed IPv6 to the "front stage".  This may be the case
>> for some or many RRG participants, but it is not for me - and I
>> don't think it is for the vast majority of Internet users or ISPs.
>> ....
>> I think most ISPs and end-users are primarily worried about the IPv4
>> address depletion problem and then a distant second about the
>> routing scaling problem.  I don't know of any end-users or ISPs who
>> are clamouring to switch their operations over to IPv6 so they don't
>> need IPv4 addresses any more - which is the only way IPv6 could help
>> with the IPv4 address depletion problem.
> 
> I moved the above 2 paragraphs together since they seem to be on the
> same/similar issue: the mentioning of v6 is just in passing; we can
> remove it if that helps reduce confusion. The point we were trying to
> make: routing scalability is a fundamental problem that can affect many
> other things (including ipv6 rollout).

I agree with this point.  Its just that your mention of IPv4
shortage moving IPv6 to "front stage", followed by discussion of
some solutions which only work with IPv6 (without noting this), and
with little discussion of those which also work with IPv4, made me
think that you imagined most of the solution to IPv4's routing
scalability and address depletion problems being found in a mass
exodus from IPv4, and into IPv6 without using any IPv4 addresses.

> below is the paragraph that's in the middle of the above two in your msg:
> 
>> I think all the map-encap schemes can assist with IPv4 address
>> exhaustion by enabling the space to be sliced and diced in smaller
>> chunks, down to individual IP addresses, in a much less expensive,
>> more flexible manner - without burdening the BGP system.
> 
> if I understand you right here: so you agree with the draft that the
> map-encap schemes can help routing to scale, even when end users use
> large number of fragmented, non-aggregatable prefixes, right?

It depends on what addresses are actually used.  I have never been
able to understand how the LISP designers envisage their system
being applied.  For instance, is the plan to convert existing PI
end-user prefixes into EID prefixes just for that end-user?  Or does
someone get a big subnet (short prefix), set it up as LISP-mapped
space (with a single BGP advertisement for the whole thing at "Proxy
Tunnel Routers") and then split the block up into hundreds or tens
of thousands of EID prefixes for about this many end-user networks?

With Ivip, there is some flexibility in terms of how space comes to
be Ivip-mapped.  However there is a clear and explicit intention
that the end result is that each block of contiguous space which is
managed by Ivip (a Mapped Address Block) has a single BGP
advertisement (by all OITRDs which support it) and that this is
split into a large number of User Address Blocks (UABs), one for
each end-user.  The boundaries of these can be flexibly changed,
without upsetting the fact that a single BGP advertisement covers a
big block of address space, which supports the needs of hundreds or
thousands of end-users.  It is up to the end-users how to split
their UAB into micronets.

For many end-users, a single IP address is all they need - so their
UAB is a single IP address which is used as a single micronet.

If for some reason Ivip wasn't used, and LISP, APT or TRRP was used
instead, I can't be sure that something like the above would prevail
- but I like to think that over time, people would figure out
something like this is the best way to do it.

So assuming common sense (as I perceive it) prevails, any of the
five map-encap schemes could enable much finer slicing and dicing of
address space and much cheaper, more flexible management of it for
vastly more end-users, with only one BGP advertisement to cover the
space used by a large number of end-users.

It would be possible to use Ivip in a bad way - such as every
end-user brings their own block of address space to the Ivip system,
requiring a different BGP advertisement for each end-user's space at
OITRDs which support that space.  However, I predict that the RUAS
and UAS model I plan would naturally lead to some organisations
supplying large blocks of space, finely divided and leased on
secure, long-term, basis, to end-users large and small.

Also, perhaps more than the LISP team and others, I am imagining
that a lot of end-users - millions of them - will be quite happy
with a single IP address or with just a handful.  Clearly, these are
a different kind of end-user from those who have gone to the trouble
of getting BGP expertise, PI space etc. today.  There aren't and
never will be hundreds of millions or billions of today's kind of PI
end-user.


  Regards

    - Robin


--
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