Re: Comments on raft-fz-6man-ipv6-alt-mark-01

Ole Troan <otroan@employees.org> Tue, 05 November 2019 09:04 UTC

Return-Path: <otroan@employees.org>
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 31B6C1208E4 for <ipv6@ietfa.amsl.com>; Tue, 5 Nov 2019 01:04:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 C4L_XZkysafk for <ipv6@ietfa.amsl.com>; Tue, 5 Nov 2019 01:04:36 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A6B12086B for <ipv6@ietf.org>; Tue, 5 Nov 2019 01:04:36 -0800 (PST)
Received: from astfgl.hanazo.no (unknown [IPv6:2a02:2121:283:c860:d12a:cf:e287:3e7f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 5BE364E11A76; Tue, 5 Nov 2019 09:04:35 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id 7E5522194B5C; Tue, 5 Nov 2019 10:04:17 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: Comments on raft-fz-6man-ipv6-alt-mark-01
From: Ole Troan <otroan@employees.org>
In-Reply-To: <BBA82579FD347748BEADC4C445EA0F21BF07AD37@NKGEML515-MBX.china.huawei.com>
Date: Tue, 5 Nov 2019 10:04:17 +0100
Cc: Tom Herbert <tom@herbertland.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2CB663DC-8D8B-4CCE-BBF0-2F2CBDEB2E2D@employees.org>
References: <CALx6S35298CHBJsSs3LGY_0Pp2_eW-dQFCbQ6SLQneoQ5U=_yQ@mail.gmail.com> <FE11E326-43C2-409C-864E-62AD8B893050@employees.org> <BBA82579FD347748BEADC4C445EA0F21BF07ACE4@NKGEML515-MBX.china.huawei.com> <B5464B84-1105-4133-8E77-09FF739D8D38@employees.org> <BBA82579FD347748BEADC4C445EA0F21BF07AD37@NKGEML515-MBX.china.huawei.com>
To: Tianran Zhou <zhoutianran@huawei.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_7hmwv0s59Zu22ggxlno_-S2cPk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 05 Nov 2019 09:04:41 -0000

Tianran,

> Yes, I know 8200 considered and changed the way to process the HBH.
> Do you mean the following words?
> NOTE: While [RFC2460] required that all nodes must examine and
> process the Hop-by-Hop Options header, it is now expected that nodes
> along a packet's delivery path only examine and process the
> Hop-by-Hop Options header if explicitly configured to do so.
> 
> From this I am always confused. We can decide/configure whether to process the HBH. But we cannot decide whether it's processed in fast path or slow path. I think this is one issue raised by the reference
> https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03
> Do I miss some other words in 8200?

Right, HBH processing by a router now has to be explicitly configured.
E.g. if a router didn't support alt mark, it would be no purpose in even parsing the HBH header (unless other options also was configured and supported).

You can of course not control how efficient that implementation implements your option...

> In addition, we did test many asics and devices. They will direct packet to the slow path.
> In addition, in real deployment, there are legacy devices that follow RFC2460.
> 
> So our idea is to show alternative options for potential environment. 

Sure, and this was discussed a lot in the context of the other RFC.

Hiding the per-hop options inside of destination options, would have pretty bad performance characteristics I would expect.

For HBH a router needs to:
if ipv6->nh == 0
   walk HBH TLVs and process them

For DestOpt a router would need to:
walk EH chain looking for DestOpt:
  walk DestOpt TLVs and make a guess which one is for in-flight versus destination

Using HBH you use a mechanism engineered for it, using DestOpt you are in middlebox territory. And you will be much more likely to end up conflicting with host functions.

Best regards,
Ole

PS: If you would do a EH performance testing project at the Singapore hackathon I would be all supportive.