[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Draft of extensions format
On Fri, 3 Sep 2010, Alan DeKok wrote:
The data I posted, and which you deleted in order to claim that no
data exists.
Is there a survey you can point me to? Our own first hand
knowledge paints a much different picture. I would be interested in any
data showing the cost to supporting infrastructure that you or anyone
else has compiled on the subject.
If 6K lines of changes ("diff / patch" format) too high a cost for
you, then your programmers are too highly paid.
I've tried multiple times to make a point that the RADIUS Server does not
represent the entire constellation of everything effected by the decision.
It would be a mistake to use the effort of one aspect of any effected
infrastructure to make a definitive judgment in EITHER direction. It was
in this context that I responded the way I did and in this context that my
question remains unresolved.
For what its worth I did include your quote in my previous email it was
separated by some of my commentary and most likely just overlooked. I
have no intention in playing games with anyone.
Can I ask how would you define a grouped VSA with multiple
sub-attributes in your draft where the total length of the entire VSA
exceeds the 1-byte type field?
For one, the question is meaningless. What does it mean if "a VSA
length exceeds a type field"?
I'm going to use an example from an actual wimax attribute to reduce the
chance of any dis-ambiguity.
For this example I will be using the wimax QoS-Descriptor:
Its structure is as follows:
1 byte -RADIUS Type (26)
1 byte - RADIUS Length
4 bytes - Vendor ID
1 byte - Wimax type (29)
1 byte - Length
1 byte - Continuation
TLV1..
TLV2..
TLV3..
TLVn...
The continuation field in QoS-Descriptor allows me to make the attribute
length larger than 255 by sending additional QoS-Descriptor attributes
which are then concatenated together using the Continuation flag.
The result is that should the combined size of all TLVs within the
QoS-Descriptor attribute in which no individual (Wimax-TLV) exceeds 251
octets leads to overflowing of the single byte length field I can leverage
the Continuation flag and send additional QoS-Descriptor attributes to
extend the size of QoS-Descriptor.
I am attempting to understand the analogue of this mechanism as it
relates to the draft.
If I interpret your question properly, the answer is to read the
document. Section 7.3. It doesn't matter if the data is a 251 octets
of "a", or 251 octets containing a sequence of TLVs.
I understand the extended type provides for fragmentation and reassembly
in 7.3 but can it as I recommended earlier act as a container or can only
the TLV data type?
2.1 and 2.2 (Extension header) say nothing of nesting. 2.3 and 2.3.1
(TLV header) discuss using TLV for nesting. The TLV header length is
limited to a single byte.
If TLV type is only able to support nesting then in my Qos-Descriptor
problem above I don't know how to define a QoS-Descriptor larger than what
the 1-byte length field is able to hold. This is the source of my
confusion/question.
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/>