Subject: [rrg] Consensus check: terminology

From: Tony Li <[email-masked]>
Date: Tue, 07 Apr 2009 20:52:50 -0700

Hi all,

As the conversation has died down, I'm going to guess that we've 
converged.  The consensus check can be found here: 
http://doodle.com/9sybb8dmk5phvp99

Please vote for or against these definitions:

locator    A locator is a name for a point of attachment within the
	   topology at a given layer.  Objects that change their point
	   of attachment(s) will need to change their associated
	   locator(s).  By default, a locator refers to layer 3.  It
	   is also possible to have locators at other layers.
	   Locators may have other properties, such as their scope
	   (local or global (default)) and their lifetime (ephemeral
	   or permanent (default)).

identifier An identifier is the name of an object at a given layer;
	   identifiers have no topological sensitivity, and do not
	   have to change, even if the object changes its point(s) of
	   attachment within the network topology.  Identifiers may
	   have other properties, such as the scope of their
	   uniqueness (local or global (default)), the probability of
	   their uniqueness (statistical or absolute (default)), and
	   their lifetime (ephemeral or permanent (default)).

address    An address is a name that is used as both an interface
	   locator and an endpoint identifier.

Tony

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 08 Apr 2009 00:11:10 -0400

Close enough for me.
Joel

Tony Li wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Michael Menth <[email-masked]>
Date: Wed, 08 Apr 2009 09:11:24 +0200

Hi Tony,

I haven't followed all the discussions. What I am missing is the 
definition of an endpoint identifier. Is it the name of a device 
attached at a certain location, i.e. an ephemeral identifier for that 
box (not interface) because it can be replaced by others and so that 
name is not permanent? That's just a guess and an extrapolation from its 
use in LISP according to my understanding. But it's not given in the text.

Apart from that, the definitions seem clear to me.

Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Ved Kafle" <[email-masked]>
Date: Wed, 8 Apr 2009 16:27:49 +0900

How about slightly modifying the definition of address to indicate that an
address is, by default, a locator? It can be treated as an identitier when
it goes into network protocols of layer 4 and above.

Ved Kafle

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony
Li
Sent: Wednesday, April 08, 2009 12:53 PM
To: [email-masked]
Subject: [rrg] Consensus check: terminology

Hi all,

As the conversation has died down, I'm going to guess that we've converged.
The consensus check can be found here: 
http://doodle.com/9sybb8dmk5phvp99

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 08 Apr 2009 01:14:55 -0700

> Apart from that, the definitions seem clear to me.

Hi Michael,

Along the way, we decided to separate the properties from the objects. 
Thus, in defining an 'identifier', we're defining entire classes of 
namespaces.  Our agreement is that the object can then be attached 
independently of this.  Thus, one can have an endpoint identifier, an 
interface identifier, a stack identifier, etc.

Regards,
Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 08 Apr 2009 01:16:08 -0700

> it goes into network protocols of layer 4 and above.

Hi Ved,

I think we already have that.

> 	   locator and an endpoint identifier.

Thus, an address is both a locator and identifier.

Tony

---

From: Michael Menth <[email-masked]>
Date: Wed, 08 Apr 2009 10:47:24 +0200

Hi Tony,

this does not really answer my question. Let me rephrase it: what is an 
endpoint?

Regards,

    Michael

Tony Li schrieb:
>> name is not permanent? That's just a guess and an extrapolation from 
>> its use in LISP according to my understanding. But it's not given in 
>> the text.
>>

---

From: Scott Brim <[email-masked]>
Date: Wed, 8 Apr 2009 07:03:43 -0400

> http://doodle.com/9sybb8dmk5phvp99

Ouch.  I had to go do my day job for a couple of days.  I'll be back
soon.  Please don't close this.

---

From: Roland Bless <[email-masked]>
Date: Wed, 08 Apr 2009 13:21:37 +0200

Hi Michael,

> this does not really answer my question. Let me rephrase it: what is an

