Re: NHRP question
Yakov Rekhter <yakov@cisco.com> Thu, 19 October 1995 14:49 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11686;
19 Oct 95 10:49 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa11682;
19 Oct 95 10:49 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com
(8.6.12/8.6.12) with ESMTP id KAA14361; Thu, 19 Oct 1995 10:23:54 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id
KAA22381 for rolc-out; Thu, 19 Oct 1995 10:31:48 -0400
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by
maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id KAA22372 for
<rolc@nexen.com>; Thu, 19 Oct 1995 10:31:44 -0400
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by
guelah.nexen.com (8.6.12/8.6.12) with ESMTP id KAA14311 for <rolc@nexen.com>;
Thu, 19 Oct 1995 10:21:38 -0400
Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by
hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id HAA04662;
Thu, 19 Oct 1995 07:27:25 -0700
Message-Id: <199510191427.HAA04662@hubbub.cisco.com>
To: Eric Gray <gray@ctron.com>
cc: rolc@nexen.com
Subject: Re: NHRP question
In-reply-to: Your message of "Thu, 19 Oct 95 10:04:14 EDT."
<30865ADE.11F0@ctron.com>
Date: Thu, 19 Oct 95 07:27:25 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Yakov Rekhter <yakov@cisco.com>
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via
ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/
Eric,
> The redundancy between these bits is largely an issue of usage. The
> fact that a query source is a host (or a router) is significant in
> determination of whether or not the information contained in a request
> is "stable" (at least to some implementations) but is none-the-less a
> fact that might be worth knowing. The same thing applies to whether or
> not _each_ destination in a response is a host or router. The issue of
> stability verses source/destination type should be treated as orthogonal
> and the bits retained - after all, the minute someone comes up with an
> example of why the information MUST be treated as orthogonal, the bits
> will neeed to re-inserted and this would be likely to be an issue with
> future backward compatibility.
If we step back for a second, we could realise, that just like an NHRP
Reply carries a set of destinations for which the originator of the
Reply could act as the end of a shortcut, an NHRP Request could also
carry a set of destinations for which the originator of the Request
could act as the end of a shortcut (recent message from Joel alluded to
this possibility). And in this case we only need to know whether the
set of destinations, for which an originator of a message (whether
Request or Reply) could provide a shortcut, could be viewed as "safe"
("stable"). This, in turn, would eliminate certain asymmetry (arguably
artificial) that is present in the current spec. It would also make it
better aligned with the router-router spec, as there is no reason
to preserve this artificial asymmetry in the router-router case.
Yakov.
- NHRP question Yakov Rekhter
- NHRP question Yakov Rekhter
- NHRP question Tony Li
- NHRP question gardo
- Re: NHRP question Eric Gray
- Re: NHRP question James Luciani
- Re: NHRP question James Luciani
- Re: NHRP question Yakov Rekhter
- Re: NHRP question Joel Halpern
- Re: NHRP question Yakov Rekhter
- Re: NHRP question Joel Halpern
- Re: NHRP question Yakov Rekhter
- Re: NHRP question Yakov Rekhter
- Re: NHRP question Eric Gray
- Re: NHRP question Eric Gray