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
- [RAM] revised draft proposed definitions RJ Atkinson
- Re: [RAM] revised draft proposed definitions Eliot Lear
- Re: [RAM] revised draft proposed definitions Tony Li
- [RAM] Re: revised draft proposed definitions Stephane Bortzmeyer
- Re: [RAM] revised draft proposed definitions HeinerHummel
- Re: [RAM] Re: revised draft proposed definitions Brian E Carpenter
- Re: [RAM] revised draft proposed definitions Brian E Carpenter
- Re: [RAM] revised draft proposed definitions Russ White
- Re: [RAM] revised draft proposed definitions RJ Atkinson
- Re: [RAM] revised draft proposed definitions JFC Morfin
- Re: [RAM] Re: revised draft proposed definitions Scott W Brim
- Re: [RAM] revised draft proposed definitions Russ White
- [RAM] Re: revised draft proposed definitions Stephane Bortzmeyer
- Re: [RAM] revised draft proposed definitions Noel Chiappa
- Re: [RAM] revised draft proposed definitions Russ White
- Re: [RAM] revised draft proposed definitions Tony Li
- Re: [RAM] revised draft proposed definitions Michael