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

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 2 Nov 2016 01:52:04 -0000

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:[email-masked]]
> Sent: 01 November 2016 23:22
> To: Surendra Kumar (smkumar); [email-masked]; 'Joel M. Halpern';
> [email-masked]
> 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; [email-masked]; 'Joel M. Halpern'; [email-masked]
> 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:[email-masked]] On Behalf Of Dave Dolson
> Sent: Tuesday, November 01, 2016 1:27 PM
> To: [email-masked]; 'Joel M. Halpern' <[email-masked]>;
> [email-masked]
> 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:[email-masked]]
> Sent: Tuesday, November 01, 2016 4:00 PM
> To: Dave Dolson; 'Joel M. Halpern'; [email-masked]
> 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:[email-masked]]
> > Sent: 01 November 2016 19:35
> > To: [email-masked]; 'Joel M. Halpern'; [email-masked]
> > 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:[email-masked]] On Behalf Of Adrian Farrel
> > Sent: Tuesday, November 01, 2016 2:48 PM
> > To: 'Joel M. Halpern'; [email-masked]
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sfc
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Dave Dolson <[email-masked]>
Date: Wed, 2 Nov 2016 08:50:51 +0000

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'; [email-masked]
Reply To: [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

So...

OLD

OLD

Adrian

of
packet
this
table
and
top
SPI
also
from
to
to be a
SF"
;-)
difference
a
packet
functional

---

From: <[email-masked]>
Date: Wed, 2 Nov 2016 09:04:25 +0000

Hi Adrian, 

Please see inline.

Cheers,
Med

PS: I would love the NSH spec to make the distinction between looping vs. spiraling (https://www.ietf.org/mail-archive/web/sfc/current/msg03179.html)

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Adrian Farrel
> Envoyé : mercredi 2 novembre 2016 02:52
> À : 'Dave Dolson'; 'Surendra Kumar (smkumar)'; 'Joel M. Halpern';
> [email-masked]
> Objet : [sfc] OK. Enough with the looping (spiralling :-) [Was:
> decrementing service function path index]
> 

[Med] This is not the role of an SFW-aware SF but a classifier. All requirements about setting SI/SPI would then be applied for this. 

> - it may be the result of a policy and visibility of the SFP

[Med]  Not sure to understand this one.

>        information available to it. 

[Med] I do think we should maintain the initial wording here. Resetting SI or SPI remarking is the responsibility of a classifier node. Whether this classifier is co-resident with an SFC-aware function is deployment-specific.  

 If an SFF receives a packet with
>        rate limiting on such logs.

[Med] OK for the log.

>        other information available to it.

[Med] Same comment as above.

>    new SPI, the (re)classifier is, in effect, the initial classifier for

[Med] I like this one.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 2 Nov 2016 23:38:25 +0000

Adrian,

This is a very good compromise. Completely agree on "Not preclude sophisticated implementations" and IMO it is crucial to go beyond legacy forwarding methods and allow for, not only flexible implementations as you note, but also for use-case evolution/innovation.

While I agree with the default behavior of SF decrementing by 1, in addition to allowing for it to be decremented by a configured value, I would like that to be extended to explicitly include a decrement value of zero (no decrement). So, I support your modified verbiage below to allow for a decrement value of *ZERO*.

This allows for control-plane/configuration dictated behavior and is flexible enough to support different methods of forwarding. 

Surendra.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2016 6:52 PM
To: 'Dave Dolson' <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

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.
SK> Firstly, why even have SI 

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:

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.
SK> Yes, absolutely. If SFs have co-located classifiers, they can restart a chain or adjust the SI, all based on policy dictated by a higher level entity.

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.

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.

OLD

Furthermore, in section 3.3 since the term "egress NSH packet" is either ambiguous or neglects the possibility of reclassification...

OLD

Adrian

of
packet
this
table
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
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
from
to
to be a
> simple forwarder, not needing to discriminate between packets from 
> another SFF or returning from an SF.
SF"
;-)
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
> > > 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
> >

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 2 Nov 2016 23:46:13 +0000

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:[email-masked]] 
Sent: Wednesday, November 02, 2016 1:51 AM
To: Adrian Farrel <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Adrian,

-Dave

  Original Message
From: Adrian Farrel
Sent: Tuesday, November 1, 2016 9:52 PM
To: Dave Dolson; 'Surendra Kumar (smkumar)'; 'Joel M. Halpern'; [email-masked] Reply To: [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

So...

OLD

OLD

Adrian

of
packet
this
table
and
top
SPI
also
from
to
to be a
SF"
;-)
difference
a
packet
functional

---

From: <[email-masked]>
Date: Thu, 3 Nov 2016 07:01:03 +0000

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

