Re: Vendor Private Extension

[James Luciani <[e-mail]>]

> I misread and thought you were talking about two extensions with the 
> same vendor ID.  To handle concurrent vendor-extensions with different 
> IDs, lets simply relax the requirement that extensions may occur only once, 
> for this particular TLV.  One could already possibly interpret things this 
> way, as the vendor-private extension is supposed to be ignored when the 
> vendor ID does not match the station that is doing the processing.

Why add the complexity to the parsing by allowing multiple occurances 
of this specific extension and this one only?????

If you have already developed the mechanics for the 
NBMA Subnetwork ID Extension, NHRP Forward NHS Record Extension, or
NHRP Reverse NHS Record Extension then you already have the machinery
you will need.  Why recreate the wheel?

The definition of the extension that I proposed allows a single vendor 
to add information at each NHRP speaker as either separate records within
the extension or to merely append to the vendor's own record which might
already be there.  Of course, if a given vendor wants to include private
information and the vendor does not already have a record in the extension
(or if the extension does not yet exist), it would then create a new record 
and append it to the extension.  Thus each vendor has the freedom to code 
their "Vendor Private Extension" record(s) as they see fit.

Let's stay consistent with the model as it exits now. Lets have a record 
per "vendor private data instance" in the Vender Private Extension.  
That is, one extension of type=8 (vendor private extension) may have mutliple 
records of the format shown below.  

> > 5.7.8  NHRP Vendor-Private Extension
> >  
> >    Discretionary = 1
> >    Type = 8
> >    Length = variable
> >  
> >    The NHRP Vendor-Private Extension is carried in NHRP packets to
> >    convey vendor-private information or NHRP extensions between NHRP
> >    speakers.  This extension may be used at any time, and unlike other
> >    extensions, this extension may be added to a reply even if it was
> >    not present in the original request.  Because only one instance of
> >    an extension type is allowed in an NHRP message, this extension is
> >    formatted to allow one or more vendors to add private information 
> >    withing a single extension.  Each vendor's NHRP speaker may add to 
> >    this extension as the message is propagated to its destination.
> > 
> >    If the receiver does not handle this extension, or does not match
> >    any of the vendor IDs in the extension, then the extension may be
> >    the extension may safely be ignored.  Each NHRP speaker may add the
> >    following record to this extension:
> > 
> >        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             |    RVU        |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |           Length              |   Data (variable length)      |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> >    Vendor ID   
> >      24-bit 802 vendor ID as assigned by the IEEE
> >  
> >    RVU
> >      Reserved for vendor use.  This field can be used for whatever
> >      the vendor desires or it may not be used at all.
> > 
> >    Length
> >      The length in octets of the private data, beginning from the
> >      first octet of the Data field.
> > 
> >    Data
> >      The vendor-private data.  This field will always end on a 32-bit
> >      boundary, so its length will always be 2+4*n octets, where n>=0.
> > 
> >    Note that the extension can contain multiple vendor entries.
> >    If a vendor adds an entry to an existing extension, then the 
> >    overall extension length is increased by the total length of 
> >    the additional entry, including the Vendor ID, Length, 
> >    and Data fields.

> (And also relax the requirement that extensions must exist in the NHRP 
> request if they are to appear in the response, as you already did in 
> your proposed text).
I obviously agree with this :-) .