Subject: Re: [RAM] candidate properties of some new name types

From: [email-masked] (Noel Chiappa)
Date: Tue, 16 Jan 2007 19:36:18 -0500 (EST)

> From: Iljitsch van Beijnum <[email-masked]>

    >>> Irrespective of shim6, in my opinion the ability to overload is a
    >>> feature. Removing that feature just because it doesn't conform to the
    >>> contemporary notion of architectural cleanliness

I'm going to second Ran here. "Overloading is bad" is a pretty old idea,
dating back at least to the start of my professional career.

    >> The idea that such semantic overloading is undesirable goes back at
    >> least as far as Shoch.

    > It's the "overloading is bad" thing that I would call contemporary.

It's hardly new that people have been pointing out that this particular
overloading is bad. See, for instance. RFC-1498 - which is itself a reprint
of a paper from *1982*. So, exactly how is a *quarter-century* "contemporary"?

It's true that only recently have the majority of people finally conceded the
point, but a substantial minority have held this position for aeons. See, for
example, the Big-Internet discussions from when IPng was being argued about,
back in 1994, and you'll see it's pretty closely divided, even back then.

    > It has worked quite well for us for the better part of the 25 years
    > that IPv4 has been around. 

Lots of kludges and/or bad ideas work OK in small systems, and fail to work
as well as the the system gets larger. For a lot of things, almost anything
would have worked for the first N years of IPv4 - and did, all over the place.

Examples are legion. Our crappy original TCP retransmission algorithms worked
fine for many years - until they didn't, at which point we were in trouble
until Van Jacobsen fixed them. Allocating addresses to end-sites without
caring about who their provider was, worked fine until 1990 or so, when we
had to change that with CIDR. Etc, etc, etc.

This one's day has finally come, is all. Too bad the necessity of fixing it
wasn't accepted earlier, when doing so would have been a lot less painful.

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: [email-masked]
Date: Thu, 18 Jan 2007 14:18:18 EST

IMHO: the identifier should name some kind of stack, and the  locator as well 
. But here each part is conceived to be  just another IP address.Right ? The 
locator is not a combination of AS# +  some router's IP address. Right? 
 
Heiner

In einer eMail vom 18.01.2007 16:27:44 Westeuropäische Normalzeit schreibt  
[email-masked]:

> -  An Identifier names a node ("stack" in IRTF NSRG parlance)
>   and is not tied to a specific interface or location.

An  Identifier names the ultimate communicating entity. At the top it is  an
application. If an interface itself needs to communicate than it gets an  ID 
(in
addition to a locator). Otherwise it has a locator  only.

Thanks,
Peter 

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

> Some candidate properties  of names, for consideration.
> 
> 
> Locators:
> - A  Locator names a single sub-network, not an interface or node
>   (This is similar to a "routing prefix" in current parlance.)
> -  A node may have multiple Locators at the same time (e.g. due
>   to multi-homing of some sort).
> - A Locator is only used for  routing and forwarding packets,
>    except that the last-hop  router uses both the Locator and
>    the Identifier to look  up the destination link-layer information
>    (e.g. MAC  address) in the ARP/ND cache inside the router.
> 
> 
>  Identifiers:
> - An Identifier names a node ("stack" in IRTF NSRG  parlance)
>    and is not tied to a specific interface or  location.
> - A node may have multiple Identifiers concurrently.
>  - A node may use multiple Identifiers concurrently,
>     however a given single transport session must not change
>     Identifier during the lifetime of that transport session.
> - An  Identifier is not necessarily globally unique, but has
>    a  very high probability of being globally unique.
> - An Identifier is  unique within the scope of a given Locator
>    that it is  used with.
> - Identifiers, and not Locators, are included in  transport-layer
>    session state.
> 
> 
>  Ran
> 
> 
> NB:  This is *different* than SHIM6.   In SHIM6, the semantics of
>       an IPv6 address  are even more overloaded than before SHIM6.
>        In this concept, Locators have crisp semantics and Identifiers
>   have different crisp semantics -- no overloading of the  same
>       namespace for multiple  purposes.
> 
> 

______________________________________________________________________________
______
Want  to start your own business?
Learn how on Yahoo! Small  Business.
http://smallbusiness.yahoo.com/r-index

---

From: [email-masked]
Date: Fri, 19 Jan 2007 08:33:02 EST

My own arguing question was :
    The locator is not a combination of AS# +  some  router's IP address. 
Right?

Answer by Ran:
So far, I'm not getting into the details of what might constitute
the  internal format of a locator.  One can imagine a range of very
different  engineering choices there.  For now, O'Dell's term
"Routing Goop"  certainly is good enough for the locator (keeping
the details vague enough to  keep our options open).

Answer by Peter:
Why not. AS# could be a part of IP address within a routing  hierarchy.

Fine, so I conclude:  Better information may be  placed/structured/stacked 
into the locator, which I think is good.
 
Heiner

In einer eMail vom 19.01.2007 00:56:10 Westeuropäische Normalzeit schreibt  
[email-masked]:

Earlier,  Heiner Hummel wrote:
> IMHO: the identifier should name some kind of  stack, and the locator
> as well . But here each part is conceived to be  just another IP  
> address.
> Right ?
> The locator is  not a combination of AS# + some router's IP address.
> Right?