> De : sfc [mailto:[email-masked]] De la part de Surendra Kumar
> (smkumar)
> Envoyé : jeudi 3 novembre 2016 00:46
> À : Dave Dolson; Adrian Farrel; 'Joel M. Halpern'; [email-masked]
> Objet : Re: [sfc] OK. Enough with the looping (spiralling :-) [Was:
> At the risk of spiraling (borrowing Adiran), this reasoning begs the
> question - why even have non-classifier SFs touch the SI to start with ?
> 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.
> 
> To: Adrian Farrel <[email-masked]>; Surendra Kumar (smkumar)
> <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
> Subject: Re: OK. Enough with the looping (spiralling :-) [Was:
> 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.
> 
> 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
> To: Dave Dolson; 'Surendra Kumar (smkumar)'; 'Joel M. Halpern';
> [email-masked] Reply To: [email-masked]
> 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 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:
> 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.
> 
> 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.
> 
> (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.
>

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 3 Nov 2016 09:20:52 -0400

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

 From the perspective of draft-mackie-bess-nsh-bgp-control-plane, it 
doesn't matter whether the SPI/SI gets modified by the SF or by a 
co-resident classifier.  The only thing that matters is what SPI/SI 
values the SFF will need to use as input to its forwarding engine.

A slightly different issue is whether the successive elements of an SPI 
have to have successive integers as their respective SI's.  That doesn't 
seem to be necessary for the proper functioning of the system, so we 
didn't want to assume it.  By not using successive integers, it becomes 
easier to insert and/or delete entries.  And if the SF knows the SI 
(call it "x") of the current element in the chain, it doesn't really 
have to know the SI of the next element in the chain, since the SFF can 
interpret "x-1" to mean "next after x", and can then modify the NSH to 
change the SI to the actual SI of the next element in the chain.

Does this create a technical problem of some sort?

---

From: Dave Dolson <[email-masked]>
Date: Thu, 3 Nov 2016 13:29:29 +0000

Eric,
I was thinking that way originally, that the SI at each hop could be arbitrary.

But can you please take a look at https://tools.ietf.org/html/draft-penno-sfc-packet-03, unfortunately expired.
In section 5.4, there are some "algorithmic" methods of reversing packets on a path that become quite elegant if one can assume each hop is SI-1 from previous.

If you wish to make each hop arbitrary, you must program each SF (not only the SFFs) with full awareness of bidirectional paths (which is section 5.1).

-Dave

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 3 Nov 2016 09:55:32 -0400

You ask whether using non-consecuitive integers for the SI in the path 
breaks something.
It is not forbidden.  You can, after all, reclassify at every hop.  (And 
many current solutions do so.)

However, it is misleading as to the intent and expected usage of SFC. 
While one can manage to make it work with monotonically decreasing but 
non-consecutive SI, it is significantly more complex.

As far as I can tell, the place where this is an issue for the BGP SFC 
control draft is not in the protocol definition.  Rather, it is in the 
examples which all treat non-consecutive as the normal case.  This is 
confusing to readers and likely to drive folks towards assumptions about 
SFC behavior that will not work without additional mechanisms.

Yours,
Joel

On 11/3/16 9:20 AM, Eric C Rosen wrote:
>> decrement-by-one. If you require otherwise, co-locate a classifier
>> with the SF.
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 3 Nov 2016 14:52:56 +0000

[Chair hat off…]
Given that the currently defined architecture allows for the requested behavior through reclassification, I personally see no reason for a change to the way decrement of service index is currently defined, other than making it explicit that decrement means “by 1”.

[Chair hat on…]
I would note that we already have working group agreement on the current NSH specification. Also, the issue of the ease of modification of SFPs was part of earlier working group discussion.  Is there new information that those requesting a behavioral change wish to bring forward?

Jim

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 3 Nov 2016 16:04:00 -0000

Gee shucks, Jim,

Do you think changing "decrement" to "decrement by 1" is not a behavioral change just because it is what you intended when (with your chair hat off) you reviewed the document? 

Or are you one of the people you are asking (with your chair hat on) to bring forward new information?

I, too, would like to see the NSH spec ship, but I would prefer to see it right.

Adrian

PS If both you and Joel simultaneously remove your chair hats, will we hit an iceberg? :-)

PPS I find the discussion about what an SF does compared to what an SF with a co-resident re-classifier does, to be dancing on the head of a pin labelled "Functional Architecture". You are all welcome to implement a functional architecture (and bless you for it), but that is not how products are marked when they ship. You will not be selling "Firewall with Added Reclassifier". Furthermore, the SFF will be entirely unaware of whether reclassification took place. So (at the risk of repeating myself), why is "SF MUST decrement by 1" a requirement in this spec, and why is my proposed compromise text not acceptable?

> From: Jim Guichard (jguichar) [mailto:[email-masked]]
> Sent: 03 November 2016 14:53
> To: Joel M. Halpern; Eric C Rosen; Dave Dolson; Adrian Farrel; Surendra Kumar
> (smkumar); [email-masked]
> Given that the currently defined architecture allows for the requested behavior
> through reclassification, I personally see no reason for a change to the way
> decrement of service index is currently defined, other than making it explicit that
> decrement means “by 1”.
> 
> [Chair hat on…]
> I would note that we already have working group agreement on the current NSH
> specification. Also, the issue of the ease of modification of SFPs was part of
> earlier working group discussion.  Is there new information that those requesting
> a behavioral change wish to bring forward?
> 
> Jim
> 
> 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 3 Nov 2016 16:17:28 -0000

> many current solutions do so.)

Good. We're agreed.

> However, it is misleading as to the intent and expected usage of SFC.

Where would the naïf reader find this intent and expected usage? Clearly it
doesn't show up in RFC 7665 and draft-ietf-sfc-nsh. Maybe it is in another WG
document?

Anyway, perhaps that is the wrong question.
Is diverging from this intent and expected usage going to break interop? Or
would it simply result in SFPs built in this unintended and unexpected way not
working for some implementations of SFFs? 
If that is the scope of the problem then it might be worth calling out, but it
is also worth noting that central controllers need to be aware of the
capabilities of the things they control - sad, but true.

> non-consecutive SI, it is significantly more complex.

Well, that might depend on your definition of "significant". 
I suspect that one line of code might be enough.

> SFC behavior that will not work without additional mechanisms.

Do you mean protocol mechanisms additional to the specifications, or additional
code mechanisms compared to something one might have coded based on an
undocumented assumption of what the existing architecture means?

Anyway (again), if your only concern is that the non-normative examples do not
include a use case where the SI values in the SFP are consecutive, then I think
we may be over-discussing the issue. It is easily fixed.

Cheers,
Adrian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 3 Nov 2016 12:21:22 -0400

Speaking from my discussions with folks about custoemr requirements (and 
thus not as a WG chair), the distinction between the SF and the 
classifier is important to at least some customers.
We have had customers ask us about mechanisms to pevent SF from 
modifying the SPI or mis-modifying the SI.
With a strong distinction in terminology and architecture I have the 
tools to have that discussion (including an Internet Draft I helped with 
on how an SFF can verify things if it chooses to).  Without that 
distinction, it gets complicated to describe the restriction.

Also, it seems that it is not just Jim and I that read the decrement as 
decrement by 1.  While I am sure you can find contexts where decrement 
is used to mean any subtraction, there are also plenty of contexts where 
it is used to mean subtracting exactly one.  Are you actually objecting 
that clarifying the intent is a change to the agreed meaning?

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 3 Nov 2016 16:21:26 +0000

Hi Adrian,

What I intended has no bearing on the discussion and I am simply pointing out that the WG has never to my knowledge exhibited confusion on this point although I accept that the assumption of decrement by 1 should be clarified. I might also point out that numerous implementations are already doing the decrement by 1 so I guess the confusion was not widespread. So in all fairness why is it unreasonable to ask why a behavioral change is necessary when the existing architecture already supports what is being asked for?

Jim

---

From: Dave Dolson <[email-masked]>
Date: Thu, 3 Nov 2016 17:54:11 +0000

I have never understood "increment" or "decrement" used alone to mean anything other than "by 1".
One writes, "decrement by X" if X is not 1.

This issue matters to me because Sandvine has a service function that performs service index decrementing (by one, of course) without requiring control-plane configuration.
To me the functional separation of Classifier and Service Function is not academic; it's real, and it is an elegant separation of responsibility.

Referring also to draft-ietf-sfc-control-plane, the C3 interface to the SF does not include forwarding information (with the exception of how to send a reverse packet--but there are alternatives).

So in terms of "seeing it done right", the functional separation and simplicity is "right".

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, November 03, 2016 12:21 PM
To: [email-masked]; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Hi Adrian,

Jim

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 3 Nov 2016 17:55:24 +0000

Hi Jim,

Inline.

-----Original Message-----
From: Jim Guichard (jguichar) 
Sent: Thursday, November 03, 2016 7:53 AM
To: Joel M. Halpern <[email-masked]>; Eric C Rosen <[email-masked]>; Dave Dolson <[email-masked]>; Adrian Farrel <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

[Chair hat off…]
Given that the currently defined architecture allows for the requested behavior through reclassification, I personally see no reason for a change to the way decrement of service index is currently defined, other than making it explicit that decrement means “by 1”.
SK> There are many SFs that do not perform classification. They are transparently inserted and I believe that is one of the motivations to steer traffic to them in SFC, via NSH. This is not changing the (default) behavior of NSH, but having NSH be more accommodative and it is not unreasonable.

[Chair hat on…]
I would note that we already have working group agreement on the current NSH specification. Also, the issue of the ease of modification of SFPs was part of earlier working group discussion.  Is there new information that those requesting a behavioral change wish to bring forward?
SK> We have had discussions on the 'SI' on this list but it was *never conclusive*.  If I recollect, your chair hat came down on us :-)

