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

["Rajesh Pazhyannur (rpazhyan)" <[e-mail]>]

John

Thanks for reviewing. Some answers provided.

Regards

Rajesh

-----Original Message-----
From: John Kaippallimalil [mailto:[e-mail]]
Sent: Wednesday, October 30, 2013 8:39 PM
To: Rajesh Pazhyannur (rpazhyan); [e-mail]
Subject: RE: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP"

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.

>        I should probably explain this in more detail in the draft, with a figure.  The procedure is defined somewhat tersely in the text in Section 2.1 and 2.2. Specifically, the WTP will indicate support for this capability in the Discover and/or Join Request and the AC will determine whether to configure this mode while configuring the WLAN by providing the Tunnel Encap Type in the IEEE 802.11 Add WLAN Message Element.

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?

>  Dan had raised the same point in his email. We envision that the AC will configure the WTP with the appropriate identifier of the AR.  So for example, if PMIPv6 were being used (and the WTP were a MAG) then the AC would provide the IP address (and other configuration like shared secret) of the LMA.  Reusing CAPWAP to provide some of the alternate tunnel configurations seem advantageous.  This detail is not there in the current version of the draft but something we hoped to add in the next version.

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?

>       This is a good question. I believe this is a matter of implementation (and not something that has to be specified in the protocol). For example, in the current CAPWAP system if the WTP is operating in local bridged mode and there is a failure with the AC such that WTP can longer communicate with the AC.  In such a case, the WTP may choose to continue providing service to existing customers. Most current implementations continue service to existing customers.

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.
>       Happy to discuss this more.

Best Regards,
John


> -----Original Message-----
> From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On
> Behalf Of Rajesh Pazhyannur (rpazhyan)
> Sent: Saturday, October 26, 2013 5:08 PM
> To: [e-mail]<mailto:[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
>
>