Re: [Fwd: NHRP Document]

"Eric W. Gray" <gray@ctron.com> Fri, 03 May 1996 17:41 UTC

Message-Id: <318A4262.6956@ctron.com>
Date: Fri, 03 May 1996 13:29:06 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Eric W. Gray" <gray@ctron.com>
Organization: Cabletron Systems, Inc.
Mime-Version: 1.0
To: "James V. Luciani" <luciani@baynetworks.com>
Cc: "Eric W. Gray" <egret@bluefin.net>, rolc@nexen.com
Subject: Re: [Fwd: NHRP Document]
References: <9605031513.AA02056@exnex.engeast>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Precedence: bulk

Jim,

You wrote (in part):
> 
...
> >       From an NHRP perspective, this looks like an NHS with multiple
> > NBMA addresses.  I don't think that this is a problem with NHRP (it
> > does allow an NHS to have multiple NBMA addresses, doesn't it?) except
...
> > for one tiny little thing:  the addresses given in these NHRP queries
> > must not be used for routing-related protocol interactions - including
> I don't grok "routing-related protocol interactions" in this context.
>

I could have said routing, routing-related and NHRP protocol interactions.
Would that be more "grok-able"?

> 
> >                              ... however, it is probably worth while to
...
> > make it explicit that the use of these addresses is not to be construed
> > to mean that the they are usable for route updates, etc. ...
> Oh... Is this what you meant by "routing-related protocol interactions"?

Yes.

> In that case 250% agreement here.
> > it comes down to this - is there an explicit mechanism by which NHSs
> > become aware of those NBMA addresses which may be used to conduct NHRP
> > and routing business with their neighbors as distinguishable from other
> > NBMA addresses which may only be used for forwarding?
> Shoot... well I had hoped we would not have to do this but it looks like
> the resolution messages (and potentially registration as well) need 3 data
> items: target address (which is where the requests are sent and this may include
> both L3 and L2 address potentially null in some cases), source address (which
> is the client sending the query; this will include both L3 and L2 address), and
> "proxy"/in care of/RSFG address (to which a reply is routed; would include both
> L3 and L2). Geez... Have I ever mentioned how much I hate parsing variable
> length fields?

And if the human mind could not parse variable length sentences, imagine how
bored we could get listening to some number of "uh, uh" left justifications 
(or, worse, right justifications) in the average conversation.

> This is actually minor surgery but I see mission creep a coming down the road.
>

That's why I proposed clarification to the text as opposed to additional fields
in the message.   However, either way may work just as well...

> 
> Regards,
> --Jim Luciani
> __________________________________________________________________________
> James V. Luciani                                   luciani@baynetworks.com
> Bay Networks, Inc.                                  voice: +1 508 439-4734
> 3 Federal St., BL3-04                               fax:   +1 508 670-8153
> Billerica, MA 01821

--
Eric Gray

[Fwd: NHRP Document] Eric W. Gray
Re: [Fwd: NHRP Document] James V. Luciani
Re: [Fwd: NHRP Document] Eric W. Gray