Subject: RE: iFCP: A couple of iFCP questions

From: Charles Monia <[email-masked]>
Date: Wed, 3 Jan 2001 17:28:35 -0800

Hi David;

See below for comments.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 3:06 PM
> To: [email-masked]; [email-masked]; [email-masked]
> 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: [email-masked]
voice: (408) 519-3986
fax:   (408) 435-8385

---

From: "Peglar, Robert" <[email-masked]>
Date: Thu, 4 Jan 2001 11:07:00 -0600

Charles

You stated below...
> session initiator to confirm that the desired endpoint was reached at

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.

Thanks
Rob

Rob Peglar
Director, Storage Architecture
XIOtech Corporation
(314) 308-6983

> From: Charles Monia [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 7:29 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: iFCP: A couple of iFCP questions
> 
> 
> Hi David;
> 
> See below for comments.
>

---

From: Charles Monia <[email-masked]>
Date: Thu, 4 Jan 2001 15:47:15 -0800

> From: Peglar, Robert [mailto:[email-masked]]
> Sent: Thursday, January 04, 2001 9:07 AM
> To: 'Charles Monia'; [email-masked]
> Cc: [email-masked]

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

---

From: "Peglar, Robert" <[email-masked]>
Date: Thu, 4 Jan 2001 18:34:31 -0600

> this should not be an issue.

OK.

If, in the case where the WWUI confirmed at session startup is
different than the WWUI seen at login, should there be a built-in
delay to allow (some, better, complete, insert word here) convergence
to occur, before re-issuing the directory query?  For example, typical
FC switches might consume 500 to 700 ms while converging the mesh.  

Just a thought.

Rob

---

From: "Sperry, Todd" <[email-masked]>
Date: Thu, 4 Jan 2001 16:50:25 -0800

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:[email-masked]]
Sent: Thursday, January 04, 2001 3:47 PM
To: Peglar, Robert
Cc: [email-masked]; Charles Monia; [email-masked]
Subject: RE: iFCP: A couple of iFCP questions

Hi Rob:

Charles

---

From: Charles Monia <[email-masked]>
Date: Thu, 4 Jan 2001 17:55:10 -0800

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

> From: Sperry, Todd [mailto:[email-masked]]
> Sent: Thursday, January 04, 2001 4:50 PM
> To: 'Charles Monia'
> Cc: [email-masked]