Subject: [rrg] Terminology straw poll

From: RJ Atkinson <[email-masked]>
Date: Thu, 10 Jun 2010 17:18:04 -0400

Hi,

Here is a terminology straw poll for the Routing RG.  
As usual, I'm running this using Doodle.  The poll
lasts 1 week from the date/time of this email note.

Here is the poll URL:
	<http://www.doodle.com/dqfyfaigxuggs922>

My thanks to Noel Chiappa, Dino Farinacci, & Joel Halpern
(in alphabetical order) for providing corrections 
to earlier draft versions of these definitions.

A few quick notes:
-------------------
- As before, I can't edit the statements during the poll,
  because it obfuscates the meaning of votes that occurred
  before the edit occurred.
- The "A" terms are pretty widely used today.
- The B through E terms are not uncommon today,
  but are a bit newer than ancient terms like 
  "bridge" or "router".

A1) A "node" is either a host or a router.  

A2) A "router" is any device that forwards packets at the 
  Network Layer (e.g. IPv4, IPv6) of the Internet Architecture.  

A3) A "host" is a device that can send/receive packets 
  to/from the network, but does not forward packets.  

A4) A "bridge" is a device that forwards packets at the 
  Link Layer (e.g. Ethernet) of the Internet Architecture.  
  An Ethernet switch or Ethernet hub are examples of bridges.

B) An "Address" is an object that combines aspects of identity 
  with topological location.  IPv4 and IPv6 addresses are 
  current examples.

C) A "Locator" is a structured topology-dependent name that 
  is not used for node identification, and is not a path.  
  Two related meanings are current, depending on the class 
  of things being named:
	1) The topology-dependent name of a node's interface.
	2) The topology-dependent name of a single subnetwork
	   OR topology-dependent name of a group of related 
	   subnetworks that share a single aggregate.   An 
	   IP routing prefix is a current example of this last.

D) An "Identifier" is a topology-independent name for a logical 
  node. Depending upon instantiation, a "logical node" might be 
  a single physical device, a cluster of devices acting as a 
  single node, or a single virtual partition of a single physical 
  device.  An OSI End System Identifier (ESID) is an example of 
  an identifier.  A Fully-Qualified Domain Name that precisely 
  names one logical node is another example. (Note well that not 
  all FQDNs meet this definition.)

E) Various other names (i.e. other than addresses, locators, 
  or identifiers), each of which has the sole purpose of 
  identifying a component of a logical system or physical device, 
  might exist at various protocol layers in the Internet Architecture.

EOF

---

From: Toni Stoev <[email-masked]>
Date: Fri, 11 Jun 2010 01:55:48 +0300

My motivation for each vote:

Not OK. I consider "host" a service related term.

Not OK. Since it forwards packets, "forwarder" is a better term. I profess Role-Based Architecture, not layering.

Not OK. I consider "host" a service related term.

Not OK. I profess Role-Based Architecture, not layering.

Not OK. An "address" is a (legacy) name, not an object. 

Not OK. A "locator" is a structured topology-dependent name of a node. It is used to determine the topological location of the node.

Not OK. A fully-qualified domain name that precisely names one logical node is a human-readable name of the node. We must not impose irrelevant meaning upon terms.

Not OK. I profess Role-Based Architecture, not layering. It saves redundant terminology.

Thanks for asking.

---

From: Fred Baker <[email-masked]>
Date: Fri, 11 Jun 2010 08:02:44 +0900

This one gives me some pause in the context of a virtual machine in a cloud computing environment. I rather like the idea of associating identifiers with an application or set of applications, and only by extension of that referring to physical or virtual machines. For example, in cloud environments, if a process or set of processes moves from one machine (physical or virtual) to another, it would be nice to be able to move all of its/their sessions with it/them.

>  all FQDNs meet this definition.)

http://www.ipinc.net/IPv4.GIF

---

From: Steven Blake <[email-masked]>
Date: Thu, 10 Jun 2010 20:16:31 -0400

>   with topological location.  IPv4 and IPv6 addresses are 

That definition of "address" fails for Ethernet.

To be comprehensive: an "Address" is a field in a packet header that is
referenced for forwarding (at that associated layer), and whose value
contains aspects of identity, which may be structured as part of a
topological hierarchy.

Regards,

// Steve

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 11 Jun 2010 10:34:39 +0900

>  all FQDNs meet this definition.)

I'm OK that the group or the whole IETF go ahead with this use of
terminologies allegedly established by 'rough consensus'.

But, to me, use of extra terminologies of identifiers and locators are
unnecessary. Sorry I have to keep to this view of minority.

My reasoning is as follows. I'm confining to a ILNP picture:

   o An ILNP ID points to a node. I'd simply call it 'node address'.

   o An ILNP Locator points to a subnet. I'd simply call it 'subnet
address'.

   o The whole site will be aggregated to a shortened Locator before exiting
the site. That is, the whole site can be identified by this
shortened/aggregated Locator in the global network. I'd call this
'shortened' Locator 'site address'.

So, basically, I wouldn't need any terminology than 'address' which has been
out there and used without problem(?) for forty years or more.

The three addresses, node-addr, subnet-addr, and site-addr, are numbers with
essentially the same quality, the only difference being the granularity of
the object each address is identifying, and that in a step-wise widening
systematic way.

What ILNP basically proposes, whether or not originally intended, is use of
hierarchical addresses to split the whole problem into manageable pieces.

One aspect I'd personally go further to assert is that there's no compelling
reason why the subnet-addr has to be global to enable the whole operation.
It can be as local as node-addr.

In contrast, the site-addr might be global since all other parties (sites)
should be able to identify/locate each other sites.

And as far as node-addr and subnet-addr are local, they don't have to be
exposed outside of a given site, or more equivalently said, they might be
visible globally but shall not be used in inter-domain routing.

In summary,

   ILNP view    My view       My scope

   identifier   node addr     local
   locator      subnet addr   local
   site locator site addr     global

The poll is something like 'here's the menu, take it or not'. That's
perfectly OK if this shop is only for ILNP. But what if there're some naive
people who'd assume that this shop is still a generic public one and would
think the categories/names in the menu are unnecessarily biased.

So, I'd be OK if the poll is to make way clear to get ILNP rolling, but not
OK if this is going to be used as any 'authentic' weapon to impose new
definitions in the networking research in general.

Thanks.

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 11 Jun 2010 11:39:11 +0900

> Not OK. I profess Role-Based Architecture, not layering.

How about call it 'relay' instead of 'forwarder'?:

    o Router:  L3 relay
    o Bridge:  L2 relay

And relays' job is executed with routing and forwarding.

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 11 Jun 2010 11:44:08 +0900

> And relays' job is executed with routing and forwarding.

And,

   o routing:  finding a path
   o forwarding:  tossing to a next-hop

-- 
DY

---

From: Toni Stoev <[email-masked]>
Date: Fri, 11 Jun 2010 10:56:18 +0300

