Re: Vendor Private Extension

[James Luciani <[e-mail]>]

> > ROLCers,
> >   
> >   Since NHRP does not permit more than one instance of any given extension
> > type, this places a bit of a constraint on the vendor private extension.
> > What if a message traverses two vendors' NHRP speakers both of which wish to 
> > include private information in the message?  It can't be done now.  
> 
> It can be done now, just as other extensions such as the forward NHS record
> extension can be appended to by intermediate stations.  No need for more
> explicit complexity here.

No it cannot.  

If vendor A and vendor B want to put their record on the vendor-private extension,
how would vendor B decide where its vendor record is within the extension?
You do not know how long the previous vendor's record is with the existing extension!  
Also the original text says nothing about adding another record to the existing 
extension.

> > 
> > I propose that the vendor private extension/TLV take on the following form:
> > 
> > 
> > 
> > 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.