[sfc] Tsvart early review of draft-ietf-sfc-nsh-ecn-support-08
Olivier Bonaventure via Datatracker <noreply@ietf.org> Fri, 19 November 2021 11:58 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 E8AE33A07E6;
Fri, 19 Nov 2021 03:58:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Olivier Bonaventure via Datatracker <noreply@ietf.org>
To: <tsv-art@ietf.org>
Cc: draft-ietf-sfc-nsh-ecn-support.all@ietf.org, sfc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.40.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <163732311487.10755.15788960258774940136@ietfa.amsl.com>
Reply-To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Date: Fri, 19 Nov 2021 03:58:34 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/Qg3Sv-fmAb_mdvynzg1TmGH6VYE>
Subject: [sfc] Tsvart early review of draft-ietf-sfc-nsh-ecn-support-08
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
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, 19 Nov 2021 11:58:35 -0000
Reviewer: Olivier Bonaventure Review result: Almost Ready I read the draft as part of the tav-area review team and found some parts that are unclear and should be clarified before publication. I have one technical concern regarding the tunnelEcnCEMarkedRatio information element. This IE is defined as "The ratio of CE-marked packets at the Observation Point". This definition is unclear. It does not indicate the period over which the ratio has been computed. This looks critical if the ingress plans to use the ratio to adjust its rate or provide ECN feedback upstream. All other IEs refer to the initialization of the metering processes the start of the period. My impression is that there are two possibilities: - clearly specify the period for the computation of tunnelEcnCEMarkedRatio, but different deployments will probably need different periods - let the ingress compute the tunnelEcnCEMarkedRatio from the other IEs that it received and remove the tunnelEcnCEMarkedRatio IE that would then be redundant Editorial comments 1. Introduction What does an interior SFC node need to implement ECN ? If this similar to the requirements for routers or do they need to do something special ? 1.2 ECN Background Why do you indicate RFC3168 as an example solution to carry ECN information while this is a standards track document ? 3.1 You mention non-IP protocols that support similar services as ECN. Could you refer to one as an example ? 4.1 Third paragraph, last sentence "not affectED by packet drop" 5. Example of Use I have difficulties to understand the examples. In figure 9, a message is an IPFIX message, am I right ? Does the figure indicate that IPFIX messages will be sent very frequently ? How often should they be sent ? Figure 10, why putting egress on the left and ingress on the right ? I cannot figure what A1, B2 etc really mean and don't understand this figure and the associated text.
- [sfc] Tsvart early review of draft-ietf-sfc-nsh-e… Olivier Bonaventure via Datatracker
- Re: [sfc] Tsvart early review of draft-ietf-sfc-n… Donald Eastlake