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

mohamed.boucadair@orange.com Thu, 14 April 2022 12:38 UTC

Return-Path: <mohamed.boucadair@orange.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 CCFCC3A176D; Thu, 14 Apr 2022 05:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.005
X-Spam-Level:
X-Spam-Status: No, score=-2.005 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzyLDlq2dyKb; Thu, 14 Apr 2022 05:38:40 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C273A1767; Thu, 14 Apr 2022 05:38:40 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar21.francetelecom.fr (ESMTP service) with ESMTPS id 4KfJsp705gz7vGk; Thu, 14 Apr 2022 14:38:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1649939919; bh=kqIrHSKZmTWEtTQc/6NwMSTP/WB/k5oeIR2qQQMTpEw=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=WE9bNprAppm+uxA4lKRxqa8q1DPfGIpdL0491Dzg05PceB/Hjph2NRBSf7uBO+/Zw kF0AisZv9dmZwVdbC6QA4oLsLh/Va0NElK2uHa/Jsvh6x3o1rU5pqSfdMlCexD5abQ opM8e0hv49SdAo5N7DtXvf94ZWDa0biLtdSvcgIin2lJ2afFhFonlha2uwftGbBT8D LU73R8PIfkKxU3o5ysIlJN9X2KnjEVPFV1leLQfWzuqo7R528nTg65+xVSWuEIvd7a MAQgotksi4muQsrTfNNGHlCs6rvdngM9aQv8aN63pkyBA0tq09Z6j0InoXrn1TJKQO sStCjnaWC/svA==
From: mohamed.boucadair@orange.com
To: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>, Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>, Greg Mirsky <gregimirsky@gmail.com>
CC: "Frank Brockners (fbrockne)" <fbrockne=40cisco.com@dmarc.ietf.org>, "sfc-chairs@ietf.org" <sfc-chairs@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "ippm@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" <draft-ietf-sfc-ioam-nsh@ietf.org>
Thread-Topic: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
Thread-Index: AdeULBhJRJPqyAEIQoSKEyRZsxugZQQB5uoACahWxgAAGYGKgBL6IjWAAA3JMYAAO7ZbAAAUk9wAAUpazIAAOJK8gAoigVWAABlSwAAACWjsAAAKcnYAAZ7CWpAABhxZEAAA5CIAAAIGRAAAWGucgAAC3sYAAAHiyzAAABl2sAAAQ4XQ
Content-Class:
Date: Thu, 14 Apr 2022 12:38:38 +0000
Message-ID: <25972_1649939918_625815CE_25972_272_1_7403bcdf0f19464a8e6f8e40f7e8048c@orange.com>
References: <MN2PR13MB4206C91446BA5FBBDA69E233D2FF9@MN2PR13MB4206.namprd13.prod.outlook.com> <CA+RyBmVSrdCaO77P4=1vZ2LmxtR65OmspN_wozyGPNwtM5Uv3A@mail.gmail.com> <CAMFZu3PaLQrHcBULzsxbdnTJyr-bVDVs1WpnFwLuSkR7DbntuQ@mail.gmail.com> <CA+RyBmWeUiTsA7-CvpXSBViB00Y-tmAuSr-P=Vf3vB61zfn6bg@mail.gmail.com> <CAMFZu3P45x9Mt5-MUpGO1Puqz57DPcGE4aBsPNxczW-pw9n=AA@mail.gmail.com> <MN2PR13MB42066C22CA66B0E1F0FC3FFFD2269@MN2PR13MB4206.namprd13.prod.outlook.com> <CAMFZu3NO6J-MM_a7TZm+wTzxbKzY5t0OkW8QNLk0673Fkr16RQ@mail.gmail.com> <CA+RyBmVVWdvLZdANV_whtcwwMKVfVpM8VL7BYMM7NTnmooUpcQ@mail.gmail.com> <CAMFZu3PEmrarcsp4tXQsx4eKvai8+UvzKSFxfcakX4LUAcayJA@mail.gmail.com> <MN2PR13MB420615DA403388EA0144A9C1D22F9@MN2PR13MB4206.namprd13.prod.outlook.com> <CAMFZu3MUmuBEDEzdafw2UHEvsTE+7sQ=E1kik5TuQ=_NznFF9w@mail.gmail.com> <CA+RyBmW=ZT0EUmSYYfZJjcapBZ5-pg93um5t287LreONLOVnJQ@mail.gmail.com> <CAMFZu3NCCmj4u75taEzBiMmkMQ0YrmK5KsUToSOKfwX1yBxePA@mail.gmail.com> <26916_1649050778_624A849A_26916_245_1_aa5a0049026247d9980f4ebbc8c5ac0b@orange.com> <CY4PR11MB1672FCF27DA2A4822C6E1B40DAED9@CY4PR11MB1672.namprd11.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> <CY4PR11MB1672C44062B9ABDFBD80C7A9DAEF9@CY4PR11MB1672.namprd11.prod.outlook.com> <CY4PR11MB1672C19416619D29F069C5EDDAEF9@CY4PR11MB1672.namprd11.prod.outlook.com>
In-Reply-To: <CY4PR11MB1672C19416619D29F069C5EDDAEF9@CY4PR11MB1672.namprd11.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-04-14T12:33:56Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=85c80a66-6abc-4569-8cfc-df7db2bcce6d; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.115.26.52]
Content-Type: multipart/alternative; boundary="_000_7403bcdf0f19464a8e6f8e40f7e8048corangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/cbkIqcT_iNLDtA9p4zBc6im2Cos>
X-Mailman-Approved-At: Mon, 18 Apr 2022 08:11:33 -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.29
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, 14 Apr 2022 12:38:46 -0000

