Subject: RE: WG next steps

From: [email-masked] (Sean Doran)
Date: Wed, 13 Nov 2002 23:28:22 +0000 (GMT)

Tony Li writes:

| I must disagree with my esteemed colleague.  The routing research
| group would be the appropriate place for this, and there is no
| visible progress there.

With respect, both parts of the second sentence above are wrong.

The IRTF RRG has deliberately avoided trying to "fix" IPv6 routing,
because that was being undertaken as IETF *engineering* work, and
because we have been aiming for a new routing system that is independent
of layer 3 frame type (i.e., not just for v4 or for v6 or for a v4/v6
dual-protocol network).  

If the IETF cannot engineer a solution to IPv6 multihoming, then
certainly, IPv6 routing *research* could be done as a subgroup
within the RRG, just as is research on micromobility.   We have
not yet reached that point.

I think that there is no consensus yet that the IETF should abandon
the engineering effort; I see no reason to believe that declaring
the problem research rather than engineering does anything other
than substitute organization name rather leaving the same people
and the problem in place; and I personally would not like to drive
the effort into the IRTF RRG until there is a much more obvious I*
consensus that that is where it belongs (or that it would make a difference).

Most importantly, the RG work will in general be much more about
architecture and generality, rather than the design of specific
protocols and practices, which should be done within the IETF.
IPv6 is a suite of extant protocols and practices, and the
discussions on requirements (such as they have happened) have
not yet gone beyond approaches faling into roughly three categories:

	-- changes to/extensions of existing protocols & practices
	-- new couplings of different protocols/practices defined elsewhere
	-- entirely or effectively new protocols/practices
	   of which there are roughly two subcategories:
		-- those which are based on known behaviours
		   or subject to ready analysis or implementation experience
		-- those which are not

The very last set has been touched on in different ways by Ran Atkinson
and Eliot Lear, and now by you.

I'm sure my various co-chairs and I would be amenable to helping
deal with that set of solutions, however there is NO clear consensus
that that set of solutions contains the only workable one(s).

	Sean.

---

From: "Tony Li" <[email-masked]>
Date: Wed, 13 Nov 2002 16:28:51 -0800

|   But is there a different way to get coherent, 
|   self-consistent proposals
|   on the table? Much of what we've seen on this list the past 
|   weeks has
|   been very interesting, but never concrete enough to really 
|   do anything
|   useful with, other than generate ideas or measure it 
|   against everyone's
|   individual idea of what the IP architecture should look like in the
|   future.

Sure.  First, we take an idea and discuss it.  We get consensus on 
the idea.  Then, we have someone go write up text on it.  We get 
consensus on the text and insure that it represents the idea.
Then we move on to the next issue, either laterally or digging deeper
down.

|   > This is the way that the IETF *used* to work and it certainly made
|   > more progress than we seem to be making now.
|   
|   Sounds good, although first trying to get a better picture 
|   of the new
|   architecture might not be a bad idea either.

Using this process, you start with the architecture and then iterate.
It allows us to leverage the writing skills of everyone in the group,
plus all of the brainpower assembled, and it avoids most of the high
ego situations.

Let me point out that if we continue the way that we have been, we'll
not make rapid progress, as we've seen.  This at least, will be a
change.

Tony

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 14 Nov 2002 20:34:24 +0100

> There are really two classes of solutions. I would 
  > categorize them as
  > "host multi-homing and network multi-homing".
  > 
  > The network multi-homing solution assumes that a network 
  > gets several
  > providers, and that the routing fabric somehow manages to 
  > make all these
  > providers behave as one. In the current architecture, the 
  > network gets a
  > single prefix, and the impact on the DFZ could be immense. 
  > 
  > The host multi-homing solution assumes that the host has 
  > several network
  > providers, and that these providers are not in any way aware of each
  > other. For example, a host may have a GPRS connection to 
  > ATT wireless
  > and a DSL connection to Earthlink. In the current 
  > architecture, the host
  > gets different addresses from the different providers. 
  > There is no DFZ
  > explosion, since each of these addresses gets aggregated in the
  > provider's prefix. The main impact is on the host software. Today we
  > have at least a partial solution, with the address 
  > selection rules; we
  > could combine that solution with a variation of Mobile IPv6 
  > for better
  > resiliency.

=> This is exactly my understanding too.

  > 
  > I suggest we charter two follow-on efforts, one to explore a network
  > based solution and one to explore a host based solution.

=> Agreed

Hesham

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 14 Nov 2002 11:44:24 -0800

> My guess is that this feature should be common to all transport layers
and
> that transport layers should only deal with identifiers. I mean, only
the
> network layer have to deal with locators.

That is a very questionable proposition. Today, the transport layer
measures round trip times to manage retransmissions, and maintain window
sizes to match sending rates with available network capacity. In a
multi-homed environment, you would expect the transport to assess RTT
and capacity for the various available paths and to make intelligent
decisions about which packet goes on what path. Clearly, you want some
aggregation, but there is certainly value in providing the transport
with handles for directing traffic one way or another, which implies
dealing with addresses or locators.

-- Christian Huitema

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 15 Nov 2002 01:30:34 +0100

