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

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 29 Jul 2002 12:52:16 -0400

Shahram,

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.

Cheers,
Andy

------

At 7/29/2002 08:39 AM -0700, Shahram Davari wrote:
>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
> >
> >
> > 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: David Charlap <[email-masked]>
Date: Tue, 30 Jul 2002 10:22:49 -0400

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: "Andrew G. Malis" <[email-masked]>
Date: Tue, 30 Jul 2002 10:41:57 -0400

David,

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:
>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.
>
>doesn't support the object should respond to it.  The range chosen depends 
>on the required behavior:
>
>128-191 - non-supporting routers will drop the object but process the rest 
>of the message.
>
>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.)
>
>to make it wider would probably be unwelcome, given the number of existing 
>implementations.)
>
>-- David

---

From: David Charlap <[email-masked]>
Date: Tue, 30 Jul 2002 11:10:20 -0400

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:
>> allocation.  Even drafts that are well on their way to becoming RFCs 
>> don't usually get numbers assigned until it actually becomes an RFC.
>>
>> 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.
>>
>> 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
> 
>