RE: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Thu, 21 October 2021 13:49 UTC

Return-Path: <giuseppe.fioccola@huawei.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 0F2B83A16F0; Thu, 21 Oct 2021 06:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 hKWDFMHYpzRe; Thu, 21 Oct 2021 06:49:26 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02213A16BB; Thu, 21 Oct 2021 06:49:26 -0700 (PDT)
Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HZpd95Bpxz6H6pW; Thu, 21 Oct 2021 21:45:01 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Thu, 21 Oct 2021 15:49:18 +0200
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2308.015; Thu, 21 Oct 2021 15:49:18 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Lars Eggert <lars@eggert.org>
CC: "draft-ietf-6man-ipv6-alt-mark@ietf.org" <draft-ietf-6man-ipv6-alt-mark@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, The IESG <iesg@ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>
Subject: RE: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)
Thread-Topic: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)
Thread-Index: AQHXiqaCe4LS65IPoke4Ve63Qoanj6vN2QKAgAA/jFCAAGp1gIAARPXQgADPTgCAAD81MIAOF+TQ
Date: Thu, 21 Oct 2021 13:49:18 +0000
Message-ID: <c4c389d3716f4caeb990fde406364f62@huawei.com>
References: <162824256748.9012.15703111505505730185@ietfa.amsl.com> <5A3DB972-AC12-40A2-970D-1846F916AD6E@eggert.org> <c8e1f6518f344594ab962947edda7948@huawei.com> <3402ee98-b072-b862-a55a-44ff9bfa9992@gmail.com> <dedd91aef6cc41ecb61b6a0bd835eb53@huawei.com> <FA0D9A71-49F8-4D48-B82D-C1B3375376F1@eggert.org> <884c9d3f52b7472ca123e056a9030290@huawei.com>
In-Reply-To: <884c9d3f52b7472ca123e056a9030290@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.219.120]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/odnYqWtODFap4tl0I93nHqEK2QY>
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: Thu, 21 Oct 2021 13:49:39 -0000

Hi Lars, All,
Please note that we just published a new revision of the draft. In section 5.3 we have clarified the recommended deployment mode based on matching FlowMonID with source and destination addresses.

Regards,

Giuseppe

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Giuseppe Fioccola
Sent: Tuesday, October 12, 2021 5:57 PM
To: Lars Eggert <lars@eggert.org>
Cc: draft-ietf-6man-ipv6-alt-mark@ietf.org; ipv6@ietf.org; Bob Hinden <bob.hinden@gmail.com>; The IESG <iesg@ietf.org>; 6man-chairs@ietf.org
Subject: RE: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Hi Lars,
Please find my replies inline tagged as [GF].

Regards,

Giuseppe


-----Original Message-----
From: Lars Eggert <lars@eggert.org> 
Sent: Tuesday, October 12, 2021 2:46 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>; draft-ietf-6man-ipv6-alt-mark@ietf.org; Bob Hinden <bob.hinden@gmail.com>; ipv6@ietf.org; The IESG <iesg@ietf.org>; 6man-chairs@ietf.org
Subject: Re: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Hi,

On 2021-10-12, at 1:46, Giuseppe Fioccola <giuseppe.fioccola@huawei.com> wrote:
> 1/1048576 collision rate is ok because you can always use the FlowMonID together with source and destination addresses for possible disambiguation.
> If we do not want to rely on source and destination addresses, 1/1048576 could not be enough. But we can simply define a longer FlowMonID so it can be used alone.
> I have nothing against this option, I'm just saying that source and destination addresses can easily be used together with FlowMonID.

what I am trying to get at is that with a 20-bit FlowMonID, at most ~1M concurrent flows can be tracked, and much less than that with random assignment of FlowMonIDs. That seems insufficient for anything but very small deployments.

[GF]: The requirement of the controlled domain mitigates not only the security concerns but also the probability of FlowMonID collisions, since the option is not spread over the internet. Our practice shows that, for limited domains with a central controller, the 20-bit FlowMonID is enough. However, I agree with you and, generally speaking, the 20-bit FlowMonID alone could not be enough in every scenario.

If there are these two modes of deployment (based on just matching FlowMonIDs and based on matching FlowMonIDs and src/dst addresses), the document should discuss how one would determine which mode to use for a given network, and what the consequences are of choosing an inappropriate one.

Or, the document should simply require a single deployment mode where source and destination IP addresses are always included in the match. This would get you to ~1M concurrent flows per host-pair (with centralized assignment), which seems to support more use cases.

[GF]: I will definitely revise the draft soon and clarify better the deployment mode. In order to support most of the scenarios, the draft will recommend only the mode where source and destination addresses are considered in the match criteria together with the FlowMonID.

You could of course also lengthen the FlowMonID, but then the document should discuss why a given length is suitable for many/most deployment scenarios of interest (in terms of supported concurrent flows), esp. with randomized assignment.

[GF]: The enlargement of the FlowMonID could not be the first choice, especially when the option is used with other extension headers (e.g. SRH) and we need to control the extension header length.

Thanks,
Lars

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------