[sfc] Éric Vyncke's Discuss on draft-ietf-sfc-ioam-nsh-11: (with DISCUSS and COMMENT)
Éric Vyncke via Datatracker <noreply@ietf.org> Tue, 02 May 2023 06:46 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 B3199C151B23; Mon, 1 May 2023 23:46:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke 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: Éric Vyncke <evyncke@cisco.com>
Message-ID: <168301000071.50043.12097401268210640932@ietfa.amsl.com>
Date: Mon, 01 May 2023 23:46:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/AJhH4WygXQyA9AKFBuWTgnFUfik>
Subject: [sfc] Éric Vyncke'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: Tue, 02 May 2023 06:46:40 -0000
Éric Vyncke 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: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Greg Mirsky for the shepherd's detailed write-up including the WG consensus ***and*** the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics: ## Section 3 This is probably due to my lack of knowledge about NSH... So, a simple discussion over email will probably be enough to clear my DISCUSS points. RFC 9197 has an incremental tracing (section 4.4.1), how does it impact the length of the IOAM header in this case? Assuming that this header size is increased, I suggest to add some text about increasing the length field of IOAM header. `When a packet with IOAM is received at an NSH based forwarding node such as an Service Function Forwarder (SFF) that does not understand IOAM header, it SHOULD drop the packet.` is actually a copy of RFC 8300 ``` Packets with Next Protocol values not supported SHOULD be silently dropped by default, although an implementation MAY provide a configuration parameter to forward them. ``` and not a new behaviour. So, let's rather be clear and use a structure like "Per section 2.2 of RFC 8300, ..." followed by the RFC 8300 text. While very similar to Jim Guichard's DISCUSS point, it is related to another part of the document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # COMMENTS (non-blocking) ## Section 1 Please expand SFF at first use. ## Section 3 Please expand ESP (is it IPsec ESP ?) in the packet format. Should there be text about the absence of padding in the "IOAM Option and Optional Data Space" field (assuming that all IOAM options are always in 32-bit units)? ## Section 4 `IANA is requested to allocate protocol numbers for the following "NSH Next Protocol" related to IOAM` is underspecified. If it is about https://www.iana.org/assignments/nsh/nsh.xhtml#next-protocol, then let's be clear. Note: I intended to DISCUSS this point, but as Jim is already holding a DISCUSS on the same point, I will let him to be the owner. # NITS (non-blocking / cosmetic) A couple of missing hypens in "open source" or "8 bit field".
- [sfc] Éric Vyncke's Discuss on draft-ietf-sfc-ioa… Éric Vyncke via Datatracker
- Re: [sfc] Éric Vyncke's Discuss on draft-ietf-sfc… Frank Brockners (fbrockne)
- Re: [sfc] Éric Vyncke's Discuss on draft-ietf-sfc… Eric Vyncke (evyncke)