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;
}
- Vendor Private Extension James Luciani
- Re: Vendor Private Extension Bruce Cole
- Re: Vendor Private Extension James Luciani
- Re: Vendor Private Extension Bruce Cole
- Re: Vendor Private Extension James Luciani
- Re: Vendor Private Extension Bruce Cole
- Re: Vendor Private Extension James Luciani
- Re: Vendor Private Extension Andrew Smith
- Re: Vendor Private Extension Trevor Blackwell
- Re: Vendor Private Extension Telford001
- Re: Vendor Private Extension Curtis Villamizar
- Re: Vendor Private Extension Tony Li
- Re: Vendor Private Extension Curtis Villamizar
- Re: Vendor Private Extension Tony Li
- Re: Vendor Private Extension Trevor Blackwell