I  am definitely NOT thinking that "each part is just another IP   
address".
My thought is conceptually to deprecate the concept of  "address" and
instead have distinct locators and identifiers (with  different
namespaces for each -- so reducing the semantic  overloading).

The approach where "each part is an IP address"  increases,
rather than decreases, the semantic overloading.  That is  also
roughly the engineering decision that SHIM6 made.

So far, I'm  not getting into the details of what might constitute
the internal format  of a locator.  One can imagine a range of very
different engineering  choices there.  For now, O'Dell's term
"Routing Goop" certainly is  good enough for the locator (keeping
the details vague enough to keep our  options  open).

Ran

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 19 Jan 2007 10:33:49 -0500 (EST)

{Sorry this reply is kind of delayed - other things have intruded!}

    > From: RJ Atkinson <[email-masked]>
    > Date: Tue, 16 Jan 2007 18:59:30 -0500

    >> on networks which don't use IEEE 801 style addresses, where does the
    >> name of the interface in the local network's namespace go/come from?
    >> Are you assuming some sort of broadcast/database/etc lookup mechanism
    >> that you can use to translate identifiers to local network interface
    >> addresses? What do you do on networks that don't support network-wide
    >> broadcast? Use a database?

    > .. With IPv6, the current practice is to use ND on all link types, not
    > just those with a link-scope broadcast/multicast capability. So
    > network::link location resolution really isn't rocket science.

Yes, but it means there's an extra mechanism down there that has to be
working correctly before packets can be delivered. From a
complexity/robustness viewpoint, that's not good.

ARP in IPv4 is, quite literally, a bag on the side. It's a quite good bag (if
I may say so myself, having been the co-designer, along with Plummer :-), but
still, it was an after-thought - we were suddenly faced with generating a
48-bit local-network interface address, when we only had a maximum of 24-bits
to play with. ARP was the obvious fix - and, being a binding layer, was
immediately the subject of various hacks because the system (ta-da) didn't
have enough binding layers (a behaviour which continues to this day, sigh).

    >> The locator names the interface, and provides in and of itself all the
    >> bits that you need to get the packet to it.

    > That would be an alternative approach, and a somewhat different
    > architecture.

There may well be engineering reasons why your approach is preferable; e.g.
some existing mechanism (e.g. IPv6 ND) you want to re-use, or some other
engineering reason (e.g. deployment issues).

However, I'm currently (still?) looking at this question on a purely
architectural level, and trying to see if there are any architectural
reasons one might prefer your approach.

    > It is limiting in various ways, for example with respect to mobility.

Oh, balderdash. Your design provides mobility, of two kinds: i) binding a
different locator to an identifier, which provides mobility over an unlimited
scope - but "full" locators provide this kind of mobility too, and ii)
mobility over a limited scope (one named by a particular locator), via
changing the mapping in whatever mechanisms maps identifiers to the "rest" of
the locator.

I fail to see how providing this second, limited, mobility does that much for
you - one might claim it's cheaper/faster than the full mobility, but against
that one has to set the facts that first, as extra-architectural mechanism,
it's more complexity, and potentially problematic (the far end cannot see it
happening, even if it cares).

More importantly, if one really wants, one can do this kind of mobility with
"full" locators too - if you really need a local binding layer, for some
engineering reason, the last element(s) in the locator could say "use local
mechanisms to map this portion of the locator to the actual locator" (or
perhaps "use local mechanisms to map the identifier to the actual locator",
which gives exactly your mechanism).

    >> mixing naming and location function in two names is really not a good
    >> idea.

    > It isn't mixing them. The Locator names the subnetwork. The Identifier
    > names the node. One merely uses the name of the node

You're splitting an almost non-existent hair. Your argument seems to be that
the interface really does have a full locator (in some abstract sense), it's
just that the complete locator is not visible to the far end, the local part
is only visible locally. Using your logic, I can sort of show that IPv4 "has"
locators and identifiers too: most interfaces have a globally-unique locator
too (their IEEE 48-bit addresses), but they are only visible inside the local
scope, via ARP.

The fact remains that system wide, you don't have a full name for the
interface, one has to use the identifier as well - with the result that there
are a variety of scenarios (e.g. two interfaces to a single physical network)
in which one *cannot* name the interface completely, i.e. the inability to
fully name an interface means there are things one can't do.

Hence, my conclusion that your scheme mixes identification and location...

    > The node name does not vary as location changes, only the subnetwork
    > name varies, and the subnetwork name always follows the topology.

As I said, there may be good engineering reasons to accept your scheme, in
which the locator does not fully name the interface.

However, thinking purely architecturally, I still feel that fully naming the
interface in the locator is architecturally superior - simpler, and more
robust.

Before we move on to the engineering practicalities, are there any good
architectural reasons to prefer "partial" locators? I haven't given it a lot
of thought, I must admit (I've more been looking at what's bad about the
idea), so perhaps I'll come up with some if I ponder it.

Although the generic point I raised (in an architecture with "full" locators,
one can always drop the last element(s), if one wants the behaviour of
"partial" locators, but one cannot add the last element(s) if one is working
in a "partial" architecture") would seem to indicate can be no possible
architectural reason to prefer "partial" locators...

	      Noel