Surendra.

Jim

On 11/3/16, 9:55 AM, "sfc on behalf of Joel M. Halpern" <[email-masked] on behalf of [email-masked]> wrote:

>It is not forbidden.  You can, after all, reclassify at every hop.  
>(And many current solutions do so.)
>
>confusing to readers and likely to drive folks towards assumptions 
>about SFC behavior that will not work without additional mechanisms.
>
>Yours,
>Joel
>
>> A slightly different issue is whether the successive elements of an 
>> SPI have to have successive integers as their respective SI's.  That 
>> doesn't seem to be necessary for the proper functioning of the 
>> system, so we didn't want to assume it.  By not using successive 
>> integers, it becomes easier to insert and/or delete entries.  And if 
>> the SF knows the SI (call it "x") of the current element in the 
>> chain, it doesn't really have to know the SI of the next element in 
>> the chain, since the SFF can interpret "x-1" to mean "next after x", 
>> and can then modify the NSH to change the SI to the actual SI of the next element in the chain.
>>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 3 Nov 2016 18:25:57 +0000

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.

I can imagine implementations wanting to jump over an SF under policy control, either statically or dynamically, just as one simple example. 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.

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: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 03, 2016 12:01 AM
To: Surendra Kumar (smkumar) <[email-masked]>; Dave Dolson <[email-masked]>; Adrian Farrel <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Hi Surendra, 

