[ieee-ietf-coord] Fwd: Last Call: <draft-ietf-opsawg-capwap-alt-tunnel-10.txt> (Alternate Tunnel Encapsulation for Data Frames in CAPWAP) to Experimental RFC

Russ Housley <housley@vigilsec.com> Wed, 29 November 2017 21:34 UTC

From: Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8E5BC9DE-7301-4EF7-AB55-980A4AB6E05A"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <540797ED-651E-4162-B4DD-DDC5A1F58D32@vigilsec.com>
References: <151198481729.7972.10583472312302909306.idtracker@ietfa.amsl.com>
To: ieee-ietf-coord@ietf.org
Date: Wed, 29 Nov 2017 16:34:29 -0500
Archived-At: <https://mailarchive.ietf.org/arch/msg/ieee-ietf-coord/-hRoyl0foNowbjnYzzci_3E1tY8>
Subject: [ieee-ietf-coord] Fwd: Last Call: <draft-ietf-opsawg-capwap-alt-tunnel-10.txt> (Alternate Tunnel Encapsulation for Data Frames in CAPWAP) to Experimental RFC
Precedence: list

This document is of interest to the IEEE 802.11 community.  Please participate in the IETF Last Call.

Russ


> From: The IESG <iesg-secretary@ietf.org>
> Subject: Last Call: <draft-ietf-opsawg-capwap-alt-tunnel-10.txt> (Alternate Tunnel Encapsulation for Data Frames in CAPWAP) to Experimental RFC
> Date: November 29, 2017 at 2:46:57 PM EST
> To: "IETF-Announce" <ietf-announce@ietf.org>
> Cc: draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, zhoutianran@huawei.com, opsawg-chairs@ietf.org, opsawg@ietf.org
> Reply-To: ietf@ietf.org
> 
> 
> The IESG has received a request from the Operations and Management Area
> Working Group WG (opsawg) to consider the following document: - 'Alternate
> Tunnel Encapsulation for Data Frames in CAPWAP'
>  <draft-ietf-opsawg-capwap-alt-tunnel-10.txt> as Experimental RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2017-12-13. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   Control and Provisioning of Wireless Access Points (CAPWAP) defines a
>   specification to encapsulate a station's data frames between the
>   Wireless Transmission Point (WTP) and Access Controller (AC).
>   Specifically, the station's IEEE 802.11 data frames can be either
>   locally bridged or tunneled to the AC.  When tunneled, a CAPWAP data
>   channel is used for tunneling.  In many deployments encapsulating
>   data frames to an entity other than the AC (for example to an Access
>   Router (AR)) is desirable.  Furthermore, it may also be desirable to
>   use different tunnel encapsulation modes between the WTP and the
>   Access Router.  This document defines extension to CAPWAP protocol
>   for supporting this capability and refers to it as alternate tunnel
>   encapsulation.  The alternate tunnel encapsulation allows 1) the WTP
>   to tunnel non-management data frames to an endpoint different from
>   the AC and 2) the WTP to tunnel using one of many known encapsulation
>   types such as IP-IP, IP-GRE, CAPWAP.  The WTP may advertise support
>   for alternate tunnel encapsulation during the discovery and join
>   process and AC may select one of the supported alternate tunnel
>   encapsulation types while configuring the WTP.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.

[ieee-ietf-coord] Fwd: Last Call: <draft-ietf-ops… Russ Housley