Hi, The problem this draft solves is described clearly, and I think that it fills a gap in the existing stds.
My questions on the previous version of the draft wrt tunnel failure, access router address, etc are all clarified here. I like the approach in 2.2 and 2.3 with respect to specifying the tunnel type/specification since it is simple enough and while providing sufficient flexibility. Section 2.1 - the figure and text help, but it would be good as the draft progresses to have a bit more of detail/clarity in the description. Best Regards, John > -----Original Message----- > From: OPSAWG [mailto:[email protected]] On Behalf Of Melinda > Shore > Sent: Tuesday, February 18, 2014 7:00 PM > To: [email protected] > Subject: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames > in CAPWAP > > Please note that Rajesh is planning to ask for working group adoption > of this document. Please give it a read and provide feedback on this > mailing list. Particularly interested in the question of how well it > meshes with CAPWAP documents we've already adopted. > > Melinda > > > > -------- Original Message -------- > Subject: [OPSAWG] Alternate Tunnel Encapsulation for Data Frames in > CAPWAP > Date: Tue, 18 Feb 2014 22:10:10 +0000 > From: Rajesh Pazhyannur (rpazhyan) <[email protected]> > To: [email protected] <[email protected]> > > > > Hello > > We have a submitted a new version of Alternate Tunnel Encapsulation for > Data Frames in CAPWAP,_http://datatracker.ietf.org/doc/draft-zhang- > opsawg-capwap-cds/_. > > Abstract > > In centralized IEEE 802.11 Wireless Local Area Network (WLAN) > architecture, the Access Controller (AC) isn't intelligent enough > actually to aggregate all the wireless frames, even the bandwidth > requirement in the access point is increasing. Thus it is a general > case in the existing operator's network that WTPs forward the > wireless frames directly to Access Router (AR) to avoid overload on > the AC. In this scenario, CAPWAP Control Channel and CAPWAP Data > Channel are separated from each other. This document extends CAPWAP > for applicability of CAPWAP Control and Data Channel separation. > > > We received some questions and suggestions from Dan Romascanu and John > Kaippallimalil on the mailing list on the previous draft. We have > attempted to address them in this draft. Specifically, > > 1. How does this draft address signaling, discovery mechanisms related > to setting up alternate tunnel. (ans. Tunneling protocols like > L2TPv3, IP/GRE (PMIPv6) already have a signaling mechanism. This > draft focuses on specifying the tunnel type and provides a > container > to hold message elements) > 2. Need for alternate tunnel encapsulation (given the existence of > defined mode with local bridging) > > > We would like to get it adopted as a working group item and would like > feedback on whether we are on track. > > > thanks > > Regards > > Rajesh > > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
