Hi Bjorn, Thanks for your reply, see my comments inline.
On Wed, Feb 26, 2014 at 9:12 AM, Björn Smedman < [email protected]> wrote: > Hi Behcet, > > Thanks for your comments. > > On Tue, Feb 25, 2014 at 9:12 PM, Behcet Sarikaya <[email protected]> > wrote: > > On Mon, Feb 24, 2014 at 4:57 PM, Björn Smedman < > [email protected]> wrote: > >> The CAPWAP shortcomings discussed are similar to the problems > >> preventing us [1] from using it in our Software-Defined Networking > >> (SDN) architecture for IEEE 802.11 [2]: > >> > > > > Where in IEEE 802.11 is this happening? > > Your link [2] is pointing to your company's evaluation system. > > > > As far as I know, in IEEE 802, SDN work is being pursued in 802.16. > > Our architecture is compliant with the IEEE 802.11 standard as-is, so > we've seen little reason to get involved with the IEEE so far. > > IEEE has SDN BoFs during face to face meetings to bring together all people interested in SDN, so 802.11 people also attend these meetings. > The work within 802.16 seems more focused on 802.3 SDN. Ours is an > overlay architecture based on tunneling 802.11 over IP (using our > implementation of the here proposed protocol). Think Contrail meets > the here proposed tunneling protocol and has a baby. ;) > > Long term we think the same split that you have for 802.3 SDN would > make sense: IETF standards track for the data plane tunneling protocol > (Geneve equivalent), separate standardization process for the control > plane (OpenFlow / Open Networking Foundation equivalent). > > >> 1. CAPWAP was specified before separation of data, control and > >> management planes became the norm in networking architecture. > >> Unsurprisingly it provides very little separation of concern, > >> conflating everything from firmware updates to configuration of an > >> extra SSID. > >> > >> 2. CAPWAP attempts to provide provisioning/management functionality > >> that overlaps with other IETF standards track protocols, e.g. SNMP and > >> NETCONF/YANG, as well as other established management protocols such > >> as TR-069. > >> > > > > This is good point I think. But TR-069 is not ready for prime time yet. > > With all its shortcomings it's still widely deployed for managing > residential gateways (fixed-line braodband CPE). We come across it a > great deal in the field. > > Yes it is widely used. > >> 3. The separation of data and control planes that CAPWAP does provide > >> is IMHO incorrect: 802.1X key exchange is considered part of the > >> control plane but the derived encryption keys protect the data plane. > >> This doesn't matter when both control and data plane terminate in the > >> same location (the AC), but becomes a problem when they are separated > >> (encryption keys end up in a different place than the encrypted > >> data!). > >> > >> 4. CAPWAP leaves many options open to the implementer and is therefore > >> less interoperable than desired. To some extent this can be solved > >> with run-time negotiation, but such negotiation of security critical > >> aspects (such as where encryption keys are derived and kept) makes it > >> impossible to reason about the security of the system. This is less > >> than ideal IMHO. > >> > >> 5. CAPWAP (partly due to 1 and 2 above) depends excessively on details > >> in the IEEE 802.11 standard, with each amendment threatening to impact > >> the protocol. > >> > >> > >> We would be interested in specifying a simplified tunneling protocol > >> for IEEE 802.11 similar to Geneve [3], avoiding the above problems: > >> > > > > Geneve seems to be derived from VXLAN or NVGRE. > > Is this correct? > > Yes, they're all essentially tunneling protocols for 802.3. What we're > proposing is an IETF standard tunneling protocol for 802.11. > > I checked the Geneve draft. Sorry but I could not see much difference between Geneve and VXLAN. In Geneve you have Variable Length Options but that could be added to VXLAN easily. So I don't understand your argument that Geneve (by the way I like the name in French :-) ) is for 802.11 and VXLAN is for 802.3? VXLAN is becoming an RFC, you have all the reasons to use it, rather than reinventing the wheel. I am also having trouble in how Geneve will be used? The way I understand from you is it is going to be used between AP and AC as a tunneling protocol instead of CAPWAP tunnel. Then why does an AP need a VNI? I think you are envisioning a virtualized AP in a VM? Then it makes sense. > >> A. The protocol should mandate a single well-defined partitioning of > >> the IEEE 802.11 stack, with 802.1X authentication, key management and > >> encryption all implemented at the tunnel termination point for > >> security reasons. > >> > >> B. The protocol should mandate a single well-defined frame format > >> relying only on a PHY-independent stable subset of IEEE 802.11, > >> ensuring compatibility with 11n/ac and (most likely) beyond. > >> > >> C. Like Geneve the protocol should not provide any > >> provisioning/management functionality, instead relying on SNMP, > >> NETCONF/YANG, TR-069 and similar. > >> > >> D. Like Geneve the protocol should not provide any control plane > >> functionality, instead remaining compatible with several > >> Software-Defined Networking (SDN) protocols for IEEE 802.11. > >> > > > > Any pointers on this? > > See Geneve draft section 2.1 Control Plane Independence > (http://tools.ietf.org/html/draft-gross-geneve-00#section-2.1). > > See my comments on Geneve above. > There's no explicit mention of "Management Plane Independence", e.g. > for firmware updates and similar, but I'd say it's just an implicit > requirement on a tunneling protocol, taken for granted. > > Since Management Plane is different, how do you handle that? I am confused. Regards, Behcet > >> E. Each virtual access point in a multi-BSSID (and/or multi-radio) > >> access point should be treated as a separate entity associated with a > >> separate tunnel. > >> > >> > >> We see strong benefits to such a protocol from an extensibility [4], > >> flexibility [5] and security [6] perspective. If there is interest in > >> exploring this further please let me know. > >> > >> Best regards, > >> > >> Björn Smedman > >> > >> 1. http://www.anyfinetworks.com > >> > >> 2. http://anyfi.net and http://www.anyfinetworks.com/products > >> > >> 3. http://tools.ietf.org/html/draft-gross-geneve-00 > >> > >> 4. http://anyfi.net/documentation#architecture > >> > >> 5. http://anyfi.net/documentation#a_how_it_all_fits_together > >> > >> 6. http://anyfi.net/documentation#i_security_model > >> > >> _______________________________________________ > >> OPSAWG mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/opsawg > > > > >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
