Sumarizing BMC Aggregator Review

[Richard Hanley]

Hi,

Yesterday we had a discussion about a BMC aggregator. I've put together a
summary of the topics we discussed.

----------------------------------------------------------------------------------------
Security

The meeting started by addressing the security model for the aggregator.
The head node of the aggregator should have some form of mutual
authentication with each of the child nodes that are being aggregated. This
authentication between nodes may be waived in cases where there is some
implicit trust in physical link (i.e. an IPMI connection over LPC or SMBUS).

Regardless of the internal authentication mechanism used, the head node
will be solely in charge of authenticating external client requests, and it
will also be in charge of assigning authorization rules.

One point that was made was that if the aggregator ever lives "off" the
machine that may break this security model, since it would force all of the
child nodes to be aware of the external network

----------------------------------------------------------------------------------------------
Supported Protocols and Data Models

We had a discussion about the supported protocols.  There is a pretty
diverse set of protocols that we may want to support as inputs into the
aggregator.  There will need to be a process/daemon that is in charge of
importing child nodes, and converting them to the aggregator data model.

One point that was made in the meeting is that having many processes each
doing their own protocol transformations is a performance risk. This risk
can be mitigated if we assume that an aggregator is only aggregating a
single protocol at a time.

----------------------------------------------------------------------------------------------
Presentation

When it comes to the presentation of the aggregator, there will most likely
be a Redfish frontend and an IPMI frontend.  However, there may be use
cases in the future with upcoming protocols (e.g. RDE over PLDM).

Because there may be a number of disparate requirements for exposing the
aggregator to the outside world, it is very important that the aggregator
provides a rich data model that other applications can program against.

----------------------------------------------------------------------------------------------
Next Steps

At this point I think we have gotten a lot of feedback on use cases and
requirements.  The next step is to iterate on designing a data model.  I
will be putting together a first pass at the data model for us to discuss.

Regards,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200205/f9d6f3a2/attachment.htm>