Re: [Idr] //Re: Status changes as of 6/21/2022
Robert Raszuk <robert@raszuk.net> Thu, 23 June 2022 21:35 UTC
Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F2AC15A72B for <idr@ietfa.amsl.com>; Thu, 23 Jun 2022 14:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qn04kckZqy7e for <idr@ietfa.amsl.com>; Thu, 23 Jun 2022 14:35:33 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 9A912C15A72A for <idr@ietf.org>; Thu, 23 Jun 2022 14:35:33 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id c65so809218edf.4 for <idr@ietf.org>; Thu, 23 Jun 2022 14:35:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SxzD0mMZs060zWv+lNoGIoNvock7EnAhNfxYoalCbqM=; b=S8fQ3l/y4ZkvoX2t6lRlPUKPP+pK8LdbkOFiWzMOgL2rVQtbQReTtYKkRB1eyzxWF9 WB0NCJl+TVob74PIXFg5lg+B1q5zDj0UX8ep1KTPj3MKcqC+RCIggkdE5CzjyD6hzy8m wJKrQa8+XRhk988FJU7NJ2kLvdPEz8dq87xmUvkig19hwVdjM7foAjZ0pe6uQBPQYg19 2k/uh0rHiVyKu5BxhLt14ihXb3YnfNsSeYK0xI26ve58KWWuYeEiI34gEh/RSW3x0K4e nCaBd5RH6vf+DLCaP1rXVQLPCR9YA/o8lvslqs2/PLxva8bnoIwmc2qd6tmvTZj0ocvh 5jRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SxzD0mMZs060zWv+lNoGIoNvock7EnAhNfxYoalCbqM=; b=lMasyxIpeb0ndTjSW6T6lu11H7t364Kztp4fY0hTSBV/GqvnC7T7MxRauZv8Iv3gJU 4ozO2QN1QW8VDcPWvsN4d3uNnhqvX6sYWZaZeppLZMz612E2gPqqyoitfY9SvKWKhRW8 nI+Pln1iC4LlOuy3XiXhS3E8kXOTFS1OIt67r6aTlVeRYTOQGQ354wh4UtZhxmSBAzDs MZzm/F9KEHTksvGE+fqyIzcP3AI+3OC06aWrLYQjSyuyWLirGbKVu9MpxuCTDVZGJfQO ZcCNrnFnp9gt4HM1aotgrIQ+u5H5GGlW1W510SyBK6ie9+CE4fiSHQteJ2AuVNc3baP8 aI1g==
X-Gm-Message-State: AJIora8osCgJZYYbP5QSPrlvghOO6CVwyyae4/Hg8ySTqcFPklC48Woy r3Zkcwv3y0bUMbgzKUGXW08c0W+UNU+mkF/9bXskzA==
X-Google-Smtp-Source: AGRyM1vt1ezvdDCOHQIYnXYSroVElh4+vBlIOl9R/RWfSBRqn3A91l0eh908GoayY+M74+KMhVe08+U4BBgAey+upfI=
X-Received: by 2002:a05:6402:2682:b0:42e:1c85:7ddc with SMTP id w2-20020a056402268200b0042e1c857ddcmr13062222edd.143.1656020131294; Thu, 23 Jun 2022 14:35:31 -0700 (PDT)
MIME-Version: 1.0
References: <2afb62b3c6aa924-00008.Richmail.00009090468066689577@chinamobile.com> <20220623193006.GA12085@pfrc.org> <CAOj+MMEZjBePJg-aHkrh_eoMNrVBQrPjfy+6_cddf_ihvON60g@mail.gmail.com> <0E6CEF37-0269-470A-A9C0-08378913EFDE@pfrc.org>
In-Reply-To: <0E6CEF37-0269-470A-A9C0-08378913EFDE@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 23 Jun 2022 23:35:20 +0200
Message-ID: <CAOj+MMGHCBLnkZOW5dhXa1gLhCJvS2FjhsTTiNU0kZqpxq2ThA@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: 姜文颖 <jiangwenying@chinamobile.com>, Sue Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000aac12705e2243bff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/vMhfFQp7CdSyPSZC1rdbOfYnaIM>
Subject: Re: [Idr] //Re: Status changes as of 6/21/2022
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jun 2022 21:35:37 -0000
Hey Jeff, > discusses how forwarding interactions stack together and start becoming tricky to reconcile. Indeed ... and as we see here such interactions are already a possibility. One can only be scared of what is going to happen when we add v2 to the mix :) - - - With that - while out of the topic - one sentence caught my attention: "The code points for Flowspec v1 and v2 are likely to be the same." Not 100% clear on what you meant by "are likely" .. If you mean *reusing* codes in v2 which are already defined in v1 then this has some pros and many cons. But perhaps you meant that v2 may just *use* currently defined codes (in v1) not that we will define them again in v2 with the same code points. Kind regards, R. On Thu, Jun 23, 2022 at 11:19 PM Jeffrey Haas <jhaas@pfrc.org> wrote: > Robert, > > Thanks for catching my error. I should know better than to do such > replies without a quick re-read of the document in question. I had > confused this with another of our many flowspec proposals we have in flight. > > While I agree with you that this is one of the proposals that doesn't have > to wait on flowspec v2 (yay!) it's also a good example of a document that > discusses how forwarding interactions stack together and start becoming > tricky to reconcile. We'll probably have this discussion further in the > "encoding of fsv2 actions" track of that work. > > Wenying, my apologies for any confusion I may have caused. > > -- Jeff > > > On Jun 23, 2022, at 4:05 PM, Robert Raszuk <robert@raszuk.net> wrote: > > Hi Jeff, > > The way I read this proposal they do not require any new code point > allocation to either flowspec v1 or v2. > > They instead took a clever idea to glue new functionality by next hop > using existing redirect-to-ip functionality. > > So the draft is Informational and presents new functionality with no > protocol extension required. > > Also that is confirmed in the draft by either statement: > > For the case that a flowspec route carries multiple Color Extend > Communities and/or a BGP Prefix SID Attribute, a protocol extension > to Flowspec is required, and is thus out of the scope of this > document. > > & > > 6. IANA Considerations > No IANA actions are required for this document. > > So I am not sure what potential squating you are referring to here. > > Many thx, > Robert > > PS . > > I do think some rewrite is needed to make the text more clear. For example > statements like this: > > This document proposes to carry the Color Extended Community and BGP > Prefix-SID Attribute* in the context of a Flowspec NLRI *[RFC8955] > [RFC8956] to an SRv6 Headend to steer traffic into one SRv6 policy, > as well as to indicate specific Tailend functions. > > need to be reworded as they indeed make an illusion that new code points > may be used. > While if I understand what authors meant to propose was to say instead "in > the same UPDATE > message" not within the NLRI itself. > > > On Thu, Jun 23, 2022 at 9:30 PM Jeffrey Haas <jhaas@pfrc.org> wrote: > >> Wenying, >> >> Glad to hear you're having good experiences with work on your draft. >> >> However, please remember two things as you take your work forward: >> - New features implemented in Flowspec v1 will cause session resets in >> implementations that don't understand the new feature. >> - Please don't ship code that squats on an unallocated code point. Not >> only >> does this raise issues of session resets, but may cause issues as we >> start >> having Flowspec v2 work make progress. The code points for Flowspec v1 >> and >> v2 are likely to be the same. >> >> The IDR Chairs would encourage you to support moving Flowspec v2 work >> forward to help you safely and interoperably deploy the new feature. >> >> -- Jeff >> >> On Thu, Jun 23, 2022 at 09:51:57AM +0800, 姜文颖 wrote: >> > >> > >> > Hi Sue and WG, >> > >> > >> > >> > draft-jiang-idr-ts-flowspec-srv6-policy has been presented at >> IETF#108/109/113 and got good feedback from WG. It has also been >> implemented by multiple vendors and successfully passed the joint >> interoperability test hosted by China Mobile. We co-authors think that it >> is ready for WG adoption call. Would you please consider adding this >> document to the awaiting list of the adoption calls? >> > >> > >> > >> > Thanks, >> > >> > Wenying and co-authors >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > >
- [Idr] //Re: Status changes as of 6/21/2022 姜文颖
- Re: [Idr] //Re: Status changes as of 6/21/2022 Susan Hares
- Re: [Idr] //Re: Status changes as of 6/21/2022 Jeffrey Haas
- Re: [Idr] //Re: Status changes as of 6/21/2022 Robert Raszuk
- Re: [Idr] //Re: Status changes as of 6/21/2022 Jeffrey Haas
- Re: [Idr] //Re: Status changes as of 6/21/2022 Robert Raszuk
- Re: [Idr] //Re: Status changes as of 6/21/2022 Jeffrey Haas
- Re: [Idr] //Re: Status changes as of 6/21/2022 Zhuangshunwan
- Re: [Idr] //Re: Status changes as of 6/21/2022 Shawn Zhang
- Re: [Idr] //Re: Status changes as of 6/21/2022 Susan Hares