John Thanks for reviewing. Some answers provided.
Regards Rajesh -----Original Message----- From: John Kaippallimalil [mailto:[email protected]] Sent: Wednesday, October 30, 2013 8:39 PM To: Rajesh Pazhyannur (rpazhyan); [email protected] 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: [email protected]<mailto:[email protected]> > [mailto:[email protected]] On > Behalf Of Rajesh Pazhyannur (rpazhyan) > Sent: Saturday, October 26, 2013 5:08 PM > To: [email protected]<mailto:[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