> I will repeat what I said before that I think that any 
  > solution that involves
  > crypto of any kind needs to be carefully thought through 
  > from the point of view
  > of CPU resources on end hosts.  While the traditional 
  > mobile host end points
  > probably don't care too much, for a general solution that 
  > would involve large
  > servers with thousands of connections, the MH solution must 
  > be low cost in such
  > an environment.

=> I am always reminded that mobile devices are power-constrained ;)
I agree that we need to be careful with this, but I don't 
think it will be a show stopper.

  > 
  > The edge router solution is not a complete solution either 
  > as has been alluded
  > to.  There will be instances where an end host may be 
  > connected to two paths,
  > neither knowing much about each other (e.g. cable, dsl and 
  > modem in a home
  > network).
  > 
  > Sounds to me like the only solution that will fly will be 
  > an E2E solution.

=> Makes sense.

Hesham

  > 
  > > 
  > > Hesham
  > > 
  > > 
  > 
  > Peter
  > 
  > --
  > Peter R. Tattam                            [email-masked]
  > Managing Director,    Trumpet Software International Pty Ltd
  > Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210
  >

---

From: "Tony Li" <[email-masked]>
Date: Thu, 14 Nov 2002 18:51:17 -0800

|   > All of this could be handled by a set of opaque handles 
|   to locators,
|   > without the direct interaction of the transport layer and the 
|   > locators.
|   
|   If you did this, wouldn't you degenerate into something 
|   resembling the DFZ
|   as it stands in IPv4.  Is what you are proposing is some 
|   kind of global ARP
|   system?  I had suggested something like this a few years 
|   back and it was
|   rejected pretty much on the the grounds that a global cloud 
|   just may not scale.
|   
|   Perhaps I just misunderstand.  There have been so many 
|   ideas and opinions
|   floating around that it's hard to keep track of them all.

No, what I'm proposing is just good software engineering
practice between the transport layer and the network
layer in the host implementation.

You're familiar with BSD sockets, right?  That gives an
application an opaque handle to a TCP connection.

Now do the same thing for locators, just one layer down.
Suppose the application wants to surf www.foo.com.  It
passes the hostname to TCP and requests a connection
to port 80.  It sets up a socket to do this.

TCP then resolves the hostname, which (in a stack
slightly different than BSD) would return a structure
that contained both the identifier and a list of 
current locators.  The locators themselves are opaque to
TCP.  Now, when TCP wants to send a segment,
it pushes the buffer, the pointer to the identifier
and one of the locator handles down into the network
layer.  This in turn formats the packet and shoves it
down to the next layer.

There shouldn't be anything controversial here.  This is
just basic software engineering.  Moreover, this is all
implementation detail, not architectural or even a 
required protocol.

Tony

---

From: "Michel Py" <[email-masked]>
Date: Thu, 14 Nov 2002 20:19:49 -0800

> Peter Tattam wrote:
> solution that involves crypto of any kind needs to be
> carefully thought through from the point of view of CPU
> resources on end hosts.

This is equally true of router-based solutions that involves crypto, as
the Cisco or Juniper CPU MHz costs a lot more than the
build-your-own-PC-install-zebra-on-it CPU Mhz.

Michel.

---

From: "Tony Li" <[email-masked]>
Date: Fri, 15 Nov 2002 09:58:22 -0800

|   There is an existing mechanism to convey information from router to
|   host, the router advertisements; it can be used, at a 
|   minimum, to prefer
|   the source prefixes that correspond to functional providers 
|   over those
|   for which connectivity has been lost; it is easy to use 
|   this mechanism
|   in a single link network; using it in a more complex 
|   network requires
|   exchange of information between the site routers. If that 
|   mechanism is
|   not sufficient, nothing prevents us from designing a better one,
|   possibly some variation of ICMP Redirect between site exit 
|   routers and
|   host on the site.

True.  When designing, please remember that unauthenticated
redirects would be a huge security hole.

Tony

---

From: "Michel Py" <[email-masked]>
Date: Fri, 15 Nov 2002 11:04:59 -0800

> Christian Huitema wrote:
> I would not be so sure about "rational". There is some
> documented evidence that the path selected by the routing
> fabric is often not the shortest route between two points;
> this is easy to understand because BGP is about policy,
> not metrics;

This is very true, but what is also true is that the enterprise network
manager also has traffic engineering concerns that are way easier to
handle with network policies than with host decisions.

Michel.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 17 Nov 2002 03:09:03 +0859 ()

Marcelo;

> > See the paper for new API.
> 
> I have tried to, but instaling japanese character set is required to
> correclty view the page
> (http://www.lab1.kuis.kyoto-u.ac.jp/~arifumi/paper/saint2003html/)

It is not a problem, because unreadable part just says "abstract"
and "references".

It is a result of laziness that a student author used a web
generation tool developped for Japanese and will soon be fixed.

> Do you have a text, printable version available? (such as an ID format)

Not yet.

						Masataka Ohta

---

From: "Michel Py" <[email-masked]>
Date: Mon, 18 Nov 2002 17:42:04 -0800

> Andrew Partan wrote:
> Huh?  If no route than the 1st packet does not
> go either.

Very true. The first packet goes to a rendezvous point, not to the
identifier precisely because there is no specific route.

> Or do you want routes that only work
> for the 1st packet of any flow?

No.

Michel.