RDE Enablement

RDE Enablement

[Garrett, Mike (HPE Server Firmware)]

Greetings,

I'm am interested to know if there has been any organized discussion or development on Redfish Device Enablement (RDE - DMTF DSP0218) for moving encoded Redfish data across PLDM/MCTP interfaces.  We are interested in promoting this standard and are willing to lead a reference implementation for OpenBMC if there is not yet something in progress.  If there is something in progress, can you point me at the work because I would love to see it.

What is the normal sequence for proposing, debating and finalizing major new features?  Would I submit something in Gerrit for review (e.g. a markdown file for the docs/designs repo?)   We could probably get something started fairly soon.

Thanks.

Mike

Re: RDE Enablement

[Ed Tanous]

On Thu, Jun 10, 2021 at 1:26 PM Garrett, Mike (HPE Server Firmware)
<mike.garrett@hpe.com> wrote:
>
> Greetings,
>
> I'm am interested to know if there has been any organized discussion or development on Redfish Device Enablement (RDE - DMTF DSP0218) for moving encoded Redfish data across PLDM/MCTP interfaces.  We are interested in promoting this standard and are willing to lead a reference implementation for OpenBMC if there is not yet something in progress.  If there is something in progress, can you point me at the work because I would love to see it.

We are interested in this as well, although we are in the early stages
of looking into it.  Ideally we'd like to have OpenBMC support add in
cards (NICs, Accelerators, ect) that supported this functionality, and
make that data available to the normal OpenBMC channels
(Redfish/ipmi/ect).

>
> What is the normal sequence for proposing, debating and finalizing major new features?

The mailing list tends to be a good choice for the very early
discussions.  https://github.com/openbmc/docs/blob/master/designs/design-template.md
tends to be a more formal process if that's what you're looking for.

>  Would I submit something in Gerrit for review (e.g. a markdown file for the docs/designs repo?)   We could probably get something started fairly soon.
>
> Thanks.
>
> Mike

RE: RDE Enablement

[Garrett, Mike (HPE Server Firmware)]

Great!  We are interested in RDE becoming ubiquitous on adapter cards so that Redfish configuration of storage and networking doesn't have to include adapter specific code.  A good success metric would be the ability to create a storage logical volume using nothing but standard Redfish operations.  In pursuit of this, a solid open source OpenBMC implementation seems like a good way to put RDE on the right footing.

My initial thoughts would be to build an RDE systemd service on top of the existing pldmd service and have an upper interface into the standard dbus interfaces for inventory, status, and configuration.  However, I suspect there's some additional dbus work needed to join RDE to bmcweb because there will be a need to dynamically change the Redfish model and support things like Actions.  A requirement for this to work would be the ability to discover PLDM devices and assign IDs (MCTP EID) in order to interrogate them for RDE capabilities.  It is unclear to me that the current PLDM and MCTP code handles discovery or if it assumes devices.

Happy to hear from folks about the best way to get this started.

Mike

-----Original Message-----
From: openbmc <openbmc-bounces+mike.garrett=hpe.com@lists.ozlabs.org> On Behalf Of Ed Tanous
Sent: Thursday, June 10, 2021 3:32 PM
To: Garrett, Mike (HPE Server Firmware) <mike.garrett@hpe.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: RDE Enablement

On Thu, Jun 10, 2021 at 1:26 PM Garrett, Mike (HPE Server Firmware) <mike.garrett@hpe.com> wrote:
>
> Greetings,
>
> I'm am interested to know if there has been any organized discussion or development on Redfish Device Enablement (RDE - DMTF DSP0218) for moving encoded Redfish data across PLDM/MCTP interfaces.  We are interested in promoting this standard and are willing to lead a reference implementation for OpenBMC if there is not yet something in progress.  If there is something in progress, can you point me at the work because I would love to see it.

We are interested in this as well, although we are in the early stages of looking into it.  Ideally we'd like to have OpenBMC support add in cards (NICs, Accelerators, ect) that supported this functionality, and make that data available to the normal OpenBMC channels (Redfish/ipmi/ect).

>
> What is the normal sequence for proposing, debating and finalizing major new features?

The mailing list tends to be a good choice for the very early discussions.  https://github.com/openbmc/docs/blob/master/designs/design-template.md
tends to be a more formal process if that's what you're looking for.

>  Would I submit something in Gerrit for review (e.g. a markdown file for the docs/designs repo?)   We could probably get something started fairly soon.
>
> Thanks.
>
> Mike

Re: RDE Enablement

[Andrew Jeffery]

On Fri, 11 Jun 2021, at 06:29, Garrett, Mike (HPE Server Firmware) wrote:
> A requirement for this 
> to work would be the ability to discover PLDM devices and assign IDs 
> (MCTP EID) in order to interrogate them for RDE capabilities.  It is 
> unclear to me that the current PLDM and MCTP code handles discovery or 
> if it assumes devices.

It's being worked on. Jeremy and Matt are working on the kernel socket-based implementation of MCTP and the associated userspace daemon for managing the networks.

Andrew

Re: RDE Enablement

[Deepak Kodihalli]

Hi Mike,

On Fri, Jun 11, 2021 at 2:29 AM Garrett, Mike (HPE Server Firmware)
<mike.garrett@hpe.com> wrote:
>
> Great!  We are interested in RDE becoming ubiquitous on adapter cards so that Redfish configuration of storage and networking doesn't have to include adapter specific code.  A good success metric would be the ability to create a storage logical volume using nothing but standard Redfish operations.  In pursuit of this, a solid open source OpenBMC implementation seems like a good way to put RDE on the right footing.
>
> My initial thoughts would be to build an RDE systemd service on top of the existing pldmd service and have an upper interface into the standard dbus interfaces for inventory, status, and configuration.  However, I suspect there's some additional dbus work needed to join RDE to bmcweb because there will be a need to dynamically change the Redfish model and support things like Actions.  A requirement for this to work would be the ability to discover PLDM devices and assign IDs (MCTP EID) in order to interrogate them for RDE capabilities.  It is unclear to me that the current PLDM and MCTP code handles discovery or if it assumes devices.