Cheers,
Med

> À : Dave Dolson; Adrian Farrel; 'Joel M. Halpern'; [email-masked] Objet 
> : Re: [sfc] OK. Enough with the looping (spiralling :-) [Was:
> 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.
> 
> 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.
> 
> 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...
> 
> Subject: OK. Enough with the looping (spiralling :-) [Was: 
> 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...
> 
> 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:
> 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.
> 
> 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.
> 
> 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.
> 
> Furthermore, in section 3.3 since the term "egress NSH packet" is 
> either ambiguous or neglects the possibility of reclassification...
> 
> OLD
> > To: Surendra Kumar (smkumar); [email-masked]; 'Joel M. 
> > Halpern'; [email-masked]
> > 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
> > > 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
> > >

---

From: <[email-masked]>
Date: Fri, 4 Nov 2016 07:49:09 +0000

Hi Surendra, 

Please see inline. 

Cheers,
Med

> De : Surendra Kumar (smkumar) [mailto:[email-masked]]
> Envoyé : jeudi 3 novembre 2016 19:26
> À : BOUCADAIR Mohamed IMT/OLN; Dave Dolson; Adrian Farrel; 'Joel M.
> Halpern'; [email-masked]
> 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/
> 
> To: Surendra Kumar (smkumar) <[email-masked]>; Dave Dolson
> <[email-masked]>; Adrian Farrel <[email-masked]>; 'Joel M.
> Halpern' <[email-masked]>; [email-masked]
> Subject: RE: OK. Enough with the looping (spiralling :-) [Was:
> It seems to me that we are trying to modifyi the SFC data plane
> architecture to accommodate a given control plane solution proposal.
>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Sun, 6 Nov 2016 21:09:04 +0000

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.

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

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: [email-masked] [mailto:[email-masked]] 
Sent: Friday, November 04, 2016 12:49 AM
To: Surendra Kumar (smkumar) <[email-masked]>; Dave Dolson <[email-masked]>; Adrian Farrel <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Hi Surendra, 

Please see inline. 

Cheers,
Med

> De : Surendra Kumar (smkumar) [mailto:[email-masked]] Envoyé : 
> jeudi 3 novembre 2016 19:26 À : BOUCADAIR Mohamed IMT/OLN; Dave 
> Dolson; Adrian Farrel; 'Joel M.
> Halpern'; [email-masked]
> Objet : RE: OK. Enough with the looping (spiralling :-) [Was: 
> It is relaxing the rigid requirement, requiring decrement by one and 
> only one. This would be too restrictive a language to put inside NSH.

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

> > Envoyé : jeudi 3 novembre 2016 00:46 À : Dave Dolson; Adrian Farrel; 
> > 'Joel M. Halpern'; [email-masked] Objet
> > 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.
> >
> > 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.
> >
> > 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 
> > When an SF has finished processing a packet the default behavior is 
> > to leave the SPI unchanged and to decrement the SI by 1.
> >
> > 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).
> > 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.
> > > based on SPI/SI. There is no mention of the source in the 
> > > forwarding
> > table.
> > >
> > >
> > >
> > >
> > >   Original Message
> > > 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
> > > between a packet received on a transport tunnel from another SFF 
> > > and a packet received (back) from an SF that it serves.
> > >
> > > > > 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.
> > > >
> > > > 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
> > > > this an SFF function? What benefit comes from doing it this way 
> > > > or did a choice simply
> > > have
> > > > to be made?
> > > >
> > > > Thanks,
> > > > Adrian
> > > >

---

From: <[email-masked]>
Date: Mon, 7 Nov 2016 13:27:45 +0000

Hi Surendra, 

Please see inline.

Cheers,
Med

> Envoyé : dimanche 6 novembre 2016 22:09
> 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):

   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): 

   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.
> 
> [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.
> 
> >
> (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.
> 
> 
> [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.
> > > > In some cases, an SFF can be a single-interface device, so "from
> SFF"
> > > > or "from
> > > SF"

---

From: Dave Dolson <[email-masked]>
Date: Mon, 7 Nov 2016 17:35:01 +0000

Surendra,
When you would have the Service Function not modify the Service Index, can you explain how the SFF is configured to discriminate between the two cases in this example?
1. NSH packet arrives from another SFF with SPI=10 and SI=255 (requires forwarding to SF1)
2. NSH packet arrives from SF1 with SPI=10 and SI=255  (already serviced)

Is it fair to say that there is a source-routing input to the SFF decision, adding an new "From" column to the table of https://tools.ietf.org/html/draft-ietf-sfc-nsh-10#section-7.1 ?

+-------------------------------------------------------------------+
| FROM      |  SPI |  SI |  Next hop(s)        |   Transport        |
+-------------------------------------------------------------------+
| SFF1      |  10  | 255 |  192.0.2.1          |   VXLAN-gpe        |
+-------------------------------------------------------------------+
| 192.0.2.1 |  10  | 255 |  198.51.100.10      |   GRE              |
+-------------------------------------------------------------------+
...
+-------------------------------------------------------------------+

-Dave

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]] 
Sent: Wednesday, November 02, 2016 7:38 PM
To: [email-masked]; Dave Dolson; 'Joel M. Halpern'; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Adrian,

Surendra.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2016 6:52 PM
To: 'Dave Dolson' <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

So...

OLD

OLD

Adrian

of
packet
this
table
and
top
SPI
also
from
to
to be a
SF"
;-)
difference
a
packet
functional

---

From: Ron Parker <[email-masked]>
Date: Mon, 7 Nov 2016 17:50:52 +0000

Dave,

I agree with your conclusion.   Decrementing SI at SFF requires the From field in its forwarding table/logic.

That being said, I'm not opposed to making SI decrement an SFF responsibility, with an acknowledgement of the above consequence.

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, November 7, 2016 12:35 PM
To: Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,
When you would have the Service Function not modify the Service Index, can you explain how the SFF is configured to discriminate between the two cases in this example?
1. NSH packet arrives from another SFF with SPI=10 and SI=255 (requires forwarding to SF1) 2. NSH packet arrives from SF1 with SPI=10 and SI=255  (already serviced)

-Dave

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 7:38 PM
To: [email-masked]; Dave Dolson; 'Joel M. Halpern'; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Adrian,

Surendra.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, November 01, 2016 6:52 PM
To: 'Dave Dolson' <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

So...

OLD

OLD

Adrian

of
packet
this
table
and
top
SPI
also
from
to
to be a
SF"
;-)
difference
a
packet
functional

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 7 Nov 2016 18:46:26 +0000

