From nobody Wed Apr 14 22:30:58 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 6C90E3A0BB1; Wed, 14 Apr 2021 22:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 w_tLN4IzxRgq; Wed, 14 Apr 2021 22:30:51 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 189853A0BB9; Wed, 14 Apr 2021 22:30:48 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id w8so11828949pfn.9; Wed, 14 Apr 2021 22:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JsJDNGCxQR9TKeGR8eSKZ5w/eLjjfhtOHKER4Uzffyc=; b=TyEY55TkqSj8AI1gyJnDEST1K9v2PSLT+0GnMd4NwQKR5/PSxkZ2qPKXZgCyhqL0QR 8gv06//sXSik+KX6CHXLTDwONp1oS9TPekkZ0Z2Yot1ZdqW9fHhGv1bL8h3yto1yH26J n68l9aDmhH4lIMDavZkRXHWSB/Izp9BC8A1MerbLUd0YrABG5ERiGpGIeS0cbVlU+uT/ qHHRK7Td4b/M5D+jTdgRHAyc3jGszExUXWTs14e9X7mDpvvBTxh2P043I/kro6dMuqW6 oZy6xTr1l8/RYGN7oQlKU6ME41jmMFSLOhbKcHKVPFADQ8i+ilnnJ1pDTMsO9IJNpaon yWog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JsJDNGCxQR9TKeGR8eSKZ5w/eLjjfhtOHKER4Uzffyc=; b=tGMAy77i/O7z2TOqDMMPyfMyRTJQwL/0gZr6FTaFvdZFSxqx7orcddE1qwtHf5htO/ 82jpEYpQ1uTpsAiP/xyvDgIYKOEL3YsCT1rrnKR8DYyLAMiDxBr7pZQepTupfPLcfxJ/ iUkdUnTIYsOCj/DxPHMVJJQHOGyn4Ohw8ES1cv+uycq+mIboSjYUr7NHK+yMQJFnVR2J cTjZLlG1nFur4xibGbPQB7jC0iebZowHfc6Y8C0Y52CwgN7BedT3dU5JfH3T6y75EvXj ZA8pynI0tCHq8Nz4Ljz7s4mTXTYR5LiHFAp6ho2PAfL/x0zYT34CVSJ6vPzYsVOQM1uv VGOg== X-Gm-Message-State: AOAM531UxExr/Gnz+x166fYfKBZ757FLQl4yrrwsL124HtjDPPS2G9a+ I4ySaczZOFSFPvmHIlz+iIyGWlMFaJAyr6TNIdVLlRxqJp1AIw== X-Google-Smtp-Source: ABdhPJyUfpSf40GOq52uFYwgA/0+IxIo/3B6o0OD/iyONyXvpfS364huIX9H/PipS3R7Trpky3nmvNl+hs28/vhDpzo= X-Received: by 2002:aa7:8a47:0:b029:24e:22de:de6a with SMTP id n7-20020aa78a470000b029024e22dede6amr1688258pfa.20.1618464647910; Wed, 14 Apr 2021 22:30:47 -0700 (PDT) MIME-Version: 1.0 References: <161591339002.5771.1047511172491571607@ietfa.amsl.com> <8BD63262-7C61-4B0C-A988-DA30F4D2AEAF@cisco.com> <29C2D267-BBC9-42D8-AA02-C59415127471@cisco.com> <11ce2993-3d6d-103b-c43f-f728b0f88729@joelhalpern.com> In-Reply-To: <11ce2993-3d6d-103b-c43f-f728b0f88729@joelhalpern.com> From: Gyan Mishra Date: Thu, 15 Apr 2021 01:30:37 -0400 Message-ID: Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt To: "Joel M. Halpern" Cc: "6man@ietf.org" <6man@ietf.org>, "Ahmed Abdelsalam (ahabdels)" , "draft-filsfils-6man-structured-flow-label@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006b997005bffc2a0a" 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: Thu, 15 Apr 2021 05:30:57 -0000 --0000000000006b997005bffc2a0a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Tue, Apr 13, 2021 at 9:04 AM Joel M. Halpern wrote= : > 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] > > > > =EF=BB=BF-----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" < > draft-filsfils-6man-structured-flow-label@ietf.org> > > Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.t= xt > > > > 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=E2=80=99t 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 n= ow > 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 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --0000000000006b997005bffc2a0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

+1

On Tue,= Apr 13, 2021 at 9:04 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:
This requires something more strict than a "limited domain&qu= ot;.=C2=A0 It
requires a limited domain with universal deployment.=C2=A0 Otherwise, very =
strange things are likely to happen.

More generally, it just seems a bad idea.=C2=A0 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]
>
> =EF=BB=BF-----Original Message-----
> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> Date: Monday, 12 April 2021 at 22:41
> To: ahabdels <ahabdels@cisco.com>, Ron Bonica <rbonica@juniper.net>, "6man@ietf.org" <6man@ietf.org>, "draft-filsfils-6man-structured-flow-label@ietf.org" &l= t;draft-filsfils-6man-structured-flow-label@ietf.org> > Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.= txt
>
>=C2=A0 =C2=A0 =C2=A0 On 13-Apr-21 04:01, Ahmed Abdelsalam (ahabdels) wr= ote:
>=C2=A0 =C2=A0 =C2=A0 > Hi Ron,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Thanks for reading the draft. I think we agre= e on the problem statement
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > In our view using a 256-bit HopByHop extensio= n header to encode a 1-bit flag, is far from efficient.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Also, as you point out, the proposed update i= n 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 e= ncode the flag in a HbH option, we won=E2=80=99t be able to use HBH for any= thing else.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > 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.
>
>=C2=A0 =C2=A0 =C2=A0 But there is no such thing as a structured flow la= bel, 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 thi= s in Recommended Design section and in next revision we are going to state = this at the beginning of the draft.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Brian
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> -------------------------------------------------------------------- >

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--
--0000000000006b997005bffc2a0a--