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

Joel Halpern <jmh@joelhalpern.com> Thu, 19 May 2022 13:00 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DEEC14F75F; Thu, 19 May 2022 06:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
X-Spam-Status: No, score=-3.851 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 AJ4aJkOxRIO0; Thu, 19 May 2022 06:00:08 -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 81F8EC14F726; Thu, 19 May 2022 06:00:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4L3qhS1QJtz1ntrZ; Thu, 19 May 2022 06:00:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1652965208; bh=ALl2X7hF9bwzRuVJd9ffNh1X9LkaUpfWBgdFLbDsx1Q=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=P5WdbYAqw0dR4k3jq+Vm5aEwoZ4QVI8m23+PkazjzYYnMkQZvzlRC1kUQCUNYs4vs W+vehXfDBrT8Kt2qqp30pB06Lfiaa1OdLZICUN5UzQiHlO01Icdn5BEKfUhgHEVem/ msZLq7LlPej2P5KkNyqufzTixgcdHSTR2PRA24/4=
X-Quarantine-ID: <nS8ZznP2L9xo>
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 4L3qhQ1wX1z1pVtM; Thu, 19 May 2022 06:00:06 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------PYYG6LYnMBzwG6zCdWer6Grh"
Message-ID: <03388407-6329-c223-4d25-4b630c2b6ba2@joelhalpern.com>
Date: Thu, 19 May 2022 09:00:03 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
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> <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> <c7de197d-6e0f-bc13-7798-2ed968efabd3@joelhalpern.com> <CAMFZu3Of0SgCdWnnrQ0Jbt6-4+pFMSMPFDeNGkX2vbktGjPR=Q@mail.gmail.com> <CAMFZu3P-1aHJg3J3k4+UnZ5G3ZsPjKx16Ogs2zK=6qcbJ1kWCg@mail.gmail.com>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <CAMFZu3P-1aHJg3J3k4+UnZ5G3ZsPjKx16Ogs2zK=6qcbJ1kWCg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/9jFTZrVbJjBpOPC02f3UB-hZbSk>
Subject: Re: [sfc] [ippm] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 May 2022 13:00:12 -0000

Thank you Shwetha.  That looks good.  Jim and I will be working on 
moving things forward.

Yours,

Joel

On 5/19/2022 12:47 AM, Shwetha Bhandari wrote:
> Hi Joel,
>
> We have published a -10 version of the draft based on this discussion. 
> Please check
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-10.txt and 
> let us know if it is ready to progress for IESG review.
>
> Thanks,
> Shwetha
>
> On Wed, May 4, 2022 at 10:02 AM Shwetha Bhandari 
> <shwetha.bhandari@thoughtspot.com> wrote:
>
>     Ack, will add text to this effect.
>
>     Thanks
>     Shwetha
>
>     On Wed, May 4, 2022, 9:23 AM Joel Halpern <jmh@joelhalpern.com> wrote:
>
>         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$>
>>>