ietf
[Top] [All Lists]

Re: [BEHAVE] General Comments on xlate-stateful-07

2010-01-18 04:33:38
Hi,

On 2010-1-18, at 1:11, Reinaldo Penno wrote:
What I mean is that the sentence starts of with "In such cases...".  These
'cases' are those when the NAT cannot determine whether the endpoints of a
TCP connection are active, as written.

right. I believe the thinking was that if you can detect whether the session is 
alive, you wouldn't time it out if it was, and you would of course time it out 
if it wasn't.

If you cannot determine this, then the default applies (and can't be shorter 
than 2 hours.)

Lars

Therefore this first paragraph only applies to this condition. If you can
actually determine if the NAT endpoints are alive, you do not need to follow
this paragraph. 

My opinion is that we should just follow REQ-5 as stated. This is would take
care of Bryan's proposal as well.




On 1/17/10 4:07 AM, "marcelo bagnulo braun" 
<marcelo(_at_)it(_dot_)uc3m(_dot_)es> wrote:

Reinaldo Penno escribió:
It clearly says in a)  that the idle timeout MAY be configurable. How
will my proposed text break 5382?


THere are two conditions:
MUST be more than 2 hours and 4 min
MAY be configurable.

So, my reading of the conditions is an AND of the two conditions, not an
OR.
Maybe someone else should comment whether they think it is an AND or an
OR....?

If it is an AND, then you can configire the timer, but needs to be
higher than 2 hours and 4 min, in any case, as it is currently stated in
the draft

It is is an OR, it is as you say, but at this point i don't interpret
the text as a OR
It also says that only in case the NAT cannot determine if endpoints
are alive.



right, we are having a disucssion whether the nat64 should send
keepalives to do this, do you think it should or not?



Why we just then just copy REQ5 verbatim?


on the light of this discussion, it seems that the current wording is
unclear, since you and me have different readings of it

Regards, marcelo


On Jan 16, 2010, at 14:34, "marcelo bagnulo braun"
<marcelo(_at_)it(_dot_)uc3m(_dot_)es> wrote:


Reinaldo Penno escribió:

Hello,

Comment inline...




Moreover, the ability to
configure the idle-timeout is also missing.




right,

i have added the follwoing text in all the occureences of the the
setting of the TCP session entry lifetite

                  The lifetime of the TCP session table entry is
set
to at least to the maximum session lifetime. The value for the
maximum
                  session lifetime MAY be configurable but it
MUST not
be less than TCP_EST (the
                  established connection idle timeout as defined in
<xref target="RFC5382"></xref>). The default value for the maximum
session lifetime
                  SHOULD be set to TCP_EST.


The whole purpose to have it configurable was to be able to
configure it to
be _less_ than TCP_EST.



no, that would break REQ5 of RFC5382 that reads:

 REQ-5:  If a NAT cannot determine whether the endpoints of a TCP
    connection are active, it MAY abandon the session if it has been
    idle for some time.  In such cases, the value of the "established
    connection idle-timeout" MUST NOT be less than 2 hours 4 minutes.
    The value of the "transitory connection idle-timeout" MUST NOT be
    less than 4 minutes.
    a) The value of the NAT idle-timeouts MAY be configurable.



The text above does not allow it to be set to less than TCP_EST. I
suggest

"The lifetime of the TCP session table entry is set
to at least to the maximum session lifetime. The value for the
maximum
session lifetime MAY be configurable  The default value for the
maximum
session lifetime SHOULD be set to TCP_EST."

Tuning TCP idle timeout is widely supported and used.



right, but the minimum value MOST NOT be less than 2 hours and 4 min

REQ-5: In the NAT64 spec the considerations on NAT throughput
performance
due to holding session state for TCP RST and TIME_WAIT
assassinations due to
holding session state are not discussed.



REQ5 leaves these aspects open and so the nat64 specification. Do
you
have any particualr text that you would like to cinlcude in the
nat64
spec w.r.t. this?


The exact same text (or a reference to it) found in RFC5382.



could you point out what exact same text you are referring to?

Regards, marcelo


Regards,

Reinaldo






_______________________________________________
Behave mailing list
Behave(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/behave

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>
  • Re: [BEHAVE] General Comments on xlate-stateful-07, Lars Eggert <=