Re: recent changes requested on the list

[Bruce Cole <[e-mail]>]

>    7) Removed the "S" bit and kept the "B" bit kinda as per Yakov's 
>       suggestion.  
>       I say "kinda" as I took a bit of a liberty and removed the S bit and
>       renamed the B bit to S since S is for 'S'table. If you want to do a 
>       global-replace-regexp go for it :-)

I think it'll be confusing to do bit renaming.  We won't know what ROLC people
mean when they mention the S bit...  Also, what about removing the A bit?


>    8) Added the new "S" bit to the Next Hop entry since each next hop entry
>       would need to be identified as stable.  As it was, there was only one
>       bit in the reply for all next hop entries.

Why does each next hop entry need to carry this bit?  Seems to me that under
realistic scenarios, the settings for these bits will be constant for all
next hop entries specified in a reply.  Can you (anyone?) give an example of
when one might want to provide multiple next hop entries in an NHRP reply,
with bits specifying differing values for different next hop entries?

>   Things I did not address below are:
>    A) EDFG Origin Flag requested by Eric Grey

Does anybody have an explanation of what this is?

>    B) Yakov's and Bruce's request to add internetwork layer address length 
>       fields on a per address basis rather than one per packet.

This would allow us to specify network layer prefixes instead of
just network layer addresses, eliminating the need for the destination prefix
extension.  Of course, this is not strictly necessary.

>    C) Russel's request to add a destination address mask field to the
>       IP-specific part of the Purge packet.

B) would provide for C) as a side effect.

> 5.1 NHRP Fixed Header

>    Packet Length
>      This is the length of the NHRP packet as a whole.

The total length of the NHRP packet, in octets.

> 5.2 NHRP Request
> 
>    The NHRP Request packet has a Type code of 1.  The NHRP Request packet
>    is used to register a client with the clients NHS by making a request for
>    itself.  This is done by setting the source address equal the destination 
>    address (which also equals client address) and the reply received serves 
>    as the acknowledgment for the registration.

I think you're complicating the semantics of request
packets in order to fold in the register packet functionality.  Apparently
this is just to make the semantics analogous to what the 1577 folks have.  I
don't see why we should bother, because doing so:

    results in gratuitous changes to the NHRP spec.

    complicates protocol implementations since one now has to perform
    a src == dst check after determining that an NHRP packet is a 
    request packet.

    leaves us with the above description of the request packet that is 
    worded as if request packets are only intended for registering, not for
    sending requests...

> 
>    The Mandatory Part has the following format:

>    Q
>      Set if the Requester is a router;  clear if the requester is a
>      host.

Per Yakov and Joel's discussion, I think we should redefine this bit
to specify whether or not the source is considered to be safe.

>    Proto Length
>      This is the length of the internetwork layer protocol address.

The length in octets, of the internetwork layer protocol addresses appearing
in this packet.  If this length is not a multiple of 4, each internetwork
layer address is zero-filled to the nearest 32-bit boundary.

[Same description applies to NHRP reply packets]

> 
>    Protocol ID
>      Specifies the internetwork layer protocol for which we are
> p     obtaining routing information.  This value also qualifies the

typo


> 5.3 NHRP Reply

>    Request ID
>      A value which, when coupled with the address of the source,
>      provides a unique identifier for the information contained in a
>      Request and its associated Reply, and any subsequent Purge.  This
>      value can be used by the source to aid in matching requests with
>      replies.  This value could also be sent across a virtual circuit
>      (in SVC environments) to aid in matching NHRP transactions with
>      virtual circuits (this use is for further study).
> 
>      The value is taken from a 32 bit counter that is incremented each
>      time a new NHRP request is transmitted.  The same value MUST be
>      used when sending another request for the same destination when a
>      previous request is still active or pending, i.e., when
>      retransmitting a request because a reply was not received, or when
>      refreshing an existing entry to avoid holding timer expiration.  A
>      new value MUST be used when sending a request when no cache entry
>      is present, or a previous cache entry was deleted for any reason.

The above discussion is redundant, and appeared in the description of the
NHRP request packet format.  Can simply use existing text:
     Copied from the NHRP Request.

>    Next-hop entry
>      A Next-hop entry consists of the following fields: a 32-bit Next-
>      hop IP Address, a 16-bit Holding Time, a S bit, a 7-bit Preference, 
>      an 8-bit Address Type, an 8-bit NBMA Length, and an NBMA Address 
>      whose length is the value of the NBMA length field.
> 
>      The Next-hop IP Address specifies the IP address of the next hop.
>      This will be the address of the destination host if it is directly
>      attached to the NBMA subnetwork, or the egress router if it is not
>      directly attached.
> 
>      The Holding Time is similar in concept the the Holding Time associated
>      with the Source NBMA Address but is time specifying the the validity 
>      of the destination address specified in the specific Next-hop entry.

Sentence doesn't parse.  What information is the above sentence trying to add?