Dave,

In general, this whole scheme of "SFF decrement" is naive: it adds complexity and changes the semantics of service completion.  As you point out, decrementing on the SFF requires that the SFF know about the source "type" of packet: did it come from an SF, or an SFF.  In effect, the SFF has some form state that it tracks.  Sure you can that state around, but then you've done nothing new.

Perhaps more importantly, SI _means_ something.  It means that the service has completed it's task.  This has a slew of benefits, ranging from simple visibility, to trace, to security, particularly when/if crypto is applied.

The current model, ensures both a simple SFF, and a consistent representation of service "done", and is implemented.

Paul

> On Nov 7, 2016, at 12:35 PM, Dave Dolson <[email-masked]> wrote:
> 
> Surendra,

---

From: Dave Dolson <[email-masked]>
Date: Mon, 7 Nov 2016 21:04:19 +0000

Paul,

Then I think we are in agreement.

-Dave

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]] 
Sent: Monday, November 07, 2016 1:46 PM
To: Dave Dolson
Cc: [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Dave,

Paul

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 7 Nov 2016 22:36:39 +0000

Hi Med,

Some comments inline, please see SK>

Rgds,
Surendra.

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

Hi Surendra, 

Please see inline.

Cheers,
Med

> dimanche 6 novembre 2016 22:09 À : BOUCADAIR Mohamed IMT/OLN; Dave 
> [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.
> 

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

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

And 

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

> 
> 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.
> 
> 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.
> 
> (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.
> 
> 
> > 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.
> > > Envoyé : jeudi 3 novembre 2016 00:46 À : Dave Dolson; Adrian 
> > > Farrel; 'Joel M. Halpern'; [email-masked] Objet
> > > At the risk of spiraling (borrowing Adiran), this reasoning begs 
> > > the question - why even have non-classifier SFs touch the SI to 
> > > start with
> ?
> > > 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.
> > >
> > > decrement-by-one. I don't know how to begin reasoning about 
> > > reverse forwarding once reclassification is added...
> > >
> > > When an SF has finished processing a packet the default behavior 
> > > is to leave the SPI unchanged and to decrement the SI by 1.
> > >
> > > from SF back to SFF so that the SPI/SI received by the SFF is not 
> > > 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 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.
> > >
> > > implementation as envisaged by the proponents of "MUST decrement 
> > > by one" is able to perform that function and still be conformant 
> > > and
> interoperable.
> > > Similarly, this behavior is flexible enough to allow for other 
> > > uses and implementations. It is consistent with
> > >        service index.  By default the SF decrements the SI by 1, 
> > > but
> it
> > >        Proxy receives a packet back from an NSH unaware SF, it 
> > > MUST
> re-
> > >        Proxy receives a packet back from an NSH unaware SF, it 
> > > MUST
> re-
> > >        Service Index.  By default the SFC Proxy decrements the SI 
> > > by
> 1,
> > >        but it MAY apply other decrements according to 
> > > configuration
> and
> > >    new SPI, the (re)classifier is, in effect, the initial 
> > > classifier
> for
> > >    the resultant SPI.
> > > END
> > >
> > >
> > > > 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
> > > > one SFF or a SF, this is what we addressed in the forwarding 
> > > > draft
> > > > - trivial
> > > to
> > > > To: [email-masked]; 'Joel M. Halpern' 
> > > > <[email-masked]>; [email-masked]
> > > > simple forwarder, not needing to discriminate between packets 
> > > > from another SFF or returning from an SF.
> > > > forwarder that cannot tell the difference between passing a 
> > > > packet to a local SF and passing
> > > a
> > > > > 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) 
> > > > > 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
> > > > >

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 7 Nov 2016 22:39:33 +0000

Hi Dave,

Please look at https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-forwarding/
It is discussed in detail.

It uses a single bit, managed by SFs, to make the <SPI,SI> opaque to SFs. This single bit is needed only because it is not the default behavior in NSH.

Surendra.

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

Surendra,

-Dave

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 7:38 PM
To: [email-masked]; Dave Dolson; 'Joel M. Halpern'; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Adrian,

Surendra.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, November 01, 2016 6:52 PM
To: 'Dave Dolson' <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

So...

OLD

OLD

Adrian

of
packet
this
table
and
top
SPI
also
from
to
to be a
SF"
;-)
difference
a
packet
functional

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 7 Nov 2016 22:50:03 +0000

Hi Ron,

As Adrian proposed and as I already agreed to, default behavior is ok as long as we are not precluding sophisticated implementations.

Two changes being sought, both does not affect the default behavior:
1. Allow SFFs and only SFFs to manage the <SPI,SI>, while having the default behavior of what it is now
2. Allow the decrement to be anything other than 'one', as per CP policy

I think you agree with this.
Surendra.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, November 07, 2016 9:51 AM
To: Dave Dolson <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Dave,

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, November 7, 2016 12:35 PM
To: Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,

-Dave

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 7:38 PM
To: [email-masked]; Dave Dolson; 'Joel M. Halpern'; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Adrian,

Surendra.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, November 01, 2016 6:52 PM
To: 'Dave Dolson' <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

So...

OLD

OLD

Adrian

of
packet
this
table
and
top
SPI
also
from
to
to be a
SF"
;-)
difference
a
packet
functional

