Re: [ippm] [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
Joel Halpern <jmh@joelhalpern.com> Wed, 04 May 2022 00:54 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 D76F9C159A24; Tue, 3 May 2022 17:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.851
X-Spam-Level:
X-Spam-Status: No, score=-8.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_DNSWL_HI=-5, 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 UDYJ5vffBpDE; Tue, 3 May 2022 17:54:32 -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 D5EC5C159A21; Tue, 3 May 2022 17:54:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4KtJJ73Fnvz1pTZH; Tue, 3 May 2022 17:54:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1651625671; bh=mMEQhj7PL6brhGuOF7TnS9+BtGrORmwBK2NZYUob/bs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ZFya4IRAwBZd0fdE97/erZWlSaK4wbgIiYGU1tCA9JwcFlBjxeT1HcICtEgjU+f4y feZelV4yHYmw76Dy9HC9/qn6H1abPm3WwtGgfcCZvIgmyD5Ymv9NqnhdCCX3aFqdea WDWJx/H0u3TETRQIGqja00V1dMHktnfYWZp8aAT0=
X-Quarantine-ID: <xRBUAqcB6Ocr>
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 4KtJJ54P1nz1pP9p; Tue, 3 May 2022 17:54:28 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------kswudrRDJtP6Fni343Smy0Gq"
Message-ID: <1e2f0696-658d-29d4-71f2-b96a3e088f4c@joelhalpern.com>
Date: Tue, 03 May 2022 20:54:27 -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>, Greg Mirsky <gregimirsky@gmail.com>
Cc: 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> <11111_1649774342_62558F05_11111_493_4_a734de5265ca498bbabf9805a6eaf91d@orange.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>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <CAMFZu3MxRx5T3XgTJfBoCpgz1pH_4tNKSdk=NJ0DXELgnCRFxw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/io7m3zhbWQMOmEuDG9xUO-oycnw>
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 00:54:35 -0000
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$> >
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Frank Brockners (fbrockne)
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Greg Mirsky
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Greg Mirsky
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Frank Brockners (fbrockne)
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Frank Brockners (fbrockne)
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… xiao.min2
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Greg Mirsky
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Joel Halpern
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Greg Mirsky
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Joel Halpern
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Joel Halpern
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Joel Halpern
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari