Hi Dan, I am reading the framework draft. Here are some initial comments:
1. In figure 1, the AA controller has connection to both AA client and AA server. I think it's not practical in many cases. AAC and AAS, IMHO, are usually in different administrative domains. For example, AAC installed on a CE, and the AAS installed on the PE. Usually, CE and PE are controlled by different domain controllers. It's hard to deploy a super controller for CE and PE. Another example is, as you showed, the IoT. It's not practical to let all the end devices connect to the AA controller. Here, what scenario did you consider for this framework? The suggestion, if I am right, is to have the AA controller only connect to the AAS. AAC can pull additional information from the path: AA controller->AAS->AAC. 2. If both AAC and AAS connect to the AA controller, that means the AAC and AAS can be synchronized and configured by the management plane. So I guess some of the control plane function between AAC and AAS can be reduced. Regards, Tianran From: OPSAWG [mailto:[email protected]] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, June 30, 2016 1:58 AM To: [email protected] Subject: [OPSAWG] a new version of the automatic attachment drafts Hi, I have submitted two new Internet-Draft that describe the automatic attachment functionality: https://datatracker.ietf.org/doc/draft-romascanu-opsawg-auto-attach-framework/ https://datatracker.ietf.org/doc/draft-romascanu-opsawg-auto-attach-lldp/ Principal changes: - addressing the comments received at IETF 95 we split the generic protocol-independent framework that describes the discovery and service mapping mechanism in a separate I-D - we clarified terminology and re-drawn the principal building blocks - we connected the discovery and authentication mechanism with the MUD proposal Questions and comments are welcome. Thanks and Regards, Dan
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
