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

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

Dan

Thanks for the review.  Really appreciate it.
Some immediate comments and we can follow up more live at the meeting next week.

Regards

Rajesh



-          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?



No, we don't expect to run the discovery and advertising protocols. We do plan to update the draft with an additional message element that will be sent by the AC to the WTP that will contain information about how the WTP can establish a tunnel (e.g., IP addresses, shared secret required if any, etc). Additionally, a number of tunneling protocols being considered like L2TPv3, PMIPv6 have their own control protocol to setup and tear down tunnels. The AC, simply, assists in providing the WTP with configuration information to initiate the control signaling.



-          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.



I don't think we are necessarily changing the CAPWAP architecture. This was the key feedback we received on the last draft. As a result, we have kept the CAPWAP architecture almost intact.  As far as the AC is concerned, the WTP behaves almost identical to a local bridging is concerned, in the sense that the AC will not see any user traffic. The difference however is that traffic is not locally bridged but actually tunneled to a different endpoint. If you think about it, a WTP can do this (without any changes to CAPWAP) and the AC-WTP interaction would work just fine. The reason to suggest the changes in the draft is that given the AC is configuring all the WTP parameters, it would be quite useful to extend CAPWAP to configure the alternate/additional tunnel parameter.



On the security front, note that the CAPWAP data channel encryption is optional. Currently, our position is that if user traffic needs to be secured then it can be handled via additional mechanism like IPSec. For example, L2TP, PMIPv6/GRE all provide  for an additional IPSec encapsulation.



At this point the document does not even mention that it updates RFC 5415 and RFC 5416.

Yes, noted.  We will address it.


-          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.


         I had hoped to provide the motivation for this in Section 1 (especially via the figures 1 and 2). Perhaps I can be more descriptive in the next version.
The main motivation is to separate the AC from the entity that handles the user traffic tunnels as well enable one of multitude of tunneling protocols for user traffic. There is still a requirement to tunnel and as result, local bridging is not an easy option. The options are either tunneled to AC or as we propose, tunnel to a different element.

-          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?

    Tunnel modes as defined today define tunnels between the WTP and AC. In the current draft, we are proposing an additional tunnel between tunnel and an endpoint other than AC. Also, the tunnel mode is being used to indicate that the user traffic is *not* being tunneled to the AC. So all in all, it seemed easier to define a new element rather than reuse/overload an existing one.



From: Romascanu, Dan (Dan) [mailto:[e-mail]]
Sent: Tuesday, October 29, 2013 8:26 AM
To: Rajesh Pazhyannur (rpazhyan); [e-mail]
Subject: RE: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP"

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Rajesh Pazhyannur (rpazhyan)
Sent: Sunday, October 27, 2013 2:08 AM
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