Re: [OPSAWG] LC request//RE: I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-09.txt

Hi Zongpeng,

Thank you very much for picking this work up. The new version has a significant improvement on addressing existing comments.
One more question that many people may be interested. Whether this I-D has been implemented or has plan to be implemented and deployed?

Best,
Tianran

> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Duzongpeng
> Sent: Monday, May 15, 2017 5:56 PM
> To: opsawg@ietf.org
> Subject: [OPSAWG] LC request//RE: I-D Action:
> draft-ietf-opsawg-capwap-alt-tunnel-09.txt
> 
> Hi All,
> 
> I am happy to join the I-D draft-ietf-opsawg-capwap-alt-tunnel, and help
> to improve the document based on the comments received and recorded in this
> page
> (https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel)
> .
> 
> I revised the document and responded to all the existing comments as listed
> in the attachments. Also thanks Joe Touch's comments, which I have solved
> in the document. The major change include:
> 1. At the security aspect, we suggest using the IPSec to protect the data
> tunnel between WTP and AR.
> 2. Add a new sub-element, "minimum IPv6 MTU", according to the suggestion
> from Joe Touch.
> 3. Make it clear that "IEEE 802.11 WTP Alternate Tunnel Failure Indication"
> is carried in "CAPWAP Station Configuration Request message".
> 4. Make it clear that we define seven sub-elements (each with its
> corresponding type number). Three of them are specific for CAPWAP, one is
> specific for GRE, and others are common ones. Make it clear that they can
> only be used as sub-elements of "Alternate Tunnel Encapsulations Type message
> element" and "IEEE 802.11 WTP Alternate Tunnel Failure Indication message
> element".
> 5. Change the structure of the draft. Firstly, introduce the three new
> "message element"; secondly, introduce the three tunnel types; finnaly,
> introduce the seven sub-elements involved.
> 6. Give more explanations to the GRE tunnel type.
> 
> Now I believe this document is ready to send to IESG. So I request for a
> WGLC. And I will also help to reply any comments/questions during the
> following procedure.
> 
> Regards,
> Zongpeng
> 
> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: Thursday, May 04, 2017 10:46 AM
> To: i-d-announce@ietf.org
> Cc: opsawg@ietf.org
> Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-09.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area Working
> Group of the IETF.
> 
>         Title           : Alternate Tunnel Encapsulation for Data Frames in
> CAPWAP
>         Authors         : Rong Zhang
>                           Rajesh S. Pazhyannur
>                           Sri Gundavelli
>                           Zhen Cao
>                           Hui Deng
>                           Zongpeng Du
> 	Filename        : draft-ietf-opsawg-capwap-alt-tunnel-09.txt
> 	Pages           : 26
> 	Date            : 2017-05-03
> 
> 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 IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-09
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-capwap-alt-tun
> nel-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-
> 09
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg