Re: [OPSAWG] Could you help review and comments the updated CAPWAP draft

John Kaippallimalil <John.Kaippallimalil@huawei.com> Thu, 31 October 2013 03:15 UTC

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
To: "Rajesh Pazhyannur (rpazhyan)" <rpazhyan@cisco.com>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: Could you help review and comments the updated CAPWAP draft
Thread-Index: Ac7UpP2yssHBL8S3TiqkLZR4EOWsNgAYwINgACQUEYAAAAgAEA==
Date: Thu, 31 Oct 2013 03:14:56 +0000
Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171CFD569B@dfweml511-mbb.china.huawei.com>
References: <470F27D1263A1B4EB73491ED995DE62525856226@NKGEML512-MBS.china.huawei.com> <6561EABF52675C45BCDACA1B4D7AA1171CFD5565@dfweml511-mbb.china.huawei.com>
In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171CFD5565@dfweml511-mbb.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [OPSAWG] Could you help review and comments the updated CAPWAP draft
Precedence: list

Hi,
I've read this draft and agree with the requirements identified and solution to tunnel to an AR, etc. There is a need to have the right means by which the AC, WTP and AR discover, sync up on tunnels, etc.

Some questions for clarification:
1. How do the AC and WTP agree that they will be using the mode where data from the WTP is not forwarded to the AC? Would there be a new message that informs the WTP of what to do. 

2. In this draft, the data is sent from a WTP to an Access Router. How does the WTP discover the right Access Router for a specific user? 
Especially considering that - as described in the draft itself - "in many deployments, the operator managing the WTPs/AC may be different from the operator providing the internet connectivity to the WTPs".
It could also be the case that sessions attached to a WTP may be homed to more than one operator.
It seems like a dynamic/protocol based discovery is better suited in this case?

3. In this case, there is a CAPWAP control relationship WTP - AC, and a data path of WTP - Access Router. If there is a failure of, lets say, the WTP - AC path (keep-alive fails), what would be the expected behavior of the data path (WTP-AR)? Would the data channel be kept or torn down? 

Also want to note that some of the proposals in draft-xue-opsawg-capwap-separation-capability-01 (Capability Announcement and AR Discovery in CAPWAP Control and Data Channel Separation) can complement this draft. We could discuss this separately as needed.

Best Regards,
John




> -----Original Message-----
> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On
> Behalf Of Rajesh Pazhyannur (rpazhyan)
> Sent: Saturday, October 26, 2013 5:08 PM
> To: opsawg@ietf.org
> Subject: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation
> for Data Frames in CAPWAP"
> 
> Hello
> 
> We have resubmitted a new version of the draft titled “Alternate Tunnel
> Encapsulation for Data Frames in CAPWAP",
> http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/.
> The previous version was titled: “Separation of CAPWAP Control and Data
> Plane: Scenarios, Requirements and Solutions”. Based on discussion in
> the last IETF, we reworked the draft.
> 
> The draft provides a reason for the need for WTP to have additional
> tunnel (beyond CAPWAP) encapsulations for user traffic. It enables a
> WTP to advertise the capability to support such alternate tunnel
> encapsulation and the AC to configure such tunnel encapsulation on the
> WTP.  The alternate tunnel encapsulation allows 1) the WTP to tunnel
> non-management data frames to an endpoint different from the AC and 2)
> allows the WTP to tunnel using one of many known ecapsulation types
> such as IP-IP, IP-GRE, CAPWAP.
> 
> 
> Regards
> 
> Rajesh
> 
>

Re: [OPSAWG] Could you help review and comments t… John Kaippallimalil