[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Draft of extensions format
On Thu, 2 Sep 2010, Alan DeKok wrote:
I'm sorry, but we put the time and effort into creating a draft
explaining exactly what we mean. I would prefer to discuss that
document rather than to help you debug and design your proposal.
I am suggesting what I believe to be a small change to make the
existing draft better and more likely to be implemented in the wild.
- 16-bit Type field
- All attributes (Including TLVs and sub-attributes) have distinct
integer identities.
The issue is the attributes are defined based on their parents and don't
standalone and so don't fit with the current flat model of defining
attributes with integer values as self-contained entities. Subgroups
require implementation infrastructure change to support.
I presume at this point that all major RADIUS servers support 3GPP2
and WiMAX. This means that they have already implemented TLVs as
proposed in the document.
In the grand scheme of things RADIUS servers are trivial components. I'm
more concerned about all the client vendors and management infrastructure.
I think requiring sub-encoding scheme for extension attributes to access
ordinary *UNGROUPED* attributes added at some point in the future
represents a significant and unnecessary complexity and upgrade cost with
little or no benefit. Flipping a switch in a RADIUS server to support a
new extension format is no problem. However plumbing SNMP OIDs into
existing infrastructure is a significant cost issue that is worth the
attempt to avoid if possible. For this reason I strongly oppose the draft
in its current form.
My advice for solving the problem within the framework of your draft was
to make type 16-bit and assign each attribute a unique integer identity.
If you look at what some are doing with the existing nested formats they
write string parsing functions and stuff them into opaque strings that are
then processed by the *RADIUS server* decoded and sent over the wire.
Not exactly the shining example of widespread support of TLVs and not
something I care to see be repeated for standard attributes as well.
The discussions Avi and & had were that we couldn't see a use-case for
TLVs needing more than 253 octets of data. The WiMAX VSAs do *not*
support TLVs having large payloads.
I double checked and I don't believe this is correct.. See:
http://www.juniper.net/techpubs/software/aaa_802/sbrc/sbrc70/sw-sbrc-admin/html/WiMAX_Overview6.html
You are not correct. I suggest reading the WiMAX specifications.
I have found other material that explicitly say the continuation flag
may be used specifically with WiMax TLVs allowing up to 4k or so TLVs.
No. There may be up to 4K of TLV's in a WiMAX VSA. But each TLV can
only carry 253 octets of data. The hint should be that the
"continuation" flag is *only* at the VSA layer, and not inside of each TLV.
This is an example of why labeling the container TLV simply 'TLV' can cause
misunderstandings and confusion.
In your draft TLV is actually the same thing as Wimax VSA.
When I say TLV is limited to 2^8.. I essentially mean the container
grouping object (TLV) which is the same as Wimax VSA. The Wimax VSA as
you note supports fragmentation.
So I still believe I am correct in that TLV in your draft does not provide
the same fragmentation options as the wimax implementation because the
entire container is limited to 2^8 while wimax is not.
In terms of a use case my Proxy-Suspects TLV would work here as well as
it needs to potentially be larger than 2^8 for cases where the proxy
server does not like multiple attributes.
TLV is universally understood to mean Type-Length-Value which all RADIUS
attributes are. This is the source of my confusion.
The standards are written to be consistent, without referring to
unwritten "universal understanding". There are many things that are
"understood" in RADIUS but which are unwritten, and therefore not
standardized. See this mailing list archive for many examples.
TLVs are used in more wire protocols than I can count. When you say TLV I
think attribute.. I don't assign the explicit use WRT containment /
encapsulation with the description. Container TLV. Envelope TLV... some
qualifier to explain its use I think would be helpful to people with
limited brain cells like myself but at the end of the day its a subjective
assessment.
regards,
Peter
--
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/>