Re: [ippm] [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
Shwetha Bhandari <shwetha.bhandari@thoughtspot.com> Wed, 04 May 2022 04:32 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 688BBC157B34 for <ippm@ietfa.amsl.com>; Tue, 3 May 2022 21:32:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.993
X-Spam-Level:
X-Spam-Status: No, score=-1.993 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thoughtspot.com header.b=r4twbM3L; dkim=pass (2048-bit key) header.d=thoughtspot-com.20210112.gappssmtp.com header.b=cIGoZAgw
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 HaD46bjU4bRc for <ippm@ietfa.amsl.com>; Tue, 3 May 2022 21:32:56 -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 98914C157B5B for <ippm@ietf.org>; Tue, 3 May 2022 21:32:55 -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 2440CdRh019443 for <ippm@ietf.org>; Tue, 3 May 2022 21:32:54 -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=L2LFaPoczPSEbcOAvxwgZdjBCw21rNylFBl2oSlhX9o=; b=r4twbM3LosLl09fKCpatcavcthMDl5DA7R0MJKRUQamqNXmdujuUPfTZsk+XQUYx6ZNX PtMY1dnKEnBIEsip+bo0CgYR+q7D6jNAK9a2ZrlFvWAFqY9OZ/Q6FScrGO8QhRWBQvw6 9WgriEfYA/q1s7sPqmugKEPgJ9yZKvbatZaH3wPV/gZmmkeOlNZtLiLfwoWuvHcro1IF SnvImeBNCuDUoQO9hfLNTW/ZPS+yqDjEy0FsENEeLJqup1Ch+sApIk/6fHHu/7fjL5ES iSRPg+fXBzExmKaBfTilHcEWbd6yU+LqS35hPacqJfZsFexXQKaDtTs51rrQxia+elaE XQ==
Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by mx0b-0055fe01.pphosted.com (PPS) with ESMTPS id 3fs4kk8php-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <ippm@ietf.org>; Tue, 03 May 2022 21:32:53 -0700
Received: by mail-qt1-f198.google.com with SMTP id m7-20020a05622a118700b002f3860a1611so153203qtk.7 for <ippm@ietf.org>; Tue, 03 May 2022 21:32:53 -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=L2LFaPoczPSEbcOAvxwgZdjBCw21rNylFBl2oSlhX9o=; b=cIGoZAgwYpzx9ESalG/ZmVhGFwVlA1DylkGSzBjq64ivfz2XGVU4OQo8XV4yrxJQy1 LNE1p1HBtS6r4FQnMBdk89npcs3/NQA6MArJlNQnWWSsevT/gB2ZHuVA+4u0A5G5OoJu kUFTysxg40CzZVQNRVMZeZg93s+/lui2MXeMPRfprcztBKUlLvsQgFF1X+C5adkvQPv+ 7Qd1+vR9ozJ3dEQ3BVVkaGlw8Y9Uuc6HIaA5IcXnW1NdxNSpROd1tO1672PS6d0kJ5NK lDZSqC7wxRk5oETEWn91or2XyPNBZ4yflLigNoMtN9aDoppbE3O97DdKLfnG/BUrXztU Pmlg==
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=L2LFaPoczPSEbcOAvxwgZdjBCw21rNylFBl2oSlhX9o=; b=BI3JKSFFXNRKHhFpTOuXqRHbg4VspLfNF7Ml7jRSA/3TQLxw9j31bjHXbAwd9+wKIo MiGkAqFwpt6tE47N7uvoCCsfO/wYVgeNPOBtDUAT5Xs6Kl7vulTHV/kpA0JS81NR0KNX xPdqJ95F7t4yH159tYf1lGlOD8u5euWW8zlffME4BhUs/bGN/XydikJAUFZf3zHJjTyE rawRvZ8HsCtThVoqmh4Cyd+QzcbPek+hMcVdiUF6zoozRpgld3EFtQa86R+VGVlKzmvb dkVJDVNqsbmxEXm18byuzaFck5nYXtEDjStAbZQgkig8giMDwyIIgXcCKZnZGoomLwFH 07qw==
X-Gm-Message-State: AOAM533D522Oj8bkm6FNq5mWS5iF7rkvHXeOBSf7yJMfozCMOfc6A7Ie G+7dZYNkt6IFu18juBtwl2gwrHK+LLBN+unMyLpmGwVcMwpFe3WjmQqjITWuhYKpGjI/Y8ZFKMh hcrqIjvRg23BHO4br3TdS
X-Received: by 2002:ac8:110a:0:b0:2f1:ea84:b84 with SMTP id c10-20020ac8110a000000b002f1ea840b84mr17767124qtj.463.1651638772786; Tue, 03 May 2022 21:32:52 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJzM9l95gHZWUxpWu+kBRN3yDMrhbpKxkNWSREzi2VajAyb9X0meHrUcWXFyHpmwzPG5G57pUIr+1R0PYlo/6uQ=
X-Received: by 2002:ac8:110a:0:b0:2f1:ea84:b84 with SMTP id c10-20020ac8110a000000b002f1ea840b84mr17767110qtj.463.1651638772427; Tue, 03 May 2022 21:32:52 -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>
In-Reply-To: <c7de197d-6e0f-bc13-7798-2ed968efabd3@joelhalpern.com>
From: Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>
Date: Wed, 04 May 2022 10:02:40 +0530
Message-ID: <CAMFZu3Of0SgCdWnnrQ0Jbt6-4+pFMSMPFDeNGkX2vbktGjPR=Q@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="0000000000005404cc05de281e1a"
X-Proofpoint-ORIG-GUID: ayE-SgGXMy18GMxSnnLTVHNdq6Fd10Mi
X-Proofpoint-GUID: ayE-SgGXMy18GMxSnnLTVHNdq6Fd10Mi
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-04_01,2022-05-02_03,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 phishscore=0 priorityscore=1501 spamscore=0 mlxscore=0 mlxlogscore=999 bulkscore=5 adultscore=0 impostorscore=0 clxscore=1015 suspectscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205040028
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/SWOW1KgDA4V1eu-whgpB5gno7-w>
X-Mailman-Approved-At: Wed, 04 May 2022 04:09:39 -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: Wed, 04 May 2022 04:32:59 -0000
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