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