The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

David,

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

Yours,
-Shahram

> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> 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
> > 
> > 
> 
>