IETF Logo Mail Archive

Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

joel jaeggli <joelja@bogus.com> Thu, 18 October 2012 07:12 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF0921F857D for <v6ops@ietfa.amsl.com>; Thu, 18 Oct 2012 00:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.367
X-Spam-Level:
X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7Wg9t4xRa1s for <v6ops@ietfa.amsl.com>; Thu, 18 Oct 2012 00:12:27 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0F021F84F5 for <v6ops@ietf.org>; Thu, 18 Oct 2012 00:12:27 -0700 (PDT)
Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q9I7CQKc059990 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 18 Oct 2012 07:12:26 GMT (envelope-from joelja@bogus.com)
Message-ID: <507FABDA.7060106@bogus.com>
Date: Thu, 18 Oct 2012 00:12:26 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121002 Thunderbird/16.0
MIME-Version: 1.0
To: "C. M. Heard" <heard@pobox.com>
References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3A2@XCH-NW-01V.nw.nos.boeing.com> <507DA6A3.20807@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3C3@XCH-NW-01V.nw.nos.boeing.com> <507DAB13.2010704@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3CE@XCH-NW-01V.nw.nos.boeing.com> <507DDF8A.9010607@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF5AB@XCH-NW-01V.nw.nos.boeing.com> <BB219517-B488-4777-AE9C-35C57BE91263@kumari.net> <Pine.LNX.4.64.1210171337470.7337@shell4.bayarea.net>
In-Reply-To: <Pine.LNX.4.64.1210171337470.7337@shell4.bayarea.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 18 Oct 2012 07:12:27 +0000 (UTC)
Cc: V6 Ops <v6ops@ietf.org>
Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Oct 2012 07:12:27 -0000

On 10/17/12 1:58 PM, C. M. Heard wrote:
> On Wed, 17 Oct 2012, Warren Kumari wrote:
>> On Oct 16, 2012, at 7:19 PM, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
>>> I have been informed by individuals working for major network
>>> equipment vendors that their implementations can handle router
>>> reassembly.
>> "can handle router reassembly" != "can handle router reassembly at
>> line rate on multiple interfaces".
>>
>> You really need this to be line rate on all interfaces, otherwise
>> there is (obviously) a DoS vector here.  Reassembly at 10G (or
>> 100G) is distinctly non-trivial and requires A: large buffers, B:
>> short timeouts, C: gets sad if not all bits go through the same
>> device, D: state and E: hardware designed specifically for this.
>> This is much more than packet comes in, packet goes out...
> Excuse me, maybe I'm as dumb as a post, but .... why in the world
> are participants in this thread posing this as problem for the core?
The fact that  high capacity requirements exsit does not imply that it a 
problem for the core.

v2.23.0 | Report a Bug | By Email