From nobody Fri Apr 9 22:05:41 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 0985F3A2287; Fri, 9 Apr 2021 22:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 ORoOKGx95l1L; Fri, 9 Apr 2021 22:05:35 -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 D63623A2286; Fri, 9 Apr 2021 22:05:34 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id b26so430778pfr.3; Fri, 09 Apr 2021 22:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=FLxBDtraAlHsZWSmPvUVLXBudU+UxJAx1bayxElneGU=; b=TQs9OGsAGHhHosfovrB/cteT9sGwIuVPw9yfcODT/UNOVt3BgQvWCqwdB/p7goSBW2 AwQKW83UcMYE6YnhPbQfeughQ3QIjogtfixa3iI35nieFIePoN/CCM2xQTbUG8jj1o5r e2JMT0+tRdoqYrh0wsRJqXBsJEotShNhmsFPST5nThD2aJiy0axdXceZjkKAoEcKtw+V SCDhJWRF6DJg9TtKoF8/v9IEKlSJLYEZLYkVzGAfjNhByOeJ5iqInAdINZ00UjuIBV7L QqDRLdIesrBM95CRsrJNUxL3iVot5Fi6mxrWrmtmZO9H+fKPVTIvAoTAjbW/HHrDBWfV MRZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=FLxBDtraAlHsZWSmPvUVLXBudU+UxJAx1bayxElneGU=; b=YUzHKkHbmkizTT/ZbMOfehfR8xm3h2BvwR4lHmn7Wg5NDyYYoYhEfqW+lRyMcUbRw4 6qubr39ddE4mb1UaG97NJGRhjNqpqvzKRGR7Db8fK4zmmjPLcIBExON0+zc9dzn+DHDL M8+56ikH/xkD5Hb6P/sS/WLefH5vFQtY7zDpjLg/pVg49iDOFvGSvfNE5a8OdQii2ZsQ VHjR7fDC6zS2j/lPci84ZF83nIYIh9xp3ZTeZgZuAoEePBq+gfu1bh6w5lTnNfUDWnjI /NsLP0pb0bTg440DphqMO1OQ4IZxoLxZ4Dp7E9ZCefYosGMauKdqK1MzWruSpeDOfZ4b aQpA== X-Gm-Message-State: AOAM531J/ipo1jeSnL39Jk7FtnL5z1ge9UKX3yir3VLsn8/ZPFrw3R9P dSfZe5Ch0aSGZMUARVVuSOrm3nLelpg= X-Google-Smtp-Source: ABdhPJyzYwoLZnBb3k3XwoDdGQq3uxytFoBnVReSXNyhUh1sZNf70Lo6L1hth0EufHUukFAK6tWvjQ== X-Received: by 2002:a05:6a00:174a:b029:1fc:d9ba:da96 with SMTP id j10-20020a056a00174ab02901fcd9bada96mr15567248pfc.40.1618031132452; Fri, 09 Apr 2021 22:05:32 -0700 (PDT) Received: from [192.168.1.5] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id y189sm3600262pfy.8.2021.04.09.22.05.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Apr 2021 22:05:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jeff Tantsura Mime-Version: 1.0 (1.0) Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt Date: Fri, 9 Apr 2021 22:05:30 -0700 Message-Id: <8B0FA4BB-5D0D-424B-8416-95A22517369A@gmail.com> References: Cc: Brian E Carpenter , Ron Bonica , draft-filsfils-6man-structured-flow-label@ietf.org, 6MAN <6man@ietf.org> In-Reply-To: To: Tom Herbert X-Mailer: iPhone Mail (18D70) 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:05:39 -0000 Thanks Tom, exactly my point. Regards, Jeff > On Apr 9, 2021, at 21:38, Tom Herbert wrote: >=20 > =EF=BB=BFOn Fri, Apr 9, 2021 at 9:22 PM Jeff Tantsura wrote: >>=20 >> To my memory, around 2015 Tom Herbert submitted a kernel patch that would= change flow label based on RTO, and this has been successfully used for =E2= =80=9Cself healing fabrics=E2=80=9D in large DCs to rebalance flows. Since e= very piece of silicon in DC that takes flow label into consideration when ha= shing the traffic uses full 20 bits - repurposing part of it would break it= . >> This and similar solutions would need to be addressed. >=20 > Jeff, >=20 > Yes, flow labels are commonly set by all the major OSes now, all > twenty bits are used, and there are deployed intermediate nodes that > act on those bts. The opportunity to repurpose flow label bits is long > gone, and it probably wouldn't even work in a limited domain. The best > direction is a HBH option. >=20 > Tom >=20 >>=20 >> Regards, >> Jeff >>=20 >>>> On Apr 9, 2021, at 20:39, Brian E Carpenter wrote: >>>=20 >>> =EF=BB=BFOn 09-Apr-21 10:12, Ron Bonica wrote: >>>> Clarence, >>>>=20 >>>> Draft-filsfils-6man-structured-flow-label addresses a real problem. How= ever, it may have issues with regard to backwards compatibility and IPv6 ext= ensibility. 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 E= CMP load-balancing. The 16 FLE bits are as defined in RFC 6437. >>>>=20 >>>> This raises the issue of backwards compatibility. Many legacy devices I= Pv6 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 b= e distributed among multiple paths. So, the degree of packet reordering at t= he ultimate destination node will increase to an unacceptable level. >>>=20 >>> And the use of the flow label for server-farm load balancing will be com= pletely broken. That's why this idea is a non-starter outside a limited doma= in. >>>=20 >>> Brian >>>=20 >>>>=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 take the f= ollowing form: >>>>=20 >>>> - An IPv6 source node needs to convey some piece of information to ever= y 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 information.= >>>>=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 borrowe= d in the base IPv6 header >>>>=20 >>>> IPv6 includes a Hop-by-hop Options header. It's purpose is to convey in= formation from the source node to every node along the packet's delivery pat= h. Sadly, it was implemented badly so that it can be used as a DoS vector. T= herefore, 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 Gorr= y Fairhurst have made a good start towards this goal in draft-hinden-6man-hb= h-processing. We vendors will also need to get behind the rehabilitation eff= ort, revising our implementations so that it can no longer be used as a DoS v= ector. In turn, network operators will also need to get behind the rehabilit= ation effort. >>>>=20 >>>> While this may not be the path of least resistance, it will contribute t= o 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: >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>>>=20 >>>>>=20 >>>>> 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 >>>>=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 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> --------------------------------------------------------------------