Skip to main content

Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP)
draft-ietf-opsawg-capwap-alt-tunnel-12

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, opsawg-chairs@ietf.org, Tianran Zhou <zhoutianran@huawei.com>, opsawg@ietf.org, zhoutianran@huawei.com, warren@kumari.net, rfc-editor@rfc-editor.org
Subject: Document Action: 'Alternate Tunnel Encapsulation for Data Frames in CAPWAP' to Experimental RFC (draft-ietf-opsawg-capwap-alt-tunnel-12.txt)

The IESG has approved the following document:
- 'Alternate Tunnel Encapsulation for Data Frames in CAPWAP'
  (draft-ietf-opsawg-capwap-alt-tunnel-12.txt) as Experimental RFC

This document is the product of the Operations and Management Area Working
Group.

The IESG contact persons are Warren Kumari and Benoit Claise.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/


Ballot Text

Technical Summary

CAPWAP defines a specification to encapsulate a station's data frames
between the Wireless Transmission Point (WTP) and Access Controller
(AC). In many deployments it is desirable to encapsulate date
frames to an entity other than the AC (for example to an Access
Router).  This document provides a specification for this and
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.

Working Group Summary

There was no drama in the WG regarding this draft. The document was
originally WGLCed in 2014, and submitted for publication in early 2015. 
The WG then requested that the document to be returned to us, so that
we could merge it with another, related draft. This has been completed, 
and so we are resubmitting it.

Document Quality

Cisco has implemented this technology. A number of operators (including CMCC and AT&T) 
originally indicated that they need something like this, but it is unclear if this is actually being / going 
to be deployed.

Personnel

Tianran Zhou is the document shepherd.
Warren Kumari is the AD.

RFC Editor Note