Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

["Surendra Kumar (smkumar)" <[e-mail]>]

Hi Med,

Some comments inline, please see SK>

Rgds,
Surendra.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Monday, November 07, 2016 5:28 AM
To: Surendra Kumar (smkumar) <[e-mail]>; Dave Dolson <[e-mail]>; Adrian Farrel <[e-mail]>; 'Joel M. Halpern' <[e-mail]>; [e-mail]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Hi Surendra, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Surendra Kumar (smkumar) [mailto:[e-mail]] Envoyé : 
> dimanche 6 novembre 2016 22:09 À : BOUCADAIR Mohamed IMT/OLN; Dave 
> Dolson; Adrian Farrel; 'Joel M.
> Halpern'; [e-mail]
> Objet : RE: OK. Enough with the looping (spiralling :-) [Was: 
> decrementing service function path index]
> 
> Hi Med,
> 
> There is no debate about the need for "SI". <SPI,SI> is a tuple that 
> represents the SFC forwarding-state.
> 
> [For simplicity of discussion, let's leave out the classifier SFs.] 1. 
> While SFF and SF are both part of the SFC architecture, the benefits 
> of SF decrementing the SI as opposed to SFF decrementing is never 
> articulated other than mandating it. On the other hand a case is laid 
> out in the draft I mentioned earlier to have only SFF decrement the SI 
> or SF to decrement by zero.
> 

[Med] I tend to agree with you on this particular point.  


> Whether it is SF or SFF stamping the forwarding state into NSH, it has 
> to be under CP control. IOW, they have to have the forwarding table 
> laid out by CP. As was discussed many times in this list, changing the 
> forwarding state on a NSH packet, then becomes a <SPI, SI> lookup or 
> an implicit decrement.
> Once you have a CP controlled SFC forwarding table,

[Med] We already have a "CP controlled SFC forwarding table". The consensus of the WG on the forwarding table is as follows (CP draft):
SK> Thanks for this information.
So, SPI is a primary key and probably SI and other information are additional keys. It does not however mandate a specific values for SI. I will take this to mean, CP draft already allows any SI value to be programmed. Please let me now if this is incorrect interpretation.

   o  SFP Forwarding Policy Table: this table reflects the SFP-specific
      traffic forwarding policy enforced by SFF components for every
      relevant incoming packet that is associated to one of the existing
      SFCs.  The SFP Identifier (SFP-id) is used as a lookup key to
      determine forwarding action regardless of whether the SFC is fully
      constrained, partially constrained, or not constrained at all.
      Additional information such as a flow identifier, Service Index
      (SI), and/or other characteristics (e.g., the 5-tuple transport
      coordinates of the original packet) may be used for lookup
      purposes.  The set of information to use for lookup purposes may
      be instructed by the control plane.

And 

   SFFs make traffic forwarding decisions according to the entries
   maintained in their SFP Forwarding Policy Table.  Such table is
                                                     ^^^^^^^^^^^^
   populated by the SFC control plane through the C2 interface.  In^
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   particular, this interface is used to instruct the SFF about the set
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   of information to use for lookup purposes (e.g., SFP-id, 5-tuple^
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   transport coordinates).  One or many entries may be installed using
   one single control message.  Installing new entries in the SFP
   Forwarding Policy Table must be immediate.  The status of enforcing
   such entries must be communicated to the control plane as part of the
   communication procedure.  In particular, specific error codes must be
   returned to the Control Element in case an error is encountered
   during the enforcement procedure.

 you have a fully
> policy compliant SPI traversal. And that policy can be anything, as 
> per the use case, while ensuring that the SI is monotonically going 
> down to zero, for other benefits.
> 
> 2. It is a big assumption to make, to say *all* packets MUST always 
> traverse *all* SFs in a chain. It is not part of the architecture, 
> unless I missed that.

[Med] Hmm, isn't you who said the following in (https://tools.ietf.org/html/draft-kumar-sfc-offloads-03): 
SK> this is a general explanation of the functionality to set the context for offloads and not to mandate a certain way of forwarding, obviously that does not belong in the offloads draft.

   Service Function Chaining (SFC) enables services to be delivered by
   selective traffic steering through an ordered set of service
   functions.  Once classified into an SFC, the traffic for a given flow                                                
   is steered through all the service functions of the SFC for the life
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   of the traffic flow even though this is often not necessary.

> 
> 3. By having SFs manipulate the forwarding state on SFC packets, SFFs 
> are essentially being co-located with SFs. There are many SFs, which 
> do not need to deal with forwarding but only servicing.
> 
> Thanks,
> Surendra.
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> Sent: Friday, November 04, 2016 12:49 AM
> To: Surendra Kumar (smkumar) <[e-mail]>; Dave Dolson 
> <[e-mail]>; Adrian Farrel <[e-mail]>; 'Joel M.
> Halpern' <[e-mail]>; [e-mail]
> Subject: RE: OK. Enough with the looping (spiralling :-) [Was:
> decrementing service function path index]
> 
> Hi Surendra,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Surendra Kumar (smkumar) [mailto:[e-mail]] Envoyé :
> > jeudi 3 novembre 2016 19:26 À : BOUCADAIR Mohamed IMT/OLN; Dave 
> > Dolson; Adrian Farrel; 'Joel M.
> > Halpern'; [e-mail]
> > Objet : RE: OK. Enough with the looping (spiralling :-) [Was:
> > decrementing service function path index]
> >
> > Hi Med,
> >
> > It is relaxing the rigid requirement, requiring decrement by one and 
> > only one. This would be too restrictive a language to put inside NSH.
> 
> [Med] SI is there to achieve two objectives: location within a chain + 
> loop detect. If we assume that the base SFC design is that a packet 
> bound to a given chain has to cross **all** the SF instances that 
> compose that chain, decrementing the index by one becomes trivial 
> while decrementing by other values is not justified.
> 
> >
> > I can imagine implementations wanting to jump over an SF under 
> > policy control, either statically or dynamically, just as one simple example.
> 
> [Med] We can consider this case from several perspectives, e.g.,:
> 
> (1) This is deployment-specific. There are other ways to achieve the 
> same
> result: create a new chain that does not involve that SF, for example.
> 
> (2) This is implementation-specific. I hear that jumping over an SF 
> can be achieved relying on some optimization that will preserve the 
> size of the classification table. For example, a signal can be sent 
> from an SF to its SFF. Doing so requires modifications to both SF and 
> SFF. One can consider that the hook required in an SFF to honor a 
> request from an SF is designed as a service function ("Void SF" 
> co-located with an SFF). Under that design, the Void SF will proceed 
> in place of the SF to be jumped. No modification is then required to the processing of SI in such design.
> 
> 
> > This is not reclassification. Whether the reasons are to prevent 
> > proliferation of SPIs or to provide dynamic control, or something 
> > else, it is use case driven.
> >
> > It is increasingly a software defined infrastructure to put it 
> > mildly and I would rather allow this while not affecting the default 
> > behavior. On the same lines, there are already drafts that are 
> > carving the MD-Type1 allocation on the fly - as per control plane - 
> > this is no
> different.
> 
> [Med] I don't think we can put these two on the same level. Further, 
> the control of the metadata is a clear control plane requirement. As 
> an editor of the CP requirement draft, I'm still trying to understand 
> if there is something that needs to be added to that document to 
> capture a NEW requirement that wasn't raised before. Thank you.
> 
> >
> > Surendra.
> > PS: A method to not even modify the 'SI' by SFs is described here:
> > https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-forwarding/
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > Sent: Thursday, November 03, 2016 12:01 AM
> > To: Surendra Kumar (smkumar) <[e-mail]>; Dave Dolson 
> > <[e-mail]>; Adrian Farrel <[e-mail]>; 'Joel M.
> > Halpern' <[e-mail]>; [e-mail]
> > Subject: RE: OK. Enough with the looping (spiralling :-) [Was:
> > decrementing service function path index]
> >
> > Hi Surendra,
> >
> > It seems to me that we are trying to modifyi the SFC data plane 
> > architecture to accommodate a given control plane solution proposal.
> >
> > As an editor of the SFC CP requirements I-D, I don't remember this 
> > "flexibility" requirement was raised.
> >
> > Can you please elaborate on why it is useful to have this control 
> > function?
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : sfc [mailto:[e-mail]] De la part de Surendra 
> > > Kumar
> > > (smkumar)
> > > Envoyé : jeudi 3 novembre 2016 00:46 À : Dave Dolson; Adrian 
> > > Farrel; 'Joel M. Halpern'; [e-mail] Objet
> > > : Re: [sfc] OK. Enough with the looping (spiralling :-) [Was:
> > > decrementing service function path index]
> > >
> > > At the risk of spiraling (borrowing Adiran), this reasoning begs 
> > > the question - why even have non-classifier SFs touch the SI to 
> > > start with
> ?
> > > I would argue to leave it alone and treat SPI+SI as a forwarding 
> > > state and opaque to SFs.
> > >
> > > Control plane can weave the same SF instance into thousands (well, 
> > > it is a 24bit SPI) of SPIs and that shouldn't be a concern for the 
> > > SF - consume metadata and service traffic.
> > >
> > > Allowing for control plane programmed decrement value is very 
> > > reasonable and useful.
> > >
> > > Surendra.
> > >
> > > -----Original Message-----
> > > From: Dave Dolson [mailto:[e-mail]]
> > > Sent: Wednesday, November 02, 2016 1:51 AM
> > > To: Adrian Farrel <[e-mail]>; Surendra Kumar (smkumar) 
> > > <[e-mail]>; 'Joel M. Halpern' <[e-mail]>; 
> > > [e-mail]
> > > Subject: Re: OK. Enough with the looping (spiralling :-) [Was:
> > > decrementing service function path index]
> > >
> > > Adrian,
> > > Perhaps I'm making too fine a point, but I consider that if an SF 
> > > does anything other than decrementing the SI by 1, we've entered 
> > > the realm of reclassification, and it is a Classifier co-located 
> > > with the SF that is overriding the SPI/SI.
> > >
> > > If you refer to Figure 8, path selection is not an action done by 
> > > an
> SF.
> > >
> > > Once reclassification is added to a deployment, we can have 
> > > unicorns (and also dragons); much more becomes possible, but it 
> > > also becomes much more difficult to reason about.
> > >
> > > You can read in the (expired) draft-penno-sfc-packet-03 some ideas 
> > > about packet reversal that depending heavily on rigid SF 
> > > decrement-by-one. I don't know how to begin reasoning about 
> > > reverse forwarding once reclassification is added...
> > >
> > > For those reasons, I would prefer to see the SF action limited to 
> > > decrement-by-one. If you require otherwise, co-locate a classifier 
> > > with the SF.
> > >
> > >
> > > -Dave
> > >
> > >
> > >
> > >   Original Message
> > > From: Adrian Farrel
> > > Sent: Tuesday, November 1, 2016 9:52 PM
> > > To: Dave Dolson; 'Surendra Kumar (smkumar)'; 'Joel M. Halpern'; 
> > > [e-mail] Reply To: [e-mail]
> > > Subject: OK. Enough with the looping (spiralling :-) [Was:
> > > decrementing service function path index]
> > >
> > >
> > > Been thinking about this instead of sleeping.
> > >
> > > Keep getting caught in rat-holes that say "no, but you could build 
> > > product like this." But they are real rat-holes. What we need is a 
> > > set of rule that work for simple implementations *and* that do not 
> > > preclude more sophisticated implementations.
> > >
> > > So...
> > >
> > > When a packet arrives at an SFF the SPI/SI indicates the SFP and 
> > > the next hop on that SFP to be executed.
> > >
> > > When an SF has finished processing a packet the default behavior 
> > > is to leave the SPI unchanged and to decrement the SI by 1.
> > >
> > > However, and SF MAY know to make other changes to a the SPI and SI.
> > > How that knowledge is installed in the SF is implementation dependent:
> > > - it may be the result of configuration (for example, normally 
> > > decrement by
> > >    1 but in event of a specific condition forward to a different
> > > chain)
> > > - it may be the result of a policy and visibility of the SFP
> > > - it may be based on information in the metadata
> > > - there may be unicorns
> > >
> > > There may be a classifier co-resident with the SF or in the path 
> > > from SF back to SFF so that the SPI/SI received by the SFF is not 
> > > a simple decrement of the SI.
> > >
> > > There may be a classifier co-resident with the SFF that processes 
> > > the packet before the SFF performs forwarding so that the SPI/SI 
> > > received by the SFF is not a simple decrement of the SI.
> > >
> > > The SFF's routing lookup may give it a choice of SFIs or SFFs to 
> > > which to send the packet for the given SPI/SI. How it resolves 
> > > this choice is a local matter (some policy that might be load 
> > > balancing and could be influenced by any manner of things if an 
> > > implementation chooses without prejudice to the interoperability 
> > > of replaceability of
> SFFs).
> > > The fact of the choice is a function of how the network has been 
> > > built, and how SFIs have been assigned, and how the SFPs have been 
> > > constructed by the controller - it is not a function of the NSH
> itself.
> > >
> > > The SFF's forwarding instructions can be simple (look up SPI/SI 
> > > and send the packet out of interface X encapsulated in tunnel Y) 
> > > or more complex (make some form of choice and manipulate the 
> > > packet) just as in most other modern forwarding paradigms.
> > >
> > > An SFF that does not recognise the SPI/SI (i.e., has no forwarding 
> > > state for it) can only (read MUST) drop the packet.
> > >
> > > What forwarding state an SFF has is a matter of:
> > > - implementation
> > > - control/management plane instructions
> > > - visibility into the SFP (and other SFPs)
> > >
> > >
> > > I believe this set of rules is consistent with 7665 and also 
> > > supports what the WG wanted to achieve with the NSH draft without 
> > > requiring any limitation on processing. That is, a simple 
> > > implementation as envisaged by the proponents of "MUST decrement 
> > > by one" is able to perform that function and still be conformant 
> > > and
> interoperable.
> > > Similarly, a simple SFF as suggested in this thread would have no
> > problems interoperating.
> > >
> > > Similarly, this behavior is flexible enough to allow for other 
> > > uses and implementations. It is consistent with
> > > draft-mackie-bess-nsh-bgp-control-
> > > plane
> > > (indeed, that draft doesn't tell the SF what to do with the SPI/SI 
> > > at
> > > all) and allows a control plane to program an SFF to do more 
> > > sophisticated things. Of course, if the SFF cannot do those things 
> > > then that will be OK since it won't support those control plane
> > instructions.
> > >
> > > Can we put this to bed with the minimal change to
> > > draft-ietf-sfc-nsh-10 section
> > > 4 as follows:
> > >
> > > OLD
> > >    3.  Update NSH: NSH-aware service functions (SF) MUST decrement the
> > >        service index.  If an SFF receives a packet with an SPI and SI
> > >        that do not correspond to a valid next hop in a valid Service
> > >        Function Path, that packet MUST be dropped by the SFF.
> > > NEW
> > >    3.  Update NSH: NSH-aware service functions (SF) MUST decrement the
> > >        service index.  By default the SF decrements the SI by 1, 
> > > but
> it
> > >        MAY apply other decrements according to configuration and other
> > >        information available to it.  If an SFF receives a packet with
> > >        an SPI and SI for which it does not have forwarding state,
> > >        it MUST be drop the packet, and SHOULD log the event subject to
> > >        rate limiting on such logs.
> > > END
> > >
> > > Similarly later in the same bullet...
> > > OLD
> > >       When the SFC
> > >        Proxy receives a packet back from an NSH unaware SF, it 
> > > MUST
> re-
> > >        encapsulates it with the correct NSH, and MUST decrement the
> > >        Service Index.
> > > NEW
> > >        When the SFC
> > >        Proxy receives a packet back from an NSH unaware SF, it 
> > > MUST
> re-
> > >        encapsulates it with the correct NSH, and MUST decrement the
> > >        Service Index.  By default the SFC Proxy decrements the SI 
> > > by
> 1,
> > >        but it MAY apply other decrements according to 
> > > configuration
> and
> > >        other information available to it.
> > > END
> > >
> > > Furthermore, in section 3.3 since the term "egress NSH packet" is 
> > > either ambiguous or neglects the possibility of reclassification...
> > >
> > > OLD
> > >    Service Index MUST be decremented by Service Functions or by SFC
> > >    Proxy nodes after performing required services and the new
> > >    decremented SI value MUST be used in the egress NSH packet.  The
> > >    initial Classifier MUST send the packet to the first SFF in the
> > >    identified SFP for forwarding along an SFP.  If re-classification
> > >    occurs, and that re-classification results in a new SPI, the
> > >    (re)classifier is, in effect, the initial classifier for the
> > >    resultant SPI.
> > > NEW
> > >    Service Index MUST be decremented by Service Functions or by SFC
> > >    Proxy nodes after performing required services as described in
> > >    Section 4.  The initial Classifier MUST send the packet to the
> > >    first SFF in the identified SFP for forwarding along an SFP.  If
> > >    re-classification occurs, and that re-classification results in a
> > >    new SPI, the (re)classifier is, in effect, the initial 
> > > classifier
> for
> > >    the resultant SPI.
> > > END
> > >
> > >
> > > Now perhaps I can sleep :-)
> > >
> > > Adrian
> > >
> > > > -----Original Message-----
> > > > From: Dave Dolson [mailto:[e-mail]]
> > > > Sent: 01 November 2016 23:22
> > > > To: Surendra Kumar (smkumar); [e-mail]; 'Joel M.
> > > > Halpern'; [e-mail]
> > > > Subject: Re: [sfc] decrementing service function path index
> > > >
> > > > I agree that the SF should be simple.
> > > > But don't confuse decrementing the SI with complexity.
> > > > There is absolutely no configuration required to have the SF 
> > > > decrement the SI
> > > of
> > > > every packet.
> > > > And there is a lot of benefit to keeping the SFF from having 
> > > > rules about
> > > packet
> > > > source.
> > > >
> > > > As far as I'm concerned, the SF decrements the SI, and it has 
> > > > been described
> > > this
> > > > way for a long time. Furthermore, the forwarding is described as 
> > > > a lookup
> > > table
> > > > based on SPI/SI. There is no mention of the source in the 
> > > > forwarding
> > > table.
> > > >
> > > >
> > > >
> > > >
> > > >   Original Message
> > > > From: Surendra Kumar (smkumar)
> > > > Sent: Tuesday, November 1, 2016 7:03 PM
> > > > To: Dave Dolson; [e-mail]; 'Joel M. Halpern'; 
> > > > [e-mail]
> > > > Subject: RE: [sfc] decrementing service function path index
> > > >
> > > >
> > > > Since the forwarders already exists, they are logical components 
> > > > to support
> > > and
> > > > perform NSH based forwarding - forwarding on SFPs, rather than 
> > > > treat them as dumb forwarders. There is benefit to be had, 
> > > > offloads being one of them, on
> > > top
> > > > of end of chain forwarding, etc. needed.
> > > >
> > > > I would rather have SFs focus on servicing the traffic than be 
> > > > burdened with
> > > SPI
> > > > management (whether it is tens or thousands of SPIs) and the 
> > > > forwarding thereof. IOW, consume metadata and service traffic 
> > > > and leave the SFP management to the external forwarders. This 
> > > > not only simplifies the SFs, it
> > > also
> > > > reduces the control plane touch point as it concerns to the SPI
> > > management.
> > > >
> > > > And you don't need complex logic to differentiate between 
> > > > traffic received
> > > from
> > > > one SFF or a SF, this is what we addressed in the forwarding 
> > > > draft
> > > > - trivial
> > > to
> > > > implement even in hardware.
> > > >
> > > > Thanks,
> > > > Surendra.
> > > >
> > > > -----Original Message-----
> > > > From: sfc [mailto:[e-mail]] On Behalf Of Dave Dolson
> > > > Sent: Tuesday, November 01, 2016 1:27 PM
> > > > To: [e-mail]; 'Joel M. Halpern' 
> > > > <[e-mail]>; [e-mail]
> > > > Subject: Re: [sfc] decrementing service function path index
> > > >
> > > > Adrian,
> > > > Thank you for paraphrasing in a clear manner.
> > > >
> > > > Yes, I'm saying that the current (as I understand it) design 
> > > > permits the SFF
> > > to be a
> > > > simple forwarder, not needing to discriminate between packets 
> > > > from another SFF or returning from an SF.
> > > > A single forwarding table handles both cases.
> > > > E.g., at SFF1, when SI=x, send to SF1; when SI=x+1, send to SFF2
> > > >
> > > > So it could tell the difference, but doesn't need to.
> > > > In some cases, an SFF can be a single-interface device, so "from
> SFF"
> > > > or "from
> > > SF"
> > > > is not as simple as checking ingress interface, for example.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Adrian Farrel [mailto:[e-mail]]
> > > > Sent: Tuesday, November 01, 2016 4:00 PM
> > > > To: Dave Dolson; 'Joel M. Halpern'; [e-mail]
> > > > Subject: RE: [sfc] decrementing service function path index
> > > >
> > > > Just clarifying my understanding of what you said (not 
> > > > necessarily agreeing
> > > ;-)
> > > >
> > > > You are saying that an SFF is simply a forwarder and cannot tell 
> > > > the
> > > difference
> > > > between a packet received on a transport tunnel from another SFF 
> > > > and a packet received (back) from an SF that it serves.
> > > >
> > > > Or, more precisely, you are saying that the SFF is simply a 
> > > > forwarder that cannot tell the difference between passing a 
> > > > packet to a local SF and passing
> > > a
> > > > packet on to a remote SFF.
> > > >
> > > > And the SFF sees a packet n+1 times for an SFP with n local SFs.
> > > >
> > > > Is that your point?
> > > >
> > > > Cheers,
> > > > Adrian
> > > >
> > > > --
> > > > Support an author and your imagination.
> > > > Tales from the Wood - Eighteen new fairy tales.
> > > > More Tales from the Wood - Eighteen MORE new fairy tales.
> > > > https://www.feedaread.com/profiles/8604/
> > > > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
> > > > Or buy from me direct.
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Dave Dolson [mailto:[e-mail]]
> > > > > Sent: 01 November 2016 19:35
> > > > > To: [e-mail]; 'Joel M. Halpern'; [e-mail]
> > > > > Subject: RE: [sfc] decrementing service function path index
> > > > >
> > > > > The SF decrements the index so that the SFF doesn't have to 
> > > > > look at the
> > > packet
> > > > > origin in order to determine whether or not to decrement it.
> > > > > We don't want the SFF to have logic like:
> > > > > If NSH packet is from one of addresses x, y z
> > > > >     Decrement SI
> > > > >
> > > > > As currently defined, the SFF simply routes packets by SPI/SI 
> > > > > without having
> > > > to
> > > > > do consider source address.
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: sfc [mailto:[e-mail]] On Behalf Of Adrian 
> > > > > Farrel
> > > > > Sent: Tuesday, November 01, 2016 2:48 PM
> > > > > To: 'Joel M. Halpern'; [e-mail]
> > > > > Subject: Re: [sfc] decrementing service function path index
> > > > >
> > > > > > With regard to the architectural components, the NSH draft 
> > > > > > does not define those.  It is using the architectural, 
> > > > > > logical, components and architecture defined by the SFC 
> > > > > > Architecture
> > > documents.
> > > > >
> > > > > I'd like to understand where in 7665 it says that the SF is 
> > > > > responsible for moving the packet on to the next SF in the 
> > > > > path,
> > > rather than the SFF.
> > > > >
> > > > > I'd also like to understand why the NSH document (that tells 
> > > > > us how to encapsulate, and what to do at each hop in the path) 
> > > > > needs to divide the responsibility for bits of protocol work 
> > > > > between different logical
> > > functional
> > > > > entities. In short, why does the SF decrement the SI, why 
> > > > > isn't this an SFF function? What benefit comes from doing it 
> > > > > this way or did a choice simply
> > > > have
> > > > > to be made?
> > > > >
> > > > > Thanks,
> > > > > Adrian
> > > > >
> > > > > _______________________________________________
> > > > > sfc mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/sfc
> > > >
> > > > _______________________________________________
> > > > sfc mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/sfc
> > >
> > > _______________________________________________
> > > sfc mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/sfc