Subject: [RAM] An attempt to summarise the "Traffic Engineering" discussion so far

From: Pekka Nikander <[email-masked]>
Date: Tue, 2 Jan 2007 21:29:29 +0200

Having read through the various sub-threads in the "TE" discussion,  
and re-read about 15 messages that seemed to have the most informed  
content to me, I'm foolishly trying to summarise what I see, with an  
architectural twinkle in my eye.  I hope this helps the community.   
However, before going to that, I really recommend people to re-read  
Elwyn's recent and very good analysis on how TE and multi-homing can  
be viewed as a single phenomenon:

   http://www1.ietf.org/mail-archive/web/ram/current/msg00102.html

At the same time I would recommend people to remember that Elwyn's  
analysis is only one way of looking at the problem domain; it can  
also be divided in a few other ways.

A brief and (hopefully) balanced summary:

One main theme was mostly concerned about the costs (hardware/ 
software/administration), with a few folks arguing that because of  
this any solution that mandates (as a non-optional feature) multiple  
globally routable IP addresses to each multi-homed host is a non- 
starter.  This argument was countered by splitting the identifier and  
locator roles of addresses and arguing that the costs will not be  
that big since the hosts will still have just one identifier.

A second overall theme cornered around who (which node) should have  
the control over path selection.  Obviously, the operators and folks  
with experience on TE and complex site multi-homing abhor each host  
being empowered to do the decision.  Almost as obviously, people  
working with mobile hosts with multiple radio interfaces consider it  
natural that hosts make the choice between the interfaces.   
Architecturally, there seems to be different kinds of path selection:  
one kind that Elwyn excellently described in his note, and another  
kind that is more related to mobility and hosts or sub-networks that  
are both mobile and multi-homed.

A third theme considered whether there should be only one multi- 
homing solution, or perhaps many of them.  Towards the end of this  
theme, it was suggested that perhaps there could be an architectural  
solution that could be implemented in a way that would fit both large  
and small multi-homed sites.

A more detailed and slightly opinionated summary:

The discussion was started by RJA's request to the operators to  
enumerate the ways TE is being used:
http://www1.ietf.org/mail-archive/web/ram/current/msg00123.html

 From there on, the discussion seemed to converge to pretty  
opinionated message exchange around the following topics:

1. Embedding of today's IP addresses in ACLs, firewall rules, ASICs  
that implement them, etc.

The crux of this argument seems to be that adding multiple globally  
routable IP addresses to each host at large multi-homed sites  
multiplies the related hardware and software costs.  The counter  
argument is that with a properly implemented identifier / locator  
split, it is the identifiers that are stored in ACLs, firewall rules,  
etc, not the locators.  Consequently, there is no additional hardware/ 
software cost here.

The main caveat here is "properly implemented".  Firstly, that may  
require adding (soft) state at the filtering devices, if the packets  
only carry the locator or if the identifiers are encrypted.   
Secondly, depending on the solution, the administrative costs of  
upgrading the information from current addresses to future  
identifiers may become a major upgrade barrier.

I think Noel summarised this thread nicely here:
http://www1.ietf.org/mail-archive/web/ram/current/msg00169.html

Marcelo added nicely some details about the implementation and state:
http://www1.ietf.org/mail-archive/web/ram/current/msg00178.html
http://www1.ietf.org/mail-archive/web/ram/current/msg00193.html

Finally, Roland added some (IMHO) very important thoughts about IDs  
and privacy:
http://www1.ietf.org/mail-archive/web/ram/current/msg00211.html

2. Troubleshooting, help desk, and other similar problems related to  
multiple IP addresses.

Even if there was an id/loc split in place that relieved the above  
burden from filtering and other configuration, having multiple  
locators per each host may still cause additional cost in  
troubleshooting, help desk, etc.  The counter argument is that with  
proper tools (which of course don't exist yet) the costs may be  
pushed back to their current levels.  Additionally, depending on the  
types of the identifiers, the IDs may be engineered to further help  
troubleshooting.

http://www1.ietf.org/mail-archive/web/ram/current/msg00160.html

3. Problems with botnets

I think Marshall Eubanks noticed this potential problem first, but  
opinions differ whether this is really a problem or not.  Basically,  
the claim is that if hosts have multiple globally routable IP  
addresses, botnet operators would benefit since they would have more  
control on how to route the traffic when leaving the individual  
bots.  The counter arguments include that many hosts will anyway  
include multiple addresses since they will have multiple interfaces  
and that simple source address selection does not equal with full  
path selection.

http://www1.ietf.org/mail-archive/web/ram/current/msg00154.html
http://www1.ietf.org/mail-archive/web/ram/current/msg00164.html

4. Who is trusted or empowered to do path selection

A central issue in the discussion seems to be whether path selection  
should be done in hosts or in routers.  Some people argue, apparently  
validly, that there are installations where it is practically  
impossible (given today's technology) to do it in the host, and would  
be a waste of resources anyway.  Igor's message outlined it pretty  
nicely:

http://www1.ietf.org/mail-archive/web/ram/current/msg00145.html

Later on, Roland made some important points:

http://www1.ietf.org/mail-archive/web/ram/current/msg00195.html

To me, there seems to be an underlying issue which perhaps didn't  
come out properly in the discussion so far.  Namely, there is only a  
relatively little amount of dependency between where the path  
selection is done *logically* in the host or not, and whether is is  
done *physically* in the host or not.  Even in the case that hosts  
were logically empowered to do some part of the path selection by  
making them logically visible through several distinct globally  
routable IP addresses, that functionality can be delegated to the  
network.  The solution smells and looks a little bit like NAT, but so  
what any solution that rewrites the address fields in the IP header.   
Personally, I tried to make this distinction clear in my other  
message (which is not in the Web archive at this writing.)

A perhaps even more fundamental problem is related to trust: who is  
trusted to make the path selection.  This was not taken up directly,  
but the botnet thread was clearly related.

W.r.t to SHIM6 in this respect, David Conrad explained the history  
succinctly:

http://www1.ietf.org/mail-archive/web/ram/current/msg00177.html

As a response to that, the details of how to make SHIM6 into a proper  
site-multi-homing technology, where the locator selection is done as  
a site-wide function and not in individual hosts, hasn't really been  
worked out.  But IMHO they could.

5. Do we need multiple or just one solution

A larger part of the discussion seemed to circle around whether we  
could live with just one solution for multi-homing, or whether there  
should be separate solutions for "large sites" and small, SO-HO type  
sites.  Obviously, some effort was spent (in vain) to define where  
the border line would be.   In the end, Noel suggested that perhaps  
there could be an architectural solution that would fit into the two  
different sets of requirements through differently engineered  
implementations:

http://www1.ietf.org/mail-archive/web/ram/current/msg00234.html

--------

I'm sure I missed some threads; sorry for that.

--Pekka Nikander

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Peter Sherbin <[email-masked]>
Date: Tue, 2 Jan 2007 19:05:10 -0800 (PST)

This is a very good summary. For the new architecture please consider the following:
1. Internet shall scale on a hard-surfaced body of any size (physics permitting) and
in space
2. The urgent task in space is to network/monitor neighboring asteroids
3. Other tasks require networks on Moon and Mars (with no ISPs or easy cabling)
4. Even with 2/3 under water Earth still is a fair testing ground for the Internet

Thanks,

Peter

> I'm sure I missed some threads; sorry for that.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com