[Federated-fs] "root" discovery and other bootstrapping protocols.

Everhart, Craig Craig.Everhart at netapp.com
Fri Mar 21 15:07:45 PDT 2008


In case it's not obvious, these two different approaches are
complementary in that they can apply to different parts of the client
namespace (at least to get them going).  Not to revive decade-old naming
wars, but the DNS SRV I-D I referred to in email yesterday suggests the
name "/nfs4" as the root for what Dan's calling an aggressive model.
There could be a totally distinct client name like "/idem" that might be
the root of what Paul was describing on the conference call, and which I
hope he'll write up.  My point here is that these can coexist simply by
having distinct client names.

		Craig 

> -----Original Message-----
> From: Ellard, Daniel 
> Sent: Friday, March 21, 2008 2:27 PM
> To: federated-fs at sdsc.edu
> Subject: [Federated-fs] "root" discovery and other 
> bootstrapping protocols.
> 
> 
> One of the topics that was mentioned as extremely desireable (if not
> required) during discussion at the IETF meeting in 
> Philadelphia is the "discovery" protocol for finding a root 
> of the namespace (without requiring substantial 
> per-client/per-locale configuration).
> 
> We talked about this yesterday on the weekly conference call, 
> and came up with two divergent but complementary 
> bootstrapping modes.  Both of these require some client 
> changes and config.
> 
> The two different modes can be characterized as "passive" and 
> "aggressive" (pithier names welcome):
> 
> Passive: "Wherever I go, there I am."  A client can find a 
> root of the local namespace with no a priori knowledge 
> whatsoever.  This could be done with something similar to a 
> DHCP service, or a reserved DNS name or SRV record.  For 
> example, by convention, each DNS server will resolve a name 
> like "localfedfs" to the IP of a "local" server that exports 
> a namespace root at a known location.  If you use DHCP to 
> find your DNS server, you'll get a local root.  If you set 
> your DNS servers by hand, you'll also be choosing your root.
> 
> Aggressive: "I know where I want to be; take me there."  This 
> uses an AFS-like view of the world, where it is possible to 
> symbolically name namespace root servers.  For example, the 
> client might have a special directory (i.e., "/fedfs") that 
> is initially empty.  If the client attempts to cd in a 
> subdirectory of this directory ("cd
> /fedfs/netapp.com") the client will interpret the name of 
> directory as the name of the DNS name to ask for SRV records 
> for namespace root servers owned by netapp.com.  Subdomains 
> would be implemented by more specific name (i.e., "cd 
> /fedfs/nane.netapp.com").  For systems that support autofs, 
> it's easy to imagine how this can be implemented as a autofs 
> module (although there's still an extra protocol to be 
> defined for this module).
> 
> According to my notes, Paul LeMahieu signed up to sketch out 
> the "passive" model and Craig Everhart is going to sketch out 
> the "aggressive" model (which he's mostly done in the form of 
> the I-D that he mailed out yesterday).  (I'm sure they'll 
> correct any mistakes or misrepresentations I've made.)
> 
> -Dan
> 
> 
> --
> Daniel Ellard, Ph.D.
> NetApp Advanced Technology Group
> 


More information about the Federated-fs mailing list