Review of draft-lior-radius-bandwidth-capability-00.txt

[Bernard Aboba <aboba@internaut.com>]

Review of draft-lior-radius-bandwidth-capability-00.txt

Overall, my recommendation is that the material from Section 3-6 of this
document be incorporated into the IEEE 802 document in the next revision.
The material from Sections 1-2 is mostly expository and therefore is not
required in an attribute specification.  My recommendation is to incorporate
the material required to describe the attributes into Section 3,  and put
the rest of section 1-2 into a separate document or drop it altogether.

Comments on Section 3-6 follow.

Section 3

The Ingress and Egress Bandwidth attributes are defined as 32 bit
values expressing Bytes per second.  Is this really the right way
to express bandwidth?  This attribute has been implemented in
Metro Ethernet networks where bandwidth of 10+ Gbps is available,
and we are seeing an order of magnitude increase every 3 years.
I'd suggest that we might want to think of alternative scales
such as Kbps, as well as a 64-bit value instead of 32-bits.

Also, the explanations of the attributes in Section 3 are minimal.
The RADIUS tradition is to explain the usage of the attribute here
(see RFC 2865) rather than writing a large "architecture" section.

While I'm fairly clear about the usage of the bw attributes in
Access-Accept, CoA-Request and Accounting-Request packets, I am
not as clear about the meaning in an Access-Request.  In that
situation "bandwidth available" seems unclear to me.  Is this
a measurement of the negotiated rate?  Of the "slot time" available
to a station?  Of the available throughput?  There are highly
transient measurements.  If we are looking for flow data then
there are better ways to get it.

Similarly, in Accounting-Request packets I can see echoing
the bw values from the Access-Accept.  But a dynamic measurement
seems redundant since we already support attributes for octets
in/out.

   Note 1 :  If Ingress-Bandwidth appears alone in an Access-Request
      packet then the NAS is indicating that it only supports symmetric
      bandwidth allocation.  Therefore, Egress bandwidth SHOULD NOT
      appear in the corresponding Access-Accept packet.
   Note 2 :  Bandwidth-Profile-Id MUST NOT appear in a RADIUS packet
      that contains either or both of Ingress-Bandwidth or
      Egress-Bandwidth attributes.

The Note 1 seems to imply that putting bw attributes in an Access-Request
is for capability negotiation.

Section 5

Why does this document require new vlues for Acct-Terminate-Cause?

Section 6

Surely there must be *some* security implications of these attributes, no?

--
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/>