Re: [BEHAVE] General Comments on xlate-stateful-07
marcelo bagnulo braun <marcelo@it.uc3m.es> Sun, 17 January 2010 12:07 UTC
Return-Path: <marcelo@it.uc3m.es>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791063A659C for <behave@core3.amsl.com>; Sun, 17 Jan 2010 04:07:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.636
X-Spam-Level:
X-Spam-Status: No, score=-106.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72kHKFADrUNw for <behave@core3.amsl.com>; Sun, 17 Jan 2010 04:07:18 -0800 (PST)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 17A653A672F for <behave@ietf.org>; Sun, 17 Jan 2010 04:07:17 -0800 (PST)
X-uc3m-safe: yes
Received: from r190-132-214-7.dialup.adsl.anteldata.net.uy (unknown [190.132.214.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 94CF87EE9B9; Sun, 17 Jan 2010 13:07:10 +0100 (CET)
Message-ID: <4B52FD6A.9030006@it.uc3m.es>
Date: Sun, 17 Jan 2010 13:07:06 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Reinaldo Penno <rpenno@juniper.net>
References: <C7776B85.F8A5%rpenno@juniper.net> <4B523EE4.6010208@it.uc3m.es> <AC8FCD86-5E8A-46ED-B3AC-9C7AC6F0F79E@juniper.net>
In-Reply-To: <AC8FCD86-5E8A-46ED-B3AC-9C7AC6F0F79E@juniper.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17136.007
Cc: IETF BEHAVE WG <behave@ietf.org>, Dave Thaler <dthaler@microsoft.com>, Dan Wing <dwing@cisco.com>
Subject: Re: [BEHAVE] General Comments on xlate-stateful-07
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Jan 2010 12:07:19 -0000
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@it.uc3m.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 >>> >>> >>> >>>
- Re: [BEHAVE] General Comments on xlate-stateful-07 Reinaldo Penno
- Re: [BEHAVE] General Comments on xlate-stateful-07 marcelo bagnulo braun
- Re: [BEHAVE] General Comments on xlate-stateful-07 Reinaldo Penno
- Re: [BEHAVE] General Comments on xlate-stateful-07 marcelo bagnulo braun
- Re: [BEHAVE] General Comments on xlate-stateful-07 Reinaldo Penno
- Re: [BEHAVE] General Comments on xlate-stateful-07 marcelo bagnulo braun
- Re: [BEHAVE] General Comments on xlate-stateful-07 Reinaldo Penno
- Re: [BEHAVE] General Comments on xlate-stateful-07 Lars Eggert
- Re: [BEHAVE] General Comments on xlate-stateful-07 Lars Eggert
- Re: [BEHAVE] General Comments on xlate-stateful-07 Reinaldo Penno
- Re: [BEHAVE] General Comments on xlate-stateful-07 marcelo bagnulo braun
- Re: [BEHAVE] General Comments on xlate-stateful-07 Reinaldo Penno
- Re: [BEHAVE] General Comments on xlate-stateful-07 marcelo bagnulo braun
- Re: [BEHAVE] General Comments on xlate-stateful-07 Reinaldo Penno
- Re: [BEHAVE] General Comments on xlate-stateful-07 Reinaldo Penno
- Re: [BEHAVE] General Comments on xlate-stateful-07 marcelo bagnulo braun
- Re: [BEHAVE] General Comments on xlate-stateful-07 Reinaldo Penno
- Re: [BEHAVE] General Comments on xlate-stateful-07 WashamFan
- Re: [BEHAVE] General Comments on xlate-stateful-07 marcelo bagnulo braun
- Re: [BEHAVE] General Comments on xlate-stateful-07 WashamFan
- Re: [BEHAVE] General Comments on xlate-stateful-07 Lars Eggert
- Re: [BEHAVE] General Comments on xlate-stateful-07 Saikat Guha