[Federated-fs] Meeting Minutes: Conference Call on 3/28

[Daniel Ellard]

On 3/28/07 8:39 PM, "Manoj Naik" <manoj at almaden.ibm.com> wrote:

> Please respond if there are errors or if I missed anything.

Manoj --

    Thanks for taking these very comprehensive notes.

I want to expand on one of the points I tried to make during the call
(because I don't think I made it very well, but it's an important thing that
has colored our thinking to the extent that we should have stated it as a
fundamental assumption):

> Arun asked how the FSN is different from the local "name" (presumable
> path or fsid). Dan explained that FSN was just a federation concept. So
> why is there a separate junction key? Because FSN is essentially a tuple
> of NSDB and junction key. What's the format of the FSN? Is it a URI or a
> string name? While the exact format of the FSN is not important for the
> requirements doc, the current thought is that the junction key could be
> a UUID (so there are no collisions), whereas the NSDB could just be a
> DNS name. David Black had commented earlier that DNS names do not
> express location of NSDB well, but Dan countered that this is the same
> problem regular clients face as well.

Assumption: DNS names are an acceptable way to identify hosts and locate
services within the federation.  There may be some extra plumbing required
(see below for possible examples) but DNS is Good Enough.

Of course, there are many problems with DNS (not to mention IP) that can
violate this assumption.  The same DNS name can resolve to different IP
addresses -- or fail to resolve at all -- depending on which DNS servers are
queried (and this is actually a feature, not a bug...).  Even if the same
DNS name resolves to the same IP number everywhere, that same IP number can
identify different hosts -- or fail to identify any hosts at all -- if the
hosts trying to route to the given IP number use different gateways with
different routing tables, etc (and again, this is a feature...).

Despite these potential problems, I believe that we can assume that DNS and
IP are good enough for the following two reasons:

1.  We've got decades worth of procedures and mechanisms for avoiding these
pitfalls.  The horrible things that can happen usually don't.

2.  The client-facing protocols all use DNS (or something very similar),
either directly or indirectly, to name things like shares, fs_locations,
exports, etc.  Therefore, if we can't make DNS work, then we can't make the
clients work, and the whole exercise is doomed unless we change all the
client-facing protocols -- which would probably just spell a different doom.

One way to satisfy this assumption is to say that all of the federation
members need to have the same view of the DNS namespace (at least for the
names used by entities in the federation).  A more realistic approach is to
assume that all of the NSDBs have globally-resolvable names and to let the
NSDBs manage translation of FSLs based on the clients on whose behalf FSN
resolution they are doing.  When a server asks the NSDB to resolve an FSN,
it can also tell the NSDB what client is going to be using the result -- and
the NSDB might answer differently depending on where the client is.

-Dan