Hi, Joe!
Thank you for reviewing the draft and providing valuable comments. Please see inline for some responses. Lin -----Original Messages----- From:"Joe Clarke (jclarke)" <[email protected]> Send time:Friday, 08/02/2024 05:34:24 To: "[email protected]" <[email protected]> Subject: [Int-area] Review of draft-bi-intarea-savi-wlan 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. LH>Regarding terminology, I think your suggestions are excellent, and we will make modifications to use more generic terms in the next version. 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. LH>In fact, we have also considered support for PD in the -03 version. Like described in RFC7513, ACs and APs can listen to DHCP-PD messages exchanged between wireless clients and DHCP servers to establish binding between secured MAC addresses and IPv6 prefixes for wireless clients. This is also mentioned in Section 10 of draft-ietf-v6ops-dhcp-pd-per-device-08. 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. LH>This is also a good suggestion. We did think poorly about autonomous AP scenarios before. Another solution we are reconsidering for autonomous AP scenarios is not to require implementation between APs as per the CAPWAP extension (Section 5.1.4), but to just suggest what to migrate and allow vendors flexibility in implementation. 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. LH>Good. We will take it to the opsawg. Joe
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
