Re: [ippm] [sfc] WGLC for Tue, 12 April 2022 15:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 786FB3A1717; Tue, 12 Apr 2022 08:05:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.004
X-Spam-Status: No, score=-2.004 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_DNSWL_BLOCKED=0.001, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 353-js4NZzQb; Tue, 12 Apr 2022 08:04:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1B2113A0ADC; Tue, 12 Apr 2022 08:04:57 -0700 (PDT)
Received: from (unknown [xx.xx.xx.2]) (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 (ESMTP service) with ESMTPS id 4Kd8CW58M0z2ybb; Tue, 12 Apr 2022 17:04:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1649775895; bh=nQXD8hp8zWocx/YIu09VUTkWxk+/rrBSqdFTotCmtYs=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=MYLM7GcRJpLd9/kVJn/53Ac+nqG/icyf3P1FlTd2joqZvp4lnTVYv5TtvNDYeEED4 SnA7+HftTXolGehanjUbsiDqeTQrGMthp4D+pGP/3i1ENVyVR/kYKhzvntN9A1dmUg MhdkhTUs4EFPZ68DZQjh3+DhLcNhHyy5eCg8KBK2uVw41ecGRVK4INdBN2/LeVNv0J MTRCdnVSJpx6Pch1VSGmYmFDvekRcMmqFMPVY53fa/gW/SyTY8aCowlAqwGZkTFj3F jcrYg9fo7U/etarH3L53hM/moUi7rEy5UQlupAh11UvfcAfoad74nfvy6w452xQRUD uXP69BoNkv5rQ==
To: Shwetha Bhandari <>
CC: "Frank Brockners (fbrockne)" <>, Greg Mirsky <>, "" <>, "" <>, "" <>, James Guichard <>, Tal Mizrahi <>, "" <>
Thread-Topic: [sfc] WGLC for
Date: Tue, 12 Apr 2022 15:04:55 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-04-12T15:02:59Z; 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=6ed5adda-9acd-420f-b156-e16ce4350856; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_1fd91873d16a4af4997b9516c02cb37forangecom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [ippm] [sfc] WGLC for
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Apr 2022 15:05:07 -0000

Hi Shwetha,

I suggest you simply add the following: “The O-bit MUST be handled following the rules in [I-D.ietf-sfc-oam-packet].”


De : Shwetha Bhandari <>
Envoyé : mardi 12 avril 2022 16:56
Cc : Frank Brockners (fbrockne) <>; Greg Mirsky <>;;;; James Guichard <>; Tal Mizrahi <>;
Objet : Re: [sfc] WGLC for


Thanks for the details: this is exactly what we had before the latest revision:

4.2<>.  IOAM and the use of the NSH O-bit

   [RFC8300] defines an "O bit" for OAM packets.  Per [RFC8300<>] 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


This was removed as per the discussion in this thread. Please check

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 ?


On Tue, Apr 12, 2022 at 8:09 PM <<>> wrote:
Hi Franck,

Thank you for the clarification even if I don’t think there is a confusion.

Please note that SFC OAM packet is defined as follows:

      Such a packet
      is any NSH-encapsulated packet that exclusively includes OAM data.
      An OAM data can be included in the Fixed-Length Context Header,
      optional Context Headers, and/or the inner packet.

Things are pretty clear (as per draft-ietf-sfc-oam-packet) that the O bit must be unset when IOAM data is included + user data.

The concern I had is that you are pointing to RFC8300 for the IOAM next protocol, which makes both “none” (i.e., no payload) and IOAM (as you request a new code) legitimate values.


De : sfc <<>> De la part de Frank Brockners (fbrockne)
Envoyé : mardi 12 avril 2022 13:55
À : BOUCADAIR Mohamed INNOV/NET <<>>; Shwetha Bhandari <<>>; Greg Mirsky <<>>
Cc :<>;<>;<>; James Guichard <<>>; Tal Mizrahi <<>>;<>
Objet : Re: [sfc] WGLC for<;!!MZ3Fw45to5uY!JpBZ4H2-MNm5lJDGjooVj_3Sq-aX7gdh5qeoNPyZ69CXOFRhgdYmSOyreClzKvZDgPAiwaGN2YTO2qUw70GqHI4QEKQpGnBw0LXBXQ$>

Hi Med,

Sorry for arriving late to the party. Reading through your message below, there seems to be a confusion about the scope and concept of different OAM mechanisms.

IOAM is scoped and designed to be protocol agnostic. IOAM data can be encapsulated into various protocols – and NSH is one example – but there is no semantic link between IOAM and the protocol used to encapsulate IOAM data.

Protocols can have their protocol specific OAM methods and solutions, like SFC OAM. Those protocol specific solutions (like SFC OAM as an example) are orthogonal to IOAM from a concept and scope perspective.

From an SFC OAM perspective, your draft-ietf-sfc-oam-packet-00 clearly and rightly states that “O bit: Setting this bit indicates an SFC OAM packet.” The O bit is about SFC OAM, and as such is orthogonal to “anything IOAM”. In earlier versions of draft-ietf-sfc-ioam-nsh we had text which stated that the O bit remains unchanged whether IOAM is present or not. To avoid any confusion, in -08 we removed this statement – just to make it crystal clear that there is no link between “IOAM” and “SFC OAM”.

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.

Hope this clarifies things – and we can finish up draft-ietf-sfc-ioam-nsh :-).

Cc’ing the ippm working group as an FYI.

Thanks & Cheers, Frank

From:<> <<>>
Sent: Monday, 4 April 2022 07:40
To: Shwetha Bhandari <<>>; Greg Mirsky <<>>
Cc:<>; Frank Brockners (fbrockne) <<>>;<>; James Guichard <<>>; Tal Mizrahi <<>>;<>
Subject: RE: [sfc] WGLC for<;!!MZ3Fw45to5uY!JpBZ4H2-MNm5lJDGjooVj_3Sq-aX7gdh5qeoNPyZ69CXOFRhgdYmSOyreClzKvZDgPAiwaGN2YTO2qUw70GqHI4QEKQpGnBw0LXBXQ$>

Hi Shwetha, all,

I agree with Greg that a statement is needed to be added to draft-ietf-sfc-oam-packet.

For example, the current text says the following:

      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<;!!MZ3Fw45to5uY!JpBZ4H2-MNm5lJDGjooVj_3Sq-aX7gdh5qeoNPyZ69CXOFRhgdYmSOyreClzKvZDgPAiwaGN2YTO2qUw70GqHI4QEKQpGnDoYxXlRw$>].

which means that “None” is authorized. The O-bit must be set for such packets, while it should be unset for other values indicating user payload as per draft-ietf-sfc-oam-packet. Absent a pointer to the OAM packet, an implementer will have to guess the behavior to follow.

BTW, the text quoted above when combined with:

   IANA is requested to allocate protocol numbers for the following "NSH
   Next Protocol" related to IOAM:

…means that IOAM data can be encapsulated in IOAM data. I don’t think you want such a behavior. No?

One last comment: please update the security considerations with NSH-specific considerations. An approach is to simply refer to Section 5 of draft-ietf-sfc-oam-packet.



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.