Re: [sfc] WG LC on draft-ietf-sfc-multi-layer-oam

mohamed.boucadair@orange.com Thu, 09 June 2022 04:58 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1817AC15AAC1 for <sfc@ietfa.amsl.com>; Wed, 8 Jun 2022 21:58:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWzG0sk4rUgy for <sfc@ietfa.amsl.com>; Wed, 8 Jun 2022 21:58:24 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (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 7A3A0C159827 for <sfc@ietf.org>; Wed, 8 Jun 2022 21:58:23 -0700 (PDT)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (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 opfednr24.francetelecom.fr (ESMTP service) with ESMTPS id 4LJX0s2yLVz1yC5; Thu, 9 Jun 2022 06:58:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1654750701; bh=BI2QRAMOWNLeqenS26xA6eaoi7kC8w/03AX8EgbrsPM=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=CVmG6Pf2RV9yvj+AK7syV7mMOs8QO5gXHSxuiDvZ+8ncrT/WaIMflH732yn9hlU63 i+6QZEK6Lac86sEBpDwVAFhdgfi5vfQnDuRFXZNbb/PSIR1MLH73wo1ghK3zjH3XEy JFMXqN3T4XIxQZZzSW7cg3SdHabSCpCfMiLGeymurmEPVz6U7zHzwcujq69C1X+EhO a3hhUC2KY00Pj/TIysy6HHmL4OyICRXq+pB2G7/QkrE/yanyFaEBnIggMQL++9O2Y8 cRR4rKQxkcJGtSzIOyOCe0DB3Pa3BGpvCGxcCeE3FFiuuI311uveHDhZC4rxlC0Z9q xjE6JYqYkzn5g==
From: mohamed.boucadair@orange.com
To: Greg Mirsky <gregimirsky@gmail.com>
CC: "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] WG LC on draft-ietf-sfc-multi-layer-oam
Thread-Index: AQHYe3ZhxSTIVCtPx0+ENclWaYAaZa1Ggoew
Content-Class:
Date: Thu, 09 Jun 2022 04:58:21 +0000
Message-ID: <15752_1654750701_62A17DED_15752_287_1_996d0481d56c40e38df07935334532a1@orange.com>
References: <c26e4142-aa80-6e54-f997-2f81e025076c@joelhalpern.com> <22742_1654248346_6299D39A_22742_162_1_3ad73e57e1244d338301d43abfff15cc@orange.com> <CA+RyBmX8UqyjRnmvYizuW4sXk6LN8=JJxHkjU+yYWJ2O3eHXZA@mail.gmail.com> <5168_1654580854_629EE676_5168_242_1_f6d0805726034ba9ae9a2f5186f0f2f1@orange.com> <CA+RyBmWApF7NRMmC1JadBdAkYM3TohzTO2+fmeEu8oNjuZXpdA@mail.gmail.com>
In-Reply-To: <CA+RyBmWApF7NRMmC1JadBdAkYM3TohzTO2+fmeEu8oNjuZXpdA@mail.gmail.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-06-09T04:53:07Z; 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=53ac4aad-5bb2-450f-859d-c352113c5712; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.115.27.53]
Content-Type: multipart/alternative; boundary="_000_996d0481d56c40e38df07935334532a1orangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/QFwPVtCkR6zuDs0Ir6qi4ci9qhA>
Subject: Re: [sfc] WG LC on draft-ietf-sfc-multi-layer-oam
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2022 04:58:28 -0000

Hi Greg,

Thanks for the updates.

All good, except one minor comment about the name of the sub-registry: it should be “NSH  Next Protocol”

CURRENT:
IANA is requested to assign a new type from the sub-registry SFC Next Protocol of the Network Service Header (NSH) Parameters registry as follows:

Cheers,
Med

De : sfc <sfc-bounces@ietf.org> De la part de Greg Mirsky
Envoyé : mercredi 8 juin 2022 22:28
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
Cc : sfc@ietf.org
Objet : Re: [sfc] WG LC on draft-ietf-sfc-multi-layer-oam

Hi Med,
thank you for your helpful follow-up. Please find my notes inlined under the GIM2>> tag. Attached is the new diff to highlight all the updates.

Regards,
Greg

On Mon, Jun 6, 2022 at 10:47 PM <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
Hi Greg,

Thank you for the changes. This looks better, but there are still very few points that are unaddressed.

Please see inline.

Cheers,
Med

De : sfc <sfc-bounces@ietf.org<mailto:sfc-bounces@ietf.org>> De la part de Greg Mirsky
Envoyé : mardi 7 juin 2022 01:58
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Cc : sfc@ietf.org<mailto:sfc@ietf.org>
Objet : Re: [sfc] WG LC on draft-ietf-sfc-multi-layer-oam

Hi Med,
many thanks for your comments. I've prepared an updated version and appreciate your feedback. Please find my responses in-lined below tagged GIM>>. Attached are the diff and copy of the updated draft.

Regards,
Greg

On Fri, Jun 3, 2022 at 2:25 AM <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
Hi Joel, all,

I reviewed this document several times. It is ready to move forward.

Some easy-to-fix comments are provided below:

* Title:

  OLD: Active OAM for Service Function Chaining
  NEW: Active OAM for Service Function Chaining (SFC)
GIM>> Done

* Section 3: It would be helpful to have a discussion at the end of the document how these various requirements listed here are met with the proposed solution. Alternatively, REQ# can be called out in subsequent sections to tag where it is addressed. For example, this text can be updated to refer the REQ#

   The
   SFC Echo Request/Reply defined in this document addresses several
   requirements listed in Section 3.  Specifically, it can be used to
   check the continuity of an SFP, trace an SFP, or localize the failure
   within an SFP.
GIM>> I propose this update to the text above
NEW TEXT:
The
   SFC Echo Request/Reply defined in this document conforms to REQ#1
   (Section 3) by using the NSH encapsulation of the monitored service.
   Further, the mechanism addresses requirements REQ#2 through REQ#7,
   listed in Section 3.  Specifically, it can be used to check the
   continuity of an SFP, trace an SFP, or localize the failure within an
   SFP.  Also, note that REQ#8 can be addressed by an extension of the
   SFC Echo Request/Reply described in this document adding proxy
   capability.

[Med] This is great. However, a similar text is still needed for REQ#3, 4, 5, and 6.
GIM2>> I propose this form:
    Further, the mechanism addresses requirements REQ#2 through REQ#7,
    listed in Section 3.
or listing them all:
    Further, the mechanism addresses requirements REQ#2, REQ#3, REQ#4,
    REQ#5, REQ#6, and REQ#7 listed in Section 3.
Which form is acceptable?


Similar text can be considered for other REQ#s.

*  Section 4: s/The O bit in NSH/The O bit in the NSH
GIM>> Done

* Section 6.1: Check the list of errors is update to date. The values are not aligned with ones in Table 8.
GIM>> Thank you for catching this miss-merge. Fixed.

* Section 6.3: Please check the list of allowed codes. Shouldn’t these values be aligned with the content on Table 7?
GIM>> Indeed, thank you for pointing this out. Extended the list with references to RFC 9145.
[Med] Thanks.


* Please consider some text about MTU. this can be basically echoing what is already in 8300 or Section 8 of rfc9145

* Section 6.6.3: Move 9015 to be listed as Normative given that it is required for:
GIM>> Done
[Med] This one is still listed as informative. Please fix it. Thanks.
GIM2>> Thank you for catching that. I've moved to the Normative RFC 9145. Done (and verified) RFC 9015.

      SF Type - two-octet field.  It is defined in [RFC9015] and
      indicates the type of SF, e.g., Firewall, Deep Packet Inspection,
      WAN optimization controller, etc.

* Section 10.1:

(1)

OLD:
   IANA is requested to assign a new type from the SFC Next Protocol
   registry as follows:

NEW:
   IANA is requested to assign a new type from the "NSH Next Protocol"
   registry available at <https://www.iana.org/assignments/nsh/nsh.xhtml#next-protocol>:
GIM>> I am not used to this form. Can the decision be left for the RFC Editor and IANA Action?
[Med] The point is to have the required information as per the following (excerpt from the writeup):

==
Confirm that any referenced IANA registries have been clearly identified.
==
GIM2>> Thank you for pointing that out to me. I propose the updated text as follows:
IANA is requested to assign a new type from the sub-registry SFC Next Protocol of the Network Service Header (NSH) Parameters registry as follows:
Would that be acceptable?



(2) Consider adding a note for the RFC editor to update all TBA1 occurrences with the assigned value.
GIM>> In my experience, an RFC Editor and IANA Action always take care of these updates.

[Med] It is very likely and they usually ask a question to confirm this. The point is to be explicit about the intent (omissions may happen).
GIM2>> Understood. I propose the following text after Table 2:
[RFC Editor, please update all occurrences of TBA1 with the value assigned by IANA Action.]



* Sections 10.2.1, 10.3.2, 10.3.3, 10.3.4, 10.4, and 10.5:

OLD: IETF Consensus
NEW: IETF Review
GIM>> Thank you! Done.

* Sections 10.2.1, 10.3.2, 10.3.3, 10.4, and 10.5:

Any particular reason why some values are reserved? (see the example below)

      | 0             |           Reserved          | This document |

While these values are used for other registries, e.g., Section 10.3.4.

* Section 10.3.4:
GIM>> In part that is the historical use of Error Code in Echo Request/Reply with zero value indicating No Error.


OLD:
   | 255     |             Reserved            |               |

NEW:
   | 255     |             Reserved            | This document |
GIM>> Done

Cheers,
Med

> -----Message d'origine-----
> De : sfc <sfc-bounces@ietf.org<mailto:sfc-bounces@ietf.org>> De la part de Joel Halpern
> Envoyé : jeudi 2 juin 2022 20:51
> À : sfc@ietf.org<mailto:sfc@ietf.org>
> Objet : [sfc] WG LC on draft-ietf-sfc-multi-layer-oam
>
> Technically, the draft is still in last call from quite some time
> ago.
>
> For clarity, and as there have been clarifications in relate
> terminology, the chairs have decided to consider taht we are
> restarting the last call today.
>
> This Working Group Last call will run for 2 weeks (and a day)
> until CoB on June 17, 2022.
>
> Please respond positively or negatively to this call.  Note that
> if we do not get enough responses we will likely be unable to
> advance the document before the WG closes.
>
> When responding, please provide clear motivation either for or
> against publication as an RFC.  Substantive comments are MUCH more
> helpful than "yes" or "no".
>
>
> Thank you,
>
> Joel and Jim
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org<mailto:sfc@ietf.org>
> https://www.ietf.org/mailman/listinfo/sfc

_________________________________________________________________________________________________________________________

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.

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc

_________________________________________________________________________________________________________________________



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.