Subject: [Ips] Make ErrorRecoveryLevel Irrelevant for Discovery sessions

From: William Studenmund <[email-masked]>
Date: Tue, 6 Sep 2005 17:06:53 -0700

As part of the great Discovery thread, I noticed that it is feasible to 
negotiate ERL > 0 for discovery sessions. However the PDUs necessary 
for ERL 1 and 2 functioning, SNACK and TASK MANAGEMENT, are not valid. 
So do we want to make the ErrorRecoveryLevel tag Irrelevant for 
SessionType=Discovery?

Or do we just want to note that discovery sessions can not readily 
handle ERL > 0 and leave it to both sides to never negotiate higher?

Take care,

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

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 07 Sep 2005 09:26:02 -0700

>So do
 > we want to make the ErrorRecoveryLevel tag Irrelevant for
 > SessionType=Discovery?

Unless I see other objections, I intend to incorporate Bill's suggestion 
into the next draft, with one change.  Rather than calling 
ErrorRecoveryLevel "irrelevant", I prefer to say that the negotiation of 
ErrorRecoveryLevel is irrelevant, and the operational ErrorRecoveryLevel 
must always be implicitly set to 0 for discovery sessions.

On the main discovery thread, thanks for all the feedback.  I intend to 
propose some specific text to the list in the next few days.

Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
StorageWorks Division
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

William Studenmund wrote:
> negotiate ERL > 0 for discovery sessions. However the PDUs necessary for 
> ERL 1 and 2 functioning, SNACK and TASK MANAGEMENT, are not valid. So do 
> we want to make the ErrorRecoveryLevel tag Irrelevant for 
> SessionType=Discovery?
> 
> ------------------------------------------------------------------------
>

---

From: William Studenmund <[email-masked]>
Date: Wed, 7 Sep 2005 10:46:25 -0700

On Sep 7, 2005, at 9:26 AM, Mallikarjun C. wrote:

> Unless I see other objections, I intend to incorporate Bill's 
> suggestion into the next draft, with one change.  Rather than calling 
> ErrorRecoveryLevel "irrelevant", I prefer to say that the negotiation 
> of ErrorRecoveryLevel is irrelevant, and the operational 
> ErrorRecoveryLevel must always be implicitly set to 0 for discovery 
> sessions.

Thank you. Yes, it sounds like you are going to add text which matches 
what I meant, not what I said; I want to effectively add an "Irrelevant 
when: SessionType=Discovery" line to section 12.20 of RFC 3720.

Take care,

Bill

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 09 Sep 2005 17:22:30 -0700

> propose some specific text to the list in the next few days.

The new proposed text is attached below.

I intend to shortly publish a -01 revision with several updates, 
including this one subject to agreement (which I hope exists based on 
the threads so far....).

Mallikarjun

Mallikarjun Chadalapaka

5	Discovery semantics
5.1	Error Recovery for Discovery Sessions
The negotiation of the key ErrorRecoveryLevel is irrelevant for 
Discovery sessions – i.e. for sessions that negotiated 
“SessionType=Discovery”.  The operational ErrorRecoveryLevel for 
Discovery sessions MUST be 0.  This naturally follows from the 
functionality constraints [RFC3720] imposes on Discovery sessions.

5.2	Discovery Philosophy and Reinstatement
Discovery sessions are intended to be relatively short-lived. 
Initiators are not expected to establish multiple Discovery sessions to 
the same iSCSI Portal (see [RFC3720]).  An initiator may use the same 
iSCSI Initiator Name and ISID when establishing different unique 
sessions with different targets and/or different portal groups.  This 
behavior is discussed in Section 9.1.1 of [RFC3720] and is, in fact, 
encouraged as conservative reuse of ISIDs.  ISID RULE in [RFC3720] 
states that there must not be more than one session with a matching 
4-tuple: <InitiatorName, ISID, TargetName, TargetPortalGroupTag>.  While 
the spirit of the ISID RULE applies to Discovery sessions the same as it 
does for Normal sessions, note that some Discovery sessions differ from 
the Normal sessions in two important aspects:
	Because [RFC3720] allows a Discovery session to be established without 
specifying a TargetName key in the Login Request PDU (let us call such a 
session an “Unnamed” Discovery session), there is no Target Node context 
to enforce the ISID RULE.
	Portal Groups are defined only in the context of a Target Node.  When 
