Re: [ippm] [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Joel Halpern <jmh@joelhalpern.com> Wed, 04 May 2022 03:53 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065DEC14792F; Tue, 3 May 2022 20:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.854
X-Spam-Level:
X-Spam-Status: No, score=-3.854 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, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-1.857, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 h2_tUas3gJSU; Tue, 3 May 2022 20:53:13 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 40C0CC14F75F; Tue, 3 May 2022 20:53:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4KtNGK01Gqz1pTbY; Tue, 3 May 2022 20:53:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1651636393; bh=iz+a+ghQO+YcP6FjYlGFonfKy+txZebRq6Ik+YXFRNQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Y+H/61R+Os3M5dQixtMeWMTHKrehWrAMQK2vAeWZwhjVTZE8vfKiCEj2CQMX8fk6a fo/2eps2lkXqC3nHkL+6PvvZ5QM8dunHTuM1ht7VmJThHCjmPNW0KvEM24xCWE0b7a f3i2lWs2ejLQEBMmJh/WOpyx4lrDd154m/WYkHjM=
X-Quarantine-ID: <24YQI3FLI9Oz>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.20.80] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4KtNGD5CZ1z1pTZF; Tue, 3 May 2022 20:53:08 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------nLeBmWo45y10E1uiiv466XT0"
Message-ID: <c7de197d-6e0f-bc13-7798-2ed968efabd3@joelhalpern.com>
Date: Tue, 03 May 2022 23:53:07 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1
Content-Language: en-US
To: Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>, Med Boucadair <mohamed.boucadair@orange.com>, James Guichard <james.n.guichard@futurewei.com>, sfc@ietf.org, ippm@ietf.org
References: <MN2PR13MB4206C91446BA5FBBDA69E233D2FF9@MN2PR13MB4206.namprd13.prod.outlook.com> <CAMFZu3N03E-nWYJNik91e+X=gr3s2TVF03ZCM8i02ru4_Q82og@mail.gmail.com> <CA+RyBmWUZcUN2jnpUuyhTmkNpwvh=2prBZDGinWe2v-b3n8+MQ@mail.gmail.com> <CAMFZu3N5+GdFk13oWbi8F1qhgRNsKpSFwza61SG2oeMW9TvaLQ@mail.gmail.com> <525_1649935673_62580539_525_487_2_d0a4949b3d9c4424a0261012c7ce6188@orange.com> <CA+RyBmX3MdqVX5=hEsO+9SMbpXw+enwnm_qb4+-6smqbsTPPwg@mail.gmail.com> <CAMFZu3NZBgKXHrktn04LbwW33S+j+kGG5hx2A+1+jJ8aasCRag@mail.gmail.com> <14665_1651047374_6268FBCD_14665_484_6_addb2a5f712d4307a463d0582cc0a8a0@orange.com> <CAMFZu3O-vEAnrBE6rhuFh_POPD5E2i_bHvdBx=GUjRKxk3AOYw@mail.gmail.com> <3dba81e6-3a42-3643-dc98-a750891d47f5@joelhalpern.com> <CA+RyBmU+o5spc8M_54Voe+4E_A2M+Q2oE6LyJgSN4+=MCtVrcg@mail.gmail.com> <CAMFZu3MxRx5T3XgTJfBoCpgz1pH_4tNKSdk=NJ0DXELgnCRFxw@mail.gmail.com> <1e2f0696-658d-29d4-71f2-b96a3e088f4c@joelhalpern.com> <CAMFZu3McUxjVTrAoT6hOWOQtiWkKg1=vMpznHzTMs-Yha=oHRA@mail.gmail.com>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <CAMFZu3McUxjVTrAoT6hOWOQtiWkKg1=vMpznHzTMs-Yha=oHRA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/uGCTENeRLX54MfmTz0DqATIXqvQ>
Subject: Re: [ippm] [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 May 2022 03:53:18 -0000

If we do not tell the implementors that there can be multiple iOAM 
headers, and how they are required to process them, then some 
implementors will follow logic we do not want.


For example, you have various selective iOAM headers.  So an SFF looks 
at the next header to check for iOAM.  Seems it is iOAM. And then seems 
the content is iOAM it can ignore.  A naive implementation might well 
stop right there and proceed with normal SFF processing.  Since you 
don't want that, just write into the spec what the WG expects.


Yours,

Joel

On 5/3/2022 11:22 PM, Shwetha Bhandari wrote:
> Why do we need to call that out explicitly in this draft? Isn't that 
> part of header processing anyway?
>
> Thanks
> Shwetha
>
> On Wed, May 4, 2022, 6:24 AM Joel Halpern <jmh@joelhalpern.com> wrote:
>
>     Can we have just a sentence or two saying that if there are
>     multiple iOAM options, the SFF must check all of them for
>     relevance and act on all relevant ones?
>
>
>     Yours,
>
>     Joel
>
>     On 5/3/2022 8:26 PM, Shwetha Bhandari wrote:
>>     Hi Greg, Joel,
>>
>>     The purpose of these options are different. Reiterating the use
>>     cases described in the draft-ietf-ippm-ioam-deployment draft :
>>     hop by hop tracing related options are -pre-allocated,
>>     incremental,direct export. The edge-to-edge option is not
>>     collecting trace but metrics at the edge and helps in correlation
>>     e.g sequence number is inserted and used to identify packet loss
>>     rate. The proof-of-transit option is used to prove that the
>>     packet has traversed the check points in the networks.
>>     There is also IOAM namespace that is used to collect specific
>>     data types in trace options and a node can be configured to
>>     process trace options with a specific namespace, this is useful
>>     when we have nodes with varying implementation of trace option
>>     data types defined.
>>     Restricting IOAM option in NSH to a specific number will make it
>>     difficult to deploy. Hence I don't see a need to update the
>>     current draft to add any of this restrictions. Let's use
>>     draft-ietf-ippm-ioam-deployment to understand the use cases and
>>     deployment modes.
>>
>>     Thanks
>>     Shwetha
>>
>>
>>     On Wed, May 4, 2022, 3:01 AM Greg Mirsky <gregimirsky@gmail.com>
>>     wrote:
>>
>>         Hi Joel,
>>         thank you for highlighting this question, I've missed it.
>>
>>         As we've discussed earlier, several IOAM trace options have
>>         been defined:
>>
>>           * pre-allocated
>>           * incremental
>>           * edge-to-edge
>>           * proof-of-transit
>>           * direct export
>>           * hybrid two-step
>>
>>         I cannot find a scenario when using more than one IOAM trace
>>         option that could be beneficial, and useful for an operator.
>>         I think that if there is no use case, then the restricting
>>         number of IOAM trace options used is reasonable and helps
>>         implementors in developing interoperable implementations.
>>
>>         Regards,
>>         Greg
>>
>>         On Mon, May 2, 2022 at 2:42 PM Joel Halpern
>>         <jmh@joelhalpern.com> wrote:
>>
>>             (Sorry, catching up on some emails I missed.)
>>
>>             If we want to allow multiple iOAM headers (up to the WG)
>>             then I think the document needs to be clear on the
>>             meaning.  If there are multiple are all supposed to be
>>             processed, just the top one until something removes it, a
>>             random one of the receivers choice?  (Yes, that last is
>>             unlikely.)
>>
>>             Yours,
>>
>>             Joel
>>
>>             On 4/27/2022 4:44 AM, Shwetha Bhandari wrote:
>>>             Hi Med,
>>>
>>>             Thanks for the confirmation and quick review.
>>>
>>>             On,
>>>
>>>                 This means the new requested TBD_IOAM value will
>>>                 also be a valid next protocol. However, I wonder
>>>                 whether IOAM in IOAM in NSH is really something you
>>>                 want to have. If not, I suggest the text is updated
>>>                 to exclude it from the allowed value in the above
>>>                 excerpt. 
>>>
>>>             Per earlier discussion in this thread, quoting Frank's
>>>             mail here for reference:
>>>
>>>                 In addition, I don’t think that
>>>                 draft-ietf-sfc-ioam-nsh would be the appropriate
>>>                 place to discuss and restrict deployment options.
>>>                 E.g., I’m not sure why we’d want to restrict a
>>>                 deployment to using a single IOAM header only. E.g.,
>>>                 one could think of using different headers for
>>>                 different namespaces or groups of namespaces for
>>>                 operational reasons. IMHO, such a discussion – if we
>>>                 really need it - would belong into
>>>                 draft-ietf-ippm-ioam-deployment, rather than into a
>>>                 draft that defines the encap of IOAM into NSH.
>>>
>>>             I think the text on Next Protocol should be as is. We
>>>             should not add restrictions on number of IOAM headers
>>>             that could be added to the packet.
>>>
>>>             Thanks,
>>>             Shwetha
>>>
>>>
>>>
>>>             On Wed, Apr 27, 2022 at 1:46 PM
>>>             <mohamed.boucadair@orange.com> wrote:
>>>
>>>                 Hi Shwetha, all,
>>>
>>>                 The changes look great. Thanks.
>>>
>>>                 There is one specific point not addressed in
>>>                 previous replies. This is related to this text:
>>>
>>>                       Next Protocol:  8-bit unsigned integer that
>>>                 determines the type of
>>>
>>>                          header following IOAM.  The semantics of
>>>                 this field are
>>>
>>>                          identical to the Next Protocol field in
>>>                 [RFC8300].
>>>
>>>                 This means the new requested TBD_IOAM value will
>>>                 also be a valid next protocol. However, I wonder
>>>                 whether IOAM in IOAM in NSH is really something you
>>>                 want to have. If not, I suggest the text is updated
>>>                 to exclude it from the allowed value in the above
>>>                 excerpt.
>>>
>>>                 Other than that, I think that the draft is ready to
>>>                 move forward.
>>>
>>>                 Cheers,
>>>
>>>                 Med
>>>
>>>                 *De :* Shwetha Bhandari
>>>                 <shwetha.bhandari@thoughtspot.com>
>>>                 *Envoyé :* mercredi 27 avril 2022 10:06
>>>                 *À :* James Guichard
>>>                 <james.n.guichard@futurewei.com>; sfc-chairs@ietf.org
>>>                 *Cc :* BOUCADAIR Mohamed INNOV/NET
>>>                 <mohamed.boucadair@orange.com>; Frank Brockners
>>>                 (fbrockne) <fbrockne=40cisco.com@dmarc.ietf.org>;
>>>                 sfc@ietf.org; ippm@ietf.org; Tal Mizrahi
>>>                 <tal.mizrahi.phd@gmail.com>;
>>>                 draft-ietf-sfc-ioam-nsh@ietf.org; Greg Mirsky
>>>                 <gregimirsky@gmail.com>
>>>                 *Objet :* Re: [sfc] WGLC for
>>>                 https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
>>>                 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!NGDq-VFOnDYhCxrwRIz1KbT5hb_RKKqKigks-nyqK1RKq5UgpwytWb7clzmlN3o0X0XBWL0KnE3aQfL7wrrx5ZezQN_YdhHpnETuWA$>
>>>
>>>                 Dear SFC chairs,
>>>
>>>                 A new version of the draft I-D.ietf-sfc-ioam-nsh has
>>>                 been submitted per the discussion in this thread.
>>>
>>>                 https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-09
>>>                 <https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-09__;!!MZ3Fw45to5uY!NGDq-VFOnDYhCxrwRIz1KbT5hb_RKKqKigks-nyqK1RKq5UgpwytWb7clzmlN3o0X0XBWL0KnE3aQfL7wrrx5ZezQN_YdhFd29kDew$>
>>>
>>>
>>>                 Can we please progress this draft to IESG if there
>>>                 are no further comments?
>>>
>>>                 Thanks,
>>>
>>>                 Shwetha
>>>
>>>                 On Thu, Apr 14, 2022 at 6:41 PM Greg Mirsky
>>>                 <gregimirsky@gmail.com> wrote:
>>>
>>>                     Hi Shwetha,
>>>
>>>                     thank you for the proposed resolution. I agree
>>>                     with Med, direct normative reference to
>>>                     I-D.ietf-sfc-oam-packet seems like the logical
>>>                     conclusion of our discussion of the use of the
>>>                     NSH O bit. Please note that we're referring to
>>>                     I-D.ietf-sfc-oam-packet in the Active SFC OAM
>>>                     draft, e.g.,:
>>>
>>>                         The O bit in NSH MUST be set, according to
>>>                         [I-D.ietf-sfc-oam-packet].
>>>
>>>                     Regards,
>>>
>>>                     Greg
>>>
>>>                     On Thu, Apr 14, 2022 at 4:27 AM
>>>                     <mohamed.boucadair@orange.com> wrote:
>>>
>>>                         Hi Shwetha,
>>>
>>>                         I prefer we go for an explicit reference to
>>>                         I-D.ietf-sfc-oam-packet rather than “any
>>>                         update to RFC8300”. This is consistent with
>>>                         the usage in the other OAM draft.
>>>
>>>                         Thank you.
>>>
>>>                         Cheers,
>>>
>>>                         Med
>>>
>>>                         *De :* Shwetha Bhandari
>>>                         <shwetha.bhandari@thoughtspot.com>
>>>                         *Envoyé :* jeudi 14 avril 2022 12:06
>>>                         *À :* Greg Mirsky <gregimirsky@gmail.com>
>>>                         *Cc :* BOUCADAIR Mohamed INNOV/NET
>>>                         <mohamed.boucadair@orange.com>; Frank
>>>                         Brockners (fbrockne)
>>>                         <fbrockne=40cisco.com@dmarc.ietf.org>;
>>>                         sfc-chairs@ietf.org; sfc@ietf.org;
>>>                         ippm@ietf.org; James Guichard
>>>                         <james.n.guichard@futurewei.com>; Tal
>>>                         Mizrahi <tal.mizrahi.phd@gmail.com>;
>>>                         draft-ietf-sfc-ioam-nsh@ietf.org
>>>                         *Objet :* Re: [sfc] WGLC for
>>>                         https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
>>>                         <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!LWQuxxxKpUum5gUoK44-znjehj2YRtlGMOATxfRVSc-7JOrPsk4BA4iP0oLQE4d0rObPhOCG_1iiipywftwMIMOEWh8lJI4$>
>>>
>>>                         Hi Med, Greg,
>>>
>>>                         How about this text :
>>>
>>>                         “The O-bit MUST be handled following the
>>>                         rules in and any updates to [RFC8300] ."
>>>
>>>                         Given that I-D.ietf-sfc-oam-packet will
>>>                         update RF8300 and there could be others in
>>>                         future?
>>>
>>>                         Thanks,
>>>
>>>                         Shwetha
>>>
>>>                         On Tue, Apr 12, 2022 at 9:24 PM Greg Mirsky
>>>                         <gregimirsky@gmail.com> wrote:
>>>
>>>                             Hi Shwetha,
>>>
>>>                             I believe that the text you've quoted is
>>>                             helpful. I would suggest changing
>>>                             references from [RFC8300] to
>>>                             [I-D.ietf-sfc-oam-packet] throughout
>>>                             that paragraph.
>>>
>>>                             Regards,
>>>
>>>                             Greg
>>>
>>>                             On Tue, Apr 12, 2022 at 7:56 AM Shwetha
>>>                             Bhandari
>>>                             <shwetha.bhandari@thoughtspot.com> wrote:
>>>
>>>                                 Med,
>>>
>>>                                 Thanks for the details: this is
>>>                                 exactly what we had before the
>>>                                 latest revision:
>>>
>>>                                 *4.2
>>>                                 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-06*section-4.2__;Iw!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpJPfzrvI$>. 
>>>                                 IOAM and the use of the NSH O-bit*
>>>
>>>                                    [RFC8300] defines an "O bit" for
>>>                                 OAM packets.  Per [RFC8300
>>>                                 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8300__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpEB5AbbE$>]
>>>                                 the O
>>>
>>>                                    bit must be set for OAM packets
>>>                                 and must not be set for non-OAM
>>>
>>>                                    packets.  Packets with IOAM data
>>>                                 included MUST follow this
>>>
>>>                                    definition, i.e. the O bit MUST
>>>                                 NOT be set for regular customer
>>>
>>>                                    traffic which also carries IOAM
>>>                                 data and the O bit MUST be set for
>>>
>>>                                    OAM packets which carry only IOAM
>>>                                 data without any regular data
>>>
>>>                                    payload.
>>>
>>>                                 This was removed as per the
>>>                                 discussion in this thread. Please
>>>                                 check
>>>                                 https://mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/
>>>                                 <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIp-CeLfeA$>
>>>
>>>                                 It looks like we are going in a loop
>>>                                 here. This definition of SFC OAM
>>>                                 packet to include the OAM data that
>>>                                 comes in inner packets via the next
>>>                                 protocol header chain is introduced
>>>                                 in draft-ietf-sfc-oam-packet to
>>>                                 update the RFC8300.
>>>
>>>                                 Jim, What are you thoughts on this?
>>>                                 Should we reintroduce the above text ?
>>>
>>>                                 Thanks,
>>>                                 Shwetha
>>>
>>>                         _________________________________________________________________________________________________________________________
>>>
>>>                           
>>>
>>>                         Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>>
>>>                         pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>>
>>>                         a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>>
>>>                         Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>
>>>                           
>>>
>>>                         This message and its attachments may contain confidential or privileged information that may be protected by law;
>>>
>>>                         they should not be distributed, used or copied without authorisation.
>>>
>>>                         If you have received this email in error, please notify the sender and delete this message and its attachments.
>>>
>>>                         As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>>
>>>                         Thank you.
>>>
>>>                 _________________________________________________________________________________________________________________________
>>>
>>>                 Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>>                 pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>>                 a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>>                 Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>
>>>                 This message and its attachments may contain confidential or privileged information that may be protected by law;
>>>                 they should not be distributed, used or copied without authorisation.
>>>                 If you have received this email in error, please notify the sender and delete this message and its attachments.
>>>                 As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>>                 Thank you.
>>>
>>             _______________________________________________
>>             ippm mailing list
>>             ippm@ietf.org
>>             https://www.ietf.org/mailman/listinfo/ippm
>>             <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!MZ3Fw45to5uY!KzP7tEXj2r_E1qNyQ90q9rykJ0iG0HA0CecIGBFXEIXiWITYay7wwoC0HbiFfO2GyUarxht3JEY45vcV4uCtZ8Xkud0uv58$>
>>