RE: iFCP: A couple of iFCP questions

["Sperry, Todd" <Todd_Sperry@adaptec.com>]

Charles,

One quick question.  You mentioned checking the
WWUI as part of the login sequence.  By this, do
you mean the 64-bit WWN (Port, Node, Fabric Port Name)
that's listed in iSNS (3.2.4).  Or is it something
else?

Thanks,
Todd.

-----Original Message-----
From: Charles Monia [mailto:cmonia@NishanSystems.com]
Sent: Thursday, January 04, 2001 3:47 PM
To: Peglar, Robert
Cc: ips@ece.cmu.edu; Charles Monia; Black_David@emc.com
Subject: RE: iFCP: A couple of iFCP questions




> -----Original Message-----
> From: Peglar, Robert [mailto:robert_peglar@xiotech.com]
> Sent: Thursday, January 04, 2001 9:07 AM
> To: 'Charles Monia'; Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: RE: iFCP: A couple of iFCP questions
> 
> 
> Charles
> 
> You stated below...
> > It's impossible to guarantee that the information returned in 
> > response to a
> > directory query won't silently become stale -- in spite of 
> > state change
> > notification.
> > 
> > Therefore, the requestor must assume that the data returned 
> > may be stale by
> > the time it is used to establish a session. It's the 
> > responsibility of the
> > session initiator to confirm that the desired endpoint was 
> reached at
> > session creation.
> 
> I agree.
> 
> However, when does this chase-one's-tail end?  If the requestor
> can make no assumption about validity, i.e. all such responses
> may be stale - how can unambiguous confirmation be achieved?  Does
> this mean one must establish a class 1 connection between endpoints?
> 
> If no guarantees can be made about connectionless query responses
> and their validity, then I think there may be a hole.
> 

Hi Rob:

With any directory-driven application, there is always a time skew between
when the information is received and when it is used. To address that
unavoidable window, the session initiator can confirm the device I/D at
session startup.  As part of the login handshake the session initiator is
given the WWUI of the responder, which can be checked against the original
value.  If there's a difference, the initiator can reissue the directory
query. State change notifications can, of course, help this by speeding the
discovery of such configuration changes.

In sum, while it may take some finite time for device configuration changes
to propagate, the process should naturally converge.  In a practical case,
this should not be an issue.

Charles


> Rob Peglar
> Director, Storage Architecture
> XIOtech Corporation
> (314) 308-6983
> 
> 
> > -----Original Message-----
> > From: Charles Monia [mailto:cmonia@NishanSystems.com]
> > Sent: Wednesday, January 03, 2001 7:29 PM
> > To: Black_David@emc.com
> > Cc: ips@ece.cmu.edu
> > Subject: RE: iFCP: A couple of iFCP questions
> > 
> > 
> > Hi David;
> > 
> > See below for comments.
> > 
> > > -----Original Message-----
> > > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > > Sent: Wednesday, January 03, 2001 3:06 PM
> > > To: jtseng@NishanSystems.com; Black_David@emc.com; ips@ece.cmu.edu
> > > Subject: RE: A couple of iFCP questions
> > > 
> > > 
> > > > 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.
> > > 
> > 
> > It's impossible to guarantee that the information returned in 
> > response to a
> > directory query won't silently become stale -- in spite of 
> > state change
> > notification.
> > 
> > Therefore, the requestor must assume that the data returned 
> > may be stale by
> > the time it is used to establish a session. It's the 
> > responsibility of the
> > session initiator to confirm that the desired endpoint was 
> reached at
> > session creation.
> > 
> > I'd venture to say that this is true of any directory-driven 
> > storage network
> > in general.
> > 
> > <remainder deleted>
> > 
> > Charles
> > Charles Monia
> > Senior Technology Consultant
> > Nishan Systems
> > email: cmonia@nishansystems.com
> > voice: (408) 519-3986
> > fax:   (408) 435-8385
> > 
>