From nobody Mon Apr 12 13:41:44 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 B3ED43A0B56; Mon, 12 Apr 2021 13:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 FSXrXNrqQuyE; Mon, 12 Apr 2021 13:41:39 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 212503A0B58; Mon, 12 Apr 2021 13:41:39 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id c17so9960899pfn.6; Mon, 12 Apr 2021 13:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=L5gROOGdA1mkcN8qfXl/IH+4UhoHivOC3+bFFTglzS8=; b=jG7FMei/uBljZ0revoWjh+3o+YHxgRdmMDKxAfoNVp3BQ5a1y1d5/xBGHrao3sLUye L9Ci0D5H3hBtrDRX0/fB8Znhg287IfBMRWyE81uD208g/EfkJ0U+5yBHvuRJBGaqqChN yjwZEZJjwJoa0xvWNTKyN6OGXtaihK1dsTqdf241oYnzDFCrL7ktIivKJGBdT5fsllHp S/oOjphDpHjSOxV8QhoM1Txn9we80ZdFoCsQa6JD+jQVwb5YG3VVWl8rkcdXe6QdaAVk T6ETjZLWrWr5tIfE5x4+qY6QfL96DG6mHN49YKunf4QxMDBu2c80kEp/0T+DsrtcW5v+ Qrlg== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=L5gROOGdA1mkcN8qfXl/IH+4UhoHivOC3+bFFTglzS8=; b=UX0y5nZNVGojdwA42nTatpE4eKmK+cL7rsnwrqpaqOVCa4m7hC3nNAF+at/wiaJ00b jpoHSa1OqBlqXP01uBOaYWhcV3nzUUZUTA9ntrTlcWb4Q0dy+FErJfZo6eiU7gyjqUx/ J29XR/M8Y0Qh1mcCfzRGym0gxIvDei+x92gBIDG6Q1SgT1cfVT9nFCPuayonFxK149yq x0xL9w8xoGjsW6xBaf5oJWhk+baXHyPjDzNCFnLkf7D9U41B2JsIOhQBcTpEa3N7SmtN ahYr5v0UI0c8yU/S3J6+rwUWC6pmy6NgpM1V7D3F6o5lj3l5VjrSwp16EETqcNlcmZzV P7JQ== X-Gm-Message-State: AOAM531aL9oFXzOtqdon9PeFGlWmtURFOEuWWaRPmqWtBdPxuE+aQS11 6Cr/42RZkt351LHSW+u6wd8oX8A6AfG0JQ== X-Google-Smtp-Source: ABdhPJw+UQdIDi5f7U3GR+0dj67JkG/Nqu5VFIGVp5cNiXKC0nvCWHcWHRi7Na727Fd40mGsGUPEWg== X-Received: by 2002:a62:cd4d:0:b029:216:8c86:bf5c with SMTP id o74-20020a62cd4d0000b02902168c86bf5cmr25615313pfg.27.1618260097079; Mon, 12 Apr 2021 13:41:37 -0700 (PDT) Received: from [192.168.178.20] ([151.210.131.14]) by smtp.gmail.com with ESMTPSA id jz8sm276308pjb.11.2021.04.12.13.41.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Apr 2021 13:41:36 -0700 (PDT) Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt To: "Ahmed Abdelsalam (ahabdels)" , Ron Bonica , "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> From: Brian E Carpenter Message-ID: Date: Tue, 13 Apr 2021 08:41:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <8BD63262-7C61-4B0C-A988-DA30F4D2AEAF@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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: Mon, 12 Apr 2021 20:41:44 -0000 On 13-Apr-21 04:01, Ahmed Abdelsalam (ahabdels) wrote: > Hi Ron, >=20 > Thanks for reading the draft. I think we agree on the problem statement= =20 >=20 > In our view using a 256-bit HopByHop extension header to encode a 1-bit= flag, is far from efficient. >=20 > Also, as you point out, the proposed update in draft-hinden-6man-hbh-pr= ocessing (which in my view is going in the right direction), limits HBH t= o one single header with one single option. If we encode the flag in a Hb= H option, we won=E2=80=99t be able to use HBH for anything else. >=20 > Structured FL can be used for packet marking while HBH can be used in m= any other use-cases that require more than simple packet marking. But there is no such thing as a structured flow label, because the standa= rd 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 poss= ibly in limited domains. From a glance at my inbox, that has now become t= he main topic of discussion. Brian =20 > Cheers, > Ahmed=20 >=20 > =EF=BB=BF-----Original Message----- > From: Ron Bonica > Date: Friday, 9 April 2021 at 00:13 > To: "6man@ietf.org" <6man@ietf.org>, "draft-filsfils-6man-structured-fl= ow-label@ietf.org" > Subject: RE: I-D Action: draft-filsfils-6man-structured-flow-label-00.t= xt > Resent from: > Resent to: , ahabdels , , , , , > Resent date: Friday, 9 April 2021 at 00:13 >=20 > Clarence, >=20 > Draft-filsfils-6man-structured-flow-label addresses a real problem.= However, it may have issues with regard to backwards compatibility and I= Pv6 extensibility. Each is addressed below. >=20 > Backwards Compatibility > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > In the draft, you divide the flow label into 4 FLC bits and 16 FLE = bits. The 4 FLC bits carry per-packet control information and are not use= d for ECMP load-balancing. The 16 FLE bits are as defined in RFC 6437. >=20 > This raises the issue of backwards compatibility. Many legacy devic= es IPv6 devices use all 20 bits of the flow label as defined in RFC 6437.= As you say in Section 4, this could cause packets belonging to a single= flow to be distributed among multiple paths. So, the degree of packet re= ordering at the ultimate destination node will increase to an unacceptabl= e level. >=20 > IPv6 Extensibility > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >=20 > Over the past decade, there have been several proposals that take t= he following form: >=20 > - An IPv6 source node needs to convey some piece of information to = every node along the packet's delivery path > - Field X in the IPv6 header is longer than it needs to be > - So, we can borrow a few bits from Field X to convey this informat= ion. >=20 > This approach is flawed for the following reasons: >=20 > - It can cause backwards compatibility issues, as described above > - It only works a few times, until there are no more bits to be bor= rowed in the base IPv6 header >=20 > IPv6 includes a Hop-by-hop Options header. It's purpose is to conve= y information from the source node to every node along the packet's deliv= ery path. Sadly, it was implemented badly so that it can be used as a DoS= vector. Therefore, network operators generally filter it. >=20 > A better approach would be: >=20 > - to avoid borrowing bits from the IPv6 header > - to use the HBH Option for its intended purpose >=20 > This will require rehabilitation of the HBH option. Bob Hinden and = Gorry Fairhurst have made a good start towards this goal in draft-hinden-= 6man-hbh-processing. We vendors will also need to get behind the rehabili= tation effort, revising our implementations so that it can no longer be u= sed as a DoS vector. In turn, network operators will also need to get beh= ind the rehabilitation effort. >=20 > While this may not be the path of least resistance, it will contrib= ute to the future extensibility of IPv6. Let's do the right thing. >=20 > = Ron >=20 >=20 >=20 >=20 >=20 > On 17-Mar-21 05:49, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Draft= s directories. > > > > > > Title : Structured Flow Label > > Authors : Clarence Filsfils > > Ahmed Abdelsalam > > Shay Zadok > > Xiaohu Xu > > Weiqiang Cheng > > Daniel Voyer > > Pablo Camarillo Garvia > > Filename : draft-filsfils-6man-structured-flow-label= -00.txt > > Pages : 12 > > Date : 2021-03-16 > > >=20 >=20 > Juniper Business Use Only >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20