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