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.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
