On Thu, Aug 25, 2022 at 12:05:54PM -0400, Michael Richardson wrote:
> > 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.
Hah! I think you are using ICN very liberally. To me, ICN is always bound to
the model, where a request message for a piece of information is sent, with
the information being "the destination address", and it is routed according
to that address, and a reply may be returned based on an onpath cache of
that information. That is a cool network layer model (incidentially also
an outgrowth of an older IP multicast model), but its scary to me to think
of replacing all of IP with ONLY that model. Thats my core ICN concern
and why i happen to be worried when someone mentions ICN..
> > 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.
I think pub/sub folks would argue their model is not ICN. Ultimately,
all the terminology woudn't be all that important if we would not
use it to avoid explaning what we really want to do technically...
> 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.
Right.
> > 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.
Sure, your argument is "the more i put onto the ACP, the more easily i may be
able to recognize ACP to fail". Reminds me of the use-it-or-loose-it IAB
draft thats just active. But thats not really maintenance. I thnk we would
need a "Maintenance" AF/set-of-ASA for the ACP/Network-Infrastructure, which
like for a plane regularily checks all the relevant aspects. Starting
with lifetime of licenses for all required software features on all network
equipment, software version, SMART status of all storage media, etc. pp.
> 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.
Puuh... yeah. This reminds me of the discuss about exactly this type of
functionality
with the MPTCP before it was shut down. Right now it doesn't have the set of
policies required to indicate when one path is preferred over another. And there
is no MPTCP WG anymore *sigh*
Cheers
Toerless
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
