Re: [Fwd: NHRP Document]

["James V. Luciani" <[e-mail]>]

Eric,
> 	One of the things that came up at the MPOA interim meeting is
> related to the current state of the NHRP document - we need to be able
> to tell the difference between an NHRP query from an RSFG (NHS) on the
> behalf of one EDFG from a similar query on the part of another EDFG.
> This means that we need to include the ATM address of the originating
> EDFG in the NHRP query that is re-originated by the RSFG on it behalf.
Yes.  This seems to be a recurring theme in a number of notes recently.

> 	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
Yes... in fact if you wave your hands quickly you see a bunch of the MARS
functionality too :-)  This is by design of course since we (A. Grenville
and I) are working on the combination of ipmc and NHRP which is 
the natural outcome of the "harmonization" ( to be called nIhPrMpC no doubt).
> 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.

> NHRP - by any NHS that sees this query in route.  This shouldn't be too 
> big a deal as I believe that we had said - at the last IETF - that the 
> NHRP response has to be returned using the internetwork address (as 
> opposed to the NBMA address); however, it is probably worth while to 
Actually what we said was that the registration reply must use ATM not
internetworking address to get the packet back to the client since in 
an asymmetric case with a multiple NHS/router LAG you can get lost.  However,
I agree that the resolution request/reply MUST use the internetworking layer
address information and take the routed path back.
> 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.  Essentially, 
Oh... Is this what you meant by "routing-related protocol interactions"?
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?
This is actually minor surgery but I see mission creep a coming down the road.

Regards,
--Jim Luciani
__________________________________________________________________________
James V. Luciani                                   [e-mail]
Bay Networks, Inc.                                  voice: [phone]
3 Federal St., BL3-04                               fax:   [phone]
Billerica, MA 01821