Re: Draft of extensions format

[Alan DeKok <aland@deployingradius.com>]

Peter Deacon wrote:
> Conceptually I like the extensions.

  Thanks.

> We are already set to run out of attribute space once.  For that reason
> allocating additional space on the same order could possibly lead to the
> same problems in the future.

  We've taken 13 years to assign about ~140 attributes.  This works out
to ~11 attributes per year.  Even if we allocate attributes 4x as
quickly, (~45 per year), the ~1500 new attributes should allow for about
33 years of progress.  At 10x the historical rate, we will have ~14
years of progress.

  That calculation ignoring nested TLVs, which further extend the type
space.  And it's ignoring the possible 1500 new VSAs for each vendor.

> My recommendation is to use a single extensions attribute and make
> length two bytes.  Rob a couple of bits from the 16-bit length field for
> fragment and possibly presence of an extra flags byte.

  Do you expect the 1500 attributes to be exhausted within 5 years?

  Even if this did happen, there are ~50 unallocated attributes in the
"unassigned" and "reserved" spaces.  Allocating 40 of them to the new
type would allow for 10K new attributes.  This total is about the same
as you would get with a ~13 bit type space, and 3 bits of flags.

  To put it into perspective, there are about 5K attributes which have
been defined by major vendors and are in widespread use.  I just don't
see a need for *fast* allocation of 1000's of attributes.

> Finally reserve the lower region that overlaps with the current standard
> attribute space so that there are no conflicts with attribute id
> references.  Thus sub attribute ID's would not be needed in this context.

  That would permit "old" style attributes to be encapsulated in the
"new" style attributes.  (Even if it was forbidden, the encoding would
allow for it.)

  In contrast, our document solves the conflict by proposing a new
*naming* mechanism.  There is no conflict between "new" attribute "1",
and "old" attribute "1".  This is because the new attribute is defined
within the context of the encapsulation layer: the "old" attribute ID.

  i.e. The "old" number 241 uses the "new" format, and it can carry the
"new" attribute "1".  This attribute is referred to numerically as
"241.1", which makes it immediately distinct from "1", which is the old
User-Name attribute.

  There is no need to avoid conflicts with the "attribute id
references", because the naming system is such that conflicts are
impossible.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>