From nobody Tue Apr 13 06:04:06 2021 Return-Path: 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 409E13A15A8; Tue, 13 Apr 2021 06:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 KzvDAgCBY0BX; Tue, 13 Apr 2021 06:04:00 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC253A15A4; Tue, 13 Apr 2021 06:04:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4FKQm01KF7z6G9tV; Tue, 13 Apr 2021 06:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1618319040; bh=BJ0wKLyqHjDpwuGbsZ9M0pgTls14SOl595MIzhkd7Qk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=If6tDM4MdsjEpnq6MWD0rjYLtme+9AW20OqNlHLOLX1Iw3ETKOG+5HCCX45xlhTlB 2igVLzQnaS6I3tvLBeBGXx4Ueduii56hlKcLmjGMatymZFuVuY9b1dp/6SSLFn9xLT 4fGEl3La8/pRPIpQxm1xeVX5IkORvLZtixhRQLXQ= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4FKQlz2FG3z6G9tC; Tue, 13 Apr 2021 06:03:58 -0700 (PDT) Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt To: "Ahmed Abdelsalam (ahabdels)" , "6man@ietf.org" <6man@ietf.org>, "draft-filsfils-6man-structured-flow-label@ietf.org" References: <161591339002.5771.1047511172491571607@ietfa.amsl.com> <8BD63262-7C61-4B0C-A988-DA30F4D2AEAF@cisco.com> <29C2D267-BBC9-42D8-AA02-C59415127471@cisco.com> From: "Joel M. Halpern" Message-ID: <11ce2993-3d6d-103b-c43f-f728b0f88729@joelhalpern.com> Date: Tue, 13 Apr 2021 09:03:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <29C2D267-BBC9-42D8-AA02-C59415127471@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 13:04:05 -0000 This requires something more strict than a "limited domain". It requires a limited domain with universal deployment. Otherwise, very strange things are likely to happen. More generally, it just seems a bad idea. It is pretending that this particular extension is so special it should get a resource that does not even exist. Please don't. Joel On 4/13/2021 4:47 AM, Ahmed Abdelsalam (ahabdels) wrote: > Inline [AA] > > -----Original Message----- > From: Brian E Carpenter > Date: Monday, 12 April 2021 at 22:41 > To: ahabdels , Ron Bonica , "6man@ietf.org" <6man@ietf.org>, "draft-filsfils-6man-structured-flow-label@ietf.org" > Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt > > On 13-Apr-21 04:01, Ahmed Abdelsalam (ahabdels) wrote: > > Hi Ron, > > > > Thanks for reading the draft. I think we agree on the problem statement > > > > In our view using a 256-bit HopByHop extension header to encode a 1-bit flag, is far from efficient. > > > > Also, as you point out, the proposed update in draft-hinden-6man-hbh-processing (which in my view is going in the right direction), limits HBH to one single header with one single option. If we encode the flag in a HbH option, we won’t be able to use HBH for anything else. > > > > Structured FL can be used for packet marking while HBH can be used in many other use-cases that require more than simple packet marking. > > But there is no such thing as a structured flow label, because the standard specifies it as a 20-bit pseudo-random value. As my and other replies have shown, the proposal is not a backwards compatible change except possibly in limited domains. From a glance at my inbox, that has now become the main topic of discussion. > > [AA] Brain, Yes. This draft targets limited domain. We highlighted this in Recommended Design section and in next revision we are going to state this at the beginning of the draft. > > Brian > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >