Subject: Vendor ID (OUI) encoding in LDP section 3.6.1.1

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 29 Jul 2002 11:14:48 -0400

RFC 3036 section 3.6.1.1 defines a 32-bit field called the "Vendor ID", 
which contains a 24-bit IEEE 802 OUI, however the exact encoding of the 
Vendor ID is not discussed.  Is there anyone that does not agree that the 
OUI should be right-justified (in bits 8-31) in the field, with bits 0-7 
set to zero?  We may wish to clarify that when LDP becomes a Draft Standard.

Thanks,
Andy

---

From: Shahram Davari <[email-masked]>
Date: Mon, 29 Jul 2002 08:39:19 -0700

Andy,

IS=a there any reason that this kind of OUI does not exist in RSVP-TE?

Yours,
-Shahram

> -----Original Message-----
> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Monday, July 29, 2002 11:15 AM
> To: [email-masked]
> Cc: Jim Harford; David Sinicrope
> Subject: Vendor ID (OUI) encoding in LDP section 3.6.1.1
> 
>

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 30 Jul 2002 11:22:41 -0400

David,

	First come, first served doesn't necessarily equate
to proprietary.  Also, vendor specific objects are very
likely to fall in the range 192-255 because of the likely
desired behavior (forward without processing if unknown).

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

-----Original Message-----
From: David Charlap [mailto:[email-masked]] 
Sent: Tuesday, July 30, 2002 11:10 AM
To: IETF MPLS List
Subject: Re: Vendor ID (OUI) encoding in LDP section 3.6.1.1

I know about the comment in IANA's file, and I have no idea what they're 
actually talking about.

They _DO_ make allocations from elsewhere.  The DIFFSERV object (class 
65) was not assigned until RFC 3270 went on-line in May.

And the DCLASS object (225 - in that region) is not proprietary - it's 
defined by RFC 2996.

-- David

Andrew G. Malis wrote:
> 
> According to http://www.iana.org/assignments/rsvp-parameters, the range 
> 224-255 is available for FCFS allocation.  It doesn't specify any other 
> particular allocation requirements.
> 
> Cheers,
> Andy
> 
> --------
> 
> At 7/30/2002 10:22 AM -0400, David Charlap wrote:
> 
>> Andrew G. Malis wrote:
>>
>>> For RSVP-TE (and classical RSVP) private extensions are typically 
>>> handled by asking IANA for a new Class Number allocation in the range 
>>> 224-255.
>>
>>
>> IANA is the organization that selects standard numbers.  But a private 
>> extension, that is not an RFC, does not normally get an IANA 
>> allocation.  Even drafts that are well on their way to becoming RFCs 
>> don't usually get numbers assigned until it actually becomes an RFC.
>>
>> As for the range, IANA may assign from anywhere, not just 224-255.
>>
>> There are three ranges of object classes that dictate how a router 
>> that doesn't support the object should respond to it.  The range 
>> chosen depends on the required behavior:
>>
>> 1-127 - non-supporting routers will not process the message at all, 
>> but will return PathErr or ResvErr.
>>
>> 128-191 - non-supporting routers will drop the object but process the 
>> rest of the message.
>>
>> 192-255 - non-supporting routers will forward the object without 
>> processing it.
>>
>> There is absolutely nothing special about the range 224-255.  And 
>> there is no region reserved for vendor-proprietary class numbers, so 
>> it is always possible for a non-standard class to conflict with 
>> another class (let alone with another vendor's non-standard class.)
>>
>> This is a problem with RSVP, but there's no real solution as long as 
>> the class ID remains an 8-bit value.  (And the kind of radical change 
>> needed to make it wider would probably be unwelcome, given the number 
>> of existing implementations.)
>>
>> -- David
> 
>

---

From: Shahram Davari <[email-masked]>
Date: Tue, 30 Jul 2002 08:32:16 -0700

David,

I think Andy is right. PacketCable has been able to get the number 226
without any RFC.

Yours,
-Shahram

> > According to 
> http://www.iana.org/assignments/rsvp-parameters, the range

---

From: [email-masked]
Date: Tue, 30 Jul 2002 21:58:11 +0100

My view on this is that any body who purports to be a 'standards
organisation' should not sanction vendor (or other, eg SP) protocol
codepoints.

regards, Neil

> From: Shahram Davari [mailto:[email-masked]]
> Sent: 30 July 2002 16:32
> To: 'David Charlap'; IETF MPLS List
> Subject: RE: Vendor ID (OUI) encoding in LDP section 3.6.1.1
> 
> 
> David,
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 30 Jul 2002 22:25:55 -0400

Neil,

>organisation' should not sanction vendor (or other, eg SP) protocol

See Q.2931 (02/95 revision is the one I'm looking at) section 4.5.8 and 
X.36 (04/95) Annex D for some examples of ITU-T usage of the IEEE OUI for 
vendor extensions and private protocol identification.

Cheers,
Andy

---

From: [email-masked]
Date: Thu, 1 Aug 2002 03:43:54 +0100

Andy, 
 
> vendor extensions and private protocol identification.
NH=> And therefore the conclusion is?.........you seem to be saying
something like 'if X commits a crime it now gives everyone the right and
also go and commit the same crime'.  I don't care which stds body does
this....it simply is not right in principle IMO.

regards, Neil