Re-,

draft-ietf-sfc-ioam-nsh includes OAM data (likely with user data) but there is an ambiguity in 8300 to whether this is considered as an OAM packet. Please refer to the SFC archives where this was discussed.

Cheers,
Med

De : Frank Brockners (fbrockne) <fbrockne@cisco.com>
Envoyé : jeudi 14 avril 2022 14:29
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>; Greg Mirsky <gregimirsky@gmail.com>
Cc : 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/

Forgot to add: A clause like " The O-bit MUST be handled following the rules in and any updates to [RFC8300]“ simply states the obvious. draft-ietf-sfc-ioam-nsh does not touch or redefine the O-bit – hence the statement is at best optional. The reader might even wonder why the obvious is re-stated in the document. My preference is still to avoid any mentioning of the O-bit in draft-ietf-sfc-ioam-nsh.

Frank

From: Frank Brockners (fbrockne)
Sent: Thursday, 14 April 2022 14:24
To: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; Shwetha Bhandari <shwetha.bhandari@thoughtspot.com<mailto:shwetha.bhandari@thoughtspot.com>>; Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Cc: Frank Brockners (fbrockne) <fbrockne=40cisco.com@dmarc.ietf.org<mailto:fbrockne=40cisco.com@dmarc.ietf.org>>; sfc-chairs@ietf.org<mailto:sfc-chairs@ietf.org>; sfc@ietf.org<mailto:sfc@ietf.org>; ippm@ietf.org<mailto:ippm@ietf.org>; James Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>>; Tal Mizrahi <tal.mizrahi.phd@gmail.com<mailto:tal.mizrahi.phd@gmail.com>>; draft-ietf-sfc-ioam-nsh@ietf.org<mailto:draft-ietf-sfc-ioam-nsh@ietf.org>
Subject: RE: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

IMHO it would be better to refer to directly RFC8300 – since this is a stable reference; and it allows us to finish up draft-ietf-sfc-ioam-nsh and get the code points allocated. I-D.ietf-sfc-oam-packet is early stages and still evolving.

Cheers, Frank

From: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Sent: Thursday, 14 April 2022 13:28
To: Shwetha Bhandari <shwetha.bhandari@thoughtspot.com<mailto:shwetha.bhandari@thoughtspot.com>>; Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Cc: Frank Brockners (fbrockne) <fbrockne=40cisco.com@dmarc.ietf.org<mailto:fbrockne=40cisco.com@dmarc.ietf.org>>; sfc-chairs@ietf.org<mailto:sfc-chairs@ietf.org>; sfc@ietf.org<mailto:sfc@ietf.org>; ippm@ietf.org<mailto:ippm@ietf.org>; James Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>>; Tal Mizrahi <tal.mizrahi.phd@gmail.com<mailto:tal.mizrahi.phd@gmail.com>>; draft-ietf-sfc-ioam-nsh@ietf.org<mailto:draft-ietf-sfc-ioam-nsh@ietf.org>
Subject: RE: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

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<mailto:shwetha.bhandari@thoughtspot.com>>
Envoyé : jeudi 14 avril 2022 12:06
À : Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>; Frank Brockners (fbrockne) <fbrockne=40cisco.com@dmarc.ietf.org<mailto:fbrockne=40cisco.com@dmarc.ietf.org>>; sfc-chairs@ietf.org<mailto:sfc-chairs@ietf.org>; sfc@ietf.org<mailto:sfc@ietf.org>; ippm@ietf.org<mailto:ippm@ietf.org>; James Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>>; Tal Mizrahi <tal.mizrahi.phd@gmail.com<mailto:tal.mizrahi.phd@gmail.com>>; draft-ietf-sfc-ioam-nsh@ietf.org<mailto:draft-ietf-sfc-ioam-nsh@ietf.org>
Objet : Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

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<mailto: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<mailto: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.