[sfc] Jim Guichard's Discuss on draft-ietf-sfc-ioam-nsh-11: (with DISCUSS and COMMENT)

Jim Guichard via Datatracker <noreply@ietf.org> Fri, 28 April 2023 19:32 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: sfc@ietf.org
Delivered-To: sfc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 271ADC3C9444; Fri, 28 Apr 2023 12:32:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Jim Guichard via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sfc-ioam-nsh@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregory.mirsky@ericsson.com, gregory.mirsky@ericsson.com
X-Test-IDTracker: no
X-IETF-IDTracker: 10.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Jim Guichard <james.n.guichard@futurewei.com>
Message-ID: <168271032915.49133.4855478761736336556@ietfa.amsl.com>
Date: Fri, 28 Apr 2023 12:32:09 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/YifW1sh1oyoVEwWclDE-oXRofwQ>
Subject: [sfc] Jim Guichard's Discuss on draft-ietf-sfc-ioam-nsh-11: (with DISCUSS and COMMENT)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 28 Apr 2023 19:32:09 -0000

Jim Guichard has entered the following ballot position for
draft-ietf-sfc-ioam-nsh-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

- Section 3:
   The IOAM-Data-Fields MUST follow the definitions corresponding to
   IOAM-Option-Types (e.g., see Section 5 of [RFC9197] and Section 3.2
   of [I-D.ietf-ippm-ioam-direct-export])

The above reference to RFC9197 is incorrect although a simple fix. The
IOAM-Option-Types are defined in Section 4 of that document not Section 5.
Adding a DISCUSS as this reference is important enough to not just be a
comment. Note that the same incorrect reference is used later on in Section 3
and must be corrected also.

- Section 3:
   The operator MUST ensure that all nodes along the service path support IOAM.
    Otherwise packets with IOAM are likely to be dropped per [RFC8300].

This text needs clarification as RFC8300 says nothing about IOAM specifically
and dropping of OAM packets is discussed in that RFC here ->
https://www.rfc-editor.org/rfc/rfc8300#:~:text=O%20bit%3A%20%20Setting,disabled%20by%20default.
The authors should clarify exactly what they mean by the above text and clarify
what specifically in RFC8300 would cause packets to be dropped if a node does
not support IOAM.

- IANA Considerations:
The text says "IANA is requested to allocate protocol numbers for the following
"NSH Next Protocol" related to IOAM" but there is no reference to the correct
registry. NSH Next Protocol allocations can be found here:
https://www.iana.org/assignments/nsh/nsh.xhtml#next-protocol and they are part
of the Network Service Header (NSH) Parameters registry. Please provide an
accurate reference to the Network Service Header (NSH) Parameters registry for
IANA.

- Section 5: Another incorrect reference needs to be corrected. "For additional
IOAM related security considerations, see Section 10 in [RFC9197].". It is
actually section 9 of that RFC so please correct the reference.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


General comment. There are several typos or grammatical errors in the document.
Suggest running an error checker against the document.

Section 1: "In-situ OAM (IOAM)" in the first sentence does not need to be
expanded as the authors already did so in the abstract.

Section 1: "Service Function Chaining (SFC) [RFC7665]" should read "Service
Function Chaining (SFC) Architecture [RFC7665]".

Section 3: 6th sentence use of "service path" should probably be changed to the
correct terminology used by the SFC architecture which is Service Function Path
(SFP). Further, the next sentence should be folded into the 6th sentence as a
single sentence to make it more readable.

Section 3: "See [I-D.ietf-ippm-ioam-deployment] for a discussion of deployment
related aspects of IOAM-Data-fields.". This reference should be changed to
[RFC9378].

Section 3: "[I-D.ietf-ippm-ioam-flags]". This reference should be changed to
[RFC9322].

Several outdated references need to be updated:

  == Outdated reference: A later version (-03) exists of
     draft-ietf-sfc-oam-packet-01

  == Outdated reference: draft-ietf-ippm-ioam-deployment has been published
     as RFC 9378

  == Outdated reference: draft-ietf-ippm-ioam-direct-export has been
     published as RFC 9326

  == Outdated reference: draft-ietf-ippm-ioam-flags has been published as RFC
     9322