RE: Re: Last Call TMF resolution

Yes, the parenthetical text is entirely too well-hidden ;-) - an
Initiator section in 4.1.4 would make the implications obvious.

Thanks,
--David

> -----Original Message-----
> From: Mallikarjun C. [mailto:[email protected]] 
> Sent: Friday, January 26, 2007 5:41 PM
> To: [email protected]
> Subject: Re: [Ips] Re: Last Call TMF resolution
> 
> David,
> 
> Legacy->RFC3720 change done.  Latest text is attached below.  
> 
> AFAICT, initiator behavior parenthetical text under 4.1.3 
> bullet-c is what you are suggesting we clarify in 4.1.4. 
> "this step also applies when the initiator is receiving the 
> Async Message in the third-party role"
> 
> But let me know if that isn't the case.
> 
> Thanks.
> 
> Mallikarjun
> 
> 
> ----- Original Message ----
> From: "[email protected]" <[email protected]>
> To: [email protected]; [email protected]
> Sent: Friday, January 26, 2007 2:02:34 PM
> Subject: RE: [Ips] Re: Last Call TMF resolution
> 
> 
> I think I see some of where I'm confused.  4.1.2 and 4.1.3 are
> about what the initiator that sent the TMF does as well as the
> target.  We need to explain what a 3rd-party initiator does,
> which for a 3720-only initiator is unchanged.  I think your
> new 4.1.4 is headed towards covering this in addition to the
> Target behavior in a mixed FastAbort/non-FastAbort case.
> 
> One crucial point that needs
> to be made is that a FastAbort initiator may get an AsyncEvent=5
> message out of the blue if some other initiator, even a Legacy
> initiator, issues a TMF that affects the FastAbort initiator's
> tasks, even if the iSCSI session only contains a single TCP
> connection (FastAbort initiator will never get AsyncEvent=5
> messages for its own TMFs on a single connection session).
> 
> On another minor note, "Legacy" as a key value seems pejorative
> to me. "RFC3720" would be neutral and in fact more descriptive
> of what's actually going on.
> 
> Thanks,
> --David
> 
> 4.1.3 Updated multi-task abort semantics
> Protocol behavior defined in this section MUST be implemented 
> by all iSCSI implementations complying with this document.  
> Protocol behavior defined in this section MUST be exhibited 
> by iSCSI implementations on an iSCSI session when they 
> negotiate the TaskReporting (section 9.1) key to "FastAbort" 
> on that session.  The execution of ABORT TASK SET, CLEAR TASK 
> SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD 
> RESET TMF Requests consists of the following sequence of 
> actions in the specified order on the specified party. 
> The initiator iSCSI layer:
> a. MUST NOT send any more Data-Out PDUs for affected tasks on 
> the issuing connection of the issuing iSCSI session once the 
> TMF is sent to the target.
> b. Should receive any responses that the target may provide 
> for some tasks among the affected tasks (may process them as 
> usual because they are guaranteed to have chronologically 
> originated prior to the TMF response).
> c. MUST respond to each Async Message PDU with AsyncEvent=5 
> as defined in section 8.1 (this step also applies when the 
> initiator is receiving the Async Message in the third-party role).
> d. Should receive the TMF Response concluding all the tasks 
> in the set of affected tasks.
> 
> The target iSCSI layer:
> a. MUST wait for all commands of the affected tasks to be 
> received based on the CmdSN ordering on the issuing session.  
> SHOULD NOT wait for new commands on third-party affected 
> sessions - only the instantiated tasks have to be considered 
> for the purpose of determining the affected tasks.  In the 
> case of target-scoped requests (i.e. TARGET WARM RESET and 
> TARGET COLD RESET), all the commands that are not yet 
> received on the issuing session in the command stream can be 
> considered to have been received with no command waiting 
> period - i.e. the entire CmdSN space up to the CmdSN of the 
> task management function can be "plugged".
> b. MUST propagate the TMF request to and receive the response 
> from the target SCSI layer. 
> c. MUST leave all active "affected TTTs" (i.e. active TTTs 
> associated with affected tasks) valid.
> d. MUST send an Asynchronous Message PDU with AsyncEvent=5 
> (section 8.1) on:
> i) each connection of each third-party session to which at 
> least one affected task is allegiant if 
> TaskReporting=FastAbort is operational on that third-party 
> session, and
> ii) each connection except the issuing connection of the 
> issuing session that has at least one allegiant affected task.
> If there are multiple affected LUs (say due to a target 
> reset), then one Async Message PDU MUST be sent for each such 
> LU on each connection that has at least one allegiant 
> affected task.  The LUN field in the Asynchronous Message PDU 
> MUST be set to match the LUN for each such LU.
> e. MUST address the Response Fence flag on the TMF Response 
> on issuing session as defined in 3.3.2.
> f. MUST address the Response Fence flag on the first post-TMF 
> Response on third-party sessions as defined in 3.3.2. If some 
> tasks originate from non-iSCSI I_T_L nexuses then the means 
> by which the target ensures that all affected tasks have 
> returned their status to the initiator are defined by the 
> specific non-iSCSI transport protocol(s).
> g. MUST free up the affected TTTs (and STags, if applicable) 
> and the corresponding buffers, if any, once it receives each 
> associated Nop-Out acknowledgement that the initiator 
> generated in response to each Async Message.  
> Implementation note: Technically, the TMF servicing is 
> complete in Step.e.  Data transfers corresponding to 
> terminated tasks may however still be in progress even at the 
> end of Step.f.  TMF Response MUST NOT be sent by the target 
> iSCSI layer before the end of Step.e, and MAY be sent at the 
> end of Step.e despite these outstanding Data transfers until 
> Step.g.  Step.g specifies an event to free up any such 
> resources that may have been reserved to support outstanding 
> data transfers.  
> 
> 4.1.3.1 Clearing effects update
> ---No changes -----
> 
> 4.1.4 Affected tasks shared across RFC3720 & FastAbort sessions
> If an iSCSI target implementation is capable of supporting 
> TaskReporting=FastAbort functionality (section 9.1), it may 
> end up in a situation where some sessions have 
> TaskReporting=RFC3720 operational (RFC3720 sessions) while 
> some other sessions have TaskReporting=FastAbort operational 
> (FastAbort sessions) even while accessing a shared set of 
> affected tasks (section 4.1.1).
> If the issuing session is a RFC3720 session, iSCSI target 
> implementation is FastAbort-capable and third-party affected 
> session is a FastAbort session, the following behavior SHOULD 
> be exhibited by the iSCSI target layer:
> a. Between steps c and d of target behavior in section 4.1.2, 
> send an Asynchronous Message PDU with AsyncEvent=5 (section 
> 8.1) on each connection of each third-party session to which 
> at least one affected task is allegiant.  If there are 
> multiple affected LUs, then send one Async Message PDU for 
> each such LU on each connection that has at least one 
> allegiant affected task.  When sent, the LUN field in the 
> Asynchronous Message PDU MUST be set to match the LUN for 
> each such LU.
> b. After step e of target behavior in section 4.1.2, free up 
> the affected TTTs (and STags, if applicable) and the 
> corresponding buffers, if any, once each associated Nop-Out 
> acknowledgement is received that the third-party initiator 
> generated in response to each Async Message sent in step a.
> If the issuing session is a FastAbort session, iSCSI target 
> implementation is FastAbort-capable and third-party affected 
> session is a RFC3720 session, the following behavior MUST be 
> exhibited by the iSCSI target layer: Asynchronous Message 
> PDUs MUST NOT be sent on the third-party session to prompt 
> the FastAbort behavior.
> 
> 
>  
> ______________________________________________________________
> ______________________
> The fish are biting. 
> Get more visitors on your site using Yahoo! Search Marketing.
> http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
> 
> _______________________________________________
> Ips mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ips
> 
> 

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