RE: A couple of iFCP questions

[Joshua Tseng <jtseng@NishanSystems.com>]

David,

See below:

> 
> > 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.

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.

> 
> 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.

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.

> 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 

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
> 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.
> 
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

> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>