ISOC & IETF Censor People,

Please, identify yourself!

Toni Stoev

---

From: Scott Brim <[email-masked]>
Date: Fri, 11 Jun 2010 10:02:28 +0200

These are the best definitions I've seen.

However, I don't know that we will actually use locator/identifier,
except where protocols call particular header fields by those names.  If
a protocol carried a locator in a field named "refrigerator", we would
call it "the refrigerator" and you would never hear anyone talk about
locators again, except in defining that field. :-)

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 11 Jun 2010 04:22:12 -0400

> out there and used without problem(?) for forty years or more.

The fundamental disagreement you and I have is your assertion/
belief above that the existing overloaded semantics of the 
IP address are "without problem for forty years or more".

If we ignore the lack of 40 years since the initial definition
of IP itself, I believe there is actually pretty broad consensus, 
both within this RG, and also within the routing/addressing parts 
of the IETF, that the current overloaded semantics are indeed 
the root of multiple problems.  The RG doesn't have consensus
on the best engineering approach to resolve those issues,
but that is a separate question from where the problems originate.

I've rummaged around in a reasonable literature search, 
and as near as I can tell, the earliest description of 
these problems caused by overloaded semantics dates back 
to 29 July 1977 when [IEN-1] was published.  More recently,
a belief among the IAB Routing & Addressing Workshop folks
and the IAB generally that overloaded semantics of the IP
address was a significant problem caused this RG being 
re-chartered about 2 years back [RFC-4984].

(Now, all that noted, I will observe that a real effort was made
to make the Terminology poll neutral with respect to a range
of proposals (e.g. LISP).)

Yours,

Ran

PS:  To find [IEN-1] online, do a web search for "ien001.pdf".
	It is only available in PDF these days, not text/plain.

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 11 Jun 2010 17:25:16 +0900

So, the Big Brother is out there, huh..?

On Fri, Jun 11, 2010 at 4:56 PM, Toni Stoev <[email-masked]> wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

-- 
DY

---

From: "Stephen D. Strowes" <[email-masked]>
Date: Fri, 11 Jun 2010 09:41:59 +0100

Oops, I missed a checkbox on my first attempt. Ran, please disregard my 
first vote, retain my amended vote.

-S.

On 10/06/10 22:18, RJ Atkinson wrote:
> My thanks to Noel Chiappa, Dino Farinacci,&  Joel Halpern

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 11 Jun 2010 17:47:23 +0900

Hi, Ran,

I think you're missing the point.

Where did I assert anything about semantic overloading?

Take, for example, the MAC address.

It points to a MAC device in a LAN. And the MAC address is taken out
of a flat number space. That is, it's a flat address space.

And the whole LAN is operating without a problem with this single
number called MAC address. It not only identifies a MAC node, but also
used in the whole routing. The only difference with the Internet
routing is that MAC uses a different routing algorithm call spanning
tree.

So, with the MAC address, they are doing

   - node identification
   - routing, and
   - forwarding.

I've never heard that MAC addressing is a problem because of context
overloading.

The same picture should repeat at the internet-layer. Nothing different.

This leads me to say that, in fact, the diagnosis that address
overloading was a problem with the Internet is simply a wrong
diagnosis. By saying this, I know I'll be one of very few minorities
that don't believe in what the whole IETF or the whole prominent
workshops that you mentioned has graciously taught us.

Now, look at the picture of ILNP that you yourself draw again.

  o ID identifies a node.
  o Locator identifies a subnet.

They are basically the same thing. With my above example of MAC,
they're using only node IDs (MAC addresses) to do all L2 routing, with
bridge (L2 relay) instead of router (L3 relay).

Would you now then go further to say that we should start calling them
MAC ID's instead of address? No, because they're used for routing.

Then would you rather propose to start calling them MAC Locators?

According to the definition of yours, both ID and Locator are exactly
the same thing as address as it is used in MAC address.

So, the problem was not IP address overloaded.

The real problem was, to me, that the IP addresses point to the
interface, not to the body.

But, very fortunately, you yourself propose a way out of this dilemma,
independently whether you knew yourself what you're really doing:

   o ID points to a node; body, not leg.
   o Locator points to a subnet; body, not leg.

Perfectly fine. This really was what we needed in every tackling the
problem of the architectural flaw of the current Internet which is the
source of the whole mess/confusion.

You did an excellent job. Congratulations.

And so, now that the real problem was not overloading of the address
in the Internet, we don't have to split the same thing into different
terminologies, and we only need to keep the same terminology 'address'
with only a more careful perception what each address space is meant
for:

   o Node address for nodes
   o Subnet address for subnets
   o MAC address for MAC nodes

etc.

-- 
DY

---

From: Scott Brim <[email-masked]>
Date: Fri, 11 Jun 2010 10:48:09 +0200

Fred Baker allegedly wrote on 06/11/2010 01:02 GMT+02:00:
> This one gives me some pause in the context of a virtual machine in a
> cloud computing environment. I rather like the idea of associating
> identifiers with an application or set of applications, and only by
> extension of that referring to physical or virtual machines. For
> example, in cloud environments, if a process or set of processes
> moves from one machine (physical or virtual) to another, it would be
> nice to be able to move all of its/their sessions with it/them.

Fred, you're right, I hadn't noticed that.  Identifiers are used in many
ways, particularly for different session instantiations.  The definition
here has a particular scope, and the scope should be explicitly stated.

swb

>> node. Depending upon instantiation, a "logical node" might be a
>> single physical device, a cluster of devices acting as a single
>> node, or a single virtual partition of a single physical device.
>> An OSI End System Identifier (ESID) is an example of an identifier.
>> A Fully-Qualified Domain Name that precisely names one logical node
>> is another example. (Note well that not all FQDNs meet this
>> definition.)

---

From: Paul Jakma <[email-masked]>
Date: Fri, 11 Jun 2010 09:50:02 +0100 (BST)

>  An Ethernet switch or Ethernet hub are examples of bridges.

I agree more or less with the above, though there are exceptions. 
E.g. obviously there may be nodes which are both hosts and routers; 
also there may be hosts which perform logical routing functions, 
without being involved in forwarding.

> 	   IP routing prefix is a current example of this last.

FWIW, to me the clarification of 1 and 2 are unneeded. Topological 
naming implies the ability to aggregate - it follows from the 
mathematical notions. Thus a topological name can identify 1 specific 
entity, or any number of them.

>  all FQDNs meet this definition.)

I don't disagree with this, but I'm not sure about it either. :)

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
He who has the courage to laugh is almost as much a master of the world
as he who is ready to die.
 		-- Giacomo Leopardi

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 11 Jun 2010 18:00:25 +0900

> here has a particular scope, and the scope should be explicitly stated.

Hi, Scott and Fred,

How about looking at the thing in this way?

  o There are various identifiers in various places, vertically or
