Subject: Re: [RAM] revised draft proposed definitions

From: [email-masked] (Noel Chiappa)
Date: Tue, 12 Jun 2007 10:21:37 -0400 (EDT)

> From: Russ White <[email-masked]>

    >> Ok, but a locator does NOT denote reachability. Thus, a locator is a
    >> string of bits that indicates a topological location.

    > I think we should, perhaps, leave reachability out? It seems like both
    > a locator and and id indicate some element of reachability (?).

Russ, reachability is a very different kind of thing, more an operational
property (i.e. a property of a name in particular circumstances in an
functioning system) , rather than a semantic one (i.e. an inherent property
of a particular name).

To give some examples, let's use 'IPvN address', which has relatively well
understood properties (since differing definitions are a real problem in this
discussion), but has the same "indicates a topological location" property as
"locator". Assume I have a host H at a site S, which is connected to the rest
of the Internet via router R; H, S and R all have an IPvN addresses.

For the first example, if the cable which connects H to the rest of the world
is unplugged, it still has a correct and authorized IPvN address, but it is
no longer reachable (from anywhere). For a slightly more complex example,
consider the situation, but this time the link connecting R and the rest of
the world is unplugged. In this case, H is still reachable from hosts inside
S, but not from the rest of the world.

So we can see that "reachability" is not a property of an address, but a
property of a tuple, (source, reachable_destination). Moreover, depending on
the actual network connectivity, and the contents of the routing tables,
reachability of a particular (source, reachable_destination) tuple can vary
over time.

So, yes, because reachabilty is an operational property, and not an inherent
semantic property, it definitely should be placed in a separate category
(although any definitions document might useful explain the above).

	Noel

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

---

From: Russ White <[email-masked]>
Date: Tue, 12 Jun 2007 10:53:48 -0400

> reachability of a particular (source, reachable_destination) tuple can vary

Once you go to a locator/id split, it seems like the tuple would need to
be expanded to: {source, locator, id}. You could count "reachability" as
a "flag" for any specific tuple, but you can't set the flag without the
tuple in place. :-)

> (although any definitions document might useful explain the above).

It might be clearer to state that while the locator and id are required
to provide reachability, reachability is not always implied because you
have the full tuple. The problem is, I think, that reachability is not
an object, nor does it describe the object. It is a state, rather than a
descriptor, if you want to define it that way.

The problem is that the state isn't valid unless you have the
descriptors, so it all depends on the definition you're using. Any
definitions document should be clear on this, I think.

BTW, I do think the locator and ID are both required for the tuple. With
DNS, today, we have reachability without IDs, but I think this causes
problems for policy and security. It's much cleaner to require both
before the reachability "flag" can be set, or the reachability state to
be positive, or however you want to say it.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone