Re: [spring] Erik Kline's No Objection on draft-ietf-spring-nsh-sr-12: (with COMMENT)

Erik Kline <ek.ietf@gmail.com> Wed, 26 April 2023 22:56 UTC

Return-Path: <ek.ietf@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA0DC151B01; Wed, 26 Apr 2023 15:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gIL4uIldzOlQ; Wed, 26 Apr 2023 15:56:34 -0700 (PDT)
Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 72DE4C15155C; Wed, 26 Apr 2023 15:56:34 -0700 (PDT)
Received: by mail-ua1-x92a.google.com with SMTP id a1e0cc1a2514c-77215852592so2357262241.2; Wed, 26 Apr 2023 15:56:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682549793; x=1685141793; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bAqK84K0jOgtDNhpTPMJxq+6joegt1qihsxlMapATwo=; b=oA8DzCZtuh9wXa0HIVLZaMD3ZNtV8oj/CAP9kVHFn9boJwKD2MfqEnkXPD3LA8YyPU 20Z+JY7rfsFYNQBbADb8rMamAVYD7AyisooZFFTbxe85bL5MYNiUn+522W1tCtfDxfo4 g96uRWuwYkO4UFrTyiZIaJdww2xCcJWduhGKR5py2Sn83OwGL4BgOhfbxmBm6iynWya0 XmKK4CEpKPs7jazqaJyFvduaZCttXT0feWZtjlfd7HsP/EeTFVJ25uHiLx6G5qfovCPY XM7MTxkUYF8S4PgH05Tq4PC8P9gmfgjEnkxDsBI14hXsX9awTYLbkWxCJ4ctF6DlxrC7 DUVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682549793; x=1685141793; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bAqK84K0jOgtDNhpTPMJxq+6joegt1qihsxlMapATwo=; b=NO9JyqbZ3+0u2Kdfqzl6LvBxYKqBaOmPbOE/Q4P9TS0o7wtSEs8VrYQruY7ZqrfDuz wYrcRb2eyewvUf5EWwKiQ5vXHDlWmsGCgxmfZEmD4W57tVkN2g0ozHYPmxguTYhgQ1jh R6w2iPQrR6zkqrQCRulg47vjMTQLBEwF3kun146HQAsl+QDTn1yjg8zyMA/BaWLHlkrU b2WV3a6w0m9uuWIfSGBwGPxVu4uBkBkKW5ZrNLb7DxWJSZ+0jRxaypf0G+HPIhZH8q6X mBuIuweMx7jZV5cf32NxfXH1FuS8PX/L+b6Zv3AGPsI9qTvJJT4Uc3hRg7XFXn3j4FM6 efgg==
X-Gm-Message-State: AAQBX9d9cOAxrlRkayBSLuDquKwwgJ73aEtqklgj13UEvvV0SbFw2l/i hUjPAZfeqXF68YPJ00O+z81BbBkHQ/mosIMvoFAJCHIk
X-Google-Smtp-Source: AKy350ae+VI+hne4Y8Vd1Xa+wVReujoo2r0nMAx2J01uSV/XmBTsOl3nsx+OpECbHnZmtLlI3VIEaoianliAmF9Z+Ec=
X-Received: by 2002:a1f:5c92:0:b0:436:597e:2c85 with SMTP id q140-20020a1f5c92000000b00436597e2c85mr7130156vkb.2.1682549793448; Wed, 26 Apr 2023 15:56:33 -0700 (PDT)
MIME-Version: 1.0
References: <168254015822.29658.13271459537716537906@ietfa.amsl.com> <86b0bf1c-4842-a012-dc00-0baf45f50c50@joelhalpern.com>
In-Reply-To: <86b0bf1c-4842-a012-dc00-0baf45f50c50@joelhalpern.com>
From: Erik Kline <ek.ietf@gmail.com>
Date: Wed, 26 Apr 2023 15:56:22 -0700
Message-ID: <CAMGpriWwtbgnci9gXtJj335hyRuWDrQAwjZQ34Fmdt19iFbjtw@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: The IESG <iesg@ietf.org>, spring@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c169f105fa452626"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/wy8IQaSoI8l7M7TKrtAD89xjyUc>
Subject: Re: [spring] Erik Kline's No Objection on draft-ietf-spring-nsh-sr-12: (with COMMENT)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Apr 2023 22:56:39 -0000

On Wed, Apr 26, 2023 at 3:23 PM Joel Halpern <jmh@joelhalpern.com> wrote:

> Responding to the first comment in line as s document contributor, trimmed.
>
> Yours,
>
> Joel
>
> On 4/26/2023 4:15 PM, Erik Kline via Datatracker wrote:
> > Erik Kline has entered the following ballot position for >
> draft-ietf-spring-nsh-sr-12: No Objection > > ... > >
> ---------------------------------------------------------------------- > >
> COMMENT:
> > ---------------------------------------------------------------------- >
> > > # Internet AD comments for draft-ietf-spring-nsh-sr-12
> > CC @ekline > > ## Comments > > ### S5.1, S5.2 > > * I am not very
> familiar with the SFC paradigm, so please do correct > me or ignore me. > >
> Does this "service-index - 1" cache end up imposing too tight a >
> restriction on the SF handling of the NSH, limiting processing to > only a
> single function (decrementing the service index by only 1)? > > I naively
> expected that the SR segment list could move a packet > through a network
> of endpoints, but that each endpoint could perhaps > trigger multiple
> functions acting on the packet without incurring > extra, duplicative
> segments to indicate additional processing on the > same node.
> <jmh> conceptually, the service function path steers the packet between
> service function instances.  A given SFF may have multiple service
> functions attached, and a packet that needs to visit multiple such will
> have its index decremented by 1 at each one.
>
> Conversely, SFC does not define what a "service function" can do.  A
> service function instance can do anything it wants, even combining several
> different operations.  Even os, it is a single service function, and
> occupies one index.
>
> In the abstract, one could have a service function path that was required
> to visit the same service function twice in a row.  But, if it is
> decrementing the service function index twice, the assumption is that it
> got returned to the SFF in between.
>
> One can imagine weirder cases (like most IETF protocols, things can be
> abused if you chose to) where the SF includes an embedded SFF.  How that
> would work with this encaps is not somethign we have tried to figure out.
> Whoever wants to do it can figure it out.
>

👍