The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Vendor ID (OUI) encoding in LDP section 3.6.1.1
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. egray@celoxnetworks.com 508 305 7214 -----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 > > |
|