The IP Over NBMA (ION) Archive

[David Horton <horton@citr.com.au>]

I have a few preliminary comments on nhrp-08.

Firstly, I wasn't expecting to see as many changes as there are 
from nhrp-VIII. (Not wrong, just unexpected).

I think that in the accumulation of a fields together to make
a more re-usable mandatory part that some clarity has been lost.

1. Target address unclear

Specifically for resolution requests which field contains 
the protocol address of the station for which the NBMA address
is desired, i.e. the target? 
In nhrp-07, it was the "Destination Protocol Address", however
I can now place 3 interpretations on the text as written.
(1) Destination Protocol Address is the address of the NHS
    and so there must be partially filled in CIEs in the request
    that are to be completed by this NHS.
(2) Destination Protocol Address is of the target, and that the 
    NHRP packet is routed all the way to that target (or the egress
    router from the NBMA), and the target responds
(3) Destination Protocol Address is the target, and that it is used
    for routing to get to the LIS where either the target is,
    or egresses, and within there is sent to the (best) NHS

If (1) then there is a problem with >1 target in that the packet
may need to be split to resolve different addresses on different 
subnets.

2. Registering addresses in multiple LIS

With multiple CIEs (protocol->NBMA mappings) being allowed in a single
registration packet, there is an ambiguity created where the device
exists on multiple subnets. These subnets may be served by different 
NHS. So again the packet has to either be split or rejected. 

I presume that the packet is still expected to be routed to the
NHS specified in the Destination Protocol Address in the common
mandatory part. Do the CIEs for which the client selected NHS is
not the server receive a "Code" of "4 - Can't Server This Address",
while the CIEs for which it does serve get a "Code" of 
"0 - Successful Registration"?

3. Request ID reintroduced to Purge

I am not sure if this was intentional, but I think it is a good thing
if this has the behaviour of allowing the client to match up purge
replys to purge requests it sent.
Was this the case, or was the request id in purges meant to be
the request-id of the original resolution reply as in NHRP-4?

4. Reuse of CIE for extensions

Why not make the structures for the extensions :-
	3. responder address extension
	4. NHRP Forward Transit NHS Record Extension
	5. NHRP Reverse Transit NHS Record Extension
use the CIE structure instead of the abbreviated form.
There would need to be additions to the text saying that certain 
fields, e.g. code, must be set to zero.
I think developers of both the client and servers would 
appreciate not having to decode extra formats.

regards,
David

 David Horton
 Centre for Information Technology Research
 Level 2 South Tower, 339 Coronation Drive, Milton, Australia 4064
 Email: d.horton@citr.uq.oz.au       Phone +61 7 32592222   Fax +61 7 32592259