hierarchically:

       - APP ID
       - Node ID
       - Subnet ID
       - Site ID
       - ISP ID

   o They're floating over each other:

       - APP floats over Nodes. (process migration over machines)
       - Node floats over subnets. (node mobility)
       - Subnet floats in a site. (subnet mobility)
       - Site floats over ISPs. (ISP migration)

And, as long as these ID's are used in moving around
(migration/floating), they are equivalently called 'address'.

-- 
DY

---

From: Fred Baker <[email-masked]>
Date: Fri, 11 Jun 2010 21:06:32 +0900

id != address. An address is used in routing, and therefore must include the locator.

IMHO, this definition doesn't define anything.

---

From: "t.petch" <[email-masked]>
Date: Fri, 11 Jun 2010 12:33:18 +0200

----- Original Message -----
From: "RJ Atkinson" <[email-masked]>
To: "Dae Young KIM" <[email-masked]>
Cc: "IRTF Routing RG" <[email-masked]>
Sent: Friday, June 11, 2010 10:22 AM

<snip>

> It is only available in PDF these days, not text/plain.

Can anyone provide me with a copy of page 9 of IEN-1?

The pdf contains two page 10 and no page 9.  ASCII would be beautiful, word or
pdf ok but, PLEASE, not the whole 36Mbyte; hopefully the IRTF would reject such
a posting, but in these days of high speed lines, you never know.

Tom Petch

---

From: William Herrin <[email-masked]>
Date: Fri, 11 Jun 2010 09:37:56 -0400

>  with topological location.  IPv4 and IPv6 addresses are

My two cents...

An address IS an object (usually an integer, not necessarily unique)
assigned to some aspect of a particular host's network stack.

An address is USED FOR various functions including next hop selection,
node identification, application identification, authentication and
association of packets with the connection to which they belong.

An address is OVERLOADED when the same address object is used by the
network stack for next hop selection and one or more additional
functions.

>  is not used for node identification, and is not a path.

A Locator is an address used by the network stack ONLY for next hop selection.

An OVERLOADED Locator is an address whose use includes next hop
selection AND something more.

>  node.

On second thought I'd like to change my vote in the poll. This one is
fine after all.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 11 Jun 2010 22:52:30 +0900

> id != address. An address is used in routing, and therefore must

Back to my MAC address example.

A MAC address identifies a MAC node. And it is used in routing.

Is a MAC address more of an identifier or of a locator?

-- 
DY

---

From: Chris Grundemann <[email-masked]>
Date: Fri, 11 Jun 2010 11:37:30 -0600

<snip>

Although I have been lurking here for some time, I am a newcomer to
this group and to IETF participation in general so please forgive my
naivety but this search for solid terminology reminds me of something
I am told that Jon Postel once said:

"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."

I have always found that statement to be a great summary of how the
Internet works in the simplest terms possible. It appears that the
attempt here is to restate it as:

"An Identifier indicates what we seek. A Locater indicates where it
is. A route indicates how we get there."

Am I way off base here?

>  with topological location.  IPv4 and IPv6 addresses are

I am not convinced that an Address by design or definition combines
identity and topology. Yes IP addresses have come to be used for both
but that is not necessarily required by their (original/default)
nature. Because the line has become blurred, I do see the potential
value in using new terminology or alternatively, by clarifying the
line.

>  is not used for node identification, and is not a path.

FWIW, if the definition stopped here, I would have agreed with it.

<snip>

$.02
~Chris

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org

---

From: Fred Baker <[email-masked]>
Date: Sat, 12 Jun 2010 02:58:49 +0900

A MAC address is used in a network that has already been located.

---

From: William Herrin <[email-masked]>
Date: Fri, 11 Jun 2010 14:11:14 -0400

On Fri, Jun 11, 2010 at 1:37 PM, Chris Grundemann <[email-masked]> wrote:
> Internet works in the simplest terms possible.

Hi Chris,

That's a great summary of how things were supposed to be. It's not
such a great description of how things are.

At work a run a ground system tied to a satellite service. IP
addresses for the servers are anycasted from two locations 5000 miles
apart. They're backended by a server cluster spread between those two
sites. Each server in the cluster has the same IP address. A load
balancer/tunnelling apparatus is used to divvy up the packets between
the cluster servers and move the packets between sites back out across
the Internet when the selected backend server is not local.

In this scenario the address no longer describes "where" the servers
are except in a very fuzzy sense. The address certainly doesn't
describe the host or interface sought. But it very accurately
describes a set of services sought, with each address tied to a
different cluster providing that specific set of services.

More generally, the address gets used in the following processes that
have nothing to do with "where" the address is located:

node identification - an address is often used to uniquely identify a
particular computer on the network. As a result, the computer retains
the same address when it moves instead of acquiring a new address.

application identification - as in my ground station example above, an
address can be tied to a particular service, rerouting to find that
service on any machine capable of providing it that is still online.
The route still indicates how to get to it but the address identifies
the service, not so much where the service is located.

authentication - The human being users identified by the IP addresses
I designate may access. You may not.  Maybe at my network border.
Maybe in my server's .htaccess file. No comment about the security
efficacy - just noting that it gets used this way.

packet association - in TCP, the connection ID is composed of the
source and destination IP addresses plus the source and destination
ports. The network stack uses the IP addresses in this scenario both
to associate incoming packets with the connection to which they belong
and to select the identity of the other host to which packets should
be returned, regardless of that other host's movement within the
network. Should that either endpoint in a TCP conversation present a
different IP address (because they're no longer where they used to
be), that TCP connection is dead.

Regards,
Bill Herrin

---

From: Fred Baker <[email-masked]>
Date: Sat, 12 Jun 2010 03:16:53 +0900

No, it's a person with a well-known position about the IETF and the Internet Society, in all probability. I don't see comments from him that are topical.

---

From: Fred Baker <[email-masked]>
Date: Sat, 12 Jun 2010 03:21:12 +0900

On Jun 11, 2010, at 5:50 PM, Paul Jakma wrote:

> I agree more or less with the above, though there are exceptions. E.g. obviously there may be nodes which are both hosts and routers; also there may be hosts which perform logical routing functions, without being involved in forwarding.

I view these terms as being mostly meaningful with respect to a conversation in progress. A system that forwards IP datagrams at the IP layer is an IP router; an IP router, unless completely static in its configuration, also exchanges datagrams with other routers in routing protocols, and is with respect to those protocols a host (it originates and receives datagrams directed to itself). Some IP routers contain built-in bridging technology, either software or hardware.

---

From: Toni Stoev <[email-masked]>
Date: Fri, 11 Jun 2010 22:15:09 +0300

Yes, "router" and "host" are well-known terms. But they are legacy. Do we at all need them here?
Whether a node forwards packets or not is a question of policy about path selection.
So are we spending a term per each policy option?
And are we researching forwarding issues, Tony?

RFC
Toni

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 12 Jun 2010 08:01:51 +0900

