At the INTAREA 120 meeting, Éric mentioned that since CAPWAP was a product of 
OPS, it might make sense for this work to move to opsawg.  As opsawg co-chair, 
I cannot say our WG would adopt this (that is a question for the WG), but I did 
take the time to read this draft as a contributor and a concerned WiFi 
implementor (on behalf of the IETF NOC).

While I think it’s a noble effort to standardize what some (most?) wireless LAN 
controllers do already today, I think there are some problems with this draft 
as it is.  First, the terminology of FIT and FAT APs was new to me.  I have 
never heard these terms.  I typically talk about lightweight (i.e., CAPWAP) APs 
or autonomous APs.   I would stick to more common terminology.  I would also 
move Access Controller (AC) to the terminology section.

Those are minor compared to the two big issues I see.  The first is a 
limitation we see today with the IETF WiFi network.  That is, we want to do 
IPv6 prefix delegation to wireless clients, and we cannot since the controller 
is doing mapping like what is described in this draft and not looking at the 
results of PD leases.  How does SAVI address PD?  To me, any standard around 
wireless address validation MUST account for PD.

The other big issue I see is in the signaling of MAC-IP mappings between 
autonomous APs.  You mention that the same CAPWAP signaling can be used, but I 
have never seen this happen between autonomous APs.   I’m not sure how that 
would scale, either.  Section 5.2 doesn’t really address what I feel are 
several challenges in the autonomous world.  Honestly, I haven’t seen this type 
of address validation with autonomous APs because there are so many challenges. 
 I would think this document should stay focused on the AC/lightweight modality.

Back to the question of moving this document to opsawg…this does seem to be 
somewhat of an operational concern, so I think there is applicability.  I think 
it’s worth taking to the opsawg list to see if there is interest.

Joe
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to