On Wed, Apr 26, 2023 at 3:23 PM Joel Halpern <j...@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. > 👍
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
