Re: NHRP question
Joel Halpern <jhalpern@newbridge.com> Wed, 18 October 1995 21:46 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17439;
18 Oct 95 17:46 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa17435;
18 Oct 95 17:46 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com
(8.6.12/8.6.12) with ESMTP id RAA11247; Wed, 18 Oct 1995 17:21:13 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id
RAA15088 for rolc-out; Wed, 18 Oct 1995 17:28:05 -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 RAA15079 for
<rolc@nexen.com>; Wed, 18 Oct 1995 17:28:02 -0400
Received: from ns.newbridge.com (ns.Newbridge.Com [192.75.23.67]) by
guelah.nexen.com (8.6.12/8.6.12) with ESMTP id RAA11212 for <rolc@nexen.com>;
Wed, 18 Oct 1995 17:18:03 -0400
Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id RAA08649
for <rolc@nexen.com>; Wed, 18 Oct 1995 17:24:17 -0400
Received: from portero(192.75.23.66) by ns via smap (V1.3)
id sma008630; Wed Oct 18 17:24:16 1995
Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99])
by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id RAA06207 for
<rolc@nexen.com>; Wed, 18 Oct 1995 17:24:11 -0400
Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0)
id AA25047; Wed, 18 Oct 95 17:19:32 EDT
Received: by lobster.Newbridge.COM (5.0/SMI-SVR4)
id AA10690; Wed, 18 Oct 1995 17:23:15 +0500
Date: Wed, 18 Oct 1995 17:23:15 +0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Joel Halpern <jhalpern@newbridge.com>
Message-Id: <9510182123.AA10690@lobster.Newbridge.COM>
To: rolc@nexen.com
Subject: Re: NHRP question
X-Sun-Charset: US-ASCII
Content-Length: 1502
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/
Last time I spoke to Yakov about the router to router case, his goal was to
eliminate all unsafe router-router cases. There are safe cases.
The intend of the combination of Q, S, and B bits was to identify the
applicable cases.
The general goal was to be able to tell if the requestor was a host
or router, and whether the responder was someone it was safe for the
requestor to talk to.
1) It seemed useful to distinguish between the "stable" case identified
by the "B" bit, and the more specific case when the responder is a
directly attached host. Clearly it is not critical.
2) One could say that a source equivalent of the "B" bit would be better
than the "Q" bit. It would be more general. However,
Most of us are probably assuming that information learned on behalf
of one source can be used for/with other sources.
If that is true, then the fact that a specific request is on behalf of
an on-subnet host is not particularly important. Therefore, what is
needed to detect safety is the Q bit.
In particular, an interdomain request is safe if the Q bit is on in the
request, or the B bit is on in the response. We could get rid of the S
bit, although I think it is a useful subset of "B" to identify.
Fortunately, in no case do any of these bits need to be adjusted hopwise
through the fabric. Domain Boundary crossing is a state that must be
indicated, but it is separate from these bit settings.
Yours,
Joel M. Halpern jhalpern@newbridge.com
Newbridge Networks Inc.
- 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