Re: NHRP protocol modifications and clarifications

Bruce Cole <bcole@cisco.com> Fri, 07 July 1995 19:58 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13372; 7 Jul 95 15:58 EDT
Received: from [204.249.96.18] by IETF.CNRI.Reston.VA.US id aa13368; 7 Jul 95 15:57 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 PAA06023; Fri, 7 Jul 1995 15:39:03 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) id PAA27109 for rolc-out; Fri, 7 Jul 1995 15:35:38 -0400
Received: from nexen.nexen.com ([204.249.96.18]) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id PAA27100; Fri, 7 Jul 1995 15:35:33 -0400
Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id PAA06018; Fri, 7 Jul 1995 15:35:32 -0400
Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by greatdane.cisco.com (8.6.8+c/8.6.5) with ESMTP id MAA15958; Fri, 7 Jul 1995 12:33:45 -0700
Message-Id: <199507071933.MAA15958@greatdane.cisco.com>
To: James Luciani <luciani@nexen.com>
Cc: Bruce Cole <bcole@cisco.com>, rolc@nexen.com, bcole@cisco.com
Subject: Re: NHRP protocol modifications and clarifications
In-Reply-To: Your message of "Fri, 07 Jul 1995 02:10:44 EDT." <199507070610.CAA06313@shovel.acton.timeplex.com>
Date: Fri, 07 Jul 1995 12:33:45 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bruce Cole <bcole@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/

> There are a number of error conditions for which you just cannot test 
> without a demux mechanism.

Yes, but the point is the protocol already provides enough information for
an implementation to demux things.

> What about the case when you have 2 or more NHCs which are co-resident with 
> their NHS?  You can't figure out for whom the packet was sent in this case 
> without burdening all NHCs to check to their database.

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.

When you have multiple logical IP networks associated with a single 
physical interface, you can treat this as a single instance of NHRP running
over multiple virtual interfaces.  Or you can stick with the concept of
multiple logical instances of NHRP.  But these are implementation details
that don't require changes to the text of the spec.

> but what do you want to do about the statement:
>     : An NHS is configured with its own identity, a set of IP address
>     : prefixes that correspond to the IP addresses of the stations it
>     : serves, a logical NBMA subnetwork identifier (see Section 5.7.2),
>     : and in the case of "server" mode, the identities of other NHSs in
>     : the same logical NBMA subnetwork.  If a served station is attached

I would clarify "own identify".  For the purposes of this section, I believe
it means the set of IP addresses and NBMA addresses assigned to the NHS
station itself.