What the term endpoint denotes depends on which level/layer you are
looking at: do you mean "host/end-system endpoint" or
"transport connection endpoint" or "application endpoint" etc.?
In case you mean an identifier for a "host" (which could be virtual
BTW), the given identifier definition applies, too. I don't see anything
special there. It's sure that also some locators/addresses will
lead to the "host" (or its interfaces/stacks) in order to deliver
data to it.

Regards,
 Roland

---

From: Michael Menth <[email-masked]>
Date: Wed, 08 Apr 2009 13:28:14 +0200

Hi Roland,

apparently an endpoint can be multiple things. Therefore, I suggest to 
add a defintion for an endpoint. It sounds like a name of a source or 
target in communication on some layer. Examples would be helpful.

Regards,

    Michael

---

From: William Herrin <[email-masked]>
Date: Wed, 8 Apr 2009 10:28:33 -0400

On Tue, Apr 7, 2009 at 11:52 PM, Tony Li <[email-masked]> wrote:
>  The consensus check can be found here: http://doodle.com/9sybb8dmk5phvp99

Tony,

Looks like I get to play lonely voice of dissent: these definitions
don't provide me with a useful language to talk about routing. With
these definitions adopted, I would need to strip the words from most
of the documents I've produced as they simply don't fit.

In addition, the definition of address is demonstrably wrong.

>           locator and an endpoint identifier.

Counterexample #1: RFC1918 IP addresses used inside a LAN consisting
of a personal computer, an ethernet hub and a NAT device. The IP
address in this example contains no locator semantics whatsoever, at
least not as you've defined a locator.

Counterexample #2: The IP address of an anycasted DNS service. The IP
address neither identifies an endpoint nor locates a particular
interface's points of attachment to the network. Instead it identifies
a service and specifies multiple locations via which that service can
be obtained.

Regards,
Bill Herrin

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

---

From: Dow Street <[email-masked]>
Date: Wed, 8 Apr 2009 08:16:40 -0700

On Apr 7, 2009, at 8:52 PM, Tony Li wrote:

> converged.  The consensus check can be found here: http://doodle.com/9sybb8dmk5phvp99
>

Also tied up with day job stuff recently...

I don't think this one is quite there yet since it doesn't directly  
address the question of how (a) namespace semantics and (b) the  
associated routing system are involved in characterizing the name of  
an attachment point as a locator (or not).  I think some of this  
relation is implied in the language above, but it is still fuzzy...

Using the postal example,

	123 High Street,
	Bigtown,
	Green County,
	Outer Luvania

We would agree (I think) that if an object / person moved next door,  
and still wanted to be reachable, it would need to use a different  
locator (say, 125 High Street).  However, what if larger sections of  
the geography itself move - perhaps today Green County is beside Blue  
County, but tomorrow it is next to Red County.  Some of the location  
information is stored outside the locator itself - in a map of some  
sort.  This map could be a static reference that all components of the  
system are aware of through outside means (e.g. a traditional  
geographic map), or it could be a dynamic map (e.g. the current system  
state of a routing system).  Depending on the nature of the "change to  
the point of attachment", and the characteristics of the system  
geography and map of that geography, the (i) locator name may need to  
change or the (ii) map itself may need to change.

R,
Dow

---

From: Eliot Lear <[email-masked]>
Date: Wed, 08 Apr 2009 17:44:57 +0200

I'm sorry for not paying attention for a while, Tony, but I think we can 
improve on the wording by reducing it.

