Re: [Ips] I-D ACTION:draft-ietf-ips-iser-00.txt

Caitlin,

Section 7.3.6 clause 1 states that:

1.  It MUST ensure a valid local STag for the I/O Buffer and a valid
    local mapping that associates the Initiator Task Tag (ITT) to
    the local STag.  This may involve allocating a valid local STag
    and establishing a local mapping.

The iSER layer has already allocated a valid local STag for the I/O buffer 
which will be used as the data sink buffer for the RDMA Read operation 
based on the DataDescriptorOut which qualifies the Get_Data invocation 
between the iSER layer and the iSCSI layer.  From a layering viewpoint, 
DataDescriptorOut is not visible to the RDMA layer.  Can you clarify how 
the RDMA layer can "flexibly map a target Data Descriptor to a local STag" 
without violating the layering purity?

Mike
Sent by:        [email protected]
To:     [email protected]
cc:     [email protected] 
Subject:        Re: [Ips] I-D ACTION:draft-ietf-ips-iser-00.txt



Section 7.3.6 clause 4.b appears to make an inappropriate requirement
on the local interface.

>    4.  If the iSER-ORD value at the target is set to greater than 0,
>        the iSER Layer at the target MUST transform the R2T PDU into an
>        RDMA Read Request Message.  While transforming the R2T PDU, the
>        iSER Layer at the target MUST ensure that the number of
>        outstanding RDMA Read Request Messages does not exceed iSER-ORD
>        value.  To transform the R2T PDU, the iSER Layer at the target:
>
>        a.  MUST derive the local STag and local Tagged Offset from the
>            DataDescriptorOut that qualified the Get_Data invocation.
>
>        b.  MUST use the local STag as the Data Sink STag of the RDMA
>            Read Request Message.

It would be legitimate to require that the Data Sink STag must be used
for the
RDMA Read Request *operation* submitted to RDMAP.  However the
RDMAP layer should be free to form the wire Data Sink STag used in
an RDMA Read Message on its own.  There are security benefits when
supporting transport neutral APIs.

Clause a) hints at the desirability of this type of flexible mapping.
However,
as drafted this flexibility would only be available at the iSER layer.
The option
to flexibly map a target Data Descriptor to a local STag is just as
important
for the RDMAP layer itself, and when dealing with the RDMA Read Data
Sink STag the protocol provides the required flexibility to the
implementation.
The iSER draft should recognize this flexibility. This is actually a
documentation
issue, since obviously the iSER level cannot prevent the RDMAP layer
from
implementing such an optimization. But false implications can still
mislead
those developing wire validation suites, which might lead to false
detections
of "protocol violations" that were in fact totally legal and
interoperable.






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