Re: [nfsv4] Review comments for WGLC of draft-ietf-nfsv4-layout-types

[hch <[e-mail]>]

On Wed, Aug 16, 2017 at 05:56:48PM +0000, Thomas Haynes wrote:
> RFC8154 doesn’t quite say that:
> 
>    The Server to Storage System protocol, called the "Control Protocol",
>    is not of concern for interoperability, although it will typically be
>    the same SCSI-based storage protocol.
> 
> I read that to say that it is possible for someone to implement the SCSI
> layout without using the SCSI-based storage protocol. 

Looks like that was a bad copy and paste job from the block layout.
I need to have a word with the lead author ;-)

> But based on the sentence above, I see a SHOULD on the use of the
> SCSI-based storage protocol as a control protocol and not a MUST.

In terms of interop it's indeed not a MUST - just the observable
behavior MUST be as if it was used, which is very close to the same.

> And given that RFC5663 also states:
> 
>    While the Server to
>    Storage System protocol, called the "Control Protocol", is not of
>    concern for interoperability here, it will typically also be a
>    block/volume protocol when clients use block/ volume protocols.
> 
> and we don’t consider that layout type to have a control protocol.

The big difference between the block and the scsi layout is that
the former does not specify a fencing protocol - and it turns out
implementing one is basically impossible except for a corner case.

> I think you are arguing that since RFC5663 did not address directly
> how the mds would fence the client and RFC8154 does, that
> a full control protocol does exist in RFC8154.  And that the
> sentence in question should read:
> 
> 
>    The Server to Storage System protocol, called the "Control Protocol",
>    is the same SCSI-based storage protocol.

Yes.

> I thought this covered that?
> 
>    In the context of fencing off of the client upon revocation of a
>    layout, these limitations come into play again, i.e., the granularity
>    of the fencing can only be at the host/logical-unit level.  Thus, if
>    one of a client's layouts is revoked by the server, it will
>    effectively revoke all of the client's layouts for files located on
>    the storage units comprising the logical volume.  This may extend to
>    the client's layouts for files in other file systems.  Clients need
>    to be prepared for such revocations and reacquire layouts as needed.

Ok.