IETF Logo Mail Archive

Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 02 December 2017 19:11 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8EA124BFA for <ipv6@ietfa.amsl.com>; Sat, 2 Dec 2017 11:11:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tzXtnZYAOMv1 for <ipv6@ietfa.amsl.com>; Sat, 2 Dec 2017 11:11:49 -0800 (PST)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F680120727 for <ipv6@ietf.org>; Sat, 2 Dec 2017 11:11:49 -0800 (PST)
Received: by mail-pg0-x22a.google.com with SMTP id f12so5882382pgo.5 for <ipv6@ietf.org>; Sat, 02 Dec 2017 11:11:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=abhr3wlBo1h9WuQy255rTMCV+7Eauq3CtLidlWQelW0=; b=uKCse4sq6sU0fQaeq6y5hn1jfg2RhvXg6JShYrtcTGHB8bDG/PBIjfoqBHYP+5yRxO FpO5ZJb0TtkOwSO+kgoK5Be3jAwvXwtLjlIp/HBftaSBzu32rj/1cR8ofhKmZiMzmuGA Jq3pCQJOcLtbqjah2jZ7Oc3EkjzU5mUk+YiGEActP71v9YDrsZQTvfNhuZXu8+TF7Rc1 Tn6tFRiVwM/SpU5D1bOOlETG0RVhBkhq4hA5uJeuMbcr/fxwveAOpQuP+1C+6vZmmUoe v7DsrnzdhO5qG921k3Nm/khBcNmNqD5izdPgioVW01fyJjmZwOvgdcLvSG6Y5SywUGPK LO4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=abhr3wlBo1h9WuQy255rTMCV+7Eauq3CtLidlWQelW0=; b=eUyl/aph9tatn/gfYRIgWxSjmGP55YSzdzeYzk1c4mY4X9TExt1NSftPe3inC3OX7O K/oII/uMouVNycmT4v1DhEk1tLcpqKqHjFppv0hGbTNZvoKUttUWDPZAntuTex0v9bxl EBUNyfmcj3eIRP5H56/5nYoqNKLC/uftQ4JvRVvfQUJPwLTXGH0LNaLnxZrhMXRLvNrZ TBggv0jRBJjkTW2/zstBr9f+Tz47YY8Lr/QlT+rP7fyDd9sV8IoRGFwNx0YUfya2JDeV wkdrN2btKav5ldGd+sGKqA6ckRrUZjhkrC9kG/TB5KoR89Ki5X1y88vjtSUYvy7yoXW9 Rplg==
X-Gm-Message-State: AJaThX7gQyLQrhr8vc/ylIcq7MlXKboSeDBrvEt4nA8KwkRaUvvK/hVN kbEnZB5oiuZscUfOM5PueLCOPA==
X-Google-Smtp-Source: AGs4zMa3MFodxber0mEgTMft1k9zztaIX7cBwuk5laZL4CKXyd18SxZ2aSWOV8DrrXS9KYfwS3NYcg==
X-Received: by 10.98.252.7 with SMTP id e7mr14359229pfh.12.1512241908352; Sat, 02 Dec 2017 11:11:48 -0800 (PST)
Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w184sm15107019pgb.36.2017.12.02.11.11.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Dec 2017 11:11:47 -0800 (PST)
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Stefano Salsano <stefano.salsano@uniroma2.it>
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <f4425076-2f76-5713-2819-9d26671d56bb@si6networks.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <bc9d7f57-8687-7f85-8ac3-49751683232b@si6networks.com> <CA+b+ERnKbRXgFycgKd7EXMVvS1Mu_RTC5tfPbNE781TDZ49rYA@mail.gmail.com> <CAO42Z2wWSucKNouo0RxNf7pmyPErNk1bVny43qTLY6E333mpcQ@mail.gmail.com> <e41ee3ae-05ef-0a1a-505e-968323b07625@gmail.com> <CAO42Z2x2-WFyxYKpcwtm_z4WiFFf1M5oiW2=j6fXnqgUG1F8DQ@mail.gmail.com> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Cc: ipv6@ietf.org
Message-ID: <aa1e5d0c-479a-9d0b-10e7-9adfe994a23b@gmail.com>
Date: Sun, 03 Dec 2017 08:11:42 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/T_W2QJ4285d-WZVq-LCAnNrrIs0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Dec 2017 19:11:50 -0000

Stefano,
On 02/12/2017 20:15, Stefano Salsano wrote:
...
> We think that for further operations that require adding of SRH 
> information to such packets originating in your SR domain, the SR 
> insertion is more efficient than tunnelling into a new packet.
> 
> This is both from the point of view of the packet size (and increase of 
> packet headers size) and from the point of view of the cost of packet 
> manipulation operations.

This surprises me. I've had discussions with hardware designers (FPGA
in particular, I think) who seriously hate the IPv6 extension header
design on the grounds of the complexity and cost of manipulating the
header chain at line speed. I can imagine that with a specifcally designed
network processor, this might be less of an issue, but is the market
big enough to support such an NP design?

In any case it seems that the main issue is the need for linked-list
operations to handle a header chain, and that is simpler if
the new packet is

<new header><new EH><old header><old EH chain><payload>

compared to

<old header><head of old EH chain><new EH><tail of old EH chain><payload>

since there is no need to walk, break, and re-link the old header chain.
These days, sticking an extra 40 bytes on the front seems unimportant
compared with the linked list operations.

   Brian

v2.23.0 | Report a Bug | By Email