>        (local or global (default)) and their lifetime (ephemeral

I propose generic definitions and then applying them in specific cases.  
Hence...

A locator is a value or string that specifies location of an object 
within a physical or logical topology.

>        their lifetime (ephemeral or permanent (default)).

An identifier is a value or string that references a specific object or 
group of objects.

The discussion of lifetime is relevant in the context of binding an 
identity to various properties.  Some properties are permanent, and some 
are ephemeral.  I will probably always have the same blood type, but my 
location changes.  In the case of a host, its name may stay the same, 
perhaps even its distinguished name, but its private and public keys may 
or may not change, even when its address does change.

In this discussion please keep in mind both host names and how GSLBs 
tend to work.

Eliot

---

From: Roland Bless <[email-masked]>
Date: Wed, 08 Apr 2009 22:06:18 +0200

Hi Bill,

> least not as you've defined a locator.

I disagree. The IP address is used to locate the component's interface
within the subnet. The resolution protocol is ARP in this case as
it "locates" the interface belonging to the particular IP address.
So first it is checked whether the destination is in the same subnet
(to me this is also related to finding the location) and if it is
the case, ARP "locates" the particular interface.

> a service and specifies multiple locations via which that service can

Correct, but I don't think that this is really a counterexample:
The Anycast address identifies _an_ endpoint (though not a
particular/specific one) that hosts the DNS service. Anycast
routing will locate _an_ interface belonging to such an endpoint.

Regards,
 Roland

---

From: William Herrin <[email-masked]>
Date: Wed, 8 Apr 2009 16:59:46 -0400

On Wed, Apr 8, 2009 at 4:06 PM, Roland Bless <[email-masked]> wrote:
> particular/specific one) that hosts the DNS service.

Hi Roland,

Nice try, but "an" is synonymous with "one" and "one endpoint" doesn't
mean "a more or less random choice among the many endpoints eligible
to respond."

Even if it did, packets may be routed to different servers on a packet
by packet basis depending on the metric and whether per-packet load
sharing is enabled. The address can hardly be an endpoint identifier
if a different endpoint is selected for every single packet.

> Anycast

Nope. The anycast DNS servers are configured with unicast IP addresses
on their network interfaces. The anycast address is assigned as a
local machine alias, reachable only by packets that get routed to the
machine through one of its unicast interfaces.

Counter-example #3:

Describe for me, if you will, the locator and endpoint identifier
semantics associated with 127.0.0.1.

Counter-example #4:

At home, I duck bandwidth limits on my ISP's usenet server by
configuring my Linux router to apply NAT and spread the source address
for outbound requests to TCP port 119 among all of my static IP
addresses on a connection by connection basis. It does this both for
source IPs used by machines are tasked to other purposes and for IP
addresses which are not assigned to any machine.

In all of those cases, the NAT machine functions as a normal router
and packet-filtering firewall in for packets except for the specific
ones where the exterior TCP port is 119. It does not mangle or
translate any other packets.

In this configuration, the source IP address has no endpoint
identifier semantics whatsoever, with Tony's definition or any other.
The TCP connection ID looks a lot like an identifier but the source IP
address by itself has only locator semantics, and then only until the
entry into my network after which packets with an external port of 119
go one way and the other packets go one of a number of different
directions.

What was it Hamlet said? More things on heaven and earth?

Regards,
Bill Herrin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 08 Apr 2009 22:56:48 -0400

The last analysis I saw is that anycast is in some sense a fiction. 
That is, it is not meaningful to describe an anycast IP "address" as an 
address according to any of the useful definitions of address.
Rather, it is a name for a collection of things.
We have merely overloaded the routing system so as to route on that 
particular kind of name.

Yours,
Joel

---

From: Tony Li <[email-masked]>
Date: Wed, 08 Apr 2009 21:14:03 -0700

Hi Dow,

> I don't think this one [locator] is quite there yet since it doesn't directly 
> associated routing system are involved in characterizing the name of an 
> attachment point as a locator (or not).  I think some of this relation 
> is implied in the language above, but it is still fuzzy...

The definition of locator isn't supposed to involve the specific routing 
system and it's not meant to specify or constrain the path in the 
general case.  Locators are supposed to define 'where' something is, not 
'how to get there'.

> We would agree (I think) that if an object / person moved next door, and 
> still wanted to be reachable, it would need to use a different locator 
> (say, 125 High Street).  However, what if larger sections of the 
> geography itself move - perhaps today Green County is beside Blue 
> County, but tomorrow it is next to Red County.  

