Redfish Aggregator vs. RDE over PLDM

Redfish Aggregator vs. RDE over PLDM

[Richard Hanley]

[-- Attachment #1: Type: text/plain, Size: 2147 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2543 bytes --]

Re: Redfish Aggregator vs. RDE over PLDM

[Deepak Kodihalli]

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

Re: Redfish Aggregator vs. RDE over PLDM

[Richard Hanley]

[-- Attachment #1: Type: text/plain, Size: 3860 bytes --]

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@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
>
>

[-- Attachment #2: Type: text/html, Size: 5043 bytes --]

Re: 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@linux.vnet.ibm.com <mailto:dkodihal@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
>