Subject: RE: [Ips] iSER: draft-ietf-ips-iser-05.txt

From: "Sanjay Goyal" <[email-masked]>
Date: Tue, 29 Nov 2005 14:08:21 -0500

Mike,

I understand that, the point I was trying to make was if Initiator
prefers  
iSCSI mode, why would it change its mind after it gets  RDMAExtensions
key from Target.

-Sanjay

>Original>-----Original Message-----
>Original>From: Mike Ko [mailto:[email-masked]] 
>Original>Sent: Tuesday, November 29, 2005 1:52 PM
>Original>To: Sanjay Goyal
>Original>Cc: [email-masked]
>Original>Subject: Re: [Ips] iSER: draft-ietf-ips-iser-05.txt
>Original>
>Original>Sanjay,
>Original>
>Original>There is the possibility that an iSER initiator might 
>Original>prefer to operate in iSCSI mode and therefore not 
>Original>offer RDMAExtensions in its Login Request. 
>Original>But if the target can support and prefers iSER mode, 
>Original>it can offer RDMAExtensions in its Login Response.  
>Original>It is then up to the initiator to determine if it 
>Original>wants to support iSER for this session.  The iSER 
>Original>draft is written to allow such possibilities.
>Original>
>Original>Mike
>Original>Sent by:        [email-masked]
>Original>To:     <[email-masked]>
>Original>cc:      
>Original>Subject:        [Ips] iSER: draft-ietf-ips-iser-05.txt
>Original>
>Original>
>Original>Hi
>Original>below is the description as per 
>Original>draft-ietf-ips-iser-05.txt section 6.3
>Original> 
>Original>--------------
>Original>An iSER-enabled node is not required to initiate the 
>Original>RDMAExtensions 
>Original>   key exchange if it prefers to operate in the 
>Original>Traditional iSCSI mode. 
>Original>   However, if the RDMAExtensions key is to be 
>Original>negotiated, an initiator 
>Original>   MUST offer the key in the first Login Request PDU in the 
>Original>   LoginOperationalNegotiation stage of the leading 
>Original>connection, and a 
>Original>   target MUST offer the key in the first Login 
>Original>Response PDU with which 
>Original>   it is allowed to do so (i.e., the first Login 
>Original>Response PDU issued 
>Original>   after the first Login Request PDU with the C bit 
>Original>set to 0) in the 
>Original>   LoginOperationalNegotiation stage of the leading 
>Original>connection.  In 
>Original>   response to the offered key=value pair of 
>Original>RDMAExtensions=yes, an 
>Original>   initiator MUST respond in the next Login Request 
>Original>PDU with which it 
>Original>   is allowed to do so, and a target MUST respond in 
>Original>the next Login 
>Original>   Response PDU with which it is allowed to do so. 
>Original>----------
>Original> 
>Original>What is confusing to me is
>Original>"if the RDMAExtensions key is to be negotiated, an initiator 
>Original>   MUST offer the key in the first Login Request PDU in the 
>Original>   LoginOperationalNegotiation stage of the leading 
>Original>connection" 
>Original>               which is later followed by "In 
>Original>response to the offered key=value pair of 
>Original>RDMAExtensions=yes, an 
>Original>   initiator MUST respond in the next Login Request 
>Original>PDU with which it 
>Original>   is allowed to do so"
>Original> 
>Original>If the Initiator did not exchange the key in first 
>Original>Login Request, means that it doesnot want to 
>Original>negotiate, why would it get the key in the first 
>Original>Login Response as Target should not send it to begin with.
>Original> 
>Original>Please clarify,
>Original> 
>Original>Regards,
>Original> 
>Original>Sanjay Goyal
>Original>678-990-1550 x204
>Original>iVivity Inc.
>Original>Norcross, GA 30093
>Original> _______________________________________________
>Original>Ips mailing list
>Original>[email-masked]
>Original>https://www1.ietf.org/mailman/listinfo/ips
>Original>
>Original>
>Original>

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

---

From: Mike Ko <[email-masked]>
Date: Tue, 29 Nov 2005 11:15:25 -0800

Sanjay,

The initiator may well reject the RDMAExtensions offer from the target, 
but we don't want to preclude the possibility that the initiator might 
want to accommodate the target and choose to support iSER instead.

Mike
To:     "Mike Ko" <[email-masked]>
cc:     <[email-masked]> 
Subject:        RE: [Ips] iSER: draft-ietf-ips-iser-05.txt

Mike,

-Sanjay