So, in  MAC, a node can be located without extra use of any other numbers.

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 12 Jun 2010 08:18:07 +0900

> be), that TCP connection is dead.

So, are you saying this semantic overloading of 'address' is the
reason to look for newer terms? Or, are you saying that such semantic
overloading is rather natural.

In LISP, EID is routable within the scope of a site. To be routable,
it should bear information for location. So, in this sense, LISP EID
is a locator at the same time.

I mean, even with a LIS scenarios like LISP, EID (or ID) is
semantically overloaded.

In ILNP, Locator identifies a subnet. So, ILNP Locator also bears
significance as another form of ID.

I mean to say that 'semantic overloading' is not the real target
problem we had to escape from. Use of term 'address' was not the real
problem.

The real problem was wrong semantic of IP address. The problem was not
overloading but mal-definition of the semantic of IP address.

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 12 Jun 2010 08:27:35 +0900

No, I was joking. I don't have any problem with such an anonymity. He
must be a person with good humor.

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 12 Jun 2010 09:13:03 +0900

Hi, Ran and folks,

As I told you, I'm perfectly OK that you go ahead with ILNP and the
term definitions proposed. You already could declare consensus with
this poll, I'd think.

The rule of the game is 'rough consensus', not unanimity. You don't
have to twist arms of some naive guys like me to change vote.

Unanimity, in fact, is an evil. Disparity and diversity are democratic virtues.

I don't think I can change your group thinking as much as you cannot
mine. I'm perfectly OK with the progress of this poll.

However, this statement of mine remains valid:

  "So, I'd be OK if the poll is to make way clear to get ILNP rolling,
but not OK if this is going to be used as any 'authentic' weapon to
impose new definitions in the networking research in general."

-- 
DY

---

From: William Herrin <[email-masked]>
Date: Fri, 11 Jun 2010 20:18:49 -0400

> overloading is rather natural.

Hi DY,

If was making any points, and I'm not entirely sure I was, it would
probably be these:

1. Terms like "host," "address," and "router," already have common and
well understood if not well defined meanings. While it might be
valuable to better formalize those meanings this group, both singly
and as a whole, lacks the prerogative to -change- those meanings.

To the extent that Ran's definitions change those terms, the
definitions are wrong. For example, any machine that speaks IP is a
host. That includes routers. I'm not saying that should be the case,
I'm saying that IS the case as the word is actually used. If we think
it would be valuable to define a type of machine which originates and
accepts IP packets but will never under any circumstances forward one
elsewhere, we should pick a new word.

2. Redefining well understood and commonly used words in terms of
poorly understood theoretical constructs is an exercise in getting
other engineers to roll their eyes at you. An address is what it is,
and that doesn't include anything about locators and identifiers. On
the other hand, it might be valuable to define a locator (which is NOT
a commonly understood term) as an address used only in a particular
way or (if it's the group's preference) an address whose use includes
particular functionality.

Quite frankly, I think it would help the discussion to have two such
terms - one for an address that is ONLY used in the next hop selection
process and a different one for an address whose use INCLUDES the next
hop selection process. Otherwise we'll keep interchangeably and
ambiguously using the term locator to mean whichever one we happen to
want to discuss.

> problem we had to escape from. Use of term 'address' was not the real

Maybe, maybe not. But we don't have to settle that in language
definitions; we need only define terms that allow us to precisely and
constructively discuss it.

Regards,
Bill Herrin

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 12 Jun 2010 10:17:32 +0900

> elsewhere, we should pick a new word.

Yes. I'd agree.

In put some other words, a node is one involved in IP packets. If
they're stub-nodes, they are also usually called host. If they're
relay nodes, they are also interchangeably called routers.

But, in an exact sense, there's one and only one type of machine,
'node'. Host and routers are, in a way, only loose synonyms used
interchangeably with 'node', for conversational convenience' sake.

> ambiguously using the term locator to mean whichever one we happen to

Maybe.

I'd rather think that semantic overloading is nothing you can escape
from. Whatever terms we might define, they will bear more semantic
significance over time and over practice. No truth is true forever.

So, to me, semantic overloading of 'address' may not have been the
real evil we had to get rid of.

-- 
DY

---

From: [email-masked]
Date: Sat, 12 Jun 2010 03:46:42 -0400

-- 
DY

Well spoken. So any correction of semantic overloaded definitions is just the attempt to make the own interpretation the prevailing one.

Honestly: I am worried that the pretty new term "Locator" is going to be bent, too - just like the term address has been.

Locator (just like the address ought to denote) denotes the location of a node. (which means WHERE that node is).

And there are better and worse locators. If the locator contains "fleet street" you cannot infer what is the neighboring street. However, given the locator contained "7thStreet"
you may conclude that 6th Street and 8th Street are next to it.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Dae Young KIM <[email-masked]>
An: William Herrin <[email-masked]>
Cc: IRTF Routing RG <[email-masked]>
Verschickt: Sa., 12. Jun. 2010, 3:17
Thema: Re: [rrg] Terminology straw poll

Yes. I'd agree.

Maybe.

---

From: Paul Jakma <[email-masked]>
Date: Sat, 12 Jun 2010 11:37:24 +0100 (BST)

On Sat, 12 Jun 2010, Fred Baker wrote:

> I view these terms as being mostly meaningful with respect to a 
> conversation in progress. A system that forwards IP datagrams at 
> the IP layer is an IP router; an IP router, unless completely 
> static in its configuration, also exchanges datagrams with other 
> routers in routing protocols, and is with respect to those 
> protocols a host (it originates and receives datagrams directed to 
> itself). Some IP routers contain built-in bridging technology, 
> either software or hardware.

Ack. And to stress Scott's point from earlier, terminology will be 
technology specific. We'll call things what they're called according 
to a protocol. So what "address" means is fairly clear if you're 
talking "IP", or if the conversation is about "ethernet". Etc.

Obviously, given the discussions here, it's quite hard to pull out 
abstract, cross-technology/agnostic terms.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
How come only your friends step on your new white sneakers?

---

From: Paul Jakma <[email-masked]>
Date: Sat, 12 Jun 2010 11:43:47 +0100 (BST)

> A MAC address is used in a network that has already been located.

"in one or more networks", if by "network" you mean "IP network". 
Further, what does "located" mean? If my MAC address is used in the 
IP network located at 192.168.0.0/24...

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
"The great question... which I have not been able to answer... is, `What does
woman want?'"
-- Sigmund Freud

---

From: Tony Li <[email-masked]>
Date: Thu, 17 Jun 2010 17:14:09 -0700

Hi all,

The poll below is now closed.  We received 21 responses.  Of those, one is clearly a poor prank and another was amended.  Both of these responses are ignored, leaving 19 valid responses.

The statements or definitions received the following responses in agreement:

