Subject: [nfsv4] [FedFS] Meeting Minutes, 06/04/2009

From: James Lentini <[email-masked]>
Date: Thu, 4 Jun 2009 16:13:16 -0400 (EDT)

FedFS Meeting Minutes, 06/04/2009
---------------------------------

Attendees
---------

Craig Everhart (NetApp)
James Lentini (NetApp)
Paul Lemahieu (EMC)
Pavan Mettu (Sun)
Renu Tewari (IBM)
Rob Thurlow (Sun)

Minutes
-------

+ IETF Note Well Agreement

  This is a reminder that our discussions are governed by the 
  IETF Note Well Agreement. See:

    http://www.ietf.org/NOTEWELL.html

  We will start each week's meeting with this announcement.

+ Review Action Items

  - James Lentini will poll for times over email.

    Complete. See below.

  - Paul Lemahieu will research LDAP trigger functionality, 
    including standardization, scalability, and configurability 
    (conditions that can cause the trigger to fire).

    There was discussion on this topic. Paul will ask another LDAP expert for
    more information.

    http://www.ietf.org/mail-archive/web/nfsv4/current/msg07057.html

  - James Lentini will research LDAP performance numbers (queries per
    second and connections)

    Complete.

    http://www.ietf.org/mail-archive/web/nfsv4/current/msg07051.html

+ New meeting time beginning next week?

  Renu believes that her conflict disappear next month.

  We will keep this meeting time and check again in a month. 

+ Bake-a-thon (June 15-19)
  http://www.connectathon.org/bakeathon/

  There was discussion about some face-to-face meetings among the 
  FedFS regulars at the event.

  We will not hold a FedFS call the week of bake-a-thon.

+ NSDB Draft Update

  Target a July 10th update.

+ FSL Caching

  Options discussed so far:

  1. No caching

  2. Administrative convention

     The proposal sent to the mailing list:

     http://www.ietf.org/mail-archive/web/nfsv4/current/msg07029.html
 
  3. Change client by
	- adding new client operation(s)
	- adding new client behavior: server assumes cache miss based on client
	  behavior (still requires changes to client software)

  4. List of caching fileservers per FSN

  5. LDAP client update features (aka FSN Delegations)

  We discussed the options above and their related AIs.

  Paul sent performance results to the mailing list.

  Based on these results, anything more than a few minutes of caching 
  seems unnecessary given the performance of LDAP Directories.

  The DNS has a TTL field and recommended values. Akami has published 
  recommended values for this field. Renu remembered one or two informational 
  RFCs describing this. The DNS TTL recommendations may serve as 
  inspiration for how to describe our recommendations.

  [AI] Renu Tewari will located informational RFCs on DNS TTL values

  The other AI from last week was related to #5 above. James and Mario 
  sent information to the mailing list on this topic. The summary is 
  that there is not a standard LDAP update protocol that is implemented
  in existing Directory Servers.

  For those interested, James noted that the disbanded IETF LDUP WG 
  has several threads on LCUP. The archive are here:

  http://www.imc.org/ietf-ldup/mail-archive/threads.html

  In particular, these email threads may be interesting:

    * LCUP show stopper (June 2003)
      http://www.imc.org/ietf-ldup/mail-archive/msg01781.html
    * Re: Is this really an LCUP show stopper? (Jun 2003)
      http://www.imc.org/ietf-ldup/mail-archive/msg01786.html
    * LDUP WG Last Call: LCUP Deliverable (Jun 2003)
      http://www.imc.org/ietf-ldup/mail-archive/msg01822.html

  While there are non-standard protocols available, we agreed that 
  such protocols should not be mentioned in the specification.

  Paul will ask another LDAP expert he knows about LDAP triggers.

  The consensus was to rule out options #1 (people will want to cache the 
  mappings), #3 (changes to the protocol are possible, but will take a 
  long time), #4 (scalability may be an issue), and #5 (LDAP has no 
  implemented AND standard way to do this) for now.

  We will update option #2 with more details about the junctions
  creation and include recommendations for the TTL of cached mappings.

  [AI] Craig Everhart will draft updated FSN-to-FSL caching text

+ LDAP DIT Structure Rules
 
  The I-D states that an FSN is required to be the parent its FSLs 
  in the DIT hierarchy.
 
  The current FedFS schema does not prevent the opposite arrangement
  (an FSL as the parent of an FSN in the DIT) from occurring due to 
  operator error or faulty software. Within the rules of the current 
  LDAP schema, it is possible for an entry 
  fslUuid=1234,dc=fed-fs,dc=com to be of type FslObject and for entry 
  fsnUuin=9876,fslUuid=1234,dc=fed-fs,dc=com to be of type FsnObject.

  The LDAP object class hierarchy is orthogonal to the DIT hierarchy. 
  Although an FsnObject is the supertype of an FslObject, that 
  does not regulate their relationship in the DIT hierarchy.

  If we wanted to enforce the "FSN is an FSL parent" requirement 
  in the LDAP schema, we could use DIT Structure Rules. DIT Structure 
  Rules are a standard part of LDAP and are described in RFC 4512, 
  Section 4.1.7.  

  James investigated support for DIT Structure Rules in OpenLDAP.
  See email thread on openldap-technical:

  http://www.openldap.org/lists/openldap-technical/200906/msg00011.htmla

  The summary is 

  (1) DIT Structure Rules are the standard way to enforce DIT 
      organization.

  (2) DIT Structure Rules are supported by few LDAP implementations 
      today, but OpenLDAP and other implementations plan to add 
      support for DIT Structure Rules in the future.

  (3) For the FedFS standard, it would be useful to describe optional 
      (but not required) DIT Structure Rules.

---

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Thu, 11 Jun 2009 11:11:23 -0400

I intended this to go to the list.

-->Andy

---------- Forwarded message ----------
From: William A. (Andy) Adamson <[email-masked]>
Date: Fri, Jun 5, 2009 at 10:29 AM
Subject: Re: [nfsv4] [FedFS] Meeting Minutes, 06/04/2009
To: James Lentini <[email-masked]>

> FedFS Meeting Minutes, 06/04/2009

Just because LDAP can keep up with a lot of traffic is no reason to
design a protocol with a lot of traffic if it can be avoided.

>  long time), #4 (scalability may be an issue)

I disagree, scalabilty is not an issue with #4. If I remember
correctly, the scalability concern with #4 is a potential 'long list
of servers caching the FSL' and the time/resources needed to contact
them all.

In fact, #4 scales a lot better than #2.

With #4, the FSL cache on a server with a junction never has to time
out. It's just like an NFSv4 delegation. The junction fileserver can
keep an FSL cached and know it is correct because it will be told when
the cached FSN<->FSL mapping is stale. This means that in the common
case where a junction is long-lived, there is no polling traffic from
the server caching the FSL. When a junction is migrated, there is
exactly one message to each server caching the migrated FSL.

#2 depends upon a timeout on the FSL cache.

For the sake of example, let's say we have a federated name space
consisting of 201 fileservers and one fileset. Fileset X is served by
fileserver201. Fileserver0 - fileserver200 all have a junction to
filesetX. I choose this example because 200 is a 'long list of
fileservers caching an FSL'. Normally this list will be less than 10
(namespace parents and replicas).

Using #2 and an FSL caching timeout of 5 minutes ("anything more than
a few minutes of caching seems unnecessary given the performance of
LDAP Directories" from above), this means 200 messages on the wire
every 5 minutes = 57600 messages a day just to know that nothing has
changed.

Using #4 and and no FSL caching timeout mean 0 messages a day.

Now the administrator migrates filesetX from fileserver201 to a new
fileserver202.

Using #2, there will be a message to fileserver201 to create the
'forwarding junction'.
Using #4 there will be 200 messages; one each to fileserver0 through
fileserver200 telling them that the mapping for fileset X has changed,
and indeed telling them the new mapping.

So, on the day filesetX was migrated, #2 sent 57601 messages, #4 sent
200 messages.
On every other day #2 sent 57600 messages, #4 sent 0 messages.

I don't see the reason to design a protocol that polls if we don't
have too, even though LDAP can handle it.

-->Andy

 and #5 (LDAP has no
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>