the TargetName key is NULL-valued (i.e. not specified), the 
TargetPortalGroupTag thus cannot be ascertained to enforce the ISID RULE.

The following sections describe the two scenarios – Named Discovery 
sessions and Unnamed Discovery sessions – separately.

5.2.1	Unnamed Discovery Sessions
For Unnamed Discovery sessions, neither the TargetName nor the 
TargetPortalGroupTag is available to the targets in order to enforce the 
ISID RULE.  So the following rule applies.

UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the following 
4-tuple for Unnamed Discovery sessions: <InitiatorName, ISID, NULL, 
TargetAddress>.  The following semantics are implied by this uniqueness 
requirement.

Resources permitting, targets MUST allow concurrent establishment of one 
Discovery session with each of its Portals by the same initiator port 
with a given iSCSI Node Name and an ISID.  Each of the concurrent 
Discovery sessions, if established by the same initiator port, MUST be 
treated as independent sessions – i.e. one session MUST NOT reinstate 
the other.

A new Unnamed Discovery session that has a matching <InitiatorName, 
ISID, NULL, TargetAddress> to an existing discovery session MUST 
reinstate the existing Unnamed Discovery session.  Note thus that only 
an Unnamed Discovery session may reinstate an Unnamed Discovery session.

5.2.2	Named Discovery Sessions
For a Named Discovery session, the TargetName key is specified by the 
initiator and thus the target can unambiguously ascertain the 
TargetPortalGroupTag as well.  Since all the four elements of the 
4-tuple are known, the ISID RULE MUST be enforced by targets with no 
changes from [RFC3720] semantics.  A new session with a matching 
<InitiatorName, ISID, TargetName, TargetPortalGroupTag> thus will 
reinstate an existing session.  Note in this case that any new iSCSI 
session (Discovery or Normal) with the matching 4-tuple may reinstate an 
existing Named Discovery iSCSI session.

---

From: William Studenmund <[email-masked]>
Date: Sun, 11 Sep 2005 17:49:53 -0700

> The new proposed text is attached below.

I have a minor comment (below), but overall, LOOKS GREAT!

> Discovery sessions ¡V i.e. for sessions that negotiated 
> ¡§SessionType=Discovery¡¨.  The operational ErrorRecoveryLevel for 
> Initiators are not expected to establish multiple Discovery sessions 
> to the same iSCSI Portal (see [RFC3720]).  An initiator may use the 
> same iSCSI Initiator Name and ISID when establishing different unique 
> 4-tuple: <InitiatorName, ISID, TargetName, TargetPortalGroupTag>.  
> While the spirit of the ISID RULE applies to Discovery sessions the 
> same as it does for Normal sessions, note that some Discovery sessions 
> differ from the Normal sessions in two important aspects:
> ƒx	Because [RFC3720] allows a Discovery session to be established 
> without specifying a TargetName key in the Login Request PDU (let us 
> call such a session an ¡§Unnamed¡¨ Discovery session), there is no 
> Target Node context to enforce the ISID RULE.
> ƒx	Portal Groups are defined only in the context of a Target Node.  
> When the TargetName key is NULL-valued (i.e. not specified), the 
> The following sections describe the two scenarios ¡V Named Discovery 
> sessions and Unnamed Discovery sessions ¡V separately.
>
> TargetPortalGroupTag is available to the targets in order to enforce 
> the ISID RULE.  So the following rule applies.
>
> UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the 
> following 4-tuple for Unnamed Discovery sessions: <InitiatorName, 
> ISID, NULL, TargetAddress>.  The following semantics are implied by 
> this uniqueness requirement.
>
> Resources permitting, targets MUST allow concurrent establishment of 
> one Discovery session with each of its

I'm not sure if we're supposed to use "MUST" like this. I think 
"SHOULD" is the correct word; we definitely think the target must do 
this, but realize there may be an occasion in which it can't.

> Portals by the same initiator port with a given iSCSI Node Name and an 
> ISID.  Each of the concurrent Discovery sessions, if established by 
> the same initiator port, MUST be treated as independent sessions ¡V 
> i.e. one session MUST NOT reinstate the other.
>
> session (Discovery or Normal) with the matching 4-tuple may reinstate 
> an existing Named Discovery iSCSI session.

Take care,

Bill

---