---

From: Ron Parker <[email-masked]>
Date: Mon, 7 Nov 2016 22:55:00 +0000

I think #1 could be complicated in practice, since you need coordination between all SFFs and SFs as to whose responsibility it is to perform the decrement.   I'd prefer to stick with the default as the sole solution rather than introduce this complexity.   Regarding #2, I think it is fine for an SF to decrement by more than 1, thereby deciding to skip over subsequent SF(s).   I'm also ok saying that an SF that does that is also behaving as a classifier.

   Ron

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]] 
Sent: Monday, November 7, 2016 5:50 PM
To: Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Hi Ron,

Two changes being sought, both does not affect the default behavior:
1. Allow SFFs and only SFFs to manage the <SPI,SI>, while having the default behavior of what it is now 2. Allow the decrement to be anything other than 'one', as per CP policy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, November 07, 2016 9:51 AM
To: Dave Dolson <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Dave,

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, November 7, 2016 12:35 PM
To: Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,

-Dave

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 7:38 PM
To: [email-masked]; Dave Dolson; 'Joel M. Halpern'; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Adrian,

Surendra.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, November 01, 2016 6:52 PM
To: 'Dave Dolson' <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

So...

OLD

OLD

Adrian

of
packet
this
table
and
top
SPI
also
from
to
to be a
SF"
;-)
difference
a
packet
functional

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 7 Nov 2016 22:55:20 +0000

I meant to say, it had to be specified outside of NSH as it is not the default behavior.
Surendra.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar (smkumar)
Sent: Monday, November 07, 2016 2:40 PM
To: Dave Dolson <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Hi Dave,

Surendra.

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

Surendra,

-Dave

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 7:38 PM
To: [email-masked]; Dave Dolson; 'Joel M. Halpern'; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Adrian,

Surendra.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, November 01, 2016 6:52 PM
To: 'Dave Dolson' <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

So...

OLD

OLD

Adrian

of
packet
this
table
and
top
SPI
also
from
to
to be a
SF"
;-)
difference
a
packet
functional

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 7 Nov 2016 23:01:57 +0000

I am afraid we will spiral on this one. 

It is not complicated, but only makes it simpler by having SFF manage the forwarding while SF deliver the service.
I would imagine there would be less number of SFFs to program (the forwarding state) than SFs, to start with. And SFs do not have to deal with forwarding state.

If we would like to remove the lines between the SF and the SFF, the SFC architecture can do away with SFF.

Surendra.

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Monday, November 07, 2016 2:55 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

   Ron

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Monday, November 7, 2016 5:50 PM
To: Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Hi Ron,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, November 07, 2016 9:51 AM
To: Dave Dolson <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Dave,

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, November 7, 2016 12:35 PM
To: Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,

-Dave

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 7:38 PM
To: [email-masked]; Dave Dolson; 'Joel M. Halpern'; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Adrian,

Surendra.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, November 01, 2016 6:52 PM
To: 'Dave Dolson' <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

So...

OLD

OLD

Adrian

of
packet
this
table
and
top
SPI
also
from
to
to be a
SF"
;-)
difference
a
packet
functional

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 7 Nov 2016 23:10:24 +0000

Comments inline.

Surendra.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Monday, November 07, 2016 10:46 AM
To: Dave Dolson <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Dave,