A1) 17  =>  89%
A2) 15  =>  79%
A3) 17  =>  89%
A4) 18  =>  95%
B) 14    =>  73%
C) 14    =>  73%
D) 13    =>  68%
E) 17    =>  89%

Based on this, I find that we have rough consensus in favor of all of these definitions, and we will incorporate these into the recommendation document.

Once again, I hope to make another editorial pass through the document (as soon as my day job permits ;-), so comments, additional terminology or consensus agreements are still very much welcome.

Regards,
Tony

---

From: Robin Whittle <[email-masked]>
Date: Tue, 22 Jun 2010 21:57:19 +1000

Hi Ran,

You wrote (msg06884), in part:

> the root of multiple problems.  

These are problems for today's interdomain routing system, in that it
causes scaling problems with the growth in the number of PI prefixes,
and the rate of change in how they are advertised in the DFZ.

However, "overloading" - having the IP address perform the roles of
Identifier and Locator - is good for hosts.

As long as hosts can rely on the routing system (local systems plus
interdomain routing system) behaving as they do today, then hosts are
saved a great deal of effort.

In today's "overloaded" system, when a host emits a packet with
destination address NNNN, the routing system will:

  1 - Generally deliver the packet to the one host whose IP address
      is NNNN, or to one of the hosts with this address if there
      are multiple such hosts (anycasting).  Otherwise, the packet
      will be dropped somewhere.

  2 - Will not deliver the packet to any host which does not have
      the IP address NNNN and therefore is not a host which
      is the intended destination of the packet.

So the sending host doesn't concern itself with where the destination
host is (or where the closest one of multiple anycasts hosts is).
Nor does it need to concern itself with the possibility that the
packet will be delivered to some host whose identity does not match
the destination address.

Compared to a Core Edge Elimination = Locator / Identifier Separation
architecture such as ILNP, the current "overloaded" system puts a lot
of responsibility on the routing system and takes it off the hosts.

Loc/ID Separation architectures (LISP is not such an architecture)
solve the scaling problem by forcing all hosts to manage separate
Identifiers and Locators, and for packets to contain these two
separate things, for both destination and source addresses.  This
makes things quite easy for the routing system, so solving the
routing scaling problem.

I believe the existing division of responsibilities is good and
should be maintained.  If Loc/ID Separation was adopted, hosts would
need to do mapping lookups and other complex, delay-prone, operations
before they can send packets to a new destination.  This will
generally delay the establishment of communications, since these
lookups must be done by the hosts.

LISP, Ivip and IRON are Core Edge Separation architectures which
preserve the current "overloaded" nature of the the IP address.

I think this is a good thing: make the routing system somewhat more
complex so it can support hosts in their current, relatively simple,
form.  This will be faster (in terms of establishing initial
communications, at least with Ivip and perhaps IRON) and more
efficient (hosts not having to send and receive longer packets, or
more packets) than with any Loc/ID Separation architecture such as ILNP.

It will also more efficient in terms of hosts not needing to maintain
any extra state or fuss around with things which the routing system
currently handles: how to get a packet to a host whose identity is NNNN.

Since more and more hosts are going to be battery operated devices
running from potentially slow, high latency, wireless connections, it
is all the more important that we not try to change the architecture
to something like Loc/ID Separation, which further burdens these
links and hosts.

For my overview of what I think should happen:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html

but IRON-RANGER has changed a lot since then.  I plan to write about
it soon.

 - Robin           http://www.firstpr.com.au/ip/ivip/

---

From: Toni Stoev <[email-masked]>
Date: Wed, 23 Jun 2010 15:51:00 +0300

Robin,

There is a way to separate identity from location and still have hosts not care much about mapping and resolving. It is by integrating resolution and session initiation. The first packet to resolve an ID to locator has characteristics relevant to those of the first one for session start. So the two can become one and of course be handled by the routing system.

Regards
Toni

---

From: Robin Whittle <[email-masked]>
Date: Wed, 23 Jun 2010 23:51:33 +1000

Hi Toni,

In "Re: [rrg] "Overloading" of Loc & ID functions – Another world is
possible." you wrote:

> There is a way to separate identity from location and still have
> hosts not care much about mapping and resolving. It is by
> integrating resolution and session initiation. The first packet to
> resolve an ID to locator has characteristics relevant to those of
> the first one for session start. So the two can become one and of
> course be handled by the routing system.

but this makes no concrete sense to me.

Locator / Identifier Separation means packets have separate fields
for these, all the way from sending host to receiving host.
Therefore, the hosts are doing different protocols from what they do
today.

Can you give a detailed account of how you propose to have hosts send
and receive packets which have separate Identifiers and Locators for
source and destination, without the delays inherent in looking up
Locators?

Then, for your concrete example, why do you argue that hosts should
do this extra work, rather than new elements in the routing system
such as ITRs, as in LISP, Ivip or (by some other name) IRON?

Does your concrete proposal involve new application protocols, or can
existing protocols work with IP addresses, with the stack somehow
implementing whatever is required so the application can assume that
an IP address is both an Identifier and Locator?  This involves
ensuring that a packet is never received by a host which does not
have the Identity implied by the application's destination IP address.

Does your proposal provide a facility similar to today's anycast and
to round-robin DNS, where one DNS name resolves to multiple IP
addresses, meaning multiple hosts or sets of anycast hosts?

How would your proposal handle multihoming and mobility?

Is there any RRG proposed architecture which matches or resembles
your plan?

If your plan doesn't alter host protocols, then I guess you must be
advocating an entirely network based solution, such as LISP, Ivip or
IRON.  In these, the hosts have no separate notion of Locator and
Identity in their communications - just as is the case today - so it
is wrong to refer to this as Loc/ID Separation.

Also, how would your analysis of the goals and proposed architectures
differ from mine?:

  - Robin

---

From: Toni Stoev <[email-masked]>
Date: Thu, 24 Jun 2010 14:38:15 +0300

Thank you, Robin, for provoking the presentation of my proposal. It follows inline.

> but this makes no concrete sense to me.

I used "hosts" meaning "nodes". I will hereafter use "node(s)" with a preference for the new proposal.

> for these, all the way from sending host to receiving host.

Or have different options in the header.

> Therefore, the hosts are doing different protocols from what they do

Sure. But the basic ideas that are known to be sustaining will be inherited.

> source and destination, without the delays inherent in looking up

A look-up needs to be done once per stateful session. Thereafter nodes inform each other of any locator changes.

Node ID system:
Imagine a DNS-like system with numbers instead of names. The IDs are FQD Number sequences. Numbers are quite less subjected to human competition than names.
A domain number server knows locators of its tended nodes. A server authoritative for a (number) subdomain is also a tended node in its parent domain.
The add-on with regard to the renown DNS is that not only servers know locators of tended nodes, but also nodes know locators of their tending servers.
Upon (initial) configuration a node gets an identifier from an ID server and thereafter informs the server about changes of its locators.