From: "Ken Sandars" <[email-masked]>
Date: Thu, 15 Sep 2005 10:53:09 +0100

Hi Mallikarjun,

Great work on the rewrite of this text. Due to technical difficulties I
never saw the original post, so I'm glad Bill replied! I agree with Bill's
tweak, too.

Cheers,
Ken

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of William Studenmund
> Sent: 12 September 2005 01:50
> To: Mallikarjun C.
> Cc: IPS
> Subject: Re: [Ips] Discovery text
> 
> 
> > Discovery sessions - i.e. for sessions that negotiated 
> > "SessionType=Discovery".  The operational ErrorRecoveryLevel for 
> > *	Because [RFC3720] allows a Discovery session to be established 
> > call such a session an "Unnamed" Discovery session), there is no 
> > *	Portal Groups are defined only in the context of a 
> Target Node.  
> > The following sections describe the two scenarios - Named Discovery 
> > sessions and Unnamed Discovery sessions - separately.
> >
> > the same initiator port, MUST be treated as independent sessions -

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 15 Sep 2005 09:21:52 -0400

It would seem to me that since there may be a requirement to change existing 
code to comply with this you should increase the version number.

Eddy

----- Original Message ----- 
From: "Ken Sandars" <[email-masked]>
To: "'William Studenmund'" <[email-masked]>; "'Mallikarjun C.'" 
<[email-masked]>
Cc: "'IPS'" <[email-masked]>
Sent: Thursday, September 15, 2005 5:53 AM
Subject: RE: [Ips] Discovery text

---

From: William Studenmund <[email-masked]>
Date: Thu, 15 Sep 2005 09:08:01 -0700

On Sep 15, 2005, at 6:21 AM, Eddy Quicksall wrote:

> It would seem to me that since there may be a requirement to change 
> existing code to comply with this you should increase the version 
> number.

I don't think we need to go that far. Since we are addressing issues 
that came up in RFC 3720, we are encountering things that didn't work 
out right the first time around. So fixing them is not necessarily a 
new version of the protocol; things were "broken" before, so the 
changes aren't breaking anything and thus won't trigger interoperation 
issues. Thus we don't need a new version number.

Take care,

Bill

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 15 Sep 2005 12:37:01 -0400

My problem is with the word MUST. Since the RFC did not require this 
behavior then some people may have already coded it not in accordance with 
the MUST case. If changed to a SHOULD as you pointed out earlier, I don't 
have a problem. Actually I think it should be MAY because some people think 
SHOULD means MUST.

> > ISID.

Eddy
----- Original Message ----- 
From: "William Studenmund" <[email-masked]>
To: "Eddy Quicksall" <[email-masked]>
Cc: "'Mallikarjun C.'" <[email-masked]>; "'IPS'" <[email-masked]>
Sent: Thursday, September 15, 2005 12:08 PM
Subject: Re: [Ips] Discovery text

Take care,

Bill

---

From: William Studenmund <[email-masked]>
Date: Thu, 15 Sep 2005 09:53:31 -0700

On Sep 15, 2005, at 9:37 AM, Eddy Quicksall wrote:

> behavior then some people may have already coded it not in accordance 
> with the MUST case. If changed to a SHOULD as you pointed out earlier, 
> I don't have a problem. Actually I think it should be MAY because some 
> people think SHOULD means MUST.

Well, they need to read the spec, specifically the reference to what 
SHOULD, MUST, and MAY mean. SHOULD is a MUST you can weasel out of. :-)

I agree that code that was fine before now isn't. I however do not 
think that means that we need a version change. Specifically, I assume 
you mean the iSCSI protocol version, since it's the only version number 
we have around.