In general, this whole scheme of "SFF decrement" is naive: it adds complexity and changes the semantics of service completion.  As you point out, decrementing on the SFF requires that the SFF know about the source "type" of packet: did it come from an SF, or an SFF.  In effect, the SFF has some form state that it tracks.  Sure you can that state around, but then you've done nothing new.
SK> A single bit, in the packet, if that is what you call the state - nothing in the SFF.
We already have 32 bits of state - <SFF, SI> in NSH. This additional bit can even be carved out of the same 32 bits, if that simplifies ?

Perhaps more importantly, SI _means_ something.  It means that the service has completed it's task.  This has a slew of benefits, ranging from simple visibility, to trace, to security, particularly when/if crypto is applied.
SK> SI==where you are on the chain. The benefits are discussed in https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-forwarding/

The current model, ensures both a simple SFF, and a consistent representation of service "done", and is implemented.
SK> SFF stays very simple with SFF decrements while SF becomes even simpler w.r.t forwarding.

Paul

> 1. NSH packet arrives from another SFF with SPI=10 and SI=255 
> (requires forwarding to SF1) 2. NSH packet arrives from SF1 with 
> SPI=10 and SI=255  (already serviced)
> 
> To: 'Dave Dolson' <[email-masked]>; Surendra Kumar (smkumar) 
> draft-mackie-bess-nsh-bgp-control-plane
>> that cannot tell the difference between passing a packet to a local 
>> SF and passing
> a
>>>> define those.  It is using the architectural, logical, components 
>>>> and architecture defined by the SFC Architecture documents.
>>>

---

From: Dave Dolson <[email-masked]>
Date: Mon, 7 Nov 2016 23:11:45 +0000

Surendra,

I think it is misleading to imply SFs need to be programmed to decrement SI by 1. This behavior can be (and should be, IMO) hard-coded. Furthermore, there is not any extra "forwarding state".

So it is false to say that decrementing the SI in the SFF is easier to configure. In fact it is harder to configure due to the source routing requirements mentioned earlier.

-Dave

  Original Message
From: Surendra Kumar (smkumar)
Sent: Monday, November 7, 2016 6:02 PM
To: Ron Parker; Dave Dolson; [email-masked]; 'Joel M. Halpern'; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra.

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Monday, November 07, 2016 2:55 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

   Ron

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Monday, November 7, 2016 5:50 PM
To: Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Hi Ron,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, November 07, 2016 9:51 AM
To: Dave Dolson <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Dave,

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, November 7, 2016 12:35 PM
To: Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,

-Dave

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 7:38 PM
To: [email-masked]; Dave Dolson; 'Joel M. Halpern'; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Adrian,

Surendra.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, November 01, 2016 6:52 PM
To: 'Dave Dolson' <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

So...

OLD

OLD

Adrian

of
packet
this
table
and
top
SPI
also
from
to
to be a
SF"
;-)
difference
a
packet
functional

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 7 Nov 2016 23:22:56 +0000

Dave,

It is very misleading to say <SPI, SI> is not a forwarding state. It is false to say "source routing" unless you mean entire SFC is a source-route, because it is already fully specified.

Then, why not have SFC (architecture) go from CF to SF to SF ... and not have the SFF demarcation, over dumb forwarders/infrastructure?

Surendra.

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Monday, November 07, 2016 3:12 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Ron Parker <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,

-Dave

  Original Message

Surendra.

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Monday, November 07, 2016 2:55 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

   Ron

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Monday, November 7, 2016 5:50 PM
To: Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Hi Ron,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, November 07, 2016 9:51 AM
To: Dave Dolson <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Dave,

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, November 7, 2016 12:35 PM
To: Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,

-Dave

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 7:38 PM
To: [email-masked]; Dave Dolson; 'Joel M. Halpern'; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Adrian,

Surendra.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, November 01, 2016 6:52 PM
To: 'Dave Dolson' <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

So...

OLD

OLD

Adrian

of
packet
this
table
and
top
SPI
also
from
to
to be a
SF"
;-)
difference
a
packet
functional

---

From: Lucy yong <[email-masked]>
Date: Tue, 8 Nov 2016 02:32:13 +0000

Surendra,

"2. Allow the decrement to be anything other than 'one', as per CP policy."

I am not sure what SFC use case demands this implementation. 

Having one rule to set SI value (i.e. SF decrements by one) provides clear and simple implementation in which SFs do not need to maintain "decrement value" state per a SPI basis, which is great benefit for implementation and operation. 

I prefer not adding this complexity to NSH. 

Regards,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar (smkumar)
Sent: Monday, November 07, 2016 5:23 PM
To: Dave Dolson; Ron Parker; [email-masked]; 'Joel M. Halpern'; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Dave,

Surendra.

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, November 07, 2016 3:12 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Ron Parker <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,

-Dave

  Original Message

Surendra.

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Monday, November 07, 2016 2:55 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

   Ron

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Monday, November 7, 2016 5:50 PM
To: Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Hi Ron,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, November 07, 2016 9:51 AM
To: Dave Dolson <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Dave,

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, November 7, 2016 12:35 PM
To: Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,

-Dave

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 7:38 PM
To: [email-masked]; Dave Dolson; 'Joel M. Halpern'; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Adrian,

Surendra.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, November 01, 2016 6:52 PM
To: 'Dave Dolson' <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

