The MPLS WG Archive

[neil.2.harrison@bt.com]

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

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> 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,
> 
> 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
> > > 
> > > 
> > 
> > 
>