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

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

Hi Scott and Lixia,

Here are some thoughts on your new ID.

Overall, I am not confident that such a high-level conceptual
framework as you are trying to make is really going to help us
design better proposals, or forward the debate about the merits of
the current proposals.

We already know so much about the strengths and problems of at least
some proposals - for instance I have critiqued LISP, APT and TRRP,
and many others have critiqued LISP extensively.  So I think our
time is better spent debating these problems and seeking solutions.
 No-one has evaluated or critiqued Ivip in the way I tried to do for
the other proposals.  I think that would be a good use of people's
time and energy.  More on this at the end of this message.


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

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.


Page 2:  I don't that Ivip has much in common with CRIO, compared to
what Ivip has in common with LISP, APT and TRRP.  For instance, Ivip
is much more flexible about where ITR and ETR functions occur than I
think CURIO is.  I don't think CURIO involves any specific mapping
mechanism, yet the mapping mechanism is perhaps the biggest single
engineering problem in map-encap schemes - and the Ivip proposal has
clear and ambitious goals for this.

In general, I got confused with what these terms mean:

   mapping point (Do you mean an ITR function?)

   aggregation point

   endpoint (a host, a destination network?)

   network administrative boundary  (two border routers of separate
                                     ASes connecting?)


Page 5: This sentence I found hard to understand:

  So far the choices are usually either to inform the host, or to
  hide the mapping information from entire networks in TI space.

I agree with your material on extra failure modes with any system
which requires a mapping system.


Page 6:

While this statement may be true to some extent:

  Since end hosts perform DNS resolution before sending packets in
  general ...

This is in the traditional model of Internet communications.
However, P2P applications get their destination host addresses as
pure IP addresses from some other source than DNS.  Likewise VoIP
applications.  Likewise, I imagine, game clients and servers, and
quite a few streaming media applications.  The majority of worm
activity has nothing to do with DNS.

Any solution which requires the mapping to be sent as part of a DNS
lookup requires a major change in DNS - and some really complex and
probably impractical administrative arrangements.

For instance, if I want to control the mapping of some IP address X,
I would need to ensure that every DNS lookup in the world which
returns this address will have my updated mapping information.

This is never going to work, I am sure.

Also, it could only work if the host itself did the ITR function.
It is not good enough that a host could send mapping information to
an ITR and expect the ITR to take it seriously, at least if the ITR
is then supposed to use that mapping for packets sent by other
hosts.  There are all sorts of gotchas in such an approach of hosts
getting mapping via DNS.

Please see my 22 Feb message:

  Hosts modified so DNS lookup also gives mapping to ITR?
  http://psg.com/lists/rrg/2008/msg00452.html


I think it is worth noting that some proposals you discuss are only
applicable to IPv6, including SHIM6, Six/One, GSE and ENCAPS
(RFC1955).

More on the problems with this host <-> DNS mapping approach below.


Page 8:

I have no clear understanding of the phrases: "where to engineer the
aggregation points" and "Mapping Point at Prefix Aggregation Places".

Again, I think this sentence is insufficiently correct to form a
basis for a good solution to the routing scaling problem:

  In today's host implementations, almost all the applications
  perform a DNS lookup to get the IP address of their intended
  destinations.

Even if it was true, I think this is a way-too-simplified notion of
how things really work:

  Thus one can simply piggyback the TAA to which the destination
  network is attached in a DNS reply.

If a hosting company has a web server running virtual servers for 20
customers, each of whom run their DNS (I know they often don't,
leaving it to the hosting company, but ...) then to control the
mapping for this server's IP address, the hosting company has to
have real-time control over the 20 separate authoritative DNS
servers.  This will never happen, for numerous administrative,
security and practical reasons.

Also, the same server could be used for email, game servers, etc.
and be known by many names in many authoritative DNSes.

  Putting the mapping information into DNS is conceptually a very
  simple solution, and has the advantage of avoiding any new design.

Only if the Internet resembled the sort of examples one gives in
introductory lessons.  This idea of getting mapping information sent
to hosts via adding it to DNS responses is so impractical that I
think it should be dropped from this discussion.  The problem of
upgrading hosts rules it out, but my critique shows there are
multiple other concerns which make it nowhere near useful or
practical enough to be considered seriously.


I disagree with this sentence:

   To avoid having to make changes to all end hosts,  all the
   proposed new mapping system designs put it outside the edge
   networks, so that within an edge network everything can run as
   today with no changes.

Ivip's mapping system includes the possibility of pushing the full
database into full database ITRs and Query Servers in the edge
network (as does APT) so it is not true to say that everything in
edge networks must or typically would run with no changes.



Page 10:

   Such a big size imposes limitations on the
   frequency of dynamic changes to mapping entries.

Not for LISP-ALT or TRRP - the authoritative query servers in each
system can change their mapping as often as they like.  However, if
they want the queriers to query rapidly to keep up with the changes,
they would need to set short caching times which would have an
impact on other parts of the system.



Page 11:

   o  At the other end of design spectrum is a pure pull/look up
      model: the initial distributor holds the mapping information,
      and the user nodes or holders pull information when needed.

I suggest adding LISP-ALT and TRRP as examples.

I suggest adding Ivip as an example to the next section.  For instance:

   Ivip pushes the full mapping database to full database ITRs
   and Query Servers located wherever operators choose.  Caching
   ITRs - including ITR functions in sending hosts - pull the
   mapping from the full database query servers, perhaps via one
   or more caching query server.


I don't agree with this:

   Yet another design approach is ALT which pushes paths to specific
   mapping information to users.

ALT is a pure pull system.

By the way, where is "the Handley proposal"?



While I think there are some potentially valuable things to gain
from adopting an over-arching theoretical perspective on this
problem, I think this attempt at a taxonomy has a long way to go
before it is capable of adding anything of value to what I think is
the real discussion here:

  Which of the five current, potentially practical, proposals:

    LISP-NERD  (Actually, it is impractical.)
    LISP-ALT
    APT
    Ivip
    TRRP

  are best?

  How could they be improved?

  Could there be another proposal which is different and better
  in at least some important respects, while still being practical?


I have contributed a great deal of material to this list concerning
real practical matters, and quite a lot of what I wrote has not been
responded to in anything like the depth I think these practical
matters deserve.

It costs time/money to participate in these discussions - and so far
I don't feel it is worth putting a lot of effort into high-level
theoretical matters - compared to improving my own proposal,
completing the series of IDs to document it clearly, and discussing
the practical aspects of the above-mentioned proposals.

  - 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