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

Joel Halpern <> Wed, 26 April 2023 22:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3CDDC15154F; Wed, 26 Apr 2023 15:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Status: No, score=-7.098 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IbPLLMmCwgGE; Wed, 26 Apr 2023 15:23:03 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 4CBFFC14CE39; Wed, 26 Apr 2023 15:23:03 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4Q6D070ykSz6Gtkf; Wed, 26 Apr 2023 15:23:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1682547783; bh=jkaeM38fHticTma885rLMKHE6rkxdOOqACTPOAo36Xg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Jz+8zf1+RUmiTZNB3NI4EslOTRdHFCTlodUDkLwr0N1IaZTRMrnNoeWatTx4YexkP twTSwBUmJm4f2csC7nVrghOP6HdmcsVMeX1eqZZlv2jTy94zSVZQabVG0D7i01tTZk I4C/hIe+pYRgy21BvIbFeQzHKEwRYMnB9p3rhVKw=
X-Quarantine-ID: <gxD2EfB5SPh6>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] (unknown []) (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 (Postfix) with ESMTPSA id 4Q6D063HqRz6GJCw; Wed, 26 Apr 2023 15:23:02 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------UBIXl3lKBjk5P75ARJQYwpW4"
Message-ID: <>
Date: Wed, 26 Apr 2023 18:23:01 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: Erik Kline <>, The IESG <>
References: <>
From: Joel Halpern <>
In-Reply-To: <>
Archived-At: <>
Subject: Re: [spring] Erik Kline's No Objection on draft-ietf-spring-nsh-sr-12: (with COMMENT)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Apr 2023 22:23:08 -0000

Responding to the first comment in line as s document contributor, trimmed.



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 > > ... > > 
---------------------------------------------------------------------- > 
> ----------------------------------------------------------------------  > > > # 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.