Subject: Consensus on identifier/locator split?

From: "Tony Li" <[email-masked]>
Date: Wed, 6 Aug 2003 10:22:35 -0700

Folks,

I don't mean to disrupt other constructive conversations,
so please carry on with those.

I'd just like to get a sense from the group about where
we are so far.  Do we have consensus about splitting
the address into locators and identifiers?  Note that
I'm NOT asking about specifics, like "how big", "what
mappings exist", "is it secure", etc. Do we agree that
we want to go down this path?

Silence is not assent...

Thanks,
Tony

---

From: Vijay Gill <[email-masked]>
Date: Wed, 6 Aug 2003 13:28:59 -0400

> the address into locators and identifiers?  Note that

I believe we should.

/vijay

---

From: Eliot Lear <[email-masked]>
Date: Wed, 06 Aug 2003 11:17:34 -0700

I don't know whether we have consensus but I think it's a good idea.

Eliot

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 6 Aug 2003 14:14:00 -0700

I would say there is consensus that splitting would solve several problems,
but I wouldn't go so far to say there is consensus that it is the right
approach. Fundamentally, splitting amounts to rearchitecting the Internet
since many current assumptions would be invalidated. While this is a fine
thing for an IRTF wg to take on, an IETF Ops WG should be focused on
realistic things that can be done in our working lifetimes. 

Tony

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tony Li
> Sent: Wednesday, August 06, 2003 10:23 AM
> To: [email-masked]
> Subject: Consensus on identifier/locator split?
> 
> 
> 
> Folks,
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 06 Aug 2003 14:25:12 -0700

> realistic things that can be done in our working lifetimes. 

We (the NSRG) looked at this, albeit obliquely.  While there was not 
even rough consensus as to results, there are several possible 
alternatives that we discussed.  How developed should a solution be 
before it hits the IETF?  HIP has implementations as does MIPv6.  There 
are some limitations to MIPv6 that Christian has done a good job of both 
illuminating and attempting to provide some answers to.  So it seems to 
me that the iEtf is well suited to look at the problem at this point in 
time, so long as the ieSG understands that the results will hit multiple 
working groups.  Trying to do this in isolation from the rest of the 
IETF would be silly.

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 6 Aug 2003 23:55:56 +0200

On woensdag, aug 6, 2003, at 23:25 Europe/Amsterdam, Eliot Lear wrote:

> So it seems to me that the iEtf is well suited to look at the problem 
> at this point in time, so long as the ieSG understands that the 
> results will hit multiple working groups.  Trying to do this in 
> isolation from the rest of the IETF would be silly.

I think the relevant other working groups and the IAB (hopefully the 
IESG too) are well aware that we're looking at this in multi6. At least 
the word "multi6" was mentioned several times in the open IAB thing and 
ipv6/v6ops (somehow can't keep those straight) sessions.

Let's first get a coherent draft on the table and then take it from 
there.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sat, 7 Aug 2004 11:05:37 +0200

Hi Tony,

I think that a previous question that we may ask is whether we agree that we
will use PA addresses (topologically meaningfull addresses)  or we will
assign PI addresses.

If we choose to use PA addresses, then we need to have multiple PA addresses
in multi-hmed environments, this implies that when a node A is communication
with a multi-homed node, node A has to know that all the PA addresses belogn
to the same mh node, so the location and id function are splitted at some
level (IP, transport, application), because somewhere someone knows that
multiple locators are linked to a sinlge entity.

If we use PI addresses we only have a single address which accomplishes both
the id and the loc fucntion so we don't have to split.

So, the question fo me is, do we agree we will use multiple PA addresses in
multi-homed environments? if so i would say we agree that the identifier
function and the location function are splitted.

Regards, marcelo

PS: I know smoe are unconfortable with this PA PI terminology, please read
as topology meaningfull and topology independent

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Tony Li
> Enviado el: miercoles, 06 de agosto de 2003 19:23
> Para: [email-masked]
> Asunto: Consensus on identifier/locator split?
>
>
>
> Folks,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Aug 2003 15:00:38 +0200

My answer is yes, this is the way to go.

In answer to Christian, I would comment that *everything*
I say on this list is conditioned by sections 3.2.2 and 3.2.3
of draft-ietf-multi6-multihoming-requirements-07. That
rather drastically limits the forms of id/loc split
I am willing to contemplate, when we fly down from
the 10,000 meter level of Tony's question.

   Brian
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Tim Chown <[email-masked]>
Date: Thu, 7 Aug 2003 14:15:31 +0100

I think this approach is one to attempt, though of course the where and
how will take a while :)