Well, it's then the job of routing to compute that path.  Certainly, you 
wouldn't want a situation where every node on the network would have to 
recompute its locator every time there was a topology change.

Tony

---

From: Dow Street <[email-masked]>
Date: Wed, 8 Apr 2009 22:11:50 -0700

On Apr 8, 2009, at 9:14 PM, Tony Li wrote:

>
> Hi Dow,
>
>> I don't think this one [locator] is quite there yet since it  
>> doesn't directly address the question of how (a) namespace  
>> semantics and (b) the associated routing system are involved in  
>> characterizing the name of an attachment point as a locator (or  
>> not).  I think some of this relation is implied in the language  
>> above, but it is still fuzzy...
>
>
> The definition of locator isn't supposed to involve the specific  
> routing system and it's not meant to specify or constrain the path  
> in the general case.  Locators are supposed to define 'where'  
> something is, not 'how to get there'.

But if the "where" name does not encode *any* information about "how  
to get there", then it doesn't really have any location semantics,  
right?

---

From: Dow Street <[email-masked]>
Date: Wed, 8 Apr 2009 22:31:42 -0700

On Apr 8, 2009, at 9:14 PM, Tony Li wrote:

>> We would agree (I think) that if an object / person moved next  
>> door, and still wanted to be reachable, it would need to use a  
>> different locator (say, 125 High Street).  However, what if larger  
>> sections of the geography itself move - perhaps today Green County  
>> is beside Blue County, but tomorrow it is next to Red County.
>
>
> Well, it's then the job of routing to compute that path.  Certainly,  
> you wouldn't want a situation where every node on the network would  
> have to recompute its locator every time there was a topology change.

Maybe we can close the terminology gap here by defining a few  
different kinds of topology change.  Then I think the latest locator  
definition might make sense if the "topology change" phrase in that  
definition referred to only some of these kinds of changes, but not  
all.  In other words, I'm not sure if we have a different  
understanding of the properties in play, or if our understanding is  
reasonably similar and it is just the words that are causing the  
confusion.

R,
Dow

---

From: Tony Li <[email-masked]>
Date: Thu, 09 Apr 2009 00:37:49 -0700

Dow Street wrote:
> But if the "where" name does not encode *any* information about "how to 
> get there", then it doesn't really have any location semantics, right?

Does our mail address of

	123 High Street,
	Bigtown,
	Green County,
	Outer Luvania

Tell us *any* information about how to get there?

Seems to have a lot of location semantics tho, yes?

Tony

---

From: Dow Street <[email-masked]>
Date: Thu, 9 Apr 2009 06:52:03 -0700

Tony,

Thanks for the comments.  More below...

On Apr 9, 2009, at 12:37 AM, Tony Li wrote:

> Dow Street wrote:
>> But if the "where" name does not encode *any* information about  
>> "how to get there", then it doesn't really have any location  
>> semantics, right?
>
>
> Does our mail address of
>
> 	123 High Street,
> 	Bigtown,
> 	Green County,
> 	Outer Luvania
>

I think you can say there is a often a continuity convention in names  
for sections of geographic landscapes.  That is, someplace in Green  
county is generally reachable from another place in Green country  
without having to exit Green county.  This is, of course, not always  
the case (e.g. Alaska).  There is also an implied hierarchy in the set  
of names for map sections in this address, e.g. Bigtown is "in" Green  
County.  Based on these conventions, and given the name of the  
location, one might say you could derive a loose path from your  
present location in the landscape to the point named by this locator,  
even without an full / explicit map.  "First get to Outer Luvania,  
then find Green County, etc.."   I think this information constitutes  
some notion of "how to get there".  However, we may not want to call  
it a "path", but more of a "plan for a path" that does not become an  
actual path until we add a road sign that says "Bigtown over there".   
If this (path) is what you are defining as information on "how to get  
there", then I think we are in sync conceptually.

