Re: NHRP question
James Luciani <luciani@nexen.com> Wed, 18 October 1995 21:13 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17081;
18 Oct 95 17:13 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa17077;
18 Oct 95 17:13 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com
(8.6.12/8.6.12) with ESMTP id QAA10729; Wed, 18 Oct 1995 16:38:34 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id
QAA14578 for rolc-out; Wed, 18 Oct 1995 16:47:29 -0400
Received: from shovel.nexen.com (shovel.nexen.com [204.249.98.39]) by
maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id QAA14569;
Wed, 18 Oct 1995 16:47:26 -0400
Received: from localhost (luciani@localhost) by shovel.nexen.com
(8.6.12/8.6.12) with SMTP id QAA11142; Wed, 18 Oct 1995 16:47:23 -0400
Message-Id: <199510182047.QAA11142@shovel.nexen.com>
To: Yakov Rekhter <yakov@cisco.com>
Subject: Re: NHRP question
In-reply-to: Your message of "Wed, 11 Oct 1995 14:48:52 PDT."
<199510112148.OAA26230@hubbub.cisco.com>
cc: rolc@nexen.com
Date: Wed, 18 Oct 1995 16:47:22 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: James Luciani <luciani@nexen.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/
Yakov, > > [Yakov says] > > Folks, > > > > Few days ago I posted a note asking what is the use of Q and S bits. > > Since nobody explained (so far) their use, let me suggest that we > > take them out of the document. > > > > Yakov. > > [shur@arch4.ho.att.com says] > Version IV of the draft (is there a later one?) states that the Q and S bits > indicate whether NHRP requestor and NBMA next hop respectively is a host > or a router. Perhaps this information could be useful in avoiding router-router > cut-through routing loops in an environment where the solution for the > router-router case is not defined, but where host-host, host-router, > router-host cut-through procedures are? These bits were in NHRP since v1. If we do not do the R2R case in NHRP, their value is questionable. It is also not clear to me why we need both of these bits even if we do need to ascertain if the connection request is R2R since the requester knows what it is and thus only the responder would need to tell the requester what the next hop possibilities are. Incidently, I think there is a hole here. Each Next Hop should have to signify if it is a router. As it is, only one bit is available even thought there might be multiple next hop entries. I actually would prefer a single "best" next hop be specified in the reply with an extension for other replies but that is an issue from a different note :-) However, one could make some argument about promiscuously listening to the "Q" bit as well as the address information and saving that data for non-authoritative (or even authoritative in some cases) resolutions. Regards, -- Jim Luciani __________________________________________________________________________ James V. Luciani Ascom Nexion voice: +1 508 266-3450 luciani@nexen.com 289 Great Rd., Acton MA 01720 FAX: +1 508 266-2300
- 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