So...

OLD

OLD

Adrian

of
packet
this
table
and
top
SPI
also
from
to
to be a
SF"
;-)
difference
a
packet
functional

---

From: <[email-masked]>
Date: Tue, 8 Nov 2016 06:26:22 +0000

Hi Surendra, 

Please see inline.

Cheers,
Med

> Envoyé : lundi 7 novembre 2016 23:37
> [Med] We already have a "CP controlled SFC forwarding table". The
> consensus of the WG on the forwarding table is as follows (CP draft):
> 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.
> 

[Med] The only setting of SI called out in the CP draft is the following: 

   The control plane must instruct the classifier about the initial
   values of the Service Index (SI).

The processing of SI by other SFC-aware nodes is complaint to the data plane documents (read SFC architecture, SFC NSH).

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 8 Nov 2016 23:52:09 +0000

Hi Lucy,

See comments inline.

-----Original Message-----
From: Lucy yong [mailto:[email-masked]] 
Sent: Monday, November 07, 2016 6:32 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Dave Dolson <[email-masked]>; Ron Parker <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,

I am not sure what SFC use case demands this implementation. 
SK> we talked about a couple. It is better not to preclude other/future implementations, just the same way there exists '8-bits' for SI. As an example, are there use cases with service chains that long, right now ?

Having one rule to set SI value (i.e. SF decrements by one) provides clear and simple implementation in which SFs do not need to maintain "decrement value" state per a SPI basis, which is great benefit for implementation and operation. 
SK> It can be made even easier by having SFs NOT do anything with SI, extending the benefit you bring up.
SK> Moreover, this is a non-default behavior.

Thanks,
Surendra.

Regards,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar (smkumar)
Sent: Monday, November 07, 2016 5:23 PM
To: Dave Dolson; Ron Parker; [email-masked]; 'Joel M. Halpern'; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Dave,

Surendra.

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, November 07, 2016 3:12 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Ron Parker <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,

-Dave

  Original Message

Surendra.

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Monday, November 07, 2016 2:55 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

   Ron

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Monday, November 7, 2016 5:50 PM
To: Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Hi Ron,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, November 07, 2016 9:51 AM
To: Dave Dolson <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Dave,

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, November 7, 2016 12:35 PM
To: Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,

-Dave

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 7:38 PM
To: [email-masked]; Dave Dolson; 'Joel M. Halpern'; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Adrian,

Surendra.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, November 01, 2016 6:52 PM
To: 'Dave Dolson' <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

So...

OLD

OLD

Adrian

of
packet
this
table
and
top
SPI
also
from
to
to be a
SF"
;-)
difference
a
packet
functional

---

From: Lucy yong <[email-masked]>
Date: Wed, 9 Nov 2016 13:38:50 +0000

Surendra,

See inline.

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]] 
Sent: Tuesday, November 08, 2016 5:52 PM
To: Lucy yong; Dave Dolson; Ron Parker; [email-masked]; 'Joel M. Halpern'; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Hi Lucy,

See comments inline.

-----Original Message-----
From: Lucy yong [mailto:[email-masked]]
Sent: Monday, November 07, 2016 6:32 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Dave Dolson <[email-masked]>; Ron Parker <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,

I am not sure what SFC use case demands this implementation. 
SK> we talked about a couple. It is better not to preclude other/future implementations, just the same way there exists '8-bits' for SI. As an example, are there use cases with service chains that long, right now ?
[Lucy] "It is better not to preclude other/future implementations", that is not always better. IMO: A protocol is to preclude some other implementations. No desire to debate on this.

Having one rule to set SI value (i.e. SF decrements by one) provides clear and simple implementation in which SFs do not need to maintain "decrement value" state per a SPI basis, which is great benefit for implementation and operation. 
SK> It can be made even easier by having SFs NOT do anything with SI, extending the benefit you bring up.
[Lucy] As Dave mentioned, people had quite debates on whether SF or SFF should decrement SI value and the WG agreed to let SI doing it. 
SK> Moreover, this is a non-default behavior.
[Lucy] supporting multiple behavior introduces complex. Unless the use cases require that, no need to introduce complexity.

Lucy 

Thanks,
Surendra.

Regards,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar (smkumar)
Sent: Monday, November 07, 2016 5:23 PM
To: Dave Dolson; Ron Parker; [email-masked]; 'Joel M. Halpern'; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Dave,

Surendra.

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, November 07, 2016 3:12 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Ron Parker <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,

-Dave

  Original Message

Surendra.

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Monday, November 07, 2016 2:55 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

   Ron

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Monday, November 7, 2016 5:50 PM
To: Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Hi Ron,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, November 07, 2016 9:51 AM
To: Dave Dolson <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Dave,

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, November 7, 2016 12:35 PM
To: Surendra Kumar (smkumar) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Surendra,

-Dave

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 7:38 PM
To: [email-masked]; Dave Dolson; 'Joel M. Halpern'; [email-masked]
Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

Adrian,

Surendra.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, November 01, 2016 6:52 PM
To: 'Dave Dolson' <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index]

So...

OLD

OLD

Adrian

of
packet
this
table
and
top
SPI
also
from
to
to be a
SF"
;-)
difference
a
packet
functional