Subject: [RRG] Terminology redux

From: RJ Atkinson <[email-masked]>
Date: Tue, 8 Jul 2008 10:15:59 -0400

Earlier, Tony Li wrote:
% In any switched network, the MAC address is used
% for a lookup in the bridge table to determine
% destination location. Thus, it clearly also
% has some locator functionality.

Some general observations:
- Many modern edge links (e.g. IEEE 802.11*, pre-JTRS,
   IEEE 802.16*, EVDO/EDGE) are neither switched nor bridged.

- Also, some Ethernet cable (e.g. coax) deployments
   still exist, though I don't see them often any more.

- Integrated Ethernet switch+router boxes are common; it is
   most of what we sell these days in the purple universe.

- In turn, many deployments (govt, enterprise, service provider,
   & other) run with L3 routing all the way to the edge box,
   with each end node being directly connected to that edge box
   (i.e. there is no bridging on the edge sub-network, just
   really simple output interface selection).

% Indeed. It's pretty clear that we can still have semantic
% cleanliness tho, as we can isolate a particular bit string
% as having L3 identifier semantics (coupled with L2 locator
% and L2 identifier semantics) and distinct from L3 locator
% semantics.

In at least some technologies that are being discussed on
this list, the "Network-layer" Identifier does not have
L2 Locator semantics.

Whether one considers such an Identifier to have L2
Identifier semantics depends mostly on how one defines
the layers; just as it can be hard to distinguish
between the "top of the network layer" and the "bottom
of the transport layer".  Is ARP at the top of layer
2 or the bottom of layer 3 ?  What layer is MPLS in ?

Quite separately from the above, I'm inclined to agree
with Brian C that an IEEE MAC address is an identifier,
not a locator.  Unlike an IP address (either version)
or a CLNP address (any address format), there simply
is no topology (e.g. routing prefix) encoded into an
IEEE MAC.  It is just an opaque ID.  The MAC can be
used as an index into a flat database, but using it
as a flat-database index doesn't magically transform the
MAC into a Locator.  If there were topology embedded
inside the bits of the MAC, I'd likely take the opposite
view.

That noted, the "EID" (sic) in LISP is simultaneously used
both for identity and for location (e.g. inside the end
sites).  This community has a word for objects with mixed
semantics of both location and identity -- we've called it
an "address" for several decades.  (just to be very clear:
This is a comment about the confusing terminology used by
LISP documents and advocates, not a criticism of the LISP
technology itself. :-)

While I think that an Identity/Location split is one path
forward, I don't think it is the only possible path forward.

I do think that this group would serve itself well to
define -- and actually use here -- more crisp terminology.
A number of the threads here seem to derive from differences
in the definitions of words, rather than material technical
differences.

Cheers,

Ran

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 8 Jul 2008 10:57:26 -0400 (EDT)

> From: RJ Atkinson <[email-masked]>

    > I'm inclined to agree with Brian C that an IEEE MAC address is an
    > identifier, not a locator. .. there simply is no topology (e.g. routing
    > prefix) encoded into an IEEE MAC. It is just an opaque ID. 

Exactly. One thing I'll add: _what_ it names is an interface, not any higher
level entity (such as an end-end entity like an 'endpoint', as I defined that
term).

There seems to sometimes be a tendency to forget that names have two
important attributes: i) the _form_ of the name (flat identifier,
topologically-significant structured name [e.g. IPv4 address],
organizationally-significant structured name [e.g. DNS name]), and ii) _what_
class of entities it names.

So when one says that a name is an 'identifier', I take that as shorthand for
'opaque flat identifier'. We have also been using it in our discussions here
as shorthand for 'opaque flat endpoint identifier', but it's important to
remember that the term 'identifier' is therefore ambiguous between those two
potential meanings (which is, I believe, the root of the issue Ran and Brian
are responding to here).

    > While I think that an Identity/Location split is one path forward, I
    > don't think it is the only possible path forward.

Any other examples?

    > A number of the threads here seem to derive from differences in the
    > definitions of words, rather than material technical differences.

It has ever been thus... :-)

	Noel

---

From: Scott Brim <[email-masked]>
Date: Tue, 08 Jul 2008 11:04:03 -0400

On 7/8/08 10:15 AM, RJ Atkinson allegedly wrote:
> 2 or the bottom of layer 3 ?  

ARP is an "adaptation function", to facilitate one layer network running 
over another.

What layer is MPLS in ?

Intra-domain MPLS is just an encapsulation for specialized carriage of 
packets over an IP network.  Inter-domain MPLS is a layer network (see 
previous ITU reference).

> inside the bits of the MAC, I'd likely take the opposite

This depends on how it's used.  An IP address does not have any topology 
encoded into it either.  Rather, we assign IP addresses in line with the 
topological hierarchy, and interpret addresses accordingly in routing. 
That is not an intrinsic property of the address.

But the main point is that you can use anything as input to your 
location function or your identification function.  That's not a good 
criterion.  What you need is not identifiers that are not used for 
location purposes (that gets us into these terminology cycles), but 
rather: names that are location-independent in the context of the 
routing and addressing architecture under consideration, and thus can be 
used as identifiers.  An architecture that makes having those easier is 
a good thing.

Scott

---

From: Scott Brim <[email-masked]>
Date: Tue, 08 Jul 2008 11:05:43 -0400

> It has ever been thus... :-)

Let me know if I should post the Hobbes quotation again.

---

From: "William Herrin" <[email-masked]>
Date: Tue, 8 Jul 2008 11:16:46 -0400

> 2 or the bottom of layer 3 ?  What layer is MPLS in ?

Ran,

Rather than get sidetracked by terminology and arguments over the
definition of an identifier, lets return to the original point: in IP,
layer 3 and above are not tightly bound to the layer-2 address.
Because of this, multiple layer-2 addresses can be used during the
delivery of an IP packet and the layer-2 addresses in use can change
willy-nilly without impacting the function of the IP protocol.

Some examples of this in action are:

* Proxy ARP
* ARP-based failover
* Linux will by default send ARP responses for any of it's IP
addresses on any interface where it receives an arp request, even if
the address is not configured on that interface.

On the other hand, layer 4 is tightly bound to layer 3: a session is
identified the ports plus the layer 3 addresses. The session does not
survive either of the layer-3 addresses changing.

-IF- the layer 4 protocols were redesigned in such a manner where this
was not the case then the layer-3 address could change willy-nilly as
well. This has major implications for address-based route aggregation.
I claim they're major enough to solve the route scaling problem.

What's the counterexample? Is it impossible to design a protocol that
permits layer-4 on different hosts to find each other dynamically as
with ARP at the layer2/3 boundary? Is it impossible to design a
wide-scale aggregable addressing protocol? Given an optimal address
layout, would the topology of the Internet still require too many
routes? Would this sort of design induce the same sort of route-policy
violations that geographical aggregation does? Such a change would
break the hell out of many of the existing network security models.
Would the resulting protocols be unsecurable?

What's the counterexample? Why -won't- decoupling layer 4 from the
layer 3 address permit a -successful- solution to route scaling
through topological route aggregation?

Regards,
Bill Herrin

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