> Seems to have a lot of location semantics tho, yes?

I would say it does.  Specifically those semantics are:

- the (country, county, city, state, street, number) hierarchy of  
names (where each level of names in the hierarchy is flat wrt to the  
names of the others)
- the numerical, proximity semantics of the street number

R,
Dow

---

From: William Herrin <[email-masked]>
Date: Thu, 9 Apr 2009 10:14:04 -0400

On Wed, Apr 8, 2009 at 10:56 PM, Joel M. Halpern <[email-masked]> wrote:
> The last analysis I saw is that anycast is in some sense a fiction. That is,
> it is not meaningful to describe an anycast IP "address" as an address
> according to any of the useful definitions of address.

Joel,

So you see an abnormality here, not a pattern in the evolution of routing?

Regards,
Bill Herrin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 09 Apr 2009 10:22:36 -0400

What I see is a hack that would be ineffective in a system that actually 
drove serious aggregation.  If we really drove prefixes to 
aggregatability, then only those few exceptions which were highly 
unusual could use the equivalent of IPv4 Anycast.
(Note, this is different from IPv6 anycast which, as I understand, is 
more like naming a portion of the map, rather than trying to name an 
arbitrary set of scattered end-nodes.)

So yes, I think anycast as captured by IPv4 treatment (like anycast DNS) 
is an abnormality, not a useful direction.
If we want to make that service a first class citizen, we will have to 
do so very differently, and recognize the costs as with multicast.

Yours,
Joel

---

From: Tony Li <[email-masked]>
Date: Thu, 09 Apr 2009 09:18:09 -0700

Dow Street wrote:

> without having to exit Green county.  This is, of course, not always the 
> case (e.g. Alaska).  There is also an implied hierarchy in the set of 
> names for map sections in this address, e.g. Bigtown is "in" Green 
> County.  Based on these conventions, and given the name of the location, 
> one might say you could derive a loose path from your present location 
> in the landscape to the point named by this locator, even without an 
> full / explicit map.  "First get to Outer Luvania, then find Green 
> County, etc.."   I think this information constitutes some notion of 
> "how to get there".  

That's certainly one possible path, but it may well not be optimal. 
What you're really pointing out here is that in a hierarchical locator 
system, that following the path via aggregates itself becomes a 
candidate path, *if* you can tell where the aggregates are.  However, to 
do that you again need the information held in the routing subsystem.

There are trivial examples where the candidate path implied by such 
routing are suboptimal, and where "cold-potato" routing is optimal. 
Imagine the case where all of the roads in Green County are very, very 
poorly maintained and full of potholes that make you drive slowly (i.e., 
high metric).  The optimal path is to stay outside of Green County until 
you get to the point outside of the county that is closest to the 
destination.

> However, we may not want to call it a "path", but 
> more of a "plan for a path" that does not become an actual path until we 
> add a road sign that says "Bigtown over there".  If this (path) is what 
> you are defining as information on "how to get there", then I think we 
> are in sync conceptually.

Agreed.

Tony

---

From: William Herrin <[email-masked]>
Date: Thu, 9 Apr 2009 12:50:46 -0400

On Thu, Apr 9, 2009 at 10:22 AM, Joel M. Halpern <[email-masked]> wrote:
> drove serious aggregation.

Joel,

Okay, well, I see an evolutionary pattern in the routing architecture.

I see a set of core services, like map resolution, where causing the
first packet to reach any one of the many eligible and available
respondents represents a significant efficiency gain for the overall
Internet architecture versus a unicast timeout and retry cycle which
continues until an available respondent is found.

And I see more of it in our future. Frankly, I'm surprised no one has
published an RFC describing an "anycast DNS resolver address" that can
be statically configured in TCP/IP network stacks with the expectation
that it'll reach the nearest operational DNS resovler. It would
greatly simplify client configuration and would make maintenance
downtime on the primary resolver much less disruptive.

