Summarizing Meeting on BMC Aggregation
mcr at sandelman.ca
Sat Jan 18 13:39:05 AEDT 2020
Thank for the interesting call yesterday.
I don't think I will have the time to attend regularly, but we'll see.
I have code to write, ya know :-)
Richard Hanley <rhanley at google.com> wrote:
> The definition of a machine here is relatively opaque, but it can be
> thought of as an atomic physical unit for management. A machine is
> then split into multiple domains, each of which is managed by some
> management controller (most cases it would be a BMC). There may be
> some cases where a domain has multiple BMCs for redundancy.
> Domains are relatively close to each other physically. Sometimes they
> will be in the same chassis/enclosure, while other cases they will be
> in an adjacent tray.
> One key point that was discussed in this meeting was that the data and
> transport of these domains is relatively unconstrained. Domains may be
> connected to the aggregator via a LAN, but there is a community need
> to support other transports like SMBus and PCIe.
If I were designing this, I would define standard way to transport IPv6 over
SMBus and PCIe, and then use IPv6 Link-Local addresses, and call it all a
LAN. This has three effects in my opinion:
1) all transports need and get security resulting in fewer bugs
2) no need to re-invent TCP or HTTPS
3) directly connected hosts have less inherent privilege.
The IETF ANIMA working group
has created an O&M mechanism called the Autonomic Control Plane.
It has a discovery and negotiation protocol (GRASP), and as well as
onboarding (BRSKI). It is designed for exactly this kind of use.
https://datatracker.ietf.org/doc/rfc8368/ describes some of the high-level
design goals. The documents are stuck in the RFC-EDITOR queue due to
cross-references, but will get RFC-numbers very soon.
I am one of the authors of BRSKI.
In addition, the IETF Remote Attestation WG (RATS), at:
has been working on an architectural document. (We have people from TCG,
FIDO, Android, Global Platform, ...) Actually, we have a few such
documents, and we are merging them, the live process visible at:
In particular, I point you to this pull request which was discussed this past
Doesn't the composite device use case look very much like the aggregator
situation you are trying to create? If you care about attestation (and I
think you said you did), then it seems like there are significant synergies
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: not available
More information about the openbmc