Re: Vendor Private Extension

James Luciani <luciani@nexen.com> Thu, 13 July 1995 16:48 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02680; 13 Jul 95 12:48 EDT
Received: from [204.249.96.18] by IETF.CNRI.Reston.VA.US id aa02675; 13 Jul 95 12:48 EDT
Received: from maelstrom.acton.timeplex.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id MAA27860; Thu, 13 Jul 1995 12:32:12 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) id MAA18310 for rolc-out; Thu, 13 Jul 1995 12:19:34 -0400
Received: from shovel.acton.timeplex.com (shovel.acton.timeplex.com [134.196.22.10]) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id MAA18285; Thu, 13 Jul 1995 12:19:30 -0400
Received: from localhost (luciani@localhost) by shovel.acton.timeplex.com (8.6.12/8.6.12) with SMTP id MAA08797; Thu, 13 Jul 1995 12:19:28 -0400
Message-Id: <199507131619.MAA08797@shovel.acton.timeplex.com>
To: Bruce Cole <bcole@cisco.com>
Subject: Re: Vendor Private Extension
In-reply-to: Your message of "Wed, 12 Jul 1995 22:57:05 PDT." <199507130557.WAA26939@greatdane.cisco.com>
cc: rolc@nexen.com
Date: Thu, 13 Jul 1995 12:19:28 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: James Luciani <luciani@nexen.com>
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

> > > 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?????
> 
> In order to allow the format of the extension to remain vendor-private
> (besides the vendor ID), as intended.

As I pointed out below, the extension is still vendor private.  The mere
fact that a given vendor's record is one of several vendor private records
does not make it any less vendor private.

> 
> > 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?
> 
> With what you propose, you potentially have a single extension with
> sub-sections that need to be skipped over, and other sub-section(s) which need
> to be processed.  This is effectively causing nesting of TLVs, which
> I think is more complex than the alternative.
> 
> Either scheme will work, maybe one can be picked next week.

But you already have to parse multiple records within a given extension so the
mechanics exist already.  There is no added complexity. Here is the basic
code in 5 minutes worth of typing; most of which was because I had to look back
at the spec 2 times:

/* base of extenstions */
struct an_extension
{
  short type;
  short length;
} *extension;

/* vendor private record */
struct vendor_record
{
  char vendor_id[3];
  char RVU;
  short record_length;
  char *record_data;
} *a_vendor_record;

extension=(start of vendor private extension)
a_vendor_record=(start of vendor private option data);


/* vendor private parser */
end_of_data=a_vendor_record+extension->length;
while (a_vendor_record!=end_of_data)
{
  if (strcmp(a_vendor_record->vendor_id,MyVendorId,3)==0)
    parse_my_data(data);
  vendor_record+= vendor_record->record_length;
}