Re: [storm] Plan for iSCSI work

[<[e-mail]>]

<WG chair hat off> I think use of "SHOULD" is the right approach here. </WG chair hat off>

<WG chair hat on> Based on list discussion, I believe "SHOULD" is the rough consensus of the WG. </WG chair hat on>

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------

> -----Original Message-----
> From: Hemal Shah [mailto:[e-mail]]
> Sent: Thursday, June 30, 2011 2:09 PM
> To: Mallikarjun Chadalapaka; Pat Thaler; Black, David; [e-mail]
> Subject: RE: [storm] Plan for iSCSI work
>
> Thanks Mallikarjun!
>
> Hemal
>
> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:[e-mail]]
> Sent: Thursday, June 30, 2011 11:06 AM
> To: Pat Thaler; Hemal Shah; [e-mail]; [e-mail]
> Subject: RE: [storm] Plan for iSCSI work
>
> Hi Pat,
>
> Thanks for flagging the inconsistency in 10.7, that's a good catch.  Given
> that and your/Hemal's feedback, I think turning the current MUST into a
> SHOULD is probably the right resolution.   That syncs them both to SHOULD.
> Unless I see other comments, I will get this into the next revision.
>
> Thanks.
>
> Mallikarjun
>
>
>   -----Original Message-----
>   From: Pat Thaler [mailto:[e-mail]]
>   Sent: Wednesday, June 29, 2011 4:03 PM
>   To: Mallikarjun Chadalapaka; Hemal Shah; [e-mail];
>   [e-mail]
>   Subject: RE: [storm] Plan for iSCSI work
>
>   Hi Malikarjun,
>
>   10.7 in the consolidated draft says that FastAbort is a SHOULD:
> "Therefore,
>   both iSCSI target and initiator implementations SHOULD support FastAbort
>   multi-task abort semantics (Section 4.2.3.4)."
>
>   When 4.2.3.5 saying "If an iSCSI target implementation is capable of
>   supporting TaskReporting=FastAbort functionality" implies that the
>   implementation was allowed to not implement FastAbort. You might
>   interpret "supporting" = (implemented and negotiated to TaskAbort) as you
>   say below, but "capable of supporting" still reads as implemented. When
>   the standard puts an if in front of that, it implies that an
> implementation is
>   allowed to be not capable of supporting FastAbort.
>
>   Neither of these is consistent with MUST implement for FastAbort. The
>   rationale for requiring FastAbort doesn't seem strong and I'd prefer that
> the
>   inconsistency be resolved by not requiring its implementation.
>
>   Regards,
>   Pat
>
>   -----Original Message-----
>   From: [e-mail] [mailto:[e-mail]] On Behalf
>   Of Mallikarjun Chadalapaka
>   Sent: Wednesday, June 29, 2011 3:16 PM
>   To: Hemal Shah; [e-mail]; [e-mail]
>   Subject: Re: [storm] Plan for iSCSI work
>
>   Hi Hemal,
>
>   >1.     The implementation of TaskReporting is required and NotUnderstood
>   response for TaskReporting key is not permitted
>
>   No.  Note that TaskReporting is not defined in RFC 3720.  Patrick
> MacArthur
>   proposed on this list a couple of weeks ago that we should fix this
>   disconnect in the consolidated draft - which I agreed with because I think
>   it's a good suggestion.
>
>    >2.    To enable FastAbort on a session, the negotiation of TaskReporting
>   key is required.
>
>   Correct, specifically "TaskReporting=FastAbort" must be negotiated.
>
>   >3.     Only when the TaskReporting=FastAbort functionality is supported,
>   the protocol behavior specified in Section 4.2.3.4 is required to be
>   implemented and exhibited.
>
>   If I were to attempt re-writing your idea, I would say:
>
>   When the protocol behavior specified in Section 4.2.3.4 is implemented and
>   TaskReporting=FastAbort is operational on a session, then the FastAbort
>   functionality is supported/exhibited on that session by the
> implementation.
>
>   >a.     Section 4.2.3.5: If an iSCSI target implementation is capable of
>   supporting
>   >TaskReporting=FastAbort functionality (Section 13.23).
>
>   "Supporting" = implemented and negotiated to "TaskReporting=FastAbort".
>   Note that if even if an implementation has implemented this functionality
>   and wants to use it, it will not be able to negotiate it on any session if
> it's
>   only communicating with a bunch of RFC 3720 implementations.
>
>    >b.    Section 4.2.2.3.3: Whenever the TaskReporting key (Section 12.23
>   "Task Reporting") is negotiated to ResponseFence or FastAbort for an iSCSI
>   session.
>   >c.     Section 4.2.2.3.4: Whenever the TaskReporting key (Section 13.23)
> is
>   negotiated to ResponseFence or FastAbort for an iSCSI session.
>
>   I don't see an issue.  Note that the discussion in these two sections is
> on
>   response fencing, not fast abort per se.
>
>   >4.     ...prefixed with some text like "Only when the
>   TaskReporting=FastAbort functionality is supported..".
>
>   Please see the above responses.  Your wording is vague for me, as I don't
>   comprehend a standalone notion of "supporting" a feature, other than
>   implementing a feature and negotiating the feature usage.   Current RFC
>   5048
>   requirement is that implementation is MUST, and negotiation is MUST
>   (may result in the feature to be used, or not).  So as such, there is
> already
>   ample flexibility for implementations.
>
>   I think you are restating your earlier suggestion to loosen the "MUST
>   implement" requirement in RFC5048.  And I've already shared how I feel
>   about it, :)  I think it would be a step in the wrong direction, when
> faster
>   error recovery with multi-task aborts with large # of
> sessions/LUs/initiators
>   is even more critical, due to increased consolidation in data centers.
>
>   At this point, I think it would be good to also hear from the rest of the
> list.
>
>   Thanks.
>
>   Mallikarjun
>
>
>
>
>
>   >Thanks Mallikarjun! I would still like to confirm my understanding of
>   >what
>   you describe as "MUST implement, but MUST negotiate".
>   >
>   >Here is my understanding:
>   >
>   >1.     The implementation of TaskReporting is required and NotUnderstood
>   response for TaskReporting key is not permitted based on the following
> text
>   from RFC5048 and Section 6.2 of the consolidated draft:
>   >                 All keys defined in [RFC3720] MUST be supported by all
>   >            compliant implementations; a NotUnderstood answer on any of
>   the
>   >            [RFC3720] keys therefore MUST be considered a protocol
>   > error
>   and
>   >            handled accordingly.
>   >2.     To enable FastAbort on a session, the negotiation of TaskReporting
>   key is required.
>   >3.     Only when the TaskReporting=FastAbort functionality is supported,
>   the protocol behavior specified in Section 4.2.3.4 is required to be
>   implemented and exhibited. There are several places in the spec that
>   indicate this type of conditionality.
>   >a.     Section 4.2.3.5: If an iSCSI target implementation is capable of
>   supporting
>   >TaskReporting=FastAbort functionality (Section 13.23).
>   >b.     Section 4.2.2.3.3: Whenever the TaskReporting key (Section 12.23
>   "Task Reporting") is negotiated to ResponseFence or FastAbort for an iSCSI
>   session.
>   >c.     Section 4.2.2.3.4: Whenever the TaskReporting key (Section 13.23)
> is
>   negotiated to ResponseFence or FastAbort for an iSCSI session.
>   >4.     If TaskReporting=FastAbort functionality is not supported, then
> the
>   protocol behavior specified in Section 4.2.3.4 is not required to be
>   implemented or exhibited. If this is true, then the first sentence in
> section
>   4.2.3.4 is misleading and should be removed or prefixed with some text
> like
>   "Only when the TaskReporting=FastAbort functionality is supported..".
>   >
>   >Hemal
>   >
>   >
>   >-----Original Message-----
>   >From: Mallikarjun Chadalapaka [mailto:[e-mail]]
>   >Sent: Friday, June 17, 2011 3:32 PM
>   >To: Hemal Shah; [e-mail]; [e-mail]
>   >Subject: RE: [storm] Plan for iSCSI work
>   >
>   >Hi Hemal,
>   >
>   >During RFC 5048 effort, I recall we settled on the "MUST implement, but
>   MUST
>   >negotiate" formulation after some list deliberation.
>   >
>   >With plain RFC 3720 semantics, there are some multi-initiator scenarios
>   >where multi-task aborts could essentially lead to target deadlocks,
>   >waiting on initiators on third-party sessions that may never respond.
>   >With the "Clarified" semantics in RFC 5048, the third-party deadlocks
>   >aren't a problem anymore, but issuing initiator could still experience
>   >timeouts and escalate error recovery - depending on the number of LUs,
>   sessions,
>   >connections and tasks affected with the issued TMF.    Escalated error
>   >recovery is usually something we want to avoid as it adds more
>   >delays/alerts/logs/failovers/failbacks etc.  Finally, "Updated"
>   >semantics
>   in
>   >RFC 5048 are meant to address this timeout problem - they permit
>   >targets to provide accelerated responses and allow them to deal with
>   >book-keeping/quiescing operations in a lazy fashion (which are the real
>   >culprits that trigger timeouts).
>   >
>   >Given all the above, the WG settled on FastAbort as a MUST-implement.
>   >The "MUST negotiate" part then is to enable backwards-compatibility
>   >with RFC
>   >3720 implementations.  At this point, I'd rather not loosen the
>   Consolidated
>   >iSCSI draft requirement from what it is in RFC 5048.  I suggest we
>   >leave it the way it is.
>   >
>   >Mallikarjun
>   >
>   >
>   >
>   >
>   >
>   >
>   >From: Hemal Shah [mailto:[e-mail]]
>   >Sent: Thursday, June 09, 2011 3:57 PM
>   >To: Mallikarjun Chadalapaka; [e-mail]; [e-mail]
>   >Subject: RE: [storm] Plan for iSCSI work
>   >
>   >Thanks Mallikarjun!
>   >
>   >The way I read Section 4.1.3 of RFC5048 and Section 4.2.3.4 of the
>   >consolidated draft, the implementation of "FastAbort" feature is a MUST.
>   >From the first paragraph text from Section 4.1.3 of RFC5048, the first
>   >sentence mandates that all iSCSI implementation comply to this section
>   >but the second sentence say that the requirement in this section is
>   >conditional to the negotiation of "FastAbort" key.
>   >
>   >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.
>   >
>   >
>   >This is confusing. I think it will be better to remove the first
>   >sentence from 4.2.3.4 and clarify that the requirements in this section
>   >is conditional. I suggest rewording the first two sentences to below:
>   >
>   >       iSCSI implementations may negotiate the TaskReporting (Section
>   >9.1) key to "FastAbort" on an iSCSI session. 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.
>   >
>   >Hemal
>   >
>   >
>   >-----Original Message-----
>   >From: Mallikarjun Chadalapaka [mailto:[e-mail]]
>   >Sent: Friday, May 27, 2011 5:29 PM
>   >To: Hemal Shah; [e-mail]; [e-mail]
>   >Subject: RE: [storm] Plan for iSCSI work
>   >
>   >Hi Hemal,
>   >
>   >The text in this draft came verbatim from section 4.1.3 of RFC 5048.
>   >There have been no changes in this area.
>   >
>   >The new text (as well as the old text) requires the TaskReporting key
>   >to be negotiated to "FastAbort" before the multi-task abort semantics
>   >can be used on an iSCSI session.
>   >
>   >Thanks.
>   >
>   >Mallikarjun
>   >
>   >
>   >
>   >
>   >  -----Original Message-----
>   >  From: Hemal Shah [mailto:[e-mail]]
>   >  Sent: Friday, May 27, 2011 4:51 PM
>   >  To: Mallikarjun Chadalapaka; [e-mail]; [e-mail]
>   >  Subject: RE: [storm] Plan for iSCSI work
>   >
>   >  Mallikarjun and David,
>   >
>   >  I noticed one problematic item in the consolidated draft. This item
>   > is
>   the
>   >  requirement to support FastAbort. This feature was already defined in
>   > the  implementation guide, but it was optional. In this draft, it
>   > became a  required feature MUST - see in section 4.2.3.4.
>   >
>   >  Do you know why the requirement was changed in the consolidated
>   draft?
>   >
>   >  I would like to keep the requirement optional as stated in the
>   > implementation guide and not break backward compatibility.
>   >
>   >  Hemal
>   >
>   >  -----Original Message-----
>   >  From: [e-mail] [mailto:[e-mail]] On
>   > Behalf  Of Mallikarjun Chadalapaka
>   >  Sent: Thursday, May 26, 2011 6:50 PM
>   >  To: [e-mail]; [e-mail]
>   >  Subject: Re: [storm] Plan for iSCSI work
>   >
>   >  Hi David,
>   >
>   >  The list of changes you have called out are already done in the
>   >latest draft.  I
>   >  assume then that you are suggesting that the list itself should be
>   >included
>   >  in the next revision of the draft.
>   >
>   >  Here's what I recall we have done so far:
>   >  1)  iSCSIProtocolLevel specified as "1", and added a related
>   >normative
>   >  reference to iSCSI-SAM draft
>   >  2)  Markers and related keys were removed
>   >  3)  SPKM authentication and related keys were removed
>   >  4)  Added a new section on responding to obsoleted keys
>   >  5)  Have explicitly allowed initiator+target implementations
>   >throughout the
>   >  text
>   >  6)  Clarified that implementations SHOULD NOT rely on SLP-based
>   >discovery
>   >  7)  Added UML diagrams, and related conventions
>   >
>   >  The above is of course in addition to consolidating the different
>   >RFCs, and
>   >  making the related editorial changes.
>   >
>   >  Thanks.
>   >
>   >  Mallikarjun
>   >
>   >
>   >
>   >
>   >    -----Original Message-----
>   >    From: [e-mail] [mailto:[e-mail]] On
>   Behalf
>   >    Of [e-mail]
>   >    Sent: Friday, May 20, 2011 2:49 PM
>   >    To: [e-mail]
>   >    Subject: [storm] Plan for iSCSI work
>   >
>   >    I thought I'd offer some advance planning/warning on this, as the
>   >    consolidated iSCSI draft (draft-ietf-storm-iscsi-cons) is large
>   >(over
>   >300
>   >    pages).  The current plan is to run a simultaneous WG Last Call on
>   >both
>   >  this
>   >    draft and the new features draft (draft-ietf-storm-iscsi-sam)
>   >starting in
>   >  mid-
>   >    June (probably the week of June 13, after I get back from a badly
>   needed
>   >    vacation).  That WG Last Call will run longer than the typical
>   >2-week time
>   >    period, due to the total size of the drafts, but will end by July
>   >5th
>   at
>   >the
>   >    latest so that the status of the drafts and the next steps are
>   >known prior
>   >  to
>   >    the T10 (SCSI standards) meetings during the week of July 11.  As
>   >July 11th
>   >    is also the draft cutoff deadline for the Quebec City IETF
>   >meetings, revised
>   >    draft versions may not show up until that meeting week (week of July
>   >    24th).
>   >
>   >    This is also a good point to announce that the storm WG will meet in
>   >    Quebec City.
>   >    I've only requested a 1-hour session, as we get most of our work
>   > done
>   on
>   >    the mailing list.  Among the items for that meeting will be
>   > figuring
>   out
>   >  what
>   >    to do with the RDMA extensions draft (despite its name,
>   >draft-ietf-storm-
>   >    rdmap-ext-00, it's not currently an official work item for the
>   >storm WG).
>   >
>   >    One thing that's missing from the consolidated iSCSI draft (and is
>   >a reason
>   >    why we're going to need a -03 version) is the changes that it makes
>   >to the
>   >    RFCs that it consolidates.  Off the top of my head, the major
>   >changes
>   >are:
>   >         - Removal of SPKM authentication
>   >         - Removal of the Marker appendix
>   >         - Removal of the SHOULD requirement for SLP implementation.
>   >    Have I missed anything significant?  The summary of this will need
>   >to
>   be
>   >    added to that draft.
>   >
>   >    WG Last Call will be an opportunity (in fact the final opportunity)
>   > to  discuss
>   >    whether anything else should be removed from iSCSI, but there's no
>   need
>   >    to wait
>   >    - I encourage people to review both drafts and post comments
>   whenever
>   >    they can.
>   >
>   >    In parallel, work will get started on any iSCSI MIB changes that
>   >are needed.
>   >    So far, I only see one MIB change - the iSCSIProtocolLevel from the
> new
>   >    features draft needs to be added to the MIB, probably with a
> structure
>   >    analogous to the iSCSI version support that's already in the MIB.
>   >
>   >    Thanks,
>   >    --David (storm WG co-chair)
>   >    ----------------------------------------------------
>   >    David L. Black, Distinguished Engineer
>   >    EMC Corporation, 176 South St., Hopkinton, MA  01748
>   >    [phone]             FAX: [phone]
>   >    [e-mail]        Mobile: [phone]
>   >    ----------------------------------------------------
>   >
>   >    _______________________________________________
>   >    storm mailing list
>   >    [e-mail]
>   >    https://www.ietf.org/mailman/listinfo/storm
>   >
>   >  _______________________________________________
>   >  storm mailing list
>   >  [e-mail]
>   >  https://www.ietf.org/mailman/listinfo/storm
>   >
>   >
>   >
>   >
>   >
>   >
>   >
>   >
>   >
>
>   _______________________________________________
>   storm mailing list
>   [e-mail]
>   https://www.ietf.org/mailman/listinfo/storm
>
>
>
>
>