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: [email protected] [mailto:[email protected]] On > Behalf Of Rajesh Pazhyannur (rpazhyan) > Sent: Saturday, October 26, 2013 5:08 PM > To: [email protected] > 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 > > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
