Hi, I read the I-D and I have some clarification questions:
- If tunneling using the new modes described in this document is going to be possible to endpoints different from the AC, is it expected for these endpoints to run all the discovery and advertising protocols? This seems to be a change from the traditional CAPWAP architecture that may have scalability and security implications - at least this needs to be prompted and discussed. At this point the document does not even mention that it updates RFC 5415 and RFC 5416. - What is the advantage of tunneling non-management data frames using the new encapsulation modes vs. bridging them using the local bridging mode in RFC 5416? The document needs to explain this. - Why does the document take the approach of defining a new alternate tunnel encapsulation message? Would it not be possible to define new values in the Tunnel Mode enumeration defined in Section 6.1 of RFC 5416? Thanks and Regards, Dan From: [email protected] [mailto:[email protected]] On Behalf Of Rajesh Pazhyannur (rpazhyan) Sent: Sunday, October 27, 2013 2:08 AM 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. We would like to get it adopted as a working group item and would like feedback on whether we are on track. Regards Rajesh
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
