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

From: Scott Brim <[email-masked]>
Date: Sat, 29 Mar 2008 13:28:54 -0400

Lixia and I (primarily Lixia) have just posted a new draft, " A
Taxonomy for New Routing and Addressing Architecture Designs".  It's
at <http://www.ietf.org/internet-drafts/draft-rrg-taxonomy-00.txt>.

Abstract:

   The Routing Research Group is tasked to design a new routing
   architecture to meet the challenges of scalability in face of
   pervasive multi-homing and inter-domain traffic engineering.  A
   number of solutions have been proposed.  This draft describes a
   taxonomy for the design space, and then uses the taxonomy to discuss
   and compare the proposed solutions.

This draft does not advocate criteria or metrics for comparing
performance of different approaches.  Rather, we've been trying to
find a unifying functional description and dimensions for discussion
of all proposals.  It's about "how", not "how well".

This hasn't been easy, and we've gone around on this draft for a
while.  It's an unfinished project and needs group discussion.  You'll
see we list ourselves as editors.

Thanks ... Scott

--
to unsubscribe send a message to [email-masked] 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

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 31 Mar 2008 12:27:25 -0700

I'm so far behind email, just notice this

On Mar 29, 2008, at 10:28 AM, Scott Brim wrote:
> Lixia and I (primarily Lixia) have just posted a new draft,

if the word "primarily" means who's responsible for the errors, that's  
more than accurate :-)

On the other hand, without Scott this draft would not have been written

> " A

I'd also like to add that the current version is rather incomplete.  
There can be design points in the space that we fail to see at this  
time, but we also have not covered completely all the points we know.  
Plan to fill in the missing parts in a revision next week (and  
hopefully also integrate in any comments/criticisms we receive before  
then)

Lixia

---

From: Robin Whittle <[email-masked]>
Date: Tue, 01 Apr 2008 10:58:13 +1100

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

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 1 Apr 2008 22:19:58 -0700

Hi Robin,

thank you very much for your quick review and comments (I sort of knew  
that we could count on you to provide prompt feedback!)
Since I have a few other fires to fight tonight, let me try to address  
your overall comments below first, and get back to you on the more  
specific comments at a later time.

> design better proposals, or forward the debate about the merits of

well, this is one view; there are other views. But we don't really  
need to debate this here.
- I myself have come to see a clearer picture from this writing exercise
   (and I believe it's probably true for Scott too)
- we can just wait and see whether the draft is or is not useful.

> time and energy.  More on this at the end of this message.

I'd mostly agree with the above, though not entirely ;-)
To me the most important thing is "understanding" the various proposals.
That is the goal of this taxonomy draft (I'm not saying it has got  
there).

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.

> ....

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

below is the paragraph that's in the middle of the above two in your  

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

Lixia

---

From: Robin Whittle <[email-masked]>
Date: Wed, 02 Apr 2008 17:51:46 +1100

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

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