If its practical for anycast to be an integral part of unicast routing
then it's likely to be suboptimal or even destructive to architect it
as a peer to unicast routing.

I also foresee a combined anycast/multicast address where a host sends
a multicast packet to a single unknown respondent on the LAN, the
local router keeps track of whether there is a respondent on the LAN,
and if there isn't then the router takes the multicast packet and
forwards it unicast to the nearest respondent that has introduced a
route into the system.

With the combined address, a host could perform a map lookup to an
architecurally defined destination (zero configuration) by emitting a
single packet on the LAN with the expectation that barring packet loss
it'll reach a system capable of fulfilling the map lookup. A minor
tweak would solve the noise on the LAN by having the host subsequently
use the respondent's unicast IP address until there's a timeout.

But I 'spose that's an ineffective hack too, yes?

Regards,
Bill Herrin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 09 Apr 2009 15:34:44 -0400

Let me turn this about.
If the "anycast" we are talking about is something that must be used 
only by a few specialized services that are intended to optimize certain 
network behaviors, then it is a hack.  Maybe a useful hack, but still a 
hack.

Conversely, if we are expecting to allow anycast for any distribution of 
services, then it had better not be in the core routing system.  Such 
anycast "addresses" do not name a location.  Hence they are inherently 
non-aggregateable.  They need to go through a mapping system of some 
sort before we ask packet forwarding to handle them.
(Yes, there are architectures where routing does not require "where", 
such as compact routing.  But until we know how to make such systems 
actually work I will not assert that even they can handle this sort of 
anycast.)

Yours,
Joel

---

From: William Herrin <[email-masked]>
Date: Thu, 9 Apr 2009 16:15:33 -0400

On Thu, Apr 9, 2009 at 3:34 PM, Joel M. Halpern <[email-masked]> wrote:
> services, then it had better not be in the core routing system.

Joel,

That's a pretty harsh view for something that's steadily becoming the
defacto standard for the DNS roots, standard for the TLD roots and
forms part of the technological underpinning of Neustar's UltraDNS
service among others.

Regards,
Bill

---

From: Scott Brim <[email-masked]>
Date: Thu, 09 Apr 2009 16:48:49 -0400

Tony Li allegedly wrote on 04 09 2009 3:37 AM:
>> to get there", then it doesn't really have any location semantics, right?
> 
> 
> Does our mail address of
> 
>     123 High Street,
>     Bigtown,
>     Green County,
>     Outer Luvania
> 

There are many bits of "where" information which are not allocated to
specific edge attachment points.  We can name them, but for now the most
important thing is that NOT ALL bits of 'where' information are
'locators'.  Locators should be restricted to being names allocated to
specific edge attachment points and should not include group addresses
or any other abstractions.

However, just because a piece of 'where' information is not a locator
doesn't mean it has to be an identifier either.

> "forwarding selector", "f-selector" - The field in the packets which the
> 	routers look at to decide where to send the packet next. In X.25,
> 	the f-selector si the VC-ID, in IPv4, the 'destination IP address'.

Actually since this is the new millennium, a forwarder can a number of
forwarding selectors, not just one.

---

From: Scott Brim <[email-masked]>
Date: Thu, 09 Apr 2009 17:09:15 -0400

> Please vote for or against these definitions:

I voted against ...

>        (local or global (default)) and their lifetime (ephemeral

This works for me except for anycast.  The problem is that if you have
an anycast address you might not _need_ to change it if you move to a
different point of attachment, and since that particular point of
attachment might not have any other name associated with it, IMHO within
a single network, anycast _does_ name a particular point of attachment.

So I'm back to the suggestion I made before you included "at a given
layer": a locator is a name for a point of attachment, and if an object
moves its associated locator(s) might not change but it cannot assume
that they will not.  Perhaps the text could say "may have to change"
or "cannot be expected not to change".

>        their lifetime (ephemeral or permanent (default)).

wfm

>        locator and an endpoint identifier.

wfm

Scott