The document we are working on will eventually become an RFC. What I 
expect will happen is that products will start claiming to support RFC 
3720 and also whatever RFC this one is (or it could be "RFC 3720 as 
updated in RFC foo").

Take care,

Bill

> ----- Original Message ----- From: "William Studenmund" 
> <[email-masked]>

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 15 Sep 2005 13:19:38 -0400

Then SHOULD is better than MUST.

Eddy

----- Original Message ----- 
From: "William Studenmund" <[email-masked]>
To: "Eddy Quicksall" <[email-masked]>
Cc: "'Mallikarjun C.'" <[email-masked]>; "'IPS'" <[email-masked]>
Sent: Thursday, September 15, 2005 12:53 PM
Subject: Re: [Ips] Discovery text

Take care,

Bill

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 15 Sep 2005 13:23:01 -0400

>3720 and also whatever RFC this one is (or it could be "RFC 3720 as

If the version number is not going to change then a statement saying that 
initiators MUST stay backward compatable to RFC3720. If you don't do that 
you will have interoperability problems.

Eddy

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 15 Sep 2005 13:39:55 -0400

So far in the RFC we have always used the word Portal with a clear statement 
as to if it is a Network Portal or a Portal Group. I would suggest that in

---

From: William Studenmund <[email-masked]>
Date: Thu, 15 Sep 2005 10:44:19 -0700

On Sep 15, 2005, at 10:23 AM, Eddy Quicksall wrote:

> If the version number is not going to change then a statement saying 
> that initiators MUST stay backward compatable to RFC3720. If you don't 
> do that you will have interoperability problems.

How?

We're talking about a part of the spec that didn't work right in RFC 
3720. Why do we need to stick to it in a backwards-compatible way?

I would agree with you (strongly) if I felt we were breaking a working 
behavior. But with respect to discovery, I don't think we are.

The requirements on initiators are rather light; don't open multiple 
discovery sessions to the same portal.

Take care,

Bill

---

From: William Studenmund <[email-masked]>
Date: Thu, 15 Sep 2005 10:50:06 -0700

On Sep 15, 2005, at 10:39 AM, Eddy Quicksall wrote:

> So far in the RFC we have always used the word Portal with a clear 
> statement as to if it is a Network Portal or a Portal Group. I would 
> suggest that in the below sentence the word Portal Groups is used 
> instead of just Portal:
>

I agree we may need a bit more clarification.

However this paragraph is in section 5.2.1, which is the unnamed 
discovery session behavior. As such (and this was a big part of the 
earlier "great thread"), we do not have well-defined target portal 
groups, thus we can't use TPGT.

I think a better change would be to use "Network Portal."

Take care,

Bill

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 15 Sep 2005 13:56:02 -0400

Thanks for the catch ... I actually meant to say Network Portal.

Eddy

----- Original Message ----- 
From: "William Studenmund" <[email-masked]>
To: "Eddy Quicksall" <[email-masked]>
Cc: "IPS" <[email-masked]>; "Mallikarjun C." <[email-masked]>
Sent: Thursday, September 15, 2005 1:50 PM
Subject: Re: [Ips] Discovery text

Take care,

Bill

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 16 Sep 2005 08:02:39 -0700

All,

Thanks for the review, I will make the MUST->SHOULD, and Portal->Network 
Portal changes as suggested.

Thanks.

Mallikarjun

Mallikarjun Chadalapaka

Ken Sandars wrote:
>>>including this one subject to agreement (which I hope 
>>
>>exists based on 
>>
>>>the threads so far....).
>>>
>>>Mallikarjun
>>>
>>>Mallikarjun Chadalapaka
>>>Initiators are not expected to establish multiple Discovery 
>>
>>sessions 
>>
>>>same iSCSI Initiator Name and ISID when establishing 
>>
>>different unique 
>>
>>>sessions with different targets and/or different portal 
>>
>>groups.  This 
>>
>>>behavior is discussed in Section 9.1.1 of [RFC3720] and is, 
>>
>>in fact, 
>>
>>>same as it does for Normal sessions, note that some 
>>
>>Discovery sessions 
>>
>>>without specifying a TargetName key in the Login Request 
>>
>>PDU (let us 
>>
>>>TargetPortalGroupTag is available to the targets in order 
>>
>>to enforce 
>>
>>>Resources permitting, targets MUST allow concurrent 
>>
>>establishment of 
>>
>>>Portals by the same initiator port with a given iSCSI Node 
>>
>>Name and an 
>>
>>>reinstate the existing Unnamed Discovery session.  Note 
>>
>>thus that only 
>>
>>>For a Named Discovery session, the TargetName key is 
>>
>>specified by the 
>>
>>>4-tuple are known, the ISID RULE MUST be enforced by 
>>
>>targets with no 
>>
>>>reinstate an existing session.  Note in this case that any 
>>
>>new iSCSI 
>>
>>>session (Discovery or Normal) with the matching 4-tuple may 
>>
>>reinstate 
>>