[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Conclusion of Pre-Work Item Review on Bandwidth Document
Thanks! Please see my comments inline.
Farid
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org]
> On Behalf Of Bernard Aboba
> Sent: Saturday, October 08, 2005 8:42 PM
> To: radiusext@ops.ietf.org
> Subject: Conclusion of Pre-Work Item Review on Bandwidth Document
>
> Just to clarify the status of the Bandwidth Document
> deployment review.
>
> The reponses appear to indicate there is interest in
> standardization of
> Bandwidth-related attributes, particularly within the switch community
> (IEEE 802.1).
>
> However, the deployment review also concluded that this
> community would
> not deploy the document as it currently exists.
>
> Also, review from the IEEE 802.11 community indicates that legacy APs
> are not capable of carrying out Bandwidth Limitation as
> specified in the
> document, due to hardware limitations. This explains why the existing
> WFA-defined VSAs have not been deployed.
>
[FA] It is not deployed because we just started seeing WMM/802.11e (with
admission control) capable APs coming to the market. IMO, these
attributes make sense only for WMM/802.11e (with admission control)
capable APs deployed in public hotspots to provide QoS w/admission for
real-time services -- e.g., VoIP. For example, When the QoS capable AP
receives a TSPEC request from a client, the AP can decide whether to
accept or reject the TSPEC based the bandwidth attributes or Profile ID
received in the Access-Accept.
> However, newer APs that are capable of carrying out Bandwidth
> Limitation
> have adopted more sophisticated VSAs, and as a result, these newer APs
> would also not be likely to adopt the approach described in
> the existing
> document.
[FA] Can you name these new AP vendors supporting BW VSAs? Using VSAs
will not promote interoperability -- I thought the interoperability was
one of the key goals that we wanted to accomplish in this WG - no?
>
> Based on the responses, the authors of the document are urged to
> incorporate the comments from the switch and 802.11 AP communities in
> order to develop a document that is likely to be deployed and
> implemented.
>
> Once that revision has been completed, and deployment
> feedback indicates
> that the revision addresses industry/customer needs, the
> RADEXT WG will
> once again consider the document for adoption as a RADEXT WG
> work item.
>
>
>
> --
> 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/>
>
--
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/>