Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-09.txt

From: [email-masked]
Date: Wed, 03 May 2017 19:46:05 -0700

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

---

From: Duzongpeng <[email-masked]>
Date: Mon, 15 May 2017 09:56:29 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, May 04, 2017 10:46 AM
To: [email-masked]
Cc: [email-masked]
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-09.txt

Abstract:

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.

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 16 May 2017 06:11:58 +0000

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

> From: OPSAWG [mailto:[email-masked]] On Behalf Of Duzongpeng
> Sent: Monday, May 15, 2017 5:56 PM
> To: [email-masked]
> 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:
> 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.
> 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
>

---

From: Duzongpeng <[email-masked]>
Date: Wed, 17 May 2017 08:57:39 +0000

Hi Tianran,

Thanks for your question.

This draft describes the scenario that, on the date plane, the WTP is connected to an AR instead of AC by using some kind of tunnel mechanisms. And this I-D describes several tunnel options. It will benefit the interworking of WTP and AC when this alt-tunnel network infrastructure is used.

As far as I know, Huawei, Cisco and ALU partially implemented the proposed solution(please correct me if my information is wrong ;-)). I.e., each of the vendors supports one or more tunnel types, while the full set is not necessary.

Best Regards
Zongpeng Du

-----Original Message-----
From: Tianran Zhou 
Sent: Tuesday, May 16, 2017 2:12 PM
To: Duzongpeng; [email-masked]
Subject: RE: [OPSAWG] LC request//RE: I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-09.txt

Hi Zongpeng,

Best,
Tianran

> 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
> 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:
> 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".
> "message element"; secondly, introduce the three tunnel types; 
> finnaly, introduce the seven sub-elements involved.
> 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
> 
> Subject: [OPSAWG] I-D Action: 
> 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.
>