Why does OpenBMC use Avahi mDNS instead of SSDP?

Patrick Williams patrick at stwcx.xyz
Fri Apr 17 06:40:10 AEST 2020


On Thu, Apr 16, 2020 at 03:02:46PM -0500, Gunnar Mills wrote:
> On 4/8/2020 3:27 PM, Joseph Reynolds wrote:
> > On 4/7/20 10:46 AM, Patrick Williams wrote:
> >> On Tue, Apr 07, 2020 at 09:58:15AM -0500, Joseph Reynolds wrote:

> >> mDNS is used more in the UNIX world, SSDP is used more in Windows.
> >>
> Was on the Redfish call earlier and this forum thread was discussed. The 
> Redfish members on the call did not totally agree with this statement. 
> They believe SSDP has a wider adaption than just Windows. A wider 
> adaption than mDNS.  Since SSDP is already in the Redfish specification 
> and has been adapted by Redfish implementations, adding a 2nd discovery 
> service would damage interoperability in Redfish.

I'm not really interested in a debate on this point, but I'm not finding
much evidence to back it up.  Can anyone point to well-used OSS
implementation of SSDP?  The only thing I can find is gssdp, which seems
to require a lot of Gnome components; not something we could easily pull
in on the BMC.

> The members on the call really wanted to encourage OpenBMC to implement 
> SSDP instead.

It probably isn't a bad thing to be able to support SSDP, don't get me
wrong, but "instead"?  Why would we want to take away service 
advertisement functionality, unless someone wants to explicitly disable it?

I can understand if they don't want to document, in the standard, a way to
advertise the Redfish service over mDNS, but isn't that a different
problem from what we're asking for?  Aren't we asking for a method to
manage the enablement of services on the BMC, specifically our mDNS
service?  So, if we still have mDNS, don't we need a way to configure it
through Redfish?

-- 

Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200416/6e08fe40/attachment.sig>


More information about the openbmc mailing list