Re: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP"

[John Kaippallimalil <[e-mail]>]

Hi,
[Sorry for reposting - but I think I posted to the wrong thread earlier - apologize for that.]

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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Rajesh Pazhyannur (rpazhyan)
> Sent: Saturday, October 26, 2013 5:08 PM
> To: [e-mail]
> 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.
> 
> We would like to get it adopted as a working group item and would like
> feedback on whether we are on track.
> 
> Regards
> 
> Rajesh
> 
>