Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass

From: [email-masked] (Noel Chiappa)
Date: Sat, 4 Apr 2009 12:35:50 -0400 (EDT)

> From: Tony Li <[email-masked]>

    > Our job isn't to articulate common usage; it's to define what the
    > terminology should be.

I disagree, because in my experience, trying to re-define terms which are
already in common use is a non-starter.

So the best we can do for the Big Three (address, locator, identifier) is to
come up with definitions which reasonly match what they mean to _most_ people
now, and hope that the outliers eventually give up on their idiosyncratic
personal definitions, and start using the one most people have.

For the Big Three, I think your version of Sat, 28 Mar 2009 20:44:11 (perhaps
very subtle tweaked) is about as good as we can get. Note that the
definitions for those three will have to be a little 'loose', because if you
make them _more_ specific, you will start to loose people from the "_most_
people" pot above.

If we need terms for very specific things, we need to pick new words. In
particular, the concept of 'field(s) in the header which a packet switch
looks at to pick the next hop' is a concept which, AFAIK, does _not_ have a
well-known term - and there's a perfect place for some new terminology.

    > Differentiating between destinations and waypoints seems to me to be
    > more about the forwarding mechanism than about the namespace itself.

Exactly. To me, a location in the network connectivity graph is just.. a
location in the network connectivity graph. (Which leads to 'locator: name of
a location in the network connectivity graph' - perhaps you could put that in
as an alternative definition.)

Note also (in light of some other comments here that I don't have time to
reply to in detail) that in general, the 'name of the location' is only
actually _used_ at the internetwork level (for getting user traffic to the
named location).

It may seem that higher-level entities _also_ have locations; e.g. if you
have a application which is running in a stack has only a single interface,
that application also 'sort of' has a location. _However_, as soon as you say
that a higher-level thing can be reached through more than one place in the
network (or 'attached to more than one place in the network') - which is what
multi-homing is - then the thing no longer has 'a' location.

So either i) higher-level things can have more than one 'location' at a time
(which is a slightly counter-intuitive property of 'location of a thing', for
non-quantum-mechanicians), or ii) higher-level things do not in fact actually
have locations - we just have the illusion that they do, in simple cases.

	Noel

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Apr 2009 14:23:45 +1200

On 2009-04-05 04:35, Noel Chiappa wrote:

...
> 'locator: name of a location in the network connectivity graph'

Oh. Finally a version that appears to be logically complete
and unambiguous. Thanks.

   Brian

---

From: Scott Brim <[email-masked]>
Date: Wed, 15 Apr 2009 14:29:10 -0400

> actually _used_ at the internetwork level (for getting user traffic to the

Clarification: it is only used _for location_ at the level at which it
names a location and by functions which do forwarding.  Consider
MIPv6: from the point of view of a correspondent node, to start with a
home address names, and only names, a point of attachment.  Later on,
when "route optimization" is done, the home address is also used as
part of authentication and session identification.  But the functions
that use it in those ways are not part of IP forwarding.

> It may seem that higher-level entities _also_ have locations; e.g.
> if you have a application which is running in a stack has only a
> single interface, that application also 'sort of' has a location.

Bzzt.  If you want to talk about "location" of an application, be very
careful what your layers are, and your layer networks.  You can talk
about location of a web services server in a web services layer
network.  That is far above IP and IP is not involved.  You can also
say that to reach an application via IP you need to send IP packets to
a particular IP-layer location.  These two views are independent.

> _However_, as soon as you say that a higher-level thing can be
> reached through more than one place in the network (or 'attached to
> more than one place in the network') - which is what multi-homing is
> - then the thing no longer has 'a' location.

Whether it has a location in its own application-level layer network
is not affected by how many IP-level connections there might be.  

swb

---

From: Scott Brim <[email-masked]>
Date: Wed, 15 Apr 2009 15:48:29 -0400

Excerpts from Scott Brim on Wed, Apr 15, 2009 02:29:10PM -0400:
> careful what your layers are, and your layer networks.  

I haven't used the term layer network in a while, and I did in this
message, so I should explain it.  It came out of ITU-T SG15.  I'm
CCing Malcolm Betts who will answer any questions :-p.

A layer network may have all 7 layers of the old X.200 7-layer model.
It also has its own point-of-attachment namespace, control, and
management.  You can stack layer networks, and/or concatenate them.

Sonet/SDH is one or more layer networks.  ATM is one (iirc ATM has
X.200 layers 1-5).  IP is a layer network.

IMHO single-hop MPLS pseudowires are not a layer network, but
multi-hop PWs are.  That's because multi-hop PWs added a namespace for
points of attachment.

Web Services can form a layer network.  It even has loose-source
routing.

swb