[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
- [sfc] Jim Guichard's Discuss on draft-ietf-sfc-io… Jim Guichard via Datatracker
- Re: [sfc] Jim Guichard's Discuss on draft-ietf-sf… Frank Brockners (fbrockne)
- Re: [sfc] Jim Guichard's Discuss on draft-ietf-sf… James Guichard