Redfish Aggregator vs. RDE over PLDM

[Deepak Kodihalli]

On 22/11/19 3:54 AM, Richard Hanley wrote:
> 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.


This makes sense - a redfish aggregator may want to include devices 
implementing RDE into the aggregate model as well.

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 <mailto: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
>