RE: DefaultTime2Retain Negotiation during Discovery Session

"Sandars, Ken" <[email protected]> Sun, 19 Aug 2007 20:45:00 -0700
Newsgroups gmane.ietf.ips
Message-ID <[email protected]>
Hi Ram,

So you're probably in a delightful loop where the initiator sends an
empty Login request PDU which requests a transition to FFP, and the
target responds with an empty Login response refusing to transit. This
goes on forever, and probably quite quickly.

Two valid target implementations to break out of this are:

1. Limit the number of Login responses the target will send before it
gives up. Let this be a gross number - say over a hundred, a thousand,
whatever you prefer.

2. Limit the duration from the start of the TCP connection to reaching
FFP. If the login phase goes over your arbitrary limit, terminate the
sequence.

Cheers
Ken

-----Original Message-----
From: RAM SUNEE [mailto:[email protected]] 
Sent: Sunday, 19 August 2007 02:46
To: Ips; William Studenmund
Subject: RE: [Ips] DefaultTime2Retain Negotiation during Discovery
Session
Importance: High



-----Original Message-----
From: William Studenmund [mailto:[email protected]]
Sent: Saturday, August 18, 2007 8:29 AM
To: RAM SUNEE
Cc: Ips
Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery
Session
Importance: High


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?



> Also, if the same situation happens during Normal Session,what the 
> target is supposed to do?

Same thing.

Take care,

Bill



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


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