The current PLDM stack upstream is mostly for the BMC as a PLDM
responder, but there is work underway to make the BMC act as a PLDM
requester, discover devices, etc. You should start seeing patches for
these shortly (there's already
https://gerrit.openbmc-project.xyz/c/openbmc/pldm/+/43465).

What is the reasoning behind having RDE as a separate service as
opposed to being part of the PLDM service? I think one of the key
aspects would be the Redfish to RDE bridge (and vice versa). We're
also interested in RDE. I'd be happy to discuss/review further on the
ML or on Gerrit (if you're planning to put up a design doc).

Thanks,
Deepak

RE: RDE Enablement

[Garrett, Mike (HPE Server Firmware)]

Hi Deepak,

Integrating RDE directly into the PLDM service sounds just fine to me.

Mike

-----Original Message-----
From: Deepak Kodihalli <deepak.kodihalli.83@gmail.com> 
Sent: Friday, June 11, 2021 1:54 AM
To: Garrett, Mike (HPE Server Firmware) <mike.garrett@hpe.com>
Cc: Ed Tanous <edtanous@google.com>; OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: RDE Enablement

Hi Mike,

On Fri, Jun 11, 2021 at 2:29 AM Garrett, Mike (HPE Server Firmware) <mike.garrett@hpe.com> wrote:
>
> Great!  We are interested in RDE becoming ubiquitous on adapter cards so that Redfish configuration of storage and networking doesn't have to include adapter specific code.  A good success metric would be the ability to create a storage logical volume using nothing but standard Redfish operations.  In pursuit of this, a solid open source OpenBMC implementation seems like a good way to put RDE on the right footing.
>
> My initial thoughts would be to build an RDE systemd service on top of the existing pldmd service and have an upper interface into the standard dbus interfaces for inventory, status, and configuration.  However, I suspect there's some additional dbus work needed to join RDE to bmcweb because there will be a need to dynamically change the Redfish model and support things like Actions.  A requirement for this to work would be the ability to discover PLDM devices and assign IDs (MCTP EID) in order to interrogate them for RDE capabilities.  It is unclear to me that the current PLDM and MCTP code handles discovery or if it assumes devices.

The current PLDM stack upstream is mostly for the BMC as a PLDM responder, but there is work underway to make the BMC act as a PLDM requester, discover devices, etc. You should start seeing patches for these shortly (there's already https://gerrit.openbmc-project.xyz/c/openbmc/pldm/+/43465 ).

What is the reasoning behind having RDE as a separate service as opposed to being part of the PLDM service? I think one of the key aspects would be the Redfish to RDE bridge (and vice versa). We're also interested in RDE. I'd be happy to discuss/review further on the ML or on Gerrit (if you're planning to put up a design doc).

Thanks,
Deepak

Re: RDE Enablement

[Deepak Kodihalli]

Hi All,

On Fri, Jun 11, 2021 at 2:02 AM Ed Tanous <edtanous@google.com> wrote:
>
> On Thu, Jun 10, 2021 at 1:26 PM Garrett, Mike (HPE Server Firmware)
> <mike.garrett@hpe.com> wrote:
> >
> > Greetings,
> >
> > I'm am interested to know if there has been any organized discussion or development on Redfish Device Enablement (RDE - DMTF DSP0218) for moving encoded Redfish data across PLDM/MCTP interfaces.  We are interested in promoting this standard and are willing to lead a reference implementation for OpenBMC if there is not yet something in progress.  If there is something in progress, can you point me at the work because I would love to see it.
>
> We are interested in this as well, although we are in the early stages
> of looking into it.  Ideally we'd like to have OpenBMC support add in
> cards (NICs, Accelerators, ect) that supported this functionality, and
> make that data available to the normal OpenBMC channels
> (Redfish/ipmi/ect).

I had a couple of questions on RDE, and I wonder if this has crossed
your mind as you started looking at RDE, or if this is
misunderstanding on my part:

1) I understand the problem RDE tries to solve in terms of avoiding
having device-specific knowledge/code on the BMC, but doesn't PLDM
also solve a similar problem? For example, if a device supported PLDM
Type 2 (and other PLDM specs such as the one for FRU, etc), the BMC
could convert PLDM to Redfish. I understand this may not be as
convenient as RDE but it still solves the device-specific code
problem, PLDM being a standard protocol as well. Am I missing
something here? Is it just that RDE is more convenient than PLDM to
Redfish conversion, or is there more to it - for example, PLDM
can't/isn't intended to be converted to Redfish, in an
effective/lossless way?

2) Is RDE specific to a class of devices? Some of the documents I see
stress on I/O adapters. Would be it odd to implement RDE on devices
like Accelerators, CPU, etc?

Thanks,
Deepak

Re: RDE Enablement

[Ed Tanous]

On Thu, Jun 10, 2021 at 1:59 PM Garrett, Mike (HPE Server Firmware)
<mike.garrett@hpe.com> wrote:
>
> Great!  We are interested in RDE becoming ubiquitous on adapter cards so that Redfish configuration of storage and networking doesn't have to include adapter specific code.  A good success metric would be the ability to create a storage logical volume using nothing but standard Redfish operations.  In pursuit of this, a solid open source OpenBMC implementation seems like a good way to put RDE on the right footing.
>
> My initial thoughts would be to build an RDE systemd service on top of the existing pldmd service and have an upper interface into the standard dbus interfaces for inventory, status, and configuration.

Way late here:

This is one part that I've wondered about quite a bit:  How do we keep
the existing PLDM things viable, without duplicating all of the
Redfish code between them?  What component owns the "source of truth"
for the Redfish tree?  In addition, how do we shuttle redfish-specific
data between the various applications that now need them?  Going
through dbus would imply that we either write a redfish specific
interface, kind of like we did for IPMI/IPMB, or we have 1:1 with dbus
interfaces to redfish interface, which seems unlikely.

>  However, I suspect there's some additional dbus work needed to join RDE to bmcweb because there will be a need to dynamically change the Redfish model and support things like Actions.

Yep, this would likely involve some changes to make the router
modifiable at runtime to add and remove the appropriate routes as
devices are detected.


>  A requirement for this to work would be the ability to discover PLDM devices and assign IDs (MCTP EID) in order to interrogate them for RDE capabilities.  It is unclear to me that the current PLDM and MCTP code handles discovery or if it assumes devices.
>
> Happy to hear from folks about the best way to get this started.
>
> Mike
>
> -----Original Message-----
> From: openbmc <openbmc-bounces+mike.garrett=hpe.com@lists.ozlabs.org> On Behalf Of Ed Tanous
> Sent: Thursday, June 10, 2021 3:32 PM
> To: Garrett, Mike (HPE Server Firmware) <mike.garrett@hpe.com>
> Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
> Subject: Re: RDE Enablement
>
> On Thu, Jun 10, 2021 at 1:26 PM Garrett, Mike (HPE Server Firmware) <mike.garrett@hpe.com> wrote:
> >
> > Greetings,
> >
> > I'm am interested to know if there has been any organized discussion or development on Redfish Device Enablement (RDE - DMTF DSP0218) for moving encoded Redfish data across PLDM/MCTP interfaces.  We are interested in promoting this standard and are willing to lead a reference implementation for OpenBMC if there is not yet something in progress.  If there is something in progress, can you point me at the work because I would love to see it.
>
> We are interested in this as well, although we are in the early stages of looking into it.  Ideally we'd like to have OpenBMC support add in cards (NICs, Accelerators, ect) that supported this functionality, and make that data available to the normal OpenBMC channels (Redfish/ipmi/ect).
>
> >
> > What is the normal sequence for proposing, debating and finalizing major new features?
>
> The mailing list tends to be a good choice for the very early discussions.  https://github.com/openbmc/docs/blob/master/designs/design-template.md
> tends to be a more formal process if that's what you're looking for.
>
> >  Would I submit something in Gerrit for review (e.g. a markdown file for the docs/designs repo?)   We could probably get something started fairly soon.
> >
> > Thanks.
> >
> > Mike

Re: RDE Enablement

[Ed Tanous]

On Wed, Jul 21, 2021 at 1:34 AM Deepak Kodihalli
<deepak.kodihalli.83@gmail.com> wrote:
>
> Hi All,
>
> On Fri, Jun 11, 2021 at 2:02 AM Ed Tanous <edtanous@google.com> wrote:
> >
> > On Thu, Jun 10, 2021 at 1:26 PM Garrett, Mike (HPE Server Firmware)
> > <mike.garrett@hpe.com> wrote:
> > >
> > > Greetings,
> > >
> > > I'm am interested to know if there has been any organized discussion or development on Redfish Device Enablement (RDE - DMTF DSP0218) for moving encoded Redfish data across PLDM/MCTP interfaces.  We are interested in promoting this standard and are willing to lead a reference implementation for OpenBMC if there is not yet something in progress.  If there is something in progress, can you point me at the work because I would love to see it.
> >
> > We are interested in this as well, although we are in the early stages
> > of looking into it.  Ideally we'd like to have OpenBMC support add in
> > cards (NICs, Accelerators, ect) that supported this functionality, and
> > make that data available to the normal OpenBMC channels
> > (Redfish/ipmi/ect).
>
> I had a couple of questions on RDE, and I wonder if this has crossed
> your mind as you started looking at RDE, or if this is
> misunderstanding on my part:

As a preface, you might consider asking these questions on the DMTF
forums if they're not specific to OpenBMC.  The authors of the RDE
spec are present in those places and generally have good answers for
what the "intent" was.

>
> 1) I understand the problem RDE tries to solve in terms of avoiding
> having device-specific knowledge/code on the BMC, but doesn't PLDM
> also solve a similar problem? For example, if a device supported PLDM
> Type 2 (and other PLDM specs such as the one for FRU, etc), the BMC
> could convert PLDM to Redfish. I understand this may not be as
> convenient as RDE but it still solves the device-specific code
> problem, PLDM being a standard protocol as well. Am I missing
> something here? Is it just that RDE is more convenient than PLDM to
> Redfish conversion, or is there more to it - for example, PLDM
> can't/isn't intended to be converted to Redfish, in an
> effective/lossless way?

From my limited knowledge, it's because RDE can be losslessly
converted to Redfish, and the BMC can take the form of a proxying
agent.  In the PLDM to Redfish model, the BMC would need upfront
knowledge of every interface in PLDM, and how it maps to the Redfish
tree, which could get onerous.  In the RDE model, embedded controllers
end up taking the same form as an individual server would to a redfish
aggregator, which is advantageous in that all the aggregator code can
be reused (if OpenBMC had an aggregator).

>
> 2) Is RDE specific to a class of devices? Some of the documents I see
> stress on I/O adapters. Would be it odd to implement RDE on devices
> like Accelerators, CPU, etc?

RDE is meant for devices with a small footprint.  There has been
discussion in the past about allowing it on the host interface for
standard out of band communication, but I don't think that ever
materialized.  Putting it on accelerators or CPUs seems logical to me
given that their controllers are small footprint.

>
> Thanks,
> Deepak

RE: RDE Enablement

[Garrett, Mike (HPE Server Firmware)]

Sorry for the delayed response but comments inline.

Thanks,

Mike

> -----Original Message-----
> From: Ed Tanous <edtanous@google.com>
> Sent: Wednesday, July 21, 2021 9:24 AM
> To: Deepak Kodihalli <deepak.kodihalli.83@gmail.com>
> Cc: Garrett, Mike (HPE Server Firmware) <mike.garrett@hpe.com>;
> OpenBMC Maillist <openbmc@lists.ozlabs.org>
> Subject: Re: RDE Enablement
> 
> On Wed, Jul 21, 2021 at 1:34 AM Deepak Kodihalli
> <deepak.kodihalli.83@gmail.com> wrote:
> >
> > Hi All,
> >
> > On Fri, Jun 11, 2021 at 2:02 AM Ed Tanous <edtanous@google.com> wrote:
> > >
> > > On Thu, Jun 10, 2021 at 1:26 PM Garrett, Mike (HPE Server Firmware)
> > > <mike.garrett@hpe.com> wrote:
> > > >
> > > > Greetings,
> > > >
> > > > I'm am interested to know if there has been any organized discussion or
> development on Redfish Device Enablement (RDE - DMTF DSP0218) for
> moving encoded Redfish data across PLDM/MCTP interfaces.  We are
> interested in promoting this standard and are willing to lead a reference
> implementation for OpenBMC if there is not yet something in progress.  If
> there is something in progress, can you point me at the work because I
> would love to see it.
> > >
> > > We are interested in this as well, although we are in the early
> > > stages of looking into it.  Ideally we'd like to have OpenBMC
> > > support add in cards (NICs, Accelerators, ect) that supported this
> > > functionality, and make that data available to the normal OpenBMC
> > > channels (Redfish/ipmi/ect).
> >
> > I had a couple of questions on RDE, and I wonder if this has crossed
> > your mind as you started looking at RDE, or if this is
> > misunderstanding on my part:
> 
> As a preface, you might consider asking these questions on the DMTF forums
> if they're not specific to OpenBMC.  The authors of the RDE spec are present
> in those places and generally have good answers for what the "intent" was.
> 
> >
> > 1) I understand the problem RDE tries to solve in terms of avoiding
> > having device-specific knowledge/code on the BMC, but doesn't PLDM
> > also solve a similar problem? For example, if a device supported PLDM
> > Type 2 (and other PLDM specs such as the one for FRU, etc), the BMC
> > could convert PLDM to Redfish. I understand this may not be as
> > convenient as RDE but it still solves the device-specific code
> > problem, PLDM being a standard protocol as well. Am I missing
> > something here? Is it just that RDE is more convenient than PLDM to
> > Redfish conversion, or is there more to it - for example, PLDM
> > can't/isn't intended to be converted to Redfish, in an
> > effective/lossless way?
> 
> From my limited knowledge, it's because RDE can be losslessly converted to
> Redfish, and the BMC can take the form of a proxying agent.  In the PLDM to
> Redfish model, the BMC would need upfront knowledge of every interface
> in PLDM, and how it maps to the Redfish tree, which could get onerous.  In
> the RDE model, embedded controllers end up taking the same form as an
> individual server would to a redfish aggregator, which is advantageous in that
> all the aggregator code can be reused (if OpenBMC had an aggregator).
> 
[MikeG] 
I agree:  First of all, RDE is PLDM (type 6).  PLDM type 2 is a good solution for sensors, but RDE abstracts many of the other "non-sensor" aspects of device management including "actions".  For example, RDE can enable a BMC to present a storage controller's logical volumes, complete with the actions needed to create new volumes, or remove them.  Some adapters may only need Type 2 sensor information, but many advanced adapters have a much more complex management interface, and a Redfish model to match.  In these cases, a solid RDE implementation will provide a way to not have to link in adapter-specific or vendor-specific management libraries to the BMC.  Additionally, since the Redfish model comes from the adapter, it should be more consistent when that adapter is inserted into various systems with different BMC implementations, allowing the adapter to have more control over its Redfish presentation.  Finally, RDE includes the capability to signal Redfish events to the BMC, which can then be transmitted to subscribers.

The "good" is that theoretically, RDE offers very high fidelity Redfish management of an adapter while the BMC mostly plays a passthrough role.
The "less-good" is that for some aspects of management, the BMC would need to parse the data and add it to dbus for things the BMC wishes to aggregate (e.g. the sensor model) - things Type 2 does well.


> >
> > 2) Is RDE specific to a class of devices? Some of the documents I see
> > stress on I/O adapters. Would be it odd to implement RDE on devices
> > like Accelerators, CPU, etc?
> 
> RDE is meant for devices with a small footprint.  There has been discussion in
> the past about allowing it on the host interface for standard out of band
> communication, but I don't think that ever materialized.  Putting it on
> accelerators or CPUs seems logical to me given that their controllers are small
> footprint.
> 
[MikeG] 
RDE is not specific to a class of devices.  It is appropriate when a device is "behind" a BMC and has a Redfish-defined data model the BMC needs to present to clients.

> >
> > Thanks,
> > Deepak

RE: RDE Enablement

[Garrett, Mike (HPE Server Firmware)]

Hello Deepak.  As an update, we are just assembling a statically linked C library that can do generic BEJ/JSON encode/decode with input dictionaries and some unit tests.  I'm thinking that we could put this in its own repo and then build out the PLDM type 6 handling in the PLDM code as you suggest.

Feedback welcome,

Mike

> -----Original Message-----
> From: Deepak Kodihalli <deepak.kodihalli.83@gmail.com>
> Sent: Friday, June 11, 2021 1:54 AM
> To: Garrett, Mike (HPE Server Firmware) <mike.garrett@hpe.com>
> Cc: Ed Tanous <edtanous@google.com>; OpenBMC Maillist
> <openbmc@lists.ozlabs.org>
> Subject: Re: RDE Enablement
> 
> Hi Mike,
> 
> On Fri, Jun 11, 2021 at 2:29 AM Garrett, Mike (HPE Server Firmware)
> <mike.garrett@hpe.com> wrote:
> >
> > Great!  We are interested in RDE becoming ubiquitous on adapter cards so
> that Redfish configuration of storage and networking doesn't have to include
> adapter specific code.  A good success metric would be the ability to create a
> storage logical volume using nothing but standard Redfish operations.  In
> pursuit of this, a solid open source OpenBMC implementation seems like a
> good way to put RDE on the right footing.
> >
> > My initial thoughts would be to build an RDE systemd service on top of the
> existing pldmd service and have an upper interface into the standard dbus
> interfaces for inventory, status, and configuration.  However, I suspect
> there's some additional dbus work needed to join RDE to bmcweb because
> there will be a need to dynamically change the Redfish model and support
> things like Actions.  A requirement for this to work would be the ability to
> discover PLDM devices and assign IDs (MCTP EID) in order to interrogate
> them for RDE capabilities.  It is unclear to me that the current PLDM and
> MCTP code handles discovery or if it assumes devices.
> 
> The current PLDM stack upstream is mostly for the BMC as a PLDM
> responder, but there is work underway to make the BMC act as a PLDM
> requester, discover devices, etc. You should start seeing patches for these
> shortly (there's already
> INVALID URI REMOVED
> project.xyz/c/openbmc/pldm/*/43465__;Kw!!NpxR!xcRomaR8B_1cmsXdTkj
> qkA4_KrGm73QRD8NxGyIU0Tg6UF95qPKk8q2mfV_PXvg$ ).
> 
> What is the reasoning behind having RDE as a separate service as opposed to
> being part of the PLDM service? I think one of the key aspects would be the
> Redfish to RDE bridge (and vice versa). We're also interested in RDE. I'd be
> happy to discuss/review further on the ML or on Gerrit (if you're planning to
> put up a design doc).
> 
> Thanks,
> Deepak