Re: [RAM] revised draft proposed definitions

[Russ White <riw at cisco.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 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.

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. :-)

> 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).

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

- --
riw at cisco.com CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGbrN8ER27sUhU9OQRAm3SAKCcDcDoy9+4ajxqNXSZ50bcPhlJmACfUJKo
GO1ouNB+XhVXRARRTtSphs8=
=EtmA
-----END PGP SIGNATURE-----

_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram