Re: [PATCH 1/3] nvmet: expose discovery subsystem in sysfs

[Christoph Hellwig <hch@lst.de>]

On Wed, Mar 23, 2022 at 01:17:32PM -0400, John Meneghini wrote:
>  1. All hosts will connect to the existing Discovery Service with the Well Known
>     Discovery NQN and retrieve the Discovery Log pages for the HostNQN provided
>     in the Fabric Connect command, as it is done today.
>
>     It was assumed that Authenticating with the Well Known Discovery NQN would
>     would not be needed or supported because:
>     a) The Discovery Controller controls the Authenticate work flow and
>        returning AUTHREQ=1 in the connect response would break legacy hosts.
>     b) It doesn't make sense to have a Well Known Discovery NQN as a part of a psk.
>
>  2. Discovery Controllers which support Authentication can return Discovery
>     Log Page Entries with Subsystem Type (SUBTYPE): 03h - as defined by TP-8014.
>     These DLPEs will contain Unique Discovery NQNs - as defined by TP-8013
>
>  3. Hosts that support Authentication can then disconnect from the Well Known
>     Discovery Controller and re-connect with the Unique Discovery NQN. These
>     hosts should expect an AUTHREQ=1 response.
>
>  4. Hosts that don't want to support Authentication can ignore the SUBTYPE 03h
>     Log Page Entries and operate normally. This would include legacy hosts.
>
> Hopefully, with some kind of a design like this, both legacy (non-authenticating)
> and new (authenticating) hosts and discovery controllers can interoperate.

This makes much more sense.  But why would a host that is part of a PSK
setup even use the well known discovery controller at all?  Whatever
mechanism is used to share the key should also distribute the actual
discovery controller to be used and avoid that entire step.