---

From: Alain Durand <[email-masked]>
Date: Fri, 08 Aug 2003 15:29:02 -0700

Are you making the assumption that all your ISPs will route your PI?
If not, you will always end-up with multiple addresses anyway.

To answer Tony's question, I think this split is unavoidable.
The question is where it happens (bellow TCP, in TCP or above)
and how to opt-in. For transition reasons, I think that opt-out is not 
realistic.

    - Alain.

---

From: Tim Chown <[email-masked]>
Date: Sat, 9 Aug 2003 11:26:37 +0100

> and how to opt-in. For transition reasons, I think that opt-out is not 

Agreed - and which WG would consider it?

Tim

---

From: Sean Doran <[email-masked]>
Date: Sat, 9 Aug 2003 20:13:11 +0100

> Agreed - and which WG would consider it?

Does that really matter?   There is a decent set of people
in this one, and I* seems pretty content to let work develop
in situ, moving it when and if that seems more obviously
productive.

	Sean.

---

From: Sean Doran <[email-masked]>
Date: Sat, 9 Aug 2003 20:13:11 +0100

Sean.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Aug 2003 10:28:09 +0859 ()

Tony;

> thing for an IRTF wg to take on,

For constructive discussion, what, do you think, are the current
assumptions which would be invalidated?

I think it is merely that the current assumptions using the terminology
of "address" should be more precisely phrased with "address" replaced
by "id" or "locator", which does not change the architecture of the
current Internet.

Or, do you have any exception?

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Aug 2003 10:41:55 +0859 ()

Alain;

> The question is where it happens (bellow TCP, in TCP or above)

Wrong.

As I presented in Vienna, Web is not the Internet.

TCP is not the Internet Protocol.

That is, there is no room for such a question for sites wanting
stability to the Internet.

Multihomed site needs its connections kept alive on path changes,
regardless of transport protocols.

That is, the split is at IP.

						Masataka Ohta

---

From: Alain Durand <[email-masked]>
Date: Tue, 12 Aug 2003 09:49:37 -0700

> TCP is not the Internet Protocol.

Correct, I should have said transport instead of TCP.

> That is, the split is at IP.

That is one solution, but not the only one, and we may be OK
with a solution that modifies a limited number of transport protocol,
or with a solution that builds multihoming in a session layer on top
of transport and that would work regardless of the underneath  
protocols.

	- Alain,

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 12 Aug 2003 19:18:34 +0200

> of transport and that would work regardless of the underneath  

Such a session layer would have keep track of how much data has been 
successfully transmitted to the other side in order to be able to 
retransmit it when the underlying transport dies and another one must 
be used. Essentially it would replicate a good part of the existing 
transport functionality.

A much more useful approach would be to run the session layer 
_underneath_ the transport layer so the transport protocol can do its 
magic and the session layer can juggle the addresses.

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 12 Aug 2003 22:24:16 +0300

> magic and the session layer can juggle the addresses.

I concur.

The interface between such a session layer and the transport layer
seems to become very interesting.  For example, which layer is going
to keep track of MTU and RTT?  How to do traffic shaping between
several transport connections going over a single endpoint-to-endpoint
"session"?  Etc.

--Pekka Nikander

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 13 Aug 2003 06:43:04 +0859 ()

Alain;

> of transport and that would work regardless of the underneath  

Solution?

As for solutions, transport and application layers must, of course,
be modified, as has been pointed out in my draft. There can be no
generic session layer defined over, say, UDP.

However, the split is at the IP layer, because it should be available
to all the transport layers.

The set of a limited number of transport protocol is not the Internet
Protocol.

						Masataka Ohta

---

From: Mans Nilsson <[email-masked]>
Date: Wed, 13 Aug 2003 09:24:38 +0200

> The set of a limited number of transport protocol is not the Internet

This follows the path of least surprise for applications. Me likes. 

-- 
Måns Nilsson         Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

One FISHWICH coming up!!

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 13 Aug 2003 08:25:59 -0500

To the chairs - if this is seriously off-topic for multi6, please
feel free to say so...

The problem with having session layer functionality (as
I understand it) underneath the transport layer, is that
so much of transport-layer functionality is tied to a
single connection path (P-MTU and RTT, to name two).

If path changes reset all of this functionality, it's not clear
to me what the benefits of being "above" session-layer
functionality might be.

And the bigger problem is that we have so many
transport protocols that are implemented in kernel
space - this was a huge problem for SCTP, and I
expect it will be a huge problem for DCCP as
well. If session-layer functionality is above transport,
end users can make decisions about deploying it;
if it's below transport, we're waiting for OS releases
before anything is possible. This shouldn't be "fatal",
but we even ended up deploying RTP-over-UDP
so we didn't have to wait for OS support of RTP
in kernels...

Spencer

----- Original Message ----- 
From: "Pekka Nikander" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>
Cc: "Alain Durand" <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 12, 2003 2:24 PM
Subject: Whither a session layer, and where (was Re: Consensus on
identifier/locator split?)

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 13 Aug 2003 20:23:34 +0300

> To the chairs - if this is seriously off-topic for multi6, please

I don't have any problem to move this elsewhere, if needed....

> single connection path (P-MTU and RTT, to name two).

Exactly.  Now, if we do the id/loc split at the IP layer,
or anywhere between the packet forwarding function in the
IP layer and the connection/transaction management at the
upper layer, much of the above has to be thought again.
Or at least we have to have a mechanism to tell the
transport layer that the underlaying connection path is
not the same any more.  And if we want to have real load
balancing, that is not enough.  But I am certainly not a
transport area person, and most probably I underestimate
the potential problems...

> to me what the benefits of being "above" session-layer

Well, the transport API is one thing....  Another benefit
might be found in the amount of signalling that is
necessary to establish and change the paths.

> so we didn't have to wait for OS support of RTP

OTOH, if the "session" layer was implemented in the
kernel, it would become available to all applications
at the same time.

N.B.  I am not quite sure whether we should call this
"session" layer or not.  In some ways it provides some
of the same services that the OSI session layer presumably
did, but in other ways it doesn't.

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 13 Aug 2003 19:47:42 +0200

On woensdag, aug 13, 2003, at 19:23 Europe/Amsterdam, Pekka Nikander 

> Exactly.

All of this is dynamic. If we only change this when necessary there 
shouldn't be too many problems. (Could even drop a few packets on 
purpose to trigger slow start for TCP.)

> Now, if we do the id/loc split at the IP layer,

There are two cases:

1. Existing applications
2. Applications that are modified to take advantage of new 
opportunities offered by the new paradigm

I think we need to focus mostly on 1., but some people are only 
interested in 2. Yes, if we can throw out all the existing stuff we can 
make it much cleaner but we can't so we can't.

> not the same any more.

Obviously if session and transport are both in the kernel there is a 
lot that can be done to make them work better together. It would be 
cool to have standardized mechanisms for this but in practice this is 
all about TCP anyway.

>> space - this was a huge problem for SCTP,

> kernel, it would become available to all applications

We made the mistake of requiring changes to all applications once, 
let's not do it again.

> did, but in other ways it doesn't.

You're right, but we don't have anything on the table at this point so 
how can we come up with a good name?

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 14 Aug 2003 10:38:54 +0859 ()

Mans;

> This follows the path of least surprise for applications. Me likes. 

It is just an API issue to let applications over TCP work with
least surprise, having nothing to do with the layer of separation.

Read my draft.

							Masataka Ohta

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Aug 2003 14:30:21 +0200 (CEST)

> we want to go down this path?

[Catching up on email]

Yes, I think we should go down this path.

  Erik