Re: [v6ops] Stephen Farrell's No Objection on draft-ietf-v6ops-siit-dc-03: (with COMMENT)

Tore Anderson <tore@fud.no> Mon, 19 October 2015 06:13 UTC

Return-Path: <tore@fud.no>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C931A1A68; Sun, 18 Oct 2015 23:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naxUXGY3j2YY; Sun, 18 Oct 2015 23:13:42 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A7B1A1A15; Sun, 18 Oct 2015 23:13:42 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=43440 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <tore@fud.no>) id 1Zo3hS-0002PJ-Vp; Mon, 19 Oct 2015 08:13:38 +0200
Date: Mon, 19 Oct 2015 08:13:38 +0200
From: Tore Anderson <tore@fud.no>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <20151019081338.20f33b8c@echo.ms.redpill-linpro.com>
In-Reply-To: <20151015133232.9056.27955.idtracker@ietfa.amsl.com>
References: <20151015133232.9056.27955.idtracker@ietfa.amsl.com>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/zi8RrS3avZQY2vce_0Ybs0Ku0kc>
Cc: v6ops@ietf.org, draft-ietf-v6ops-siit-dc@ietf.org, v6ops-chairs@ietf.org, The IESG <iesg@ietf.org>, fred.baker@cisco.com
Subject: Re: [v6ops] Stephen Farrell's No Objection on draft-ietf-v6ops-siit-dc-03: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 19 Oct 2015 06:13:43 -0000

* "Stephen Farrell" <stephen.farrell@cs.tcd.ie>

> Stephen Farrell has entered the following ballot position for
> draft-ietf-v6ops-siit-dc-03: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> I would have thought that the BR and ER would be new targets
> for DoS attack, however, I'm not sure those are really
> different in this respect compared to other existing routers
> in a data centre - did the wg consider if there are any such
> differences that are worth noting? (I thought about it for 2
> minutes, without finding any;-)

Hello Stephen,

The scalability characteristics of an BR/ER is indeed more similar to
that of a traditional IP router. This is due to them operating in a
completely stateless mode, handling one packet at a time, and
forgetting everything about it immediately after.

A stateless translator does not contain any flow tracking table, so the
number of concurrent flows (and the flow initiation rate) is
irrelevant. This is mentioned briefly in section 1.2.

I hope that answers your comment.

Tore