So here's how the initial resolution/outreach is done:
A node knows the ID of a remote node (from the DNS). The node dispatches an initial packet for the remote node with destination ID and source ID & locator. The packet is sent to the source node's ID server using a known locator.
The server performs longest match of the destination ID, first with its own ID. If the matching part is shorter (than the server's ID) then the packet is relayed to the parent ID domain server.
When the destination ID covers the ID of the server and there is a remaining part, the destination ID is compared to the IDs of the server's tended nodes/subdomains. And then the packet is relayed to the matched tended node or subdomain server.
Generally, this longest-ID-match & relay approach leads to finding & reaching the destination node initially. I call this inicast.

> such as ITRs, as in LISP, Ivip or (by some other name) IRON?

No extra work. Nodes will use locators for packet outreach and IDs for session maintenance.
The routing system will consist of path selection facilities that make use of locators.
The node ID system will consist of ID distribution/matching servers.

> an IP address is both an Identifier and Locator?

For this separate uses of IDs and locators new application protocols or amendments of exiting ones are needed.

> This involves 

Yes, an important feature. Destination identifier.

> addresses, meaning multiple hosts or sets of anycast hosts?

Anycasting is a matter of naming and recognition of service types. It is not about naming nodes or their location. Service type naming is a different aspect of the architecture.

A node identifier may resolve to multiple locators, which would be used in a round-robin fashion or with some preference. But those locators would be each of the same node.

> How would your proposal handle multihoming and mobility?

Every "home" of a node may supply it with a locator. Locators may come and go. Sessions are maintained with identifiers.

> Is there any RRG proposed architecture which matches or resembles

Matching – no. Resembling – I guess no. Others are welcome to match.

>   http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html

I have not read all the writings there. Maybe in the course of this discussion I could answer. Or you could help me do so.

Toni

---

From: Robin Whittle <[email-masked]>
Date: Thu, 24 Jun 2010 23:17:10 +1000

Short version:   Toni's proposal seems to be a Locator/ID Separation
                 architecture (AKA Core Edge Elimination).

Hi Toni,

Thanks for your response.  Unfortunately I can only get a vague idea
of what you are proposing from the text you wrote.  It is quite a lot
of work to write up a new routing and addressing system in a manner
that other people can understand it clearly.

You wrote, in part:

> A look-up needs to be done once per stateful session. Thereafter
> nodes inform each other of any locator changes.

But what if both change their locators at the same time?

How can one node be sure a message supposedly from the other node,
regarding the other node's new locator, is authentic?

>> Then, for your concrete example, why do you argue that hosts
>> should do this extra work, rather than new elements in the
>> routing system such as ITRs, as in LISP, Ivip or (by some other
>> name) IRON?
> 

There certainly is extra work.  Initially the sending host A only
knows B's Identifier, and it somehow uses this with the number
servers to get a packet to B.  I am not sure how A finds out B's
locator, but it needs to find this out ASAP so it can send subsequent
packets directly to B, without relying on any other servers.

There are extra delays in using these number servers.

When B gets a packet from A, it will have A's Identifier and it may
have A's Locator - but there's no way B can trust this Locator.  So
it needs to do a lookup, or whatever it is you described with number
servers, to send a packet to A, rather than to some other host which
pretends to be A.

> The routing system will consist of path selection facilities that
> make use of locators. The node ID system will consist of ID
> distribution/matching servers.

I am sure you could write this up in a way others could understand,
but it will take a few pages and probably require some diagrams.

>> Does your concrete proposal involve new application protocols,
>> or can existing protocols work with IP addresses, with the stack
>> somehow implementing whatever is required so the application can
>> assume that an IP address is both an Identifier and Locator?
> 
> For this separate uses of IDs and locators new application
> protocols or amendments of exiting ones are needed.

OK - so applications need to be rewritten and do more work.  I think
there's no way anyone would be interested in adopting such a system,
since - as with other CEE architectures - the benefits for each
adoptor and for routing scalability only occur after almost everyone
has adopted it.

Requiring changes to host stacks is a real barrier to adoption.
Requiring applications to be rewritten is far worse.  See:

  http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

>> This involves ensuring that a packet is never received by a host
>> which does not have the Identity implied by the application's
>> destination IP address.
> 

It can only be achieved, as far as I know, by B doing a secure lookup
of A's Identifier to get A's Locator - and then sending the packet to
that Locator.  (Or some alternative by which number servers send the
first packet and reliably and securely inform B what A's Locator is.)

>> Does your proposal provide a facility similar to today's anycast
>> and to round-robin DNS, where one DNS name resolves to multiple
>> IP addresses, meaning multiple hosts or sets of anycast hosts?
> 
> Anycasting is a matter of naming and recognition of service types.
>  It is not about naming nodes or their location. Service type
> naming is a different aspect of the architecture.

I am not sure what you mean by this, but it does not seem to accord
with my understanding of anycast being multiple hosts in multiple
locations all around the Net, with the same IP address.  Then, the
interdomain routing system (without any extra elaboration for this
purpose) causes the packet to be sent to the "closest" such host.
("Closest" with BGP is not necessarily physically or topologically
close.)

> A node identifier may resolve to multiple locators, which would be
>  used in a round-robin fashion or with some preference. But those 
> locators would be each of the same node.

At present a FQDN can resolve to multiple IP addresses, each of which
combines the functions of Identifier and Locator for the particular
host in the round-robin group.  Then the session begins and continues
with one of these hosts, and is maintained with this IP address.

With your proposal, an Identifier can have multiple locators, each
for a different node.  But this seems to violate the concept of an
Identifier being specific to each physical node.  Then, your
applications need to keep track of specific Identifier-Locator pairs,
since each pair with a different Locator refers to a different node -
and for session continuation, the session always needs to be with the
node specified by this pair.

You could do FQDN round-robin to Identifier, and then for each
Identifier, have a single node, with one or more Locators.  That
would work fine, I think.

> Every "home" of a node may supply it with a locator. Locators may
> come and go. Sessions are maintained with identifiers.

Yes, but you have to organise a secure and efficient way to tell a
distant node B that A has now got a new Locator.

>> Is there any RRG proposed architecture which matches or
>> resembles your plan?
> 

Your proposal seems to be a host-based system along the lines of the
Core Edge Elimination architectures (the architectures which really
do implement Locator/Identifier Separation):

   GLI-Split
   ILNP - Identifier-Locator Network Protocol
   Name-Based Sockets
   RANGI

>> Also, how would your analysis of the goals and proposed
>> architectures differ from mine?:
>> 
> I have not read all the writings there. Maybe in the course of
> this discussion I could answer. Or you could help me do so.

Other than Tony and Lixia's:

  http://tools.ietf.org/html/draft-irtf-rrg-recommendation

my msg06219 is the only attempt anyone has made for writing what they
would like to see as an RRG Recommendation.  Unlike Tony and Lixia's
document, my attempt covers mobility and includes a proper
description of goals and critiques of all proposals (or at least
descriptions of why they can't be considered proper proposals).

I understand that your plan would make life easy for the routing
system, compared to the additional mechanisms needed for LISP, Ivip
or IRON.

However, it is not clear to me why you want to place the extra
workload on nodes (AKA each communicating host), with the delays
required at each node which is part of a two-way communication, and
the need for complex security arrangements so each node can learn of
a new Locator for the other node ASAP.

It is not clear how you handle mobility, since that would require all
communicating nodes of a mobile node to instantly know its new
Locator, the moment it acquires a Locator in a new network.  This can
happen in a split second, when one radio network goes down and
another is chosen - or even on the same radio network when the node
communicates with a new radio tower (even if the node hasn't moved -
the network can make this happen) which uses a different base-station
controller which uses a different IP gateway.  For instance, I
understand that in Beijing, in one 3G network, there are multiple IP
gateways in the whole city.  Your node can discover its new Locator
quickly, but how can it securely communicate this to all its
correspondent nodes in time not to lose any packets from them?  If
there are 50 correspondent nodes, then that is 50 secure messages
which need to be sent out and acknowledged.  That is a lot of work
for a 3G handset, and it would chew up expensive radio bandwidth.
Also, what if both nodes in a communication get new Locators at the
same time?  There's no way either can know the new locator of the
other, since it can't receive the update message, which would be sent
to its old Locator.

These last two paragraphs are critiques which apply to the other CEE
architectures too.

If you write up your proposal in sufficient detail and read the other
CEE architectures, I think you may find some points of commonality.

Whatever it is you are proposing, it is a Loc/ID Separation (CEE)
architecture - and I oppose such architectures for the reasons
mentioned in my msg06219 and in my recent message:

 http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html

  - Robin

---

From: Toni Stoev <[email-masked]>
Date: Fri, 25 Jun 2010 12:56:18 +0300

Further reply Part 1

> But what if both change their locators at the same time?

This would be a breakdown and a session re-establishment process would be conducted. At least one of the sides, when realizing what would have happened, would make an inicast to restore the session.

> regarding the other node's new locator, is authentic?

First, by looking at the other node's identifier. Second, by sending a further message and receiving a reply. Third, if needed, by doing inicast.

> packets directly to B, without relying on any other servers.

When A's inicast packet reaches B, B replies with its locator directly to A.
Thus, both sides get to know their ID & Loc tuples.

> There are extra delays in using these number servers.

Just like doing any other resolution. But in the meantime the inital packet is on its way. And when the process of resolving completes the packet will likely be closer to its destination. This moment is when the directly tending ID server gets the packet.

> servers, to send a packet to A, rather than to some other host which

No lookup is required.
B would send a further handshake reply to A. A's reply would be the proof.

> but it will take a few pages and probably require some diagrams.

That would be nice of me. I hope the interest grows.

To be continued.

---

From: Robin Whittle <[email-masked]>
Date: Fri, 25 Jun 2010 23:39:15 +1000

Short version:  Toni hasn't yet described a secure method by which
                one node can tell another it has a new Locator.

                I can't imagine how this proposal, or any other CEE
                (Loc/ID Separation) architecture, such as ILNP,
                could handle mobility with sufficiently short
                delays and sufficiently light-weight protocols
                to make it practical or attractive for VoIP.

                If a scalable routing proposal can't do mobility
                with delays short enough to not disrupt conversations
                with VoIP, then I think it is a non-starter.  So far
                I think TTR Mobility is the only approach to mobility
                which can do this - and it is only for CES
                architectures such as LISP, Ivip and perhaps IRON.

Hi Toni,

Thanks for your reply.  You wrote:

>>> A look-up needs to be done once per stateful session.
>>> Thereafter nodes inform each other of any locator changes.
>>
> This would be a breakdown and a session re-establishment process
> would be conducted. At least one of the sides, when realizing what
> would have happened, would make an inicast to restore the session.

This condition could only be detected by upper layers.  So the
application, or TCP, would need to time out due to lack of response
from the other node, since the packets the application sends are
going to the old Locator, not the new one.  Then you could restart
the "inicast" process, and I guess continue the session based on the
original Identifiers with the new Locators.  However, this would be a
serious disruption to service, since it would take 5 or 10 seconds
for the application to time out.  If you let it time out any sooner,
then you could be restarting the "inicast" process every time there
is a brief outage or a few dropped packets.

The same thing would happen if B changes its Locator and sends a
message to A about this, but the message is dropped and does not
arrive at A.  A's applications would time out due to not getting any
responses from B (A would be sending packets to B's old Locator
address), and then you would restart the "inicast" system.  To get
around this, you would need to have A acknowledge B's message, so B
could resend until it got an ack.  However, that would make the
process of gaining a new Locator far more expensive.

With mobility, the device might gain a new Locator and lose the old
one very rapidly and arbitrarily - without user action.  If B is
communicating with 50 other nodes, then this means 50 outgoing
messages and receiving 50 acks.

Please compare this with the TTR approach to mobility, in which a new
(Locator) IP address just involves the mobile node establishing a new
tunnel with its (typically) one TTR (Translating Tunnel Router):

  http://www.firstpr.com.au/ip/ivip/#mobile

All other approaches to mobility I know of have the same problem as
just described - all CEE (Loc/ID Separation) architectures, and LISP
Mobile.

With TTR Mobility, the mobile node can have multiple IP addresses
from various access networks, and create a tunnel from each to the
current TTR.  So it can establish a new tunnel from a new access
network before it loses its address in a previous access network.
Since the TTR is typically nearby, this tunnel establishment process
can occur in a few milliseconds, and so, I think, be suitable for VoIP.

Any CEE mobility system will involve delays telling all the
correspondent nodes about the new Locator. Since the correspondent
nodes could be anywhere in the world, and since the mobile node needs
to send out messages, and get acks, for each one, this is never going
to be practical, or be fast enough to support VoIP.

>> How can one node be sure a message supposedly from the other
>> node, regarding the other node's new locator, is authentic?
> 
> First, by looking at the other node's identifier. 

This doesn't achieve any security.

> Second, by sending a further message and receiving a reply.

Nor does this.

Let's say A and B have established a session.  X wants to impersonate
B.  X gets A's Identifier and Locator, either directly by setting up
a session with B, or by having another node Y do so.

Then X sends a message to A with B's Identifier and current Locator,
telling A that it has a new Locator.

With what you have proposed so far, there is no security whatsoever,
and A would accept the message and send all the packets it intends
for B to X instead.

> Third, if needed, by doing inicast.

Sure, you could restart the expensive session establishment process
every time either node changes its Locator.  However, this is
unacceptable in terms of cost - especially for mobility - and it
presents a completely unacceptable DoS vulnerability.

Let's say X wants to cause havoc for B and all the nodes it is
communicating with.  If it somehow knows the Identifiers and Locators
of these nodes, or has an inexpensive way of finding some such nodes,
it sends an unsecured message to each such node, purportedly from B,
that B has a new Locator and that the node should restart the
"inicast" process before sending any further packets.

This would tie up B and its targeted correspondent nodes with
"inicast" operations and the delays would disrupt traffic.

You have not yet proposed a secure method by which one node can tell
another that it has a new locator.  I think the best way to do it is
for each session to involve each node sending a nonce to the other,
and using this nonce to secure messages in the future regarding
change of Locator.  This adds to the complexity of the "inicast"
protocol and to the state stored by each node.  For instance, for B
to send A its nonce, it can do it in two ways:

  1 - B send the nonce, perhaps as part of its first reply packet to
      A.  Then B waits for an acknowledgement that this nonce has
      been received - which is probably best done by A sending
      another packet with that nonce, or with a hash of it, to B.
      This too could be piggybacked onto a traffic packet.

  2 - Keep sending the nonce for some number of packets, and assume
      that A will get it.  If A doesn't, then it won't be able to
      continue the session and will have to restart the "inicast"
      process.

Note how this makes packets longer than at present - and/or requires
more packets being sent.  With the current system (IP address
performing both Identifier and Locator functions) there's no need for
this stuff.  The current system works fine for a unidirectional
and/or single packet communication, without any overhead.  Yet for
what you are describing, or for any other CEE (Loc/ID Separation)
approach, both hosts need to send and receive packets with the other
host before a single two-way application packet exchange can be
completed.

>>>> routing system such as ITRs, as in LISP, Ivip or (by some
>>>> other name) IRON?
>>>
>> There certainly is extra work.  Initially the sending host A
>> only knows B's Identifier, and it somehow uses this with the
>> number servers to get a packet to B.  I am not sure how A finds
>> out B's locator, but it needs to find this out ASAP so it can
>> send subsequent packets directly to B, without relying on any
>> other servers.
> 
> When A's inicast packet reaches B, B replies with its locator
> directly to A. Thus, both sides get to know their ID & Loc tuples.

This is assuming the "inicast" system can be trusted to send the
initial packet from A really to B, and to no other node which does
not have B's Identity.

But then, B needs a nonce from A to secure the B->A reply packet,
otherwise X could guess that A was sending packets to B, and send A
packets which appear to A to be replies from B.  Assuming X's packet
is accepted by A, then A will send packets to X, whenever it wants to
send packets to B.

> Just like doing any other resolution. 

No.

In today's system, if A has B's IP address, the two-way communication
proceeds without any delays, extra packets or extra state at all.

If A has to do a DNS lookup on B, then that is a DNS delay for A.
Then B can reply straight to A, using A's IP address found in the
source field of the initial packet.  It doesn't know for sure that
the initial packet came from A, but it does know that the routing
system will send the reply packet to A, or drop it.  So there is no
need for B to do any kind of DNS lookup or any other delay-inducing
process to respond to a new session from A.  It can send user
information in the reply packet, because it know that the packet will
never be sent to a host other than A, even if the packet which
appeared to be from A was sent by an attacker.

Therefore, in the current system, without any extra overhead or
delays, B can respond to a packet which has A's IP address in the
source field, with information it intends to get to A, without any
possibility that the information would arrive at a host other than A.

To ensure this with CEE involves the "inicast" - or whatever the
system is for secure Identifier to Locator lookups - by both hosts.

Since ILNP is supposed to support existing application protocols, it
needs to do these two lookups, in order that the application (which
may assume current network behaviour) will be assured that a reply to
A (in the above example) really goes to the node whose Identity is A
(unless it is dropped), and cannot go to any other node.

In your proposal, you have new application protocols, so perhaps you
don't always need to do both lookups, since the application won't be
making the same assumption.  But then, you need to have the logic of
many applications rewritten, with new protocols - not just keep the
current application protocol with a new interface to the IP stack.

I can't imagine any higher barrier to widespread adoption than the
need to rewrite application programs - especially if it involves
altering the actual protocol used by the application.

> But in the meantime the
> inital packet is on its way. And when the process of resolving
> completes the packet will likely be closer to its destination.
> This moment is when the directly tending ID server gets the
> packet.

I don't clearly understand you "inicast" system, but it will involve
delays and potentially long paths.  Your system needs to do this in
both directions A->B and A<-B.

>> When B gets a packet from A, it will have A's Identifier and it
>> may have A's Locator - but there's no way B can trust this
>> Locator.  So it needs to do a lookup, or whatever it is you
>> described with number servers, to send a packet to A, rather
>> than to some other host which pretends to be A.
> 
> No lookup is required. B would send a further handshake reply to
> A. A's reply would be the proof.

This is no proof at all.  X could have sent the packet to B, claiming
to be A (having A's Identifier) but using X's Locator.  With your
current proposal, B would reply to X, thinking it was replying to A.
 Then when it gets a response from what it thinks is A, it would have
no way of knowing it was really sending packets to X, not A.

B shouldn't send back anything to A unless it has reliably and
independently determined A's Locator, using your "inicast" system -
which is presumably reliable and 100% secure.

So there are delays and extra work for both nodes at the start of a
session.

>>> The routing system will consist of path selection facilities
>>> that make use of locators. The node ID system will consist of
>>> ID distribution/matching servers.

>> I am sure you could write this up in a way others could
>> understand, but it will take a few pages and probably require
>> some diagrams.
> 

I suggest you first write up what your goals are, and why you believe
it is necessary and desirable to burden all nodes with extra work in
order to do what CES systems (LISP, Ivip and IRON) do in the network,
without any extra work by nodes.  Depending on how the mapping system
works, there may be some delays, but there is no extra node effort,
longer packets, state in the nodes etc.

Ivip uses Distributed Real Time Mapping, which will generally involve
very short initial packet delays - too short, I believe, to have a
significant impact on any application protocol or any human
perception  of responsiveness.  The DRTM documentation is:

  1 -  http://www.firstpr.com.au/ip/ivip/drtm/   (Color diagrams.)

  2 -  http://tools.ietf.org/html/draft-whittle-ivip-drtm

  3 -  http://www.ietf.org/mail-archive/web/rrg/current/msg06128.html
       (Please read only the section on "DNS-based system so TRs can
        find DITR-Site-QSDs.)

I think you need to show how "inicast" is secure and establish a
system to secure Locator change messages.

Then I think you need to show how it is scalable, efficient, secure
and fast to do Locator change messages for mobility.  As far as I
know, you can't do this with any CEE (Loc/ID Separation)
architecture, for reasons discussed above and in my previous message.

I think it is pointless developing a scalable routing system which
doesn't provide global mobility.  As far as I know, the only approach
to mobility which will work is TTR Mobility.  This could be used by
LISP as well as Ivip.  I haven't read the latest IRON material so I
am not sure what Fred's Mobility plans are.

TTR Mobility is for CES architectures - not for a CEE proposal such
as yours.

  - Robin