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:[email protected]]
Sent: Tuesday, October 29, 2013 8:26 AM
To: Rajesh Pazhyannur (rpazhyan); [email protected]
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: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Rajesh Pazhyannur (rpazhyan)
Sent: Sunday, October 27, 2013 2:08 AM
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
