Subject: RE: A couple of iFCP questions

From: [email-masked]
Date: Wed, 3 Jan 2001 15:54:37 -0500

> It is safe to discard a translation when there are no active N_PORT
> sessions for a remote N_PORT.  In that case, the iFCP gateway SHOULD
> invalidate and remove the mapping to that remote N_PORT.

I don't believe that is always correct.  I know of Fibre Channel systems
that do something approximating a mainframe-style disconnect/reconnect
based on dropping the N_PORT session and opening up a new one if the
gap in I/O activity is sufficient.  I suspect things may be even worse in
the
tape world where the gap between sessions may be much longer (e.g.,
when the tape device is being sequentially shared among a set of
systems); is anyone on this list a tape expert who knows for certain? 
Prematurely discarding a translation will cause unexpected results in
these cases.

OTOH, there should be a solution along the lines of accumulating a
large number of "should be invalid" translations, discarding them in a
single batch and issuing the appropriate state change notifications.
Care is still required, as this "correct" operation of the (logical/virtual)
fabric may still have undesirable higher-level consequences (e.g., backup
application aborts).  I should note that this approach is unique to
Fibre Channel, as the networking analogs (e.g., running UDP through
a NAT) don't have a facility like state change notification available, and
hence generally can't recover from incorrectly discarding a translation.

> Of course,
> even if it doesn't, a device establishing a new N_PORT session has the
> responsibility of validating any pre-existing mapping by checking WWPN's
> of the remote device.

If "device" refers to the Fibre Channel device containing the N_PORT, I'm
not
sure this check is (always) done.  OTOH, if a mapping has changed, the state
change notification mechanism described in the response to the second
question will prevent this sort of problem.

The explanation of iSNS's role in change propagation seems fine, although
it makes connectivity to iSNS a requirement for operation of an iFCP
gateway -- in other words, if the iFCP gateway loses contact with iSNS,
it loses the ability to detect that its translations have become invalid.
I mostly wanted to note the contrast in availability requirements with DNS -
DNS does not have to be available after a connection has been set up.

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: [email-masked]
Date: Wed, 3 Jan 2001 18:05:39 -0500

> I need to correct my prior message to state that "It is safe to discard
> a translation when there are no N_PORT sessions to the remote N_PORT...".
> The translation MAY be discarded when a PLOGO logout message
> that terminates the N_PORT session is detected.  This is what I meant
> in the original message.  Sorry about the confusion.

And I was a little sloppy in my language.  By "dropping the N_PORT session",
I meant the use of PLOGO to terminate the session.  After doing this, a
Fibre Channel device can use PLOGI to initiate a new connection to the same
target without checking with the fabric nameserver, because it can rely on
state change notification to tell it if a N_PORT ID has become invalid;
there
are FC devices that behave in this fashion.  Probing a remote N_PORT
to see if a session is alive won't catch this situation; something like a
state change notification to force the originator to go back to the fabric
nameserver is necessary.  Reliance on state change notification is also
why the WWPN of the target may not be checked when the new session
is set up.

In any case, this is further down in the details than I really wanted to go
at
this juncture -- I'm satisfied that FC state change notifications can be
used to handle these situations.  The result may have some
"brute force" characteristics to it, and the usual caveats about not
using state change notifications unless they're really necessary applies.

--David

---

From: Joshua Tseng <[email-masked]>
Date: Wed, 3 Jan 2001 14:33:12 -0800

David,

> single batch and issuing the appropriate state change notifications.

It is certainly possible for an implementation to periodically probe
N_PORT sessions to determine if they are still valid and alive, and
for it to discard mappings and TCP connections supporting N_PORT sessions
that no longer exist.

> sure this check is (always) done.  OTOH, if a mapping has 

Regardless of whether FC devices actually do this checking, it
should be done.  Existing FC networks have the exact same issue.  If
they don't check the WWPN of the device they are talking to, then
they run a risk of corrupting data by talking to the wrong device. 

> changed, the state
I see the availability requirements for iSNS to be similar to that
of DNS for existing IP hosts.  Yes, iSNS is required if there is a
reconfiguration of the network.  But the same is true for IP hosts
using DNS for name resolution.  A storage device being unplugged
and moved around in the storage network is no different from an
administrator moving an IP host to a different subnet.  In both cases,
iSNS/DNS will be needed.  In fact, the latter case is more tedious since
it requires modification of resource records in the DNS server, while
the iSNS has update capability in the protocol itself.

Josh