Subject: Re: [Ips] Discovery reinstatement

From: William Studenmund <[email-masked]>
Date: Thu, 1 Sep 2005 09:56:54 -0700

On Aug 31, 2005, at 12:56 PM, Ken Sandars wrote:

> Hi Mallikarjun,
>
> I like your approach to this problem. In my mind the answer to 
> question 1 is
> a strong yes, however, I do not like the clause about Network Entity.
>
>> From my last posting, I restate: an initiator may not know if two 
>> Portals
> belong to the same Network Entity. For the purposes of discovery, all 
> it
> requires prior to establishing the discovery session is each Portal's 
> TCP
> addressing information.
>
> Without a priori knowledge of which portals are in the same Network 
> Entity,
> it would be difficult for an initiator to deterministically know if 
> starting
> a discovery session to Portal Y is going to reinstate its existing 
> discovery
> session on Portal X.
>
> Of the four possibilities you propose, I agree that II is on the path 
> to
> predictable behaviour. However, I suggest the decision to reinstate a
> Discovery session should be based upon matching the tuple 
> InitiatorName +
> ISID + servicing iSCSI Portal. Hence a Network Entity with four 
> Portals may
> carry four discovery sessions simultaneously from the one 
> InitiatorName+ISID
> pair (one per Portal).

Your proposal basically is Option B, or Option III. :-)

Take care,

Bill
_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Ken Sandars" <[email-masked]>
Date: Fri, 2 Sep 2005 03:56:45 +0100

> Your proposal basically is Option B, or Option III. :-)

Nope. I made no reference to TPGT, only to Portal. As Mallikarjun said, TPGT
only makes sense in the scope of a node. In no way do I want to introduce
TPGT processing, the processing of more keys or other work added.

In effect, the discovery session is to the Network Entity via any of its
Network Portals (identified by its IP address and TCP port). From the
initiator's perspective, it only knows about the Portal. Hence if the target
is thinking about reinstating any sessions, it should limit its scope of
destruction to the same Portal.

And I certainly don't want Option III - there is no "semi-acceptance" of the
assertion in what I'm suggesting.

> Bill

Cheers,
Ken

---

From: William Studenmund <[email-masked]>
Date: Fri, 2 Sep 2005 08:50:43 -0700

> TPGT processing, the processing of more keys or other work added.

True, I missed that detail. :-)

The main reason I'd still mention the phrase TPGT is that it's what's 
in the ISID rule and all sessions obey the ISID rule. :-)

> destruction to the same Portal.

I like this. I had thought of it yesterday, then realized that's what 
you're talking about. I think this will avoid the main concern I had 
with the "NUL TPGT" which is that having a new discovery session to the 
no-target target name would REQUIRE other discovery sessions to be 
closed. Allowing TPGT was a way to create domains beyond which we 
didn't care about other sessions. Your suggestion is to make each 
portal such a domain.

So I officially change my mind. I like this idea.

As for the ISID rule and the no-name target, we can say that a target 
should act AS IF each TCP port (and other ports for other protocols) 
had different TPGT values for the ISID rule. The exact (pseudo)values 
do not matter and need not be transmitted to the initiator; they exist 
only to cause the ISID rule to not apply between ports. The only time 
that an initiator will run into an issue with parallel discovery is if 
it tries to connect to the same IP/port twice in the same run. But it 
should be smart enough to notice that first...

Take care,

Bill