Redfish Aggregator vs. RDE over PLDM

[Richard Hanley]

Hi,

A few weeks ago I wrote a posting about creating a Redfish aggregator.
Here is a brief summary of the use case I am looking to design around:

*In the medium term future, we will need to support hardware that has
multiple management controllers on the same "machine."   This simplest
version of this is a system with a management shared between a BMC and a
Host.  More complex versions will have multiple expansion/accelerator cards
attached to the motherboard.  Each of these expansion cards may have an
instance of open-bmc on them, along with a bmc on the motherboard.  Our end
goal is to have a centralized Redfish service on the motherboard bmc that
acts as the main communication to the outside world.  This motherboard
service would have to take external requests and forward them to the other
on-board management controllers.*

After doing some research I think there are two main paths to accomplishing
this.

*Redfish Aggregator*
In this approach all of the management agents are running a Redfish
service.  The core motherboard service would act as a web based
proxy/translator for all requests.

*Redfish Device Enablement*
When talking to Jeff Autor about a way to implement this, he pointed me to
the recently completed RDE spec.  RDE is a specification that allows
devices to implement portions of a Redfish service over PLDM.  It allows
devices to support Redfish even if they don't have an HTTP stack.

*Thoughts and Questions*
Is RDE on the open-bmc roadmap at the moment?  Are there any other
companies looking into adding support for RDE?  Does anyone have any strong
feelings on this issue?

I think that in the long term a solid implementation of RDE offers a lot
more flexibility than a http aggregator.  However, I'd also expect it's
significantly more effort to get up and running.  Hence why I am asking how
the community feels about this subject.

I'm also interested in hearing what people's experience working with MCTP
or PLDM have been.  Has anyone here used them in production? Are there any
particular highlights or lowlights with the protocols?

Any feedback you have is really appreciated.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191118/57ae0967/attachment.htm>