From ietf-ipr@ietf.org Mon Mar 4 22:24:09 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE9D21F869B; Mon, 4 Mar 2013 22:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.104 X-Spam-Level: X-Spam-Status: No, score=-102.104 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTKXwE3s1jJP; Mon, 4 Mar 2013 22:24:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A387721F866F; Mon, 4 Mar 2013 22:24:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: philip_matthews@magma.ca, jdrosen@cisco.com, dwing@cisco.com, rohan@ekabal.com X-Test-IDTracker: no X-IETF-IDTracker: 4.41 Message-ID: <20130305062408.1773.8820.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2013 22:24:08 -0800 Cc: behave@ietf.org, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com, martin.stiemerling@neclab.eu, ipr-announce@ietf.org Subject: [BEHAVE] IPR Disclosure: SSH Communications Security Corporation's Statement about IPR related to RFC 5389 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 06:24:09 -0000 Dear Philip Matthews, Jonathan Rosenberg, Dan Wing, Rohan Mahy: An IPR disclosure that pertains to your RFC entitled "Session Traversal Utilities for NAT (STUN)" (RFC5389) was submitted to the IETF Secretariat on 2013-02-23 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/1987/). The title of the IPR disclosure is "SSH Communications Security Corporation's Statement about IPR related to RFC 5389.""); The IETF Secretariat From Martin.Stiemerling@neclab.eu Thu Mar 7 06:59:16 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE7221F8C8D for ; Thu, 7 Mar 2013 06:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.628 X-Spam-Level: X-Spam-Status: No, score=-103.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8-a0gRMgnGq for ; Thu, 7 Mar 2013 06:59:15 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 977AF21F8D10 for ; Thu, 7 Mar 2013 06:59:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0591C103615 for ; Thu, 7 Mar 2013 15:59:15 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5Aqg5F90zbI for ; Thu, 7 Mar 2013 15:59:14 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id DD07A103614 for ; Thu, 7 Mar 2013 15:59:09 +0100 (CET) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 7 Mar 2013 15:59:09 +0100 Message-ID: <5138AB3D.3070902@neclab.eu> Date: Thu, 7 Mar 2013 15:59:09 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Subject: [BEHAVE] Why is draft-ietf-tsvwg-natsupp not normative in draft-ietf-behave-sctpnat? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 14:59:16 -0000 Hi, I wonder why draft-ietf-tsvwg-natsupp is not normative in draft-ietf-behave-sctpnat? Especially when I read in draft-ietf-behave-sctpnat-08.txt, Section 6, page 7: "In this case the INIT SHOULD be dropped by the NAT and an ABORT SHOULD be sent back to the SCTP host with the M-Bit set and an appropriate error cause (see [I-D.ietf-tsvwg-natsupp] for the format)." Thanks, Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From dwing@cisco.com Fri Mar 8 08:07:46 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8E121F87F6 for ; Fri, 8 Mar 2013 08:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTHvkHPxWEfU for ; Fri, 8 Mar 2013 08:07:42 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7675F21F868E for ; Fri, 8 Mar 2013 08:07:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1149; q=dns/txt; s=iport; t=1362758862; x=1363968462; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=z6/FcCcLCbbsV6tOTyQEJUEKXse24JuIVaUeudjSGr0=; b=jCAGZe8sgvEczRleS9bYsZsbIFJUmtzPTIYzY/Z0sWUzmQua9iZBQOhY CXv/ShFAeCX9Jyhaik95whdrwoPcsKK1FftDiFEvfiFgyac7/+KNG/DTe /hjbOJCAJ/VOxLrSSq6qI+iVFLFBKYc55Y3FxQz19bklPliLVFIljcM0Y A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAPUKOlGrRDoJ/2dsb2JhbABDhQe/RYFZFnSCLAEBAQMBAQEBNzQLBQsLRicwBhOIDQUNuxAEjVUEgQAzB4JfYQOIcY1ihXmKeYFUgVeBSA X-IronPort-AV: E=Sophos;i="4.84,809,1355097600"; d="scan'208";a="72159769" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 08 Mar 2013 16:07:41 +0000 Received: from [10.32.240.196] ([10.32.240.196]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r28G7fdJ012266; Fri, 8 Mar 2013 16:07:41 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dan Wing In-Reply-To: <5138AB3D.3070902@neclab.eu> Date: Fri, 8 Mar 2013 08:07:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6A15298C-30A5-46C2-846F-23288112C021@cisco.com> References: <5138AB3D.3070902@neclab.eu> To: Martin Stiemerling X-Mailer: Apple Mail (2.1499) Cc: draft-ietf-behave-sctpnat@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Why is draft-ietf-tsvwg-natsupp not normative in draft-ietf-behave-sctpnat? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 16:07:46 -0000 On Mar 7, 2013, at 6:59 AM, Martin Stiemerling = wrote: > Hi, >=20 > I wonder why draft-ietf-tsvwg-natsupp is not normative in > draft-ietf-behave-sctpnat? Yes, tsvwg-natsupp should now be a normative reference. > Especially when I read in draft-ietf-behave-sctpnat-08.txt, Section 6, > page 7: > "In this case the INIT SHOULD be dropped by the NAT and an ABORT = SHOULD be sent back to the SCTP host with the M-Bit set and an = appropriate error cause (see [I-D.ietf-tsvwg-natsupp] for the format)." draft-ietf-behave-sctpnat also needs to be clarified on the source = address of that ABORT message -- it seems it needs to be sent with the = source address of the SCTP server.=20 -d >=20 > Thanks, >=20 > Martin >=20 > --=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe > NEC Europe Limited > Registered Office: > Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB > Registered in England 2832014 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From tuexen@fh-muenster.de Sun Mar 10 06:22:35 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC4921F8600 for ; Sun, 10 Mar 2013 06:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7NHAw6MyIGE for ; Sun, 10 Mar 2013 06:22:34 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 71BBC21F85DC for ; Sun, 10 Mar 2013 06:22:34 -0700 (PDT) Received: from dhcp-42c6.meeting.ietf.org (dhcp-42c6.meeting.ietf.org [130.129.66.198]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id BDAFC1C0C0BF6; Sun, 10 Mar 2013 14:22:31 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <6A15298C-30A5-46C2-846F-23288112C021@cisco.com> Date: Sun, 10 Mar 2013 09:22:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0784B30F-FCC8-4551-943A-8B2C4FD23F12@fh-muenster.de> References: <5138AB3D.3070902@neclab.eu> <6A15298C-30A5-46C2-846F-23288112C021@cisco.com> To: Dan Wing X-Mailer: Apple Mail (2.1283) Cc: draft-ietf-behave-sctpnat@tools.ietf.org, behave@ietf.org, Martin Stiemerling Subject: Re: [BEHAVE] Why is draft-ietf-tsvwg-natsupp not normative in draft-ietf-behave-sctpnat? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 13:22:35 -0000 On Mar 8, 2013, at 11:07 AM, Dan Wing wrote: >=20 > On Mar 7, 2013, at 6:59 AM, Martin Stiemerling = wrote: >=20 >> Hi, >>=20 >> I wonder why draft-ietf-tsvwg-natsupp is not normative in >> draft-ietf-behave-sctpnat? >=20 > Yes, tsvwg-natsupp should now be a normative reference. Correct. It will be in the next revision. >=20 >> Especially when I read in draft-ietf-behave-sctpnat-08.txt, Section = 6, >> page 7: >> "In this case the INIT SHOULD be dropped by the NAT and an ABORT = SHOULD be sent back to the SCTP host with the M-Bit set and an = appropriate error cause (see [I-D.ietf-tsvwg-natsupp] for the format)." >=20 > draft-ietf-behave-sctpnat also needs to be clarified on the source = address of that ABORT message -- it seems it needs to be sent with the = source address of the SCTP server.=20 Correct. I added The source address of the packet containing the ABORT chunk MUST be the destination address of the packet containing the INIT chunk. This will be in the next rev. Thanks for the comments. Best regards Michael >=20 > -d >=20 >=20 >>=20 >> Thanks, >>=20 >> Martin >>=20 >> --=20 >> martin.stiemerling@neclab.eu >>=20 >> NEC Laboratories Europe >> NEC Europe Limited >> Registered Office: >> Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB >> Registered in England 2832014 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >=20 >=20 From internet-drafts@ietf.org Sun Mar 10 23:55:47 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7763C21F8845; Sun, 10 Mar 2013 23:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDvkVKM3QoAU; Sun, 10 Mar 2013 23:55:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BC621F882D; Sun, 10 Mar 2013 23:55:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.42 Message-ID: <20130311065526.27886.31244.idtracker@ietfa.amsl.com> Date: Sun, 10 Mar 2013 23:55:26 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-15.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 06:55:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : Discovery of the IPv6 Prefix Used for IPv6 Address Synth= esis Author(s) : Teemu Savolainen Jouni Korhonen Dan Wing Filename : draft-ietf-behave-nat64-discovery-heuristic-15.txt Pages : 20 Date : 2013-03-10 Abstract: This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi- interface deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat64-discovery-heuris= tic-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Mar 12 08:21:41 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0D421F8BD7; Tue, 12 Mar 2013 08:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCCFf-AVu9oA; Tue, 12 Mar 2013 08:21:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F4E21F8BD9; Tue, 12 Mar 2013 08:21:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.42 Message-ID: <20130312152139.17756.62716.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2013 08:21:39 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-16.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 15:21:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : Discovery of the IPv6 Prefix Used for IPv6 Address Synth= esis Author(s) : Teemu Savolainen Jouni Korhonen Dan Wing Filename : draft-ietf-behave-nat64-discovery-heuristic-16.txt Pages : 20 Date : 2013-03-12 Abstract: This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi- interface deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat64-discovery-heuris= tic-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dwing@cisco.com Wed Mar 13 11:11:07 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A76021F8E0B for ; Wed, 13 Mar 2013 11:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0y5fqq0WrUNP for ; Wed, 13 Mar 2013 11:11:06 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A49B121F8E73 for ; Wed, 13 Mar 2013 11:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=649; q=dns/txt; s=iport; t=1363198266; x=1364407866; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=8AnvXo3ZUiPlzdXh5szyBaVX+60DG0p/0BGgPi1CSXA=; b=jTxopORHP9+HJYRAACfePCFcv+N8BPCWr80fo3uOtn20YfvKTTYYUicX WTzXn96Knj20Mf1XCYG4jbFxqa47gPygCQGLTsoJ1ALXdjpwWyibYMQeg muy3VumDOLGBEccYUphxSJHHtIki4x33xWxNssWvX7ipmHY1JTBkLEymZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFADbAQFGrRDoI/2dsb2JhbABDh1y8eoFZFm0Hgi88P4EyDIgmDcMQF48NgmZhA5ZWgR+PV4MmIA X-IronPort-AV: E=Sophos;i="4.84,838,1355097600"; d="scan'208";a="72258809" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 13 Mar 2013 18:11:06 +0000 Received: from sjc-vpn7-905.cisco.com (sjc-vpn7-905.cisco.com [10.21.147.137]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2DIB5YZ025915; Wed, 13 Mar 2013 18:11:06 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Mar 2013 14:11:05 -0400 Message-Id: <65DAA8E7-B1A8-4581-80F2-D1734999BA1A@cisco.com> To: "behave@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: behave-chairs@tools.ietf.org Subject: [BEHAVE] logging drafts X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:11:07 -0000 The two NAT logging drafts were presented at the BEHAVE meeting at = IETF86 (draft-sivakumar-behave-nat-logging-06 and = draft-ietf-behave-syslog-nat-logging-00). They are both WG documents = and based on the feedback at the meeting, we would like to see: * an update of the table presented at the meeting (slide 6 of = http://tools.ietf.org/agenda/86/slides/slides-86-behave-2.pdf). =20 * text added to the SYSLOG and IPFIX documents explaining their = applicability. * discussion on the list to reach consensus that SYSLOG and IPFIX = should, or should not, send different events because of their different = applicability. -d From swmike@swm.pp.se Wed Mar 13 11:17:14 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336FC21F8DE1 for ; Wed, 13 Mar 2013 11:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtpNd5eWtwDg for ; Wed, 13 Mar 2013 11:17:13 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2EF21F8E21 for ; Wed, 13 Mar 2013 11:17:13 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8431B9C; Wed, 13 Mar 2013 19:17:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 790439A; Wed, 13 Mar 2013 19:17:12 +0100 (CET) Date: Wed, 13 Mar 2013 19:17:12 +0100 (CET) From: Mikael Abrahamsson To: Dan Wing In-Reply-To: <65DAA8E7-B1A8-4581-80F2-D1734999BA1A@cisco.com> Message-ID: References: <65DAA8E7-B1A8-4581-80F2-D1734999BA1A@cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "behave@ietf.org" Subject: Re: [BEHAVE] logging drafts X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:17:14 -0000 On Wed, 13 Mar 2013, Dan Wing wrote: > * discussion on the list to reach consensus that SYSLOG and IPFIX > should, or should not, send different events because of their different > applicability. I was the one who asked the syslog question from Jabber yesterday, forgot to type my name. So I understand that syslog can be done over TCP and even TLS (even though this is not widely implemented), I would like some kind of discussion on how to actually do this in real life with hundreds of thousands of entries per second flowing across this logging solution. There are boxes available today on the market that will do millions of new sessions per seconds. When I looked at this it seemed unfeasable to do logging for this amount of data, and doing the port block allocation is the only way to solve this problem. Is it suitable to have this kind of scalability discussion in these drafts (or at least a reference to one) or is that out of scope? -- Mikael Abrahamsson email: swmike@swm.pp.se From tom.taylor.stds@gmail.com Wed Mar 13 11:31:58 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A385521F8E71 for ; Wed, 13 Mar 2013 11:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXDf6rCvcrlv for ; Wed, 13 Mar 2013 11:31:57 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id CD5A721F8D98 for ; Wed, 13 Mar 2013 11:31:57 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id um15so1314362pbc.28 for ; Wed, 13 Mar 2013 11:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1Bw9+uAwcXZ00Lw3UgS4+ROd27HFSFOXZam0SVocVy8=; b=JrnvuNfHwwbMW2Yuhn4GBVi/EdWpm2lCyInGx05YyQo+vhOF3HMNE6aCIIyIMz+4IK iqELAFqhRK02JJS1Su86AoZwI9xcBhy9V13rENV6NeKxCx4cST7r3kgzwMBLJQ0X/VR3 cwQmy5WGkBmtobppwQCh/mTGRSA2Zcgc+/IfWCCEzHsHQl/+wZr5jUBDFoz6G5ujZQ7X tCMyTZg340lxmOPEuZo9kNx0kojmLgU4oqGRnZKcv+4ASSNg5BugyCyk0mjdjt4A1700 ZJHaLQO8ZaDubJdedr1/K+SNKVBbWpt6TOzB42DxSwOjh+/KroCZRBBrXwUu4aIYh5bg n5Wg== MIME-Version: 1.0 X-Received: by 10.68.222.73 with SMTP id qk9mr47985014pbc.115.1363199517421; Wed, 13 Mar 2013 11:31:57 -0700 (PDT) Received: by 10.68.158.44 with HTTP; Wed, 13 Mar 2013 11:31:57 -0700 (PDT) In-Reply-To: References: <65DAA8E7-B1A8-4581-80F2-D1734999BA1A@cisco.com> Date: Wed, 13 Mar 2013 14:31:57 -0400 Message-ID: From: Tom Taylor To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=047d7b2ee08dff743d04d7d29e24 Cc: "behave@ietf.org" , Dan Wing Subject: Re: [BEHAVE] logging drafts X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:31:58 -0000 --047d7b2ee08dff743d04d7d29e24 Content-Type: text/plain; charset=ISO-8859-1 I think it's quite reasonable to have such a discussion in the Syslog draft. We did seem to agree yesterday that Syslog could implement all of the events the IPFIX document does, but: - enabling of specific reports should be configurable (a basic Syslog functionality, I think); - such a discussion of when you might enable per-session logging (low volume situation, e.g., managed small office gateway) should be present. We probably also want to address the point raised regarding blocking if reliable transmission is used, by requiring a configurable policy regarding whether sessions should continue to be set up even if the transmission queue is full. Tom Taylor On Wed, Mar 13, 2013 at 2:17 PM, Mikael Abrahamsson wrote: > On Wed, 13 Mar 2013, Dan Wing wrote: > > * discussion on the list to reach consensus that SYSLOG and IPFIX should, >> or should not, send different events because of their different >> applicability. >> > > I was the one who asked the syslog question from Jabber yesterday, forgot > to type my name. > > So I understand that syslog can be done over TCP and even TLS (even though > this is not widely implemented), I would like some kind of discussion on > how to actually do this in real life with hundreds of thousands of entries > per second flowing across this logging solution. > > There are boxes available today on the market that will do millions of new > sessions per seconds. When I looked at this it seemed unfeasable to do > logging for this amount of data, and doing the port block allocation is the > only way to solve this problem. Is it suitable to have this kind of > scalability discussion in these drafts (or at least a reference to one) or > is that out of scope? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > ______________________________**_________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/**listinfo/behave > --047d7b2ee08dff743d04d7d29e24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it's quite reasonable to have such a discussion in the Syslog d= raft. We did seem to agree yesterday that Syslog could implement all of the= events the IPFIX document does, but:

- enabling of specific reports= should be configurable (a basic Syslog functionality, I think);

- such a discussion of when you might enable per-session logging (low v= olume situation, e.g., managed small office gateway) should be present.
=
We probably also want to address the point raised regarding blocking if= reliable transmission is used, by requiring a configurable policy regardin= g whether sessions should continue to be set up even if the transmission qu= eue is full.

Tom Taylor


On Wed, Mar 13, 2013 a= t 2:17 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Wed, 13 Mar 2013, Dan Wing wrote:

* discussion on the list to reach consensus that SYSLOG and IPFIX should, o= r should not, send different events because of their different applicabilit= y.

I was the one who asked the syslog question from Jabber yesterday, forgot t= o type my name.

So I understand that syslog can be done over TCP and even TLS (even though = this is not widely implemented), I would like some kind of discussion on ho= w to actually do this in real life with hundreds of thousands of entries pe= r second flowing across this logging solution.

There are boxes available today on the market that will do millions of new = sessions per seconds. When I looked at this it seemed unfeasable to do logg= ing for this amount of data, and doing the port block allocation is the onl= y way to solve this problem. Is it suitable to have this kind of scalabilit= y discussion in these drafts (or at least a reference to one) or is that ou= t of scope?

--
Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se
_______________________________________________
Behave mailing list
Behave@ietf.org = https://www.ietf.org/mailman/listinfo/behave

--047d7b2ee08dff743d04d7d29e24-- From internet-drafts@ietf.org Tue Mar 19 12:56:05 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D0A21F8C06; Tue, 19 Mar 2013 12:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP8be5V26YWB; Tue, 19 Mar 2013 12:56:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD8521F8B74; Tue, 19 Mar 2013 12:56:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130319195605.19816.13531.idtracker@ietfa.amsl.com> Date: Tue, 19 Mar 2013 12:56:05 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 19:56:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : IPFIX Information Elements for logging NAT Events Author(s) : Senthil Sivakumar Renaldo Penno Filename : draft-ietf-behave-ipfix-nat-logging-00.txt Pages : 14 Date : 2013-03-19 Abstract: NAT devices are required to log events like creation and deletion of translations and information about the resources it is managing. With the wide deployment of Carrier Grade NAT (CGN) devices, the logging of events have become very important for legal purposes. The logs are required in many cases to identify an attacker or a host that was used to launch malicious attacks and/or for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices behave differently and hence it is difficult to expect a consistent behavior. The lack of a consistent way makes it difficult to write the collector applications that would receive this data and process it to present useful information. This document describes the information that is required to be logged by the NAT devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kristian.poscic@alcatel-lucent.com Sun Mar 31 05:22:04 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19CE21F8573; Sun, 31 Mar 2013 05:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4DWBZq-zgDM; Sun, 31 Mar 2013 05:22:02 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id B5F3221F849C; Sun, 31 Mar 2013 05:22:02 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r2VCLw9a028340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 31 Mar 2013 07:21:59 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r2VCLvAX024753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 31 Mar 2013 08:21:58 -0400 Received: from US70UWXCHMBA06.zam.alcatel-lucent.com ([169.254.11.15]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Sun, 31 Mar 2013 08:21:57 -0400 From: "Poscic, Kristian (Kristian)" To: "behave@ietf.org" , "softwires@ietf.org" Thread-Topic: packet reordering in MAP Thread-Index: Ac4uB4uRFRGCdwgZTzy7vxCW8THBdQ== Date: Sun, 31 Mar 2013 12:21:56 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AA9B897@US70UWXCHMBA06.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02AA9B897US70UWXCHMBA06z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [BEHAVE] packet reordering in MAP X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 12:22:04 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F02AA9B897US70UWXCHMBA06z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can someone share some history and research backed data behind this stateme= nt at the very bottom of section 4 in RFC 6145 (IP/ICMP Translation Algorit= hm). The translator SHOULD make sure that the packets belonging to the same flow leave the translator in the same order in which they arrived. I'm wondering why would be acceptable for a box to reorder packets of the s= ame flow (SHOULD vs MUST)? While TCP can cope with reordering well (seq numbers plus TCP has MSS mecha= nism to avoid fragmentation all together if the nodes in the path also supp= ort MSS), I would think that (at least some) apps using UDP transport woul= d not tolerate packet reordering. So I was hoping that someone can offer some references of real research bac= ked data rather than opinions (I would like to her opinions as well but th= ey often differ). Even if you have ECMP in the network and if all the nodes in the end-to-end= path are performing per flow load balancing over ECMP links (which should = be the norm), packet reordering should not happen. If nodes are performing per-packet load balancing over ECMP links then pack= et reordering can occur but I would consider this bad practice (I know that= some old platforms would do per packet load balancing on ECMP links though= ). The reason I ask this is in the context of implementing fragmentation/reass= embly for MAP-E/T (although the issue extends beyond MAP). For example in distributed platforms it would make sense to implement MAP t= ranslation function in-line (in the forwarding cards) but the reassembly fu= nction in the service cards since the reassembly function adds additional c= omplexity and buffering requirements (I understand that the fragmented traf= fic is small percentage of all traffic, but still...). Let say that a v6 packet arrives to a BR (from the CPE). The BR will process this packet in-line and send it out as v4. Then another number of fragmented packets of the same flow arrive -> the BR= process those in service blades (not in-line). While service blade is processing the fragments (reassembling them), anothe= r non-fragmented packet of the same flow arrives on the BR. This packet is processed in-line and sent out before the previously receive= d fragments are reassembled in service blade. Now the BR has caused packet re-ordering. Why is this, according to RFC 6145) acceptable? Any feedback appreciated. Kris --_000_7921F977B17D5B49B8DCC955A339D2F02AA9B897US70UWXCHMBA06z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can someone share some history and research backed d= ata behind this statement at the very bottom of section 4 in RFC 6145 (IP/I= CMP Translation Algorithm).

 

The transla= tor SHOULD make sure that the packets belonging to the

  = ; same flow leave the translator in the same order in which they=

  = ; arrived.

 

I’m wondering why would be acceptable for a bo= x to reorder packets of the same flow (SHOULD vs MUST)?

 

While TCP can cope with reordering well (seq numbers= plus TCP has MSS mechanism to avoid fragmentation all together if the node= s in the path also support MSS), I would think that (at least some)  a= pps using UDP transport would not tolerate packet reordering.

So I was hoping that someone can offer some referenc= es of real research backed data rather than opinions  (I would like to= her opinions as well but they often differ).

Even if you have ECMP in the network and if all the = nodes in the end-to-end path are performing per flow load balancing over EC= MP links (which should be the norm), packet reordering should not happen.

If nodes are performing per-packet load balancing ov= er ECMP links then packet reordering can occur but I would consider this ba= d practice (I know that some old platforms would do per packet load balanci= ng on ECMP links though).

 

The reason I ask this is in the context of implement= ing fragmentation/reassembly for MAP-E/T (although the issue extends beyond= MAP).

For example in distributed platforms it would make s= ense to implement MAP translation function in-line (in the forwarding cards= ) but the reassembly function in the service cards since the reassembly fun= ction adds additional complexity and buffering requirements (I understand that the fragmented traffic is small = percentage of all traffic, but still…).

Let say that a v6 packet arrives to a BR (from the C= PE).

The BR will process this packet in-line and send it = out as v4.

Then another number of fragmented packets of the sam= e flow arrive -> the BR process those in service blades (not in-line).

While service blade is processing the fragments (rea= ssembling them), another non-fragmented packet of the same flow arrives on = the BR.

This packet is processed in-line and sent out before= the previously received fragments are reassembled in service blade.

Now the BR has caused packet re-ordering.=

Why is this, according to RFC 6145) acceptable?

 

Any feedback appreciated.

Kris

 

  

--_000_7921F977B17D5B49B8DCC955A339D2F02AA9B897US70UWXCHMBA06z_-- From brian.e.carpenter@gmail.com Sun Mar 31 05:45:15 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB7021F845A; Sun, 31 Mar 2013 05:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.844 X-Spam-Level: X-Spam-Status: No, score=-99.844 tagged_above=-999 required=5 tests=[AWL=-0.923, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmQ-3agFUO0t; Sun, 31 Mar 2013 05:45:14 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4425821F8319; Sun, 31 Mar 2013 05:45:14 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hj8so935922wib.7 for ; Sun, 31 Mar 2013 05:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KrHuaBdGefY8jnl7bK3GNcL4kOxkxagqLh+CYltTv6M=; b=dC0R0/ZG9ZjUl9xjOwN9By7b0wHhsHv2bqPXBg/0PRNMPcPhf0AdRPd8pMOLk8DE1F gITZRc2VxAde78QgPX1RDoh8BhQQ3hKzGp8cxqrVqxAQ1XO1+F5s+U1EkoDHU27gAHm8 HmOj2yaHcd5PMtEeOjn9uQAeBAGEr3HIXVUYCEpNxtgBG0lEsdboYBXOTohfOK7S030X JKsPfrIvhNvjO5t5DjbdkNj3RPQnbj75IMlTEyNBdQ9zh5oeKWNovC4+0TeU6vZJHW3D PhyltyWMK4QqoR5A3IP8j/bYn03JD05lUAHzCwrHVPjrkLvdO2/zrXG8I88eXbjLex4D WiVw== X-Received: by 10.180.92.229 with SMTP id cp5mr5731883wib.20.1364733913355; Sun, 31 Mar 2013 05:45:13 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-177.as13285.net. [2.102.218.177]) by mx.google.com with ESMTPS id dp5sm8178471wib.1.2013.03.31.05.45.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Mar 2013 05:45:12 -0700 (PDT) Message-ID: <51582FD6.9060503@gmail.com> Date: Sun, 31 Mar 2013 13:45:10 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Poscic, Kristian (Kristian)" References: <7921F977B17D5B49B8DCC955A339D2F02AA9B897@US70UWXCHMBA06.zam.alcatel-lucent.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AA9B897@US70UWXCHMBA06.zam.alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] packet reordering in MAP X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 12:45:15 -0000 Have a look at section 3.1.8 in RFC 6250, and there is a reference: Bennett, J., Partridge, C., and N. Shectman, "Packet reordering is not pathological network behavior", IEEE/ACM Transactions on Networking, Vol. 7, No. 6, December 1999. A UDP application that cannot tolerate reordering is broken. Since the Internet does not and cannot guarantee the order of delivery, I think the SHOULD is appropriate. For example, if a translator is almost out of memory, surely it is better to send a packet out of order than to drop it? Brian On 31/03/2013 13:21, Poscic, Kristian (Kristian) wrote: > Can someone share some history and research backed data behind this statement at the very bottom of section 4 in RFC 6145 (IP/ICMP Translation Algorithm). > > The translator SHOULD make sure that the packets belonging to the > same flow leave the translator in the same order in which they > arrived. > > I'm wondering why would be acceptable for a box to reorder packets of the same flow (SHOULD vs MUST)? > > While TCP can cope with reordering well (seq numbers plus TCP has MSS mechanism to avoid fragmentation all together if the nodes in the path also support MSS), I would think that (at least some) apps using UDP transport would not tolerate packet reordering. > So I was hoping that someone can offer some references of real research backed data rather than opinions (I would like to her opinions as well but they often differ). > Even if you have ECMP in the network and if all the nodes in the end-to-end path are performing per flow load balancing over ECMP links (which should be the norm), packet reordering should not happen. > If nodes are performing per-packet load balancing over ECMP links then packet reordering can occur but I would consider this bad practice (I know that some old platforms would do per packet load balancing on ECMP links though). > > The reason I ask this is in the context of implementing fragmentation/reassembly for MAP-E/T (although the issue extends beyond MAP). > For example in distributed platforms it would make sense to implement MAP translation function in-line (in the forwarding cards) but the reassembly function in the service cards since the reassembly function adds additional complexity and buffering requirements (I understand that the fragmented traffic is small percentage of all traffic, but still...). > Let say that a v6 packet arrives to a BR (from the CPE). > The BR will process this packet in-line and send it out as v4. > Then another number of fragmented packets of the same flow arrive -> the BR process those in service blades (not in-line). > While service blade is processing the fragments (reassembling them), another non-fragmented packet of the same flow arrives on the BR. > This packet is processed in-line and sent out before the previously received fragments are reassembled in service blade. > Now the BR has caused packet re-ordering. > Why is this, according to RFC 6145) acceptable? > > Any feedback appreciated. > Kris > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From kristian.poscic@alcatel-lucent.com Sun Mar 31 05:48:05 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157E121F8496; Sun, 31 Mar 2013 05:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHsnDgsK9s1k; Sun, 31 Mar 2013 05:48:04 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 44FF921F845D; Sun, 31 Mar 2013 05:48:04 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r2VCm2eO014977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 31 Mar 2013 07:48:02 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r2VCm25U014225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 31 Mar 2013 08:48:02 -0400 Received: from US70UWXCHMBA06.zam.alcatel-lucent.com ([169.254.11.15]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Sun, 31 Mar 2013 08:48:02 -0400 From: "Poscic, Kristian (Kristian)" To: Brian E Carpenter Thread-Topic: [BEHAVE] packet reordering in MAP Thread-Index: Ac4uB4uRFRGCdwgZTzy7vxCW8THBdQAJ4/sAAAhXG0A= Date: Sun, 31 Mar 2013 12:48:01 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AA9B924@US70UWXCHMBA06.zam.alcatel-lucent.com> References: <7921F977B17D5B49B8DCC955A339D2F02AA9B897@US70UWXCHMBA06.zam.alcatel-lucent.com> <51582FD6.9060503@gmail.com> In-Reply-To: <51582FD6.9060503@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "softwires@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] packet reordering in MAP X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 12:48:05 -0000 T2ssIHRoaXMgaXMgZXhhY3RseSB3aGF0IEkgd2FzIGxvb2tpbmcgZm9yLiBMZXQgbWUgdGFrZSBh IGxvb2sgYXQgdGhpcy4gVGhhbmtzIQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21d IA0KU2VudDogU3VuZGF5LCBNYXJjaCAzMSwgMjAxMyA1OjQ1IEFNDQpUbzogUG9zY2ljLCBLcmlz dGlhbiAoS3Jpc3RpYW4pDQpDYzogYmVoYXZlQGlldGYub3JnOyBzb2Z0d2lyZXNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbQkVIQVZFXSBwYWNrZXQgcmVvcmRlcmluZyBpbiBNQVANCg0KSGF2ZSBh IGxvb2sgYXQgc2VjdGlvbiAzLjEuOCBpbiBSRkMgNjI1MCwgYW5kIHRoZXJlIGlzIGEgcmVmZXJl bmNlOg0KQmVubmV0dCwgSi4sIFBhcnRyaWRnZSwgQy4sIGFuZCBOLiBTaGVjdG1hbiwgIlBhY2tl dCByZW9yZGVyaW5nIGlzIG5vdCBwYXRob2xvZ2ljYWwgbmV0d29yayBiZWhhdmlvciIsIElFRUUv QUNNIFRyYW5zYWN0aW9ucyBvbiBOZXR3b3JraW5nLCBWb2wuIDcsIE5vLiA2LCBEZWNlbWJlciAx OTk5Lg0KDQpBIFVEUCBhcHBsaWNhdGlvbiB0aGF0IGNhbm5vdCB0b2xlcmF0ZSByZW9yZGVyaW5n IGlzIGJyb2tlbi4NCg0KU2luY2UgdGhlIEludGVybmV0IGRvZXMgbm90IGFuZCBjYW5ub3QgZ3Vh cmFudGVlIHRoZSBvcmRlciBvZiBkZWxpdmVyeSwgSSB0aGluayB0aGUgU0hPVUxEIGlzIGFwcHJv cHJpYXRlLg0KDQpGb3IgZXhhbXBsZSwgaWYgYSB0cmFuc2xhdG9yIGlzIGFsbW9zdCBvdXQgb2Yg bWVtb3J5LCBzdXJlbHkgaXQgaXMgYmV0dGVyIHRvIHNlbmQgYSBwYWNrZXQgb3V0IG9mIG9yZGVy IHRoYW4gdG8gZHJvcCBpdD8NCg0KICAgQnJpYW4NCg0KT24gMzEvMDMvMjAxMyAxMzoyMSwgUG9z Y2ljLCBLcmlzdGlhbiAoS3Jpc3RpYW4pIHdyb3RlOg0KPiBDYW4gc29tZW9uZSBzaGFyZSBzb21l IGhpc3RvcnkgYW5kIHJlc2VhcmNoIGJhY2tlZCBkYXRhIGJlaGluZCB0aGlzIHN0YXRlbWVudCBh dCB0aGUgdmVyeSBib3R0b20gb2Ygc2VjdGlvbiA0IGluIFJGQyA2MTQ1IChJUC9JQ01QIFRyYW5z bGF0aW9uIEFsZ29yaXRobSkuDQo+IA0KPiBUaGUgdHJhbnNsYXRvciBTSE9VTEQgbWFrZSBzdXJl IHRoYXQgdGhlIHBhY2tldHMgYmVsb25naW5nIHRvIHRoZQ0KPiAgICBzYW1lIGZsb3cgbGVhdmUg dGhlIHRyYW5zbGF0b3IgaW4gdGhlIHNhbWUgb3JkZXIgaW4gd2hpY2ggdGhleQ0KPiAgICBhcnJp dmVkLg0KPiANCj4gSSdtIHdvbmRlcmluZyB3aHkgd291bGQgYmUgYWNjZXB0YWJsZSBmb3IgYSBi b3ggdG8gcmVvcmRlciBwYWNrZXRzIG9mIHRoZSBzYW1lIGZsb3cgKFNIT1VMRCB2cyBNVVNUKT8N Cj4gDQo+IFdoaWxlIFRDUCBjYW4gY29wZSB3aXRoIHJlb3JkZXJpbmcgd2VsbCAoc2VxIG51bWJl cnMgcGx1cyBUQ1AgaGFzIE1TUyBtZWNoYW5pc20gdG8gYXZvaWQgZnJhZ21lbnRhdGlvbiBhbGwg dG9nZXRoZXIgaWYgdGhlIG5vZGVzIGluIHRoZSBwYXRoIGFsc28gc3VwcG9ydCBNU1MpLCBJIHdv dWxkIHRoaW5rIHRoYXQgKGF0IGxlYXN0IHNvbWUpICBhcHBzIHVzaW5nIFVEUCB0cmFuc3BvcnQg d291bGQgbm90IHRvbGVyYXRlIHBhY2tldCByZW9yZGVyaW5nLg0KPiBTbyBJIHdhcyBob3Bpbmcg dGhhdCBzb21lb25lIGNhbiBvZmZlciBzb21lIHJlZmVyZW5jZXMgb2YgcmVhbCByZXNlYXJjaCBi YWNrZWQgZGF0YSByYXRoZXIgdGhhbiBvcGluaW9ucyAgKEkgd291bGQgbGlrZSB0byBoZXIgb3Bp bmlvbnMgYXMgd2VsbCBidXQgdGhleSBvZnRlbiBkaWZmZXIpLg0KPiBFdmVuIGlmIHlvdSBoYXZl IEVDTVAgaW4gdGhlIG5ldHdvcmsgYW5kIGlmIGFsbCB0aGUgbm9kZXMgaW4gdGhlIGVuZC10by1l bmQgcGF0aCBhcmUgcGVyZm9ybWluZyBwZXIgZmxvdyBsb2FkIGJhbGFuY2luZyBvdmVyIEVDTVAg bGlua3MgKHdoaWNoIHNob3VsZCBiZSB0aGUgbm9ybSksIHBhY2tldCByZW9yZGVyaW5nIHNob3Vs ZCBub3QgaGFwcGVuLg0KPiBJZiBub2RlcyBhcmUgcGVyZm9ybWluZyBwZXItcGFja2V0IGxvYWQg YmFsYW5jaW5nIG92ZXIgRUNNUCBsaW5rcyB0aGVuIHBhY2tldCByZW9yZGVyaW5nIGNhbiBvY2N1 ciBidXQgSSB3b3VsZCBjb25zaWRlciB0aGlzIGJhZCBwcmFjdGljZSAoSSBrbm93IHRoYXQgc29t ZSBvbGQgcGxhdGZvcm1zIHdvdWxkIGRvIHBlciBwYWNrZXQgbG9hZCBiYWxhbmNpbmcgb24gRUNN UCBsaW5rcyB0aG91Z2gpLg0KPiANCj4gVGhlIHJlYXNvbiBJIGFzayB0aGlzIGlzIGluIHRoZSBj b250ZXh0IG9mIGltcGxlbWVudGluZyBmcmFnbWVudGF0aW9uL3JlYXNzZW1ibHkgZm9yIE1BUC1F L1QgKGFsdGhvdWdoIHRoZSBpc3N1ZSBleHRlbmRzIGJleW9uZCBNQVApLg0KPiBGb3IgZXhhbXBs ZSBpbiBkaXN0cmlidXRlZCBwbGF0Zm9ybXMgaXQgd291bGQgbWFrZSBzZW5zZSB0byBpbXBsZW1l bnQgTUFQIHRyYW5zbGF0aW9uIGZ1bmN0aW9uIGluLWxpbmUgKGluIHRoZSBmb3J3YXJkaW5nIGNh cmRzKSBidXQgdGhlIHJlYXNzZW1ibHkgZnVuY3Rpb24gaW4gdGhlIHNlcnZpY2UgY2FyZHMgc2lu Y2UgdGhlIHJlYXNzZW1ibHkgZnVuY3Rpb24gYWRkcyBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgYW5k IGJ1ZmZlcmluZyByZXF1aXJlbWVudHMgKEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBmcmFnbWVudGVk IHRyYWZmaWMgaXMgc21hbGwgcGVyY2VudGFnZSBvZiBhbGwgdHJhZmZpYywgYnV0IHN0aWxsLi4u KS4NCj4gTGV0IHNheSB0aGF0IGEgdjYgcGFja2V0IGFycml2ZXMgdG8gYSBCUiAoZnJvbSB0aGUg Q1BFKS4NCj4gVGhlIEJSIHdpbGwgcHJvY2VzcyB0aGlzIHBhY2tldCBpbi1saW5lIGFuZCBzZW5k IGl0IG91dCBhcyB2NC4NCj4gVGhlbiBhbm90aGVyIG51bWJlciBvZiBmcmFnbWVudGVkIHBhY2tl dHMgb2YgdGhlIHNhbWUgZmxvdyBhcnJpdmUgLT4gdGhlIEJSIHByb2Nlc3MgdGhvc2UgaW4gc2Vy dmljZSBibGFkZXMgKG5vdCBpbi1saW5lKS4NCj4gV2hpbGUgc2VydmljZSBibGFkZSBpcyBwcm9j ZXNzaW5nIHRoZSBmcmFnbWVudHMgKHJlYXNzZW1ibGluZyB0aGVtKSwgYW5vdGhlciBub24tZnJh Z21lbnRlZCBwYWNrZXQgb2YgdGhlIHNhbWUgZmxvdyBhcnJpdmVzIG9uIHRoZSBCUi4NCj4gVGhp cyBwYWNrZXQgaXMgcHJvY2Vzc2VkIGluLWxpbmUgYW5kIHNlbnQgb3V0IGJlZm9yZSB0aGUgcHJl dmlvdXNseSByZWNlaXZlZCBmcmFnbWVudHMgYXJlIHJlYXNzZW1ibGVkIGluIHNlcnZpY2UgYmxh ZGUuDQo+IE5vdyB0aGUgQlIgaGFzIGNhdXNlZCBwYWNrZXQgcmUtb3JkZXJpbmcuDQo+IFdoeSBp cyB0aGlzLCBhY2NvcmRpbmcgdG8gUkZDIDYxNDUpIGFjY2VwdGFibGU/DQo+IA0KPiBBbnkgZmVl ZGJhY2sgYXBwcmVjaWF0ZWQuDQo+IEtyaXMNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IC0tDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBCZWhhdmUgbWFpbGluZyBsaXN0DQo+IEJlaGF2ZUBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2ZQ0K From Ted.Lemon@nominum.com Sun Mar 31 06:30:41 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD0D21F87B7; Sun, 31 Mar 2013 06:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-mw6IEvBy5A; Sun, 31 Mar 2013 06:30:40 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 67F0D21F85C9; Sun, 31 Mar 2013 06:30:40 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUVg6gA8hWjrFXi5bfI+Wo3nIYCLSwiGG@postini.com; Sun, 31 Mar 2013 06:30:40 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4EE24128240; Sun, 31 Mar 2013 06:30:38 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D93E519005C; Sun, 31 Mar 2013 06:30:38 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 31 Mar 2013 06:30:38 -0700 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [Softwires] [BEHAVE] packet reordering in MAP Thread-Index: Ac4uB4uRFRGCdwgZTzy7vxCW8THBdQAQLU4AAAGW9IA= Date: Sun, 31 Mar 2013 13:30:39 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775129E38@mbx-01.win.nominum.com> References: <7921F977B17D5B49B8DCC955A339D2F02AA9B897@US70UWXCHMBA06.zam.alcatel-lucent.com> <51582FD6.9060503@gmail.com> In-Reply-To: <51582FD6.9060503@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <6A465DDD2FCAC543AC3C1EDC5D1F05B0@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "Poscic, Kristian \(Kristian\)" , "behave@ietf.org" Subject: Re: [BEHAVE] [Softwires] packet reordering in MAP X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 13:30:41 -0000 On Mar 31, 2013, at 8:45 AM, Brian E Carpenter wrote: > For example, if a translator is almost out of memory, surely it is > better to send a packet out of order than to drop it? Almost surely it is already too late to fix the brokenness that began when = the translator allowed its buffer to get so full. The internet is *suppos= ed* to drop packets in the face of congestion! (Sorry, I realize that's off-topic, but I couldn't let this pass unremarked= .) From brian.e.carpenter@gmail.com Sun Mar 31 07:51:33 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0770521F857E; Sun, 31 Mar 2013 07:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.614 X-Spam-Level: X-Spam-Status: No, score=-99.614 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqSo7VTytHyl; Sun, 31 Mar 2013 07:51:32 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2B02F21F8564; Sun, 31 Mar 2013 07:51:31 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id hi18so974016wib.9 for ; Sun, 31 Mar 2013 07:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OfBYkKj6hCtUVPIfPgD5nypvL51IN856sc32W8b2iKA=; b=E7GVTLB6Gjg/pHNLVonVqNZ9GIrjgbsBBmHUX7pYmmD3nGgK6eejbTyA/kWCnPy/zB Vj0XBAuhdPR7Jojxv25uWLd7SG8yAcFXvmdA+VREOhYHBFjfsomOPCEU+srchHjrTX/q vuP1DsqGRuZdJgFWERouwb2whiIsyoLMDo+ey3F7dKZGzJLYxYnI7uLlxckfKz6XEJly ivucvkYUmo/BVxPdJYZtcBwgfiyzoVO47AFHGmnCx4WvClbzmEUb1Rrkf3xHDVwqFHtm QK0tuzYDTcaPuljMPpi+lGET5h0cEQ+1Iq+Cq/YPMHoMzSvKG61WUYudtFevKpjoiddU saYw== X-Received: by 10.180.182.36 with SMTP id eb4mr6100312wic.8.1364741491347; Sun, 31 Mar 2013 07:51:31 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-177.as13285.net. [2.102.218.177]) by mx.google.com with ESMTPS id fg6sm9605430wib.10.2013.03.31.07.51.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Mar 2013 07:51:30 -0700 (PDT) Message-ID: <51584D70.8010103@gmail.com> Date: Sun, 31 Mar 2013 15:51:28 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <7921F977B17D5B49B8DCC955A339D2F02AA9B897@US70UWXCHMBA06.zam.alcatel-lucent.com> <51582FD6.9060503@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775129E38@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775129E38@mbx-01.win.nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" , "Poscic, Kristian \(Kristian\)" , "behave@ietf.org" Subject: Re: [BEHAVE] [Softwires] packet reordering in MAP X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 14:51:33 -0000 Ted On 31/03/2013 14:30, Ted Lemon wrote: > On Mar 31, 2013, at 8:45 AM, Brian E Carpenter wrote: >> For example, if a translator is almost out of memory, surely it is >> better to send a packet out of order than to drop it? > > Almost surely it is already too late to fix the brokenness that began when the translator allowed its buffer to get so full. The internet is *supposed* to drop packets in the face of congestion! > > (Sorry, I realize that's off-topic, but I couldn't let this pass unremarked.) Yes, there is certainly an interesting question about the trade-offs between reordering and drops under congestion, but as far as this spec goes, the point is that both can happen anyway, so imposing a MUST would be unreasonable. Brian From Ted.Lemon@nominum.com Sun Mar 31 07:56:15 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAC021F85C0; Sun, 31 Mar 2013 07:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apL-z0-21Hqa; Sun, 31 Mar 2013 07:56:14 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id ADD4221F85B8; Sun, 31 Mar 2013 07:56:14 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUVhOjm25H+krVHNyJNdh/GK3eePLC1PR@postini.com; Sun, 31 Mar 2013 07:56:14 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4ACE2128279; Sun, 31 Mar 2013 07:56:14 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2B6B819005C; Sun, 31 Mar 2013 07:56:14 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 31 Mar 2013 07:56:08 -0700 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [Softwires] [BEHAVE] packet reordering in MAP Thread-Index: Ac4uB4uRFRGCdwgZTzy7vxCW8THBdQAQLU4AAAGW9IAAAtJCAAAAKgYA Date: Sun, 31 Mar 2013 14:56:08 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775129FF6@mbx-01.win.nominum.com> References: <7921F977B17D5B49B8DCC955A339D2F02AA9B897@US70UWXCHMBA06.zam.alcatel-lucent.com> <51582FD6.9060503@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775129E38@mbx-01.win.nominum.com> <51584D70.8010103@gmail.com> In-Reply-To: <51584D70.8010103@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <83B2ECE492DBBC4DA793B10F525D7247@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "Poscic, Kristian \(Kristian\)" , "behave@ietf.org" Subject: Re: [BEHAVE] [Softwires] packet reordering in MAP X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 14:56:15 -0000 On Mar 31, 2013, at 10:51 AM, Brian E Carpenter wrote: > Yes, there is certainly an interesting question about the trade-offs betw= een > reordering and drops under congestion, but as far as this spec goes, the = point > is that both can happen anyway, so imposing a MUST would be unreasonable. Indeed so.