From nobody Fri Apr 9 22:21:15 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 3AF9C3A2314; Fri, 9 Apr 2021 22:21:13 -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=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 2bUuwW6R1aoQ; Fri, 9 Apr 2021 22:21:08 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 65B843A2312; Fri, 9 Apr 2021 22:21:08 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id c17so5591602pfn.6; Fri, 09 Apr 2021 22:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lLXCE0ZiCB9QGj3pbfvKJcbtvn73bE83UjK8rge/zko=; b=d18aPv8UWNMg+9p0szHqXtYQCMFtdXSrtvVr3rOJSx19NzjdIeY8Y6sBHRelrxZMUj yvfFI3rc50v3wmSxqOB+Ahs58Xclv7gVf4eoRlfKRZCrQ/VQH7nRETv3FyzKuTIbDTue Z83YgaQ0+NMTakVf4KGeAuA3S94lFiKqDROBmUopTVM4Yy+mFBIWRebkOXuR5VNY8BRM cwqWnSQAmszZXB+TJtUChts3d7yBL3fi6xVY0Kqb5BBM0BegyrAzhD3lr/zzFqLjyAYJ 9Ay4W/qq2XtUDb7rgei/ZHuOR9BL6ioWc/ZTgkPkeQ0K4lSSPokS7XbKvdReiNh6mNPQ gX6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lLXCE0ZiCB9QGj3pbfvKJcbtvn73bE83UjK8rge/zko=; b=YRjK48dE7K0dmnA9O6i3csa+x9tHwDiPF0VcSisZfg9FtqbxbYC39Br2jnmnllmTkK vf+0vfMvejgesxZQm+LMSCNa8bHQ1AAjam9fpWdht1nBFxmGRR6r/vFBFxlqeVh5qn0A DAtlOrlahYVv+SdOYsWwfLqxvek/sIQ93HsYo5GHcKuZuWHb816yYxPVAeP+SruPSMf1 cI68+2Jy9BPTI8yvfDWEtMvFsg4/845lANJONoeZG9khRCOpljGeKiWlxuM1JwLq8I2S +dC0/0zn3U44BlufdP+sMkUJPcbrrmOgvSqOJJSxCj+ifW4etjDohkYwpd1soAOP5ZYr 77OA== X-Gm-Message-State: AOAM533s62t5vEeTdvo47r8b/KxM4FMkqd/OmYv5XbRSbZhryrHLlxsX zd/707S6fOVXF9+NSlhAgNhKBX1sLDnrTQ== X-Google-Smtp-Source: ABdhPJyF6R1yphBbQkB/nee2k+BGTrG57coHWfezWSbBcW6SmUQtFLjZIlmYSXk+4urauwkA3zAgtw== X-Received: by 2002:a63:e19:: with SMTP id d25mr16645124pgl.24.1618032066533; Fri, 09 Apr 2021 22:21:06 -0700 (PDT) Received: from [192.168.178.20] ([151.210.131.14]) by smtp.gmail.com with ESMTPSA id t184sm4151889pgt.32.2021.04.09.22.21.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Apr 2021 22:21:05 -0700 (PDT) Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt To: Gyan Mishra , Ron Bonica Cc: "draft-filsfils-6man-structured-flow-label@ietf.org" , "6man@ietf.org" <6man@ietf.org> References: <161591339002.5771.1047511172491571607@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <7d320886-12d3-cf38-42ae-50ae0a8f6a4f@gmail.com> Date: Sat, 10 Apr 2021 17:21:03 +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: 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: Sat, 10 Apr 2021 05:21:14 -0000 On 10-Apr-21 16:56, Gyan Mishra wrote: >=20 > RFC 6437 does talk about both stateless 5 tuple hash for uniform load b= alancing as well as stateless flow label for signaling.=C2=A0 The RFC say= s both can be used simultaneously but I don=E2=80=99t see how that=E2=80=99= s possible. If a particular subset of hosts run a protocol that pre-assigns flow labe= ls in some *stateful* way among that set of hosts, they shouldn't disturb= everybody else who follows the RFC. That was the theory, anyway. It's ne= ver been tested to my knowledge. Brian >=20 > In theory if that were possible the flow label could be used for PM tel= emetry but that is not possible as the 20 bits have to be used for statel= ess or stateful but not both simultaneously. >=20 > I believe this draft is an attempt to allow the flow label to serve two= functions simultaneously both stateless ECMP load balancing FLE 16 bits = and stateful 4 bits for PM signaling and monitoring. >=20 > I understand the restructuring of the 20 bits but the major issue is ba= ckwards compatibility. >=20 >=20 > Kind Regards >=20 > Gyan >=20 > On Sat, Apr 10, 2021 at 12:46 AM Gyan Mishra > wrote: >=20 >=20 > +1 to Ron=E2=80=99s comment on backwards compatibility as the prima= ry goal and benefit of RFC 6437 is stateless locally significant uniform = load balancing with 5-tuple hash to generate the 20 bit flow label input = key to a hash function =C2=A0and as Ron pointed out all 20 bits in the fl= ow label are used for the load balancing hash. =C2=A0 >=20 > RFC 6437 uniform per flow load balancing is one of the many benefit= s of migration to IPv6 data plane IPv6 only - SRv6 or SR-MPLSv6 core for = operators. >=20 >=20 > Kind Regards=C2=A0 >=20 > Gyan=C2=A0 >=20 > On Thu, Apr 8, 2021 at 6:13 PM Ron Bonica > wrote: >=20 > Clarence, >=20 > Draft-filsfils-6man-structured-flow-label addresses a real prob= lem. However, it may have issues with regard to backwards compatibility a= nd IPv6 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 > 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= used for ECMP load-balancing. The 16 FLE bits are as defined in RFC 6437= =2E >=20 > This raises the issue of backwards compatibility. Many legacy d= evices IPv6 devices use all 20 bits of the flow label as defined in RFC 6= 437. As you say in=C2=A0 Section 4, this could cause packets belonging to= a single flow to be distributed among multiple paths. So, the degree of = packet reordering at the ultimate destination node will increase to an un= acceptable level. >=20 > IPv6 Extensibility > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Over the past decade, there have been several proposals that ta= ke the 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 info= rmation. >=20 > This approach is flawed for the following reasons: >=20 > - It can cause backwards compatibility issues, as described abo= ve > - It only works a few times, until there are no more bits to be= borrowed in the base IPv6 header >=20 > IPv6 includes a Hop-by-hop Options header. It's purpose is to c= onvey information from the source node to every node along the packet's d= elivery 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-hin= den-6man-hbh-processing. We vendors will also need to get behind the reha= bilitation effort, revising our implementations so that it can no longer = be used as a DoS vector. In turn, network operators will also need to get= behind the rehabilitation effort. >=20 > While this may not be the path of least resistance, it will con= tribute to the future extensibility of IPv6. Let's do the right thing. >=20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ron >=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-D= rafts directories. > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: Structured Flow Label > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Clarence Filsfils > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ahmed Abdelsalam > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Shay Zadok > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Xiaohu Xu > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Weiqiang Cheng > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Daniel Voyer > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pablo Camarillo Garvia > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0= : draft-filsfils-6man-structured-flow-label-00.txt > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 12 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 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 > --=20 >=20 > >=20 > *Gyan Mishra* >=20 > /Network Solutions A//rchitect=C2=A0/ >=20 > /Email gyan.s.mishra@verizon.com = // > / >=20 > /M 301 502-1347 >=20 > / >=20 >=20 > --=20 >=20 > >=20 > *Gyan Mishra* >=20 > /Network Solutions A//rchitect=C2=A0/ >=20 > /Email gyan.s.mishra@verizon.com // > / >=20 > /M 301 502-1347 >=20 > / >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20