Re: nhrp-05

[David Horton <[e-mail]>]

In answer to the solicitation for opinions:

>4.   Proposal to position forward & reverse record extensions for debugging
>    only.
If these function as debugging tools only, then can't we simplify
the content to just the IP addresses?

>5.   Proposal to remove register packets
I disagree. I would prefer to add the acknowledgement to the register
packet. It seems to that unless a client is paranoid, it only has to
get an acknowledged registration packet when it first starts up.
After that, it can send unacknowledged keep-alives and halve the 
baseline NHRP traffic.

>6.   Proposal to add prefix mask to purge packet
A prefix mask extension sounds reasonable, though it may 
complicate client implementations to always act on it.
If the purge acknowledge set the mask to be what was actually
purged, then the NHS revert to entry by entry if needed.

>7.   Proposal to remove netid from purge packet
(I presume Request ID is meant)
It (now) feels right to me to include the request ID as it provides
a temporal ordering for a client has already re-acquired the destination
address from its new source. A purge coming in from the previous NHS
home of the destination, which would blow away the re-acquired address,
can be ignored because the request ID in the purge is older than
request-id associated with current cached address.
I think the request id has its role as an ordering in this case rather
than as a specific instance identifier. That said, the case being 
protected here is probably going to be rare.

>8.   Proposal to redefine Q bit to specify whether or not source is safe.
I think I missed that one.
>9.   Proposal to relocate Q/B/A bits in packet, so that they may be
>     specified per NBMA address.
Sounds like the correct thing to do in terms of the data model.


Some comments on the draft as posted 31-Oct (including some trivial typos).

page 2: (Introduction)
>      3)  All members outside of the LIS are accessed via a router.
Should that be "accessable via a router"? Otherwise it is denying short-cuts?

page 5: (Protocol Overview)
>                                       Note that because NHRP packets
>   are encapsulated with the NBMA address of neighboring stations (see
>   encapsulation discussion, section 5), NHSs must be next hops to one
>   another in order for forwarding of these packets to be possible.

I couln't find the NBMA address in the encapsulation. Can the NHC
ATM address always be assumed to be passed up as part of SVC establishment
to the NHS? If this connection were somehow set up via a well known PVC,
the ATM address may not be available to the NHS.
Thus shouldn't the requester's ATM address be added to the fixed header.
Couldn't there also be cases where a direct reply or error be sent
directly to the sender. I can envisage an NHS receiving a request
for an address in a protocol address that it doesn't support, which
it would forward to an NHS that did support the protocol, but 
come across some error and be unable to send an error because it didn't 
have an address it could understand.

page 8: (Deployment)
>  If the addressed NHS does not serve the destination address specified
>  in the NHRP request, the request packet is routed at the network
>  layer based upon the request's destination address, and forwarded to
>  the neighboring NHS determined by the routing decision.
Does the second paragraph prohibit the forwarding of NHRP requests
to other NHS based solely on protocol type. I am thinking here of 
a client that speaks something other than IP sending in a packet to 
an IP NHS. It would be possible for NHS to 'know' of other NHS that serve
that protocol.

I guess another answer would be a "Can't serve" error response.
In this case could there be an extension for this error containing 
the NBMA address for a 'better' server?

Page 9: (Deployment)
>   NHSs may also be deployed with the group or multicast address of
>   their peers, and an NHS might use this as a means of forwarding NHRP
>   requests it cannot satisfy to its peers.  This might elicit a
>   response (to the NHS) from one or more NHSs, depending on the
>   response strategy.  
In the case where a multicast request is sent, 
then presumably there can be multiple replies. These could be direct,
and they could also be conflicting (with respect to positive/negative).
Do we need to add semantics to handle the potential inconsistencies,
such as defining a wait time after receiving a negative reply, or
a delay after sending a request, to allow positive replies to come
in subsequently?

page 13:
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |Q|A|P|B| Unused | Proto Length |          Protocol ID          |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                      Protocol ID (Cntd)                       |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                         Request ID                            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In the IPv4 case where the protocol ID will fit in the first longword
along with the length and the flags, does the continuation longword
get included, and coded as zeros, or is it omitted so that the 
request ID immediately follow?

page 13,14: (NBMA Length)
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      |    Unused     |  NBMA Length  | Source NBMA Address (variable)|
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>:
>     NBMA Length
>     The NBMA length field is the length of the NBMA address of the
>     source station in bits.
 
The NBMA address length is specified to be only up to 255 bits. Is
this too small?
This points to a slight problem in the mapping in NHRP-MIB, where
the address is attribute is an octet string, implying an 8 bit
alignment. I think an additional attribute will be needed in the MIB
to reflect the bit size of the address.

page 18 and page 25: (unrecognized discretionary extensions)
>     Any extensions present in the NHRP Request packet MUST be present
>     in the NHRP reply packet, except for the case of unrecognized
>     discretionary extensions (see section 5.7).

Is this saying that an NHS may remove a discretionary extension
that it doesn't understand? The wording at the top of page 18 
seems at odds with the commentary on the D bit on the bottom of page 25.
To me, I would have thought it to
be necessary to copy the extension on to the next hop, and even 
in the processing from Request to Reply so that it can be handled 
by something that does understand it. 
For example, say there was a vendor private extension similar to
the Reverse NHS record extension. It may add timestamps as a performance
monitor. The particular extension is only acted on in replies, so 
wouldn't work if stripped on the outbound leg.

page 18: (Q bit)
Why isn't the Q bit present in Register packets too?
I think there are some assumed semantics here that need to be written down.

page 18: (acknowledged register)
Could the register packet have acknowledgement bit(s) to request the NHS
to reply to a register packet. This is so that the initial registration
can be assured of having worked (back to the client), but allowing
subsequent one to not place additional load on the network.
A second bit is presumably needed so that an acknowledged register
can be distinguished from a randomly floating request.
It seems odd to me that the protocol is asymmetric with Purge
being acknowledged, but Register isn't.

(I presume 1 register packet per hold time would need to be acknowledged
to reassure the client that the unacknowledged registers worked).

I guess an alternative would be a request for itself. However I presume
that this would be a much greater overhead in the NHS.

page 19: (Can't serve error)
>   It is possible that a misconfigured station will attempt to register
>   with the wrong NHS (i.e., one that cannot serve it due to policy
>   constraints or routing state).  If this is the case, the NHS MUST
>   reply with an Error Indication of type Can't Serve This Address.

Isn't the automatic "Can't serve" handling of misconfigured stations 
a bit harsh?
Wouldn't it ease integration if the NHS were to use its greater
knowledge of the network to forward the register request to a more 
appropriate NHS, or for the error reply to suggest to the client
a more appropriate NHS to register with. This way the poor device
can actually connect into the network.

page 21: (Requester IP Address)
The Requester-IP address that the NHS inserts in the NHRP-Purge request 
has to be the same as the Source-IP that was in the original NHRP-Request
packet. In the NHRP-Purge acknowledgement, the NHC must ensure
it is identical to that in the NHRP-Purge request (by copying).

page 21: (Purge dissemination)
Given that client sending a Purge is proactively clearing up a soon
to be wrong NBMA address from the network, shouldn't the NHS receiving
this purge be required to act on this the same way as if it received
a register packet with a changed address. That is, shouldn't this 
purge receipt at the NHS generate a number of purge requests to 
all the devices who have been sent an NHRP reply with this data
in the hold time?

Do we need to have any temporal ordering defined?

Page 21: (Purge retry period)
>  The station sending the NHRP Purge request MUST periodically
>  retransmit the request until it is acknowledged, or until the holding
Purge requests must be periodically retransmitted. Should there
be some indication of the kind of period:-
+ 1/3 of the remaining hold time
+ every second
+ every minute
+ some configured value

Page 22: (Errors for Requests only)
>   The NHRP Error Indication is used to convey error indications to the
>   initiator of an NHRP Request packet.
Are Error Indication packets only for NHRP-Request packets as indicated
in the first paragraph? We have specific errors for Register and 
Reply packets.

Page 22: (Size for IP specific part)
> ... Error Header ...
> ... (IPv4-Specific) ...
> ... Contents of NHRP Packet in error  ...

Shouldn't the IPv4 specific part (Dest IP ->Source NBMA) be encapsulated
in a counted portocol independent part so that the erroneous packet
can be accessed by a non-IP NHRP speaker. 
I presume that if a non-IP speaker were to send a packet to an IP
speaker, which didn't like the packet, the IP speaker would choose 
to send an error back. In order for the non-IP speaker to make 
proper use of the error packet, it would probably have to look
at the encapsulated bad packet.

So I propose an extra length field containing the length of the 
IPv4 Specific part.

Page 23: (Contained erroneous packet when too big)
In the case of the "8 - NHRP SDU Size Exceeded", what is the fate of the
encapsulated erroneous packet? Should it be truncated?
If so then should we also have a length field for the amount of the
included erroneous packet that is being returned?

Page 29: (Forward extension)
If the purpose of this extension is debugging, is it necessary
to still have the NBMA addresses as well as the NHS IPs?

Page 29: (Forward extension)
>   The last-hop NHS (the one that will be generating the NHRP Reply)
>   SHALL NOT update this extension (since this information will be in
>   the reply).
Why shouldn't the last NHS include itself in the "Forward" extension.
An NHS responding with an egress router's address as the next hop
wouldn't have its address in the list. Wouldn't the only way to be
sure be to also include the responder address extension?
Given that this is for debugging purposes, is the optimisation
of excluding the last NHS excessive? Does it do harm to include it?

Page 31: (QoS extension)
>   ...  alignment with
>   resource reservation may be useful.
A reference perhaps?

Page 32: (Authentication)
>   Distribution of authentication keys is outside the scope of this
>   document.
However NHRP-MIB has them as common to interfaces/IP addresses in the
same LIS.

Page 32: (Authentication: MD5 reference)
>   In the case of Keyed MD5 Authentication, the Authentication Data
>   contains the 16 byte MD5 digest of the entire NHRP packet, including
A reference perhaps?

Page 33: (Vendor-private)
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Vendor ID                                |   payload     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Payload (cont) ...                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Does a diagram enhance text?

Page 37: (NLRI)
>     The NHS examines the Network Layer Reachability Information (NLRI)
Reference to BGP?

page 40: (References)
>   [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh
>       Govindan, draft-ietf-rolc-nbma-arp-00.txt.

Shouldn't this be RFC 1735 instead of draft-ietf-rolc-nbma-arp-00.txt?

regards,
David

 David Horton
 Centre for Information Technology Research
 University of Queensland, 4072        Australia
 Email: [e-mail]         Phone [phone]   Fax [phone]