Thank you Pascal for for the review! I don't think I want to respond to your specific comments, but rather constrast some text to explain why (charter aside) we felt that we need to leave out constrained networks.
The ACP is primarily about connecting network *service* equipment at an ISP (or Enterprise) with the Network Operations Center for managemenet and control. Running SDN flows over the ACP makes a significant amount of sense. Doing RESTconf over the ACP also makes sense. Or just ssh in and type "conf term" and go, knowing you *can't* fat finger something and lose your command channel. The ACP is secondarily (today! we hope it will change) about connectivity *among* this equipment such that the devices can interact at a meta-level. The ACP is in some sense an "Internet of Routers", ... by routers and *for* routers (and devices that contain switching functionality like hypervisors) These devices otherwise do revenue generating activities like moving packets, slicing and dicing video, running virtual machines, mining bitcoin, etc. There is no fundamental reason why constrained networks of constrained devices couldn't have an ACP, except for code size and energy consumption. I.e. except for the thing that makes them constrained. In a cabinet full of a physical hosts supporting some kind of virtualized structure such as you might find at facebook, google, amazon, etc. the little bit of interaction between the Top-of-Rack switch, the service processors (iDrac, iLO, etc.) of the systems, is significantly less than 1% of the typical 10G+ that the cabinet probably has. The ACP gives you a safe and secure place to bring in the sensors and actuators in the cabinet (IP enabled power bars, etc.). IPsec support in a powerbar is not unknown. To constrast this to battery-powered OpenMote scale devices. The ACP overhead is probably 80% of the bandwidth of network. You asked about why we have so many possible ACP technologies, but really IPsec is the MTI. That's partly because many are unfamiliar with IPsec and are sure that some other "custom" solution would be better. Grass is just greener over there. But in fact we actually have no other IETF standard solution that we can actually point to. "SSL VPN" is a marketing term, solutions are completely vertically integrated: they don't interoperate at all. OpenVPN an example of one, but it is a company/open-source-project, not an RFC. And also some would like to try MACSEC. I think that we could get IPsec + IKEv2 (or some other similar technology) into an OpenMote, but I'm not sure it's worthwhile, because at the end of the day the ROI isn't that good if you eat 70% of the system doing this. This brings me to your comments about how many parents to select and the like. While we don't have layer-2 ACKs in the IPsec hop-by-hop tunnels the way that 15.4 does, but we do have IKEv2 dead-peer-detection messages. We will generally know quite quickly if we have lot a connection to a parent. The occurance of an IKEv2 negotiation also provides a very strong signal of that there is a new peer. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
