Toerless Eckert <t...@cs.fau.de> wrote:
> I can not link ICN to the use-cases you describe. I could however
> easily map the resilient light-switch use-case to multicast and GRASP:
okay.
> Light switches could M_FLOOD instructions, such as in old building
> automation: GROUP_123 on/off. And lights are then preconfigured to
> belong to a group. Or as you propose, they could M_FLOOD status, as you
> propose. And lights are then preconfigured to be interested in a
> particular set of light-switches (or other states, motion sensors
> etc..).
ICN is just a signed M_FLOOD here.
> I am sure a pub-sub geek would describe this as a pub/sub bus kinda
> operation. Difference to multicast/messages is that buses supposedly
> cache state, so a light that had power failure should immediately get
> th relevant information, whether it is group status or other states of
> interest from the bus instead of having to wait or re-request messages.
I think that in an ICN, any node with the signed message can retransmit it.
> Wrt to resilience and whether to run data across ACP to be able to
> validate its correct/resilient operation: I think we often said that
> simpler networks such as low-power iot networks may not want to afford
> the complexity of separate ACP and data-plane, in which case the
> data-plane is the acp, aka: automatic/secure/resilient. However:
Yes, but I'm not talking about the lower-power part of the network.
I'm thinking about a 100G/s backbone in a building, whose purpose is to
provide data services to the tenants. (Probably using SR6, metro-ethernet,
QinQ, or...). The ACP would be the management plane for that network.
Some gateways/routers would have 100G interfaces, but also low-power IoT
interfaces, or powered BACnet/100baseT1. Or even GPIO boards that have
analog wires to buttons.
> In a large/fast/complex netework, you may have different degrees of
> degradation of the network, and the purpose of the ACP is to be the one
> layer of last-defense, of what the network should be able to do when
> everything else may have failed, especially also to perform possibly
> complex repair operations remotely. So the question really is how much
> you want put into that last line of defense.
part of my point is that if you think of the ACP as being the "last line",
then that means that you might not notice if it has broken.
> IMHO automated testing and automated injection of errors and all this
> good stuff for resilient networks should test the data-plane, and in a
> simple approach, all the control for these ongoing OAM operations could
> go across the ACP, but maybe even most of that complex and maybe
> high-load control should go to data-plane. Think about ongoing Mbps
> streams of network telemetry to centralized or decentralized analytics
> engines that attempt to measure network health. ACP or not...
I come back to SHIM6, MPTCP or QUIC/MASQUE. Initiate the connection over ACP
addresses, but then discover some higher bandwidth IP addresses and prefer
them for the bulk transfers.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
