[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

RE: DefaultTime2Retain Negotiation during Discovery Session



William,

Wouldn't it also be legal for the Target to
terminate the Login with a response code of
Initiator Error after the receipt of the first
empty PDU since the value was offered by the
Target but not returned by the Initiator?

Thanks,
Ken Craig

-----Original Message-----
From: William Studenmund [mailto:wrstuden@xxxxxxx] 
Sent: Sunday, August 19, 2007 10:12 PM
To: RAM SUNEE
Cc: Ips
Subject: Re:  DefaultTime2Retain Negotiation during Discovery
Session
Importance: High


On Aug 18, 2007, at 9:46 AM, RAM SUNEE wrote:

> On Aug 18, 2007, at 8:08 AM, RAM SUNEE wrote:
>
>> Hello,
>>
>> During LoginOperational negotiation phase of Discovery Session, 
>> Initiator didn't initiate negogiation for DefaultTime2Retain key.
>> Target tried to negotiate for this key a value of 0,but initiator
>> tried to
>> enter full feature phase without responding to this specific key.
>> In this case what target is supposed to do?
>
> What do you mean "tried to enter full feature phase without 
> responding"? It sent back an empty PDU requesting transitioning to 
> FFP? Did the target correctly not offer to transition to FFP (did not 
> set the 'T' bit in the login response)? The target should not set the 
> 'T' bit and it should wait for the initiator to answer, and eventually

> time out the login.
>
> From the RFC:
> 12.16.  DefaultTime2Retain
>
>    Use: LO Senders: Initiator and Target Scope: SW
>
>    DefaultTime2Retain=<numerical-value-0-to-3600>
>
>    Default is 20.  Result function is Minimum.
>
> So it's valid to negotiate in a discovery session.
>
> RAM> Target didn't set 'T' bit when it sent Login response with
> DefaultTime2Retain key.
> What I mean here is that Intiator responded back with a Login
> request with
> an empty PDU(no keys), requesting transition to FFP.
> Because initiator responded back here, there is no question of  
> timing out
> the login.What is the correct way the target should handle this?

The target should send back an empty PDU denying the transition to FFP.

There certainly is a question of timing out the login. :-) It is  
perfectly reasonable for a target to terminate a login that doesn't  
complete after a number of replies. Ken mentioned 100 or 1000 PDUs.  
I'd set the limit lower, say at 20. Another option is to keep the  
count low, say 10, and reset it when you get a reasonable PDU.

I also recommend that if you kill a login attempt for this reason  
(didn't complete, were outstanding Keys), log why you're doingthis and  
what keys were outstanding. This will help customers escalate the  
issue w/ the initiator vendor.

Take care,

Bill


_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips


_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips


[IETF]     [Linux iSCSI]     [Linux SCSI]     [Linux Resources]     [Yosemite News]     [IETF Announcements]     [IETF Discussion]     [SCSI]

Add to Google Powered by Linux