Re: [ippm] [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
Shwetha Bhandari <shwetha.bhandari@thoughtspot.com> Thu, 19 May 2022 04:47 UTC
Return-Path: <shwetha.bhandari@thoughtspot.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 3914FC20D71B for <ippm@ietfa.amsl.com>; Wed, 18 May 2022 21:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thoughtspot.com header.b=bdVkd+LN; dkim=pass (2048-bit key) header.d=thoughtspot-com.20210112.gappssmtp.com header.b=rgze0vXo
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 I79Qkx9oH5_h for <ippm@ietfa.amsl.com>; Wed, 18 May 2022 21:47:15 -0700 (PDT)
Received: from mx0b-0055fe01.pphosted.com (mx0b-0055fe01.pphosted.com [205.220.176.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14FABC20D706 for <ippm@ietf.org>; Wed, 18 May 2022 21:47:14 -0700 (PDT)
Received: from pps.filterd (m0211452.ppops.net [127.0.0.1]) by mx0b-0055fe01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 24J2iXNv022902 for <ippm@ietf.org>; Wed, 18 May 2022 21:47:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thoughtspot.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=proofpoint; bh=5gQxdrKJtZa7cUAEq6CmFYwklLbpqsMoD2VN32L7OXY=; b=bdVkd+LNtEUqqACZq08hoPG3hsnsp2UovyeM8ZNND9oB8+trfA0s+b438gTiVUQaZSMs 7GlTIJcve4wl2V+JvXk5AEzH69Sf850V/rR7OYTL0ilyFLlScWRH0hP9n9jakuyg0QS2 5zTms8LlSv5cA8UpmDTBfwFa5ZlVqZqJTO+7CLejX2QVUgIfEWHohce4N2g+5eGfpkGN 8Vi1cCF5wM2d6zHkzRRvzP+IqGGZH5xQs8peQLg6fVAcxMhQK6PE9pdjLsLj/3s2hpzO nSpNnqx953u6L+blvVNKgxTsx4T0WUnDhMbx7l3xPWhjBdmYzA0SaBHLP8fh0po+rMs4 cQ==
Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by mx0b-0055fe01.pphosted.com (PPS) with ESMTPS id 3g5c4f0a82-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <ippm@ietf.org>; Wed, 18 May 2022 21:47:13 -0700
Received: by mail-qt1-f197.google.com with SMTP id d15-20020ac85d8f000000b002f3b3b7e0adso3344759qtx.20 for <ippm@ietf.org>; Wed, 18 May 2022 21:47:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thoughtspot-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5gQxdrKJtZa7cUAEq6CmFYwklLbpqsMoD2VN32L7OXY=; b=rgze0vXoX732okwCbVt5pqC/l03vNQg1m6Z4YWZMPfjA/p6mikuSjGFZOyS7RQPCdt WRelcPCmSEVHsbMx4/8H0r3vBtuMYl+0Q+1JOhfdaXO2OFVIupRRn60/noDr5xF1FFFK 8FwHX0+n9psdWNmtMOK02MhrdYXfoaOFrsB7xYOZXwwUFja+Pu4MC06bmaxCAi1Ofs1L dtHZLOX6y0dpqiJZJxnrGeC5j0kKiPnj+N3aZqXUaT4PPeTXFTc9CFdjTyirAPqQrZeM yzJGKU9XSyyQd7m5fEwrvtCuRhTENbSzMPV67M+kKuUKGx/mDHR42iI0d3YrNfv6TEwJ 7GQQ==
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=5gQxdrKJtZa7cUAEq6CmFYwklLbpqsMoD2VN32L7OXY=; b=KeS5Q+TJXzAEJWWVcx2e52FFTwO3npf8Cj/Lb0Wz9mNajL4SR7/bZzvOybXJIm+sjp YKNz6Qn7Q3FASCkOzEWnpctWXcniiu9HeAYHiyrT6Pnhm9KsFB6025mZwZXfLCiaR6oy eVFYj5U32p5Hhi4JOYjJVZiVKSVgAYFVtch4k4x3mL0ozvlBuDqjfOiup2vTzHyqG4Jh bWvm3Fv2/04csB0y2ROjkdTO9WOS7gxsT6uBwHiTpsCNnTTPvgRHi9xxpdOeF2huHHIp nJpaZyPsC2dD0jU0XF69D4niXGbByv/8WP9P4qBnHEnJk11JVSMdLkkU4nP8vAFk4jG8 uzWg==
X-Gm-Message-State: AOAM5328shs8FniaiVh1wQsa4Ue0Irwqs0ByEfXG8Qzg5EpTVcKcTL0x u9WXbvkMUXETMSyP5XqI9ffcY3KCGkOAOpwzogcW1lRL4PQg6B4fmxqc1hiaU0n9HFfog8b2qGC YF7PvwZ34VwF6jctnVYDz
X-Received: by 2002:ac8:7f04:0:b0:2f3:d6d6:8406 with SMTP id f4-20020ac87f04000000b002f3d6d68406mr2505295qtk.509.1652935632754; Wed, 18 May 2022 21:47:12 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJz7shnaqiM+XNWinLQZqZrgwUGVUi/0FNpJFE7BL5PsKm11PL/HyzjICv/HtrTBNV1QmEmRWuQJCbDu9woRxC8=
X-Received: by 2002:ac8:7f04:0:b0:2f3:d6d6:8406 with SMTP id f4-20020ac87f04000000b002f3d6d68406mr2505284qtk.509.1652935632263; Wed, 18 May 2022 21:47:12 -0700 (PDT)
MIME-Version: 1.0
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> <c7de197d-6e0f-bc13-7798-2ed968efabd3@joelhalpern.com> <CAMFZu3Of0SgCdWnnrQ0Jbt6-4+pFMSMPFDeNGkX2vbktGjPR=Q@mail.gmail.com>
In-Reply-To: <CAMFZu3Of0SgCdWnnrQ0Jbt6-4+pFMSMPFDeNGkX2vbktGjPR=Q@mail.gmail.com>
From: Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>
Date: Thu, 19 May 2022 10:17:01 +0530
Message-ID: <CAMFZu3P-1aHJg3J3k4+UnZ5G3ZsPjKx16Ogs2zK=6qcbJ1kWCg@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.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
Content-Type: multipart/alternative; boundary="00000000000032b73d05df5611b8"
X-Proofpoint-GUID: i1vIfETnycDdiNQL_LodkTLZJ8IT9ntk
X-Proofpoint-ORIG-GUID: i1vIfETnycDdiNQL_LodkTLZJ8IT9ntk
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-18_09,2022-05-17_02,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 bulkscore=5 phishscore=0 mlxlogscore=999 adultscore=0 priorityscore=1501 spamscore=0 lowpriorityscore=0 impostorscore=0 suspectscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205190030
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/0b5C5SCeQXPHBtpudoVXvDOAMiA>
X-Mailman-Approved-At: Thu, 19 May 2022 09:52:52 -0700
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: Thu, 19 May 2022 04:47:19 -0000
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$> >>>>> >>>>
- 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