Subject: [nfsv4] MUST and MAY as it relates to Trunking

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 26 Aug 2008 12:06:00 -0400

There is an issue in draft-25 that relates to responding to Lars's
question about the mandatory/recommended status of trunking.

The problem really relates to an ambiguity in the spec about the word
"trunking".  In some places we refer to trunking purely in terms the
relationship between connections and sessions (session trunking) or
between sessions and client IDs (client ID trunking), including cases in
which we know trunking is valid because we are targeting the same server
IP address.

However, in other places, we limit the term to the special case in which
the validity of trunking is determined by information obtained through
EXCHANGE_ID.  For example, client ID trunking is mandatory if "trunking"
is used in the first sense but optional and limited to cases involving
server clustering if it used in the second sense.

So I've modified the Trunking section to take account of this
distinction and make things clearer.  Right now I'm having some
environmental issues running xml2rfc, so I'm sending the xml.  Attached
in the old (draft-25) xml for the trunking section, my modified xml, and
a diff and a context diff between the two.

I'll send the corresponding text files when I get xml2rfc to run
properly.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 27 Aug 2008 13:35:05 -0400

As promised, here are the corresponding text files.

-----Original Message-----
From: Noveck, Dave 
Sent: Tuesday, August 26, 2008 12:06 PM
To: [email-masked]'
Subject: MUST and MAY as it relates to Trunking 

I'll send the corresponding text files when I get xml2rfc to run
properly.
6,8c6,22
<    trunking.  NFSv4.1 repliers and requesters MUST support session
<    trunking.  NFSv4.1 servers MAY support client ID trunking.  NFSv4.1
<    clients MUST support client ID trunking.
---
>    trunking.
> 
>    NFSv4.1 servers MUST support both forms of trunking within the
>    context of a single server network address and MUST support both
>    forms within the context of the set of network addresses used to
>    access a single server.  NFSv4.1 servers in a clustered configuration
>    MAY allow network addresses for different server to uses clientid
>    trunking.
> 
>    Clients may use either form of trunking as long as they do not, when
>    trunking between different server network addresses, violate the
>    servers' mandates as to the kinds of trunking to be aallowed (see
>    below).  With regard to callback channels, the client MUST allow the
>    server to choose among all callback channels valid for a given
>    clientid and MUST support trunking when the connections supporting
>    the backchannel allow session or clientid trunking to be used for
>    callbacks
12c26,30
<    network addresses, to the same session.
---
>    network addresses, to the same session.  When the target network
>    addresses (a server addres) of the two connections are the same, the
>    server MUST support such session trunking.  When the target network
>    addresses are different, the server MAY indicate such support using
>    the data returned by the EXCHANGE_ID operation (see below).
15,33c33,54
<    same client ID, major server owner ID (Section 2.5), and server scope
<    (Section 11.7.7).  When two servers return the same major server
<    owner and server scope it means the two servers are cooperating on
<    locking state management which is a prerequisite for client ID
<    trunking.
< 
<    Understanding and distinguishing session and client ID trunking
<    requires understanding how the results of the EXCHANGE_ID
<    (Section 18.35) operation identify a server.  Suppose a client sends
<    EXCHANGE_ID over two different connections each with a possibly
<    different target network address but each EXCHANGE_ID with the same
<    value in the eia_clientowner field.  If the same NFSv4.1 server is
<    listening over each connection, then each EXCHANGE_ID result MUST
<    return the same values of eir_clientid, eir_server_owner.so_major_id
<    and eir_server_scope.  The client can then treat each connection as
<    referring to the same server (subject to verification, see
<    Paragraph 5 later in this section), and it can use each connection to
<    trunk requests and replies.  The question is whether session trunking
<    and/or client ID trunking applies.
---
>    same client ID.  Servers MUST support clientid trunking for two
>    target network addresses whenever they allow session trunking for
>    those same two network addresses.  In addition, a server MAY, by
>    presenting the same major server owner ID (Section 2.5), and server
>    scope (Section 11.7.7) allow additional case of client ID trunking.
>    When two servers return the same major server owner and server scope
>    it means that the two servers are cooperating on locking state
>    management which is a prerequisite for client ID trunking.
> 
>    Understanding and distinguishing when the client is allowed to use
>    session and client ID trunking requires understanding how the results
>    of the EXCHANGE_ID (Section 18.35) operation identify a server.
>    Suppose a client sends EXCHANGE_ID over two different connections
>    each with a possibly different target network address but each
>    EXCHANGE_ID with the same value in the eia_clientowner field.  If the
>    same NFSv4.1 server is listening over each connection, then each
>    EXCHANGE_ID result MUST return the same values of eir_clientid,
>    eir_server_owner.so_major_id and eir_server_scope.  The client can
>    then treat each connection as referring to the same server (subject
>    to verification, see Paragraph 7 later in this section), and it can
>    use each connection to trunk requests and replies.  The client's
>    choce is whether session trunking or client ID trunking applies.
46,50c67,72
<       associate the connection to the session.  (Of course, if the
<       client does not want to use session trunking, it can invoke
<       CREATE_SESSION on the connection.  This will result in client ID
<       trunking as described below.)
< 
---
>       associate the connection to the session.
>       Of course, if the client does not want to use session trunking, it
>       is not required to do so.  It can invoke CREATE_SESSION on the
>       connection.  This will result in client ID trunking as described
>       below.  It can also decide to drop the connection if it does not
>       choose to use trunking.
62d83
< 
67d87
< 
72c92,93
< 
---
>       The client is free to choose not to use client ID trunking by
>       simply dropping the connection at this point.

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 27 Aug 2008 10:47:01 -0700 (PDT)

Other than typos and spelling, it looks good to me.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/