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
>>
>
>