Re: [RAM] revised draft proposed definitions

Russ White <riw@cisco.com> Tue, 12 June 2007 13:07 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy65g-0004jH-4U; Tue, 12 Jun 2007 09:07:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy65f-0004jC-5t for ram@iab.org; Tue, 12 Jun 2007 09:07:19 -0400
Received: from xmail03.myhosting.com ([168.144.250.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy65d-00043c-S2 for ram@iab.org; Tue, 12 Jun 2007 09:07:19 -0400
Received: (qmail 29923 invoked from network); 12 Jun 2007 13:07:17 -0000
Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender <riw@cisco.com>) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for <rja@extremenetworks.com>; 12 Jun 2007 13:07:17 -0000
Message-ID: <466E9A7D.5010500@cisco.com>
Date: Tue, 12 Jun 2007 09:07:09 -0400
From: Russ White <riw@cisco.com>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: RJ Atkinson <rja@extremenetworks.com>
Subject: Re: [RAM] revised draft proposed definitions
References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> <466D69FC.3010003@cisco.com> <715690CE-8527-4123-9A09-101FC7EDF5EC@cisco.com> <466E7C4A.3000002@cisco.com> <10DD5D2F-6694-4097-BA8C-B7EC1E350A66@extremenetworks.com>
In-Reply-To: <10DD5D2F-6694-4097-BA8C-B7EC1E350A66@extremenetworks.com>
X-Enigmail-Version: 0.95.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: ram@iab.org
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

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


>>> 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 (?).
> 
> Neither indicates reachability.

> The original quote at top is correct.  Having a locator does not
> mean that there is a working forwarding path between one's
> current location and the location named by that original loocator.
> Purely as an example, an ACL somewhere along the path might
> cause one's packets towards that location to be dropped.

So, your basic argument is that because you may, at times, have a
locator and an id, and the device might still not be reachable, you can
never say locators or id's carry reachability information? That seems to
be stretching it a bit--if some of b is not contained in a, then none of
b must be contained in a.

If a locator/id pair never contains reachability, then reachability is a
mythological creature, and the Internet fails. The exception does not
rule out the general case.

An ID is useless for reaching a device without a locator, hence a
locator must be present to reach the device, hence a locator carries
some type of reachability information. If a locator didn't carry
reachability information, it wouldn't be required to reach a device. At
the same time, locator is useless for reaching a device without an ID.
Hence, and ID must be present to reach a device. If an ID didn't carry
any sort of reachability information, it wouldn't be required to reach
the device, hence an ID must carry some form of reachability information.

You may redefine "reachability," so there are two different types of
this beast, but if you can't reach something without a specific piece of
information, that specific piece of information carries reachability as
part of it's meaning.

Unless, of course.... You're going to propose a third, and completely
different thing, which doesn't exist in the routing context at all
today, a "reachability advertisement." This would have a "reachable
through this path" bit of some type, which says that not only does the
device exist, it is also reachable along a specific path. Since IP
networks are hop by hop, and not session oriented, the idea of a "path,"
itself, within IP, is rather ambiguous, and hence, such and
advertisement would be problematic, at best.

:-)

Russ

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

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

iD8DBQFGbpp9ER27sUhU9OQRAgUjAJ40fBPkOJPnE+hb0w8S7ZXu7jzVQQCfV65V
OZpOSuJsaOF+apG1HU5VpGU=
=8teH
-----END PGP SIGNATURE-----

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