RE: iFCP: A couple of iFCP questions

[Charles Monia <cmonia@NishanSystems.com>]

Hi Todd:

In the case of an FC N_PORT login, I was referring to the 64-bit Port_Name
(or alternatively the Node_Name) field returned in the ACC frame.

Analogous considerations would also apply to an iSCSI login -- although, of
course, the handshake and WWUI format is different.

Charles

> -----Original Message-----
> From: Sperry, Todd [mailto:Todd_Sperry@adaptec.com]
> Sent: Thursday, January 04, 2001 4:50 PM
> To: 'Charles Monia'
> Cc: ips@ece.cmu.edu
> Subject: RE: iFCP: A couple of iFCP questions
> 
> 
> 
> 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
> > > 
> > 
>