Re: NHRP V6 Problems

[Grenville Armitage <[e-mail]>]

Chris,

Jim is on vacation, and since I helped with the changes relating
to packet syntax I can probably answer some of your questions.


>>1.  Is the LLC/SNAP encapsulation referred to in the document finalized?

>>>   [0xAA-AA-03] [0x00-00-5E] [0x00-03]

This is the codepoint used by MARS in ipmc-08/09. It was chosen for
NHRPv6 as part of the effort to achieve commonality.

	[..]
>>3.   We discussed this point before, and agreed on the outcome.  I think the
>>     discussion of alignment for the protocol address should be consist with 
>>     the way it is described for the NBMA address.  IE.  in the address
>>     field discription, not in the length field discription.  I like the
>>     wording that is currently being used for NBMA address.

I'm not sure if the "we" you mention is you and Jim (in which case
I probably shouldn't respond :-) or the WG. Anyway, as part of the
effort to converge on packet construction/parsing rules similar to
MARS and ATMARP I let an error slip through. Padding of address
fields (either protocol or NBMA) is _not_ meant to occur. The new
text was meant to say that protocol and NBMA address fields have
exactly the number of octets allocated in the packet as are indicated
by their length fields, and that their length fields indicate exactly
the number of valid octets in the corresponding address field.

[The reason this is important is if we ever need to encode true
 variable length addresses. Either the NBMA address length fields
 indicates the size of the padded field containing the variable
 length address, or it indicates the number of valid octets within
 the padded field. In the first case, you need additional information
 to determine the number of valid octets. In the second case you need
 to calculate the padding and add it to the indicated length before you
 can find the start of the next address. The parsing rules for
 the second case then require different code for NHRP and MARS packet
 parsing, something we're trying to avoid. (historical note - the ip-atm
 WG decided in Danvers that 32 bit padding of proto and NBMA/ATM
 address fields was not necessary.) ]


cheers,
gja
_________________________________________________________________________
Grenville Armitage                               [e-mail]
Bellcore, 445 South St.      http://gump.bellcore.com:8000/~gja/home.html
Morristown, NJ 07960 USA          (voice) [phone] {.. 2504 (fax)}