Re: NHRP protocol modifications and clarifications

James Luciani <luciani@nexen.com> Tue, 11 July 1995 22:13 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19080; 11 Jul 95 18:13 EDT
Received: from [204.249.96.18] by IETF.CNRI.Reston.VA.US id aa19075; 11 Jul 95 18:13 EDT
Received: from maelstrom.acton.timeplex.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id SAA08703; Tue, 11 Jul 1995 18:02:03 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) id RAA12367 for rolc-out; Tue, 11 Jul 1995 17:59:34 -0400
Received: from shovel.acton.timeplex.com (shovel.acton.timeplex.com [134.196.22.10]) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id RAA12358; Tue, 11 Jul 1995 17:59:30 -0400
Received: from localhost (luciani@localhost) by shovel.acton.timeplex.com (8.6.12/8.6.12) with SMTP id RAA08066; Tue, 11 Jul 1995 17:59:29 -0400
Message-Id: <199507112159.RAA08066@shovel.acton.timeplex.com>
To: Bruce Cole <bcole@cisco.com>
Subject: Re: NHRP protocol modifications and clarifications
In-reply-to: Your message of "Fri, 07 Jul 1995 12:33:45 PDT." <199507071933.MAA15958@greatdane.cisco.com>
cc: rolc@nexen.com
Date: Tue, 11 Jul 1995 17:59:28 -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/

> I don't think I understand the need for multiple distinct clients in an NBMA
> station (where the clients share the same IP address and interface).
>
> Having multiple logical IP addresses associated with a single physical 
> NBMA interface is of course reasonable, and is neither precluded nor required
> by NHRP.

I think I understand what you don't see now.  I am not saying that:
"the clients share the same IP address and interface".

I am saying that in order to demux the traffic, when two or more Next Hop 
Clients (NHC) are physically co-located in the same box with an NHS then they 
must have DIFFERENT IP addresses NOT a shared IP address.  How else would you 
demux the client messages to their appropriate destination?

There are a number of error conditions for which you just cannot test without a
demux mechanism.  If you get an error message, how do you intuit for whom it 
was sent?...  Lets say it is an error case of incorrect message type.
What about the case when you have 2 or more Next Hop Clients (NHCs) which are 
co-resident with their NHS?  You can't figure out for whom a reply was sent 
in this case without burdening all NHCs to check to their database.