Redfish Aggregator vs. RDE over PLDM

[Richard Hanley]

Hi Deepak,

Thank you very much for this feedback.  You've been very helpful while I've
been working to brainstorm on this subject.

There were a couple of thoughts that led me down this path.

One of the difficulties I see in creating an aggregator comes in how you
slice up a system and make it discoverable.  This might be a google
specific idiosyncrasy, but imagine a case where a Redfish service is
managing a chassis, expect for two sensors which are on a different
service.  How would an aggregator know that these two chassis should be
merged together.  When I read about Platform Descriptor Records (PDR) in
PLDM it seemed to me that it was trying to solve a similar problem.

In my reading of the RDE spec, there are two main issues that it is was
addressing:
  (1) How to fit the Redfish data model into a binary protocol.
  (2) How does a device implement only a portion of a Redfish service.
Most of the spec is dealing with issue (1), but issue (2) is the same issue
that the aggregator is trying to solve.

Another thing that I'm expecting is that at some point we will have some
legacy hardware that will have trouble running an HTTP stack.

This all kind of leads me to a larger point.  Which is that if this Redfish
aggregator is designed in a certain way, it may make RDE integration easier
in the future.  I just wanted to get an idea of whether that design goal is
worth considering.

Thanks,
Richard

On Wed, Nov 20, 2019 at 7:29 AM Deepak Kodihalli <
dkodihal at linux.vnet.ibm.com> wrote:

> On 19/11/19 4:51 AM, Richard Hanley wrote:
> > *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?
>
> IBM will use PLDM over MCTP (over an LPC binding) for Host - BMC
> communications (system management being shared between the Host and the
> BMC) on upcoming systems. The main motivation to switch to PLDM was
> because it fit the bill of an industry standard communications protocol
> with improvements compared to in-band IPMI. RDE was also motivation for
> us to work on implementing a PLDM stack, although RDE isn't on the
> immediate roadmap. If you're interested in looking at the existing
> PLDM/MCTP code/design docs on OpenBMC, I have some links below.
>
> We're able to map our requirements for the in-band Host BMC
> communications path to standard PLDM mostly. We did define a set of OEM
> commands to model a file as a PLDM object (and have that transferred).
> We still need to run this by PMCI to see if it's of interest to anyone
> for standardization purposes.
>
> I'm curious why we'd use RDE for a case where the multiple management
> controllers all do have a network stack and can parse JSON. Wouldn't
> they just implement Redfish (instead of RDE) and hence this makes a case
> for the Redfish Aggregator? Based on my reading of the RDE spec, it
> seemed to target IO adapters, for eg storage controllers, that would
> want to participate in Redfish based management, but the firmware
> running on those wouldn't implement an HTTP stack.
>
> https://github.com/openbmc/pldm
> https://github.com/openbmc/libmctp
> https://github.com/openbmc/docs/blob/master/designs/pldm-stack.md
> https://github.com/openbmc/docs/blob/master/designs/mctp.md
>
> Thanks,
> Deepak
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191121/cbe2b96d/attachment-0001.htm>