Subject: [sfc] FW: New Version Notification for draft-kumar-sfc-sfp-optimization-00.txt

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 25 Jun 2014 01:47:05 +0000

Hi,

We published a new draft last month.
Just occurred to me that I never forwarded this to the list.

Surendra.

On 5/10/14 11:54 AM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-kumar-sfc-sfp-optimization-00.txt
>has been successfully submitted by Surendra Kumar and posted to the
>IETF repository.
>
>Name:		draft-kumar-sfc-sfp-optimization
>Revision:	00
>Title:		Service Function Path Optimization
>Document date:	2014-05-10
>Group:		Individual Submission
>Pages:		14
>URL:            
>http://www.ietf.org/internet-drafts/draft-kumar-sfc-sfp-optimization-00.tx
>t
>Status:         
>https://datatracker.ietf.org/doc/draft-kumar-sfc-sfp-optimization/
>Htmlized:       
>http://tools.ietf.org/html/draft-kumar-sfc-sfp-optimization-00
>
>
>Abstract:
>   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.
>   Steering traffic to service functions only while required and not
>   otherwise, leads to optimal SFCs with improved latencies, reduced
>   resource consumption and better user experience.
>
>   This document describes the rationale, techniques and necessary
>   protocol extensions to achieve such optimization.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 25 Jun 2014 14:31:37 +0000

Hello Surendra

Interesting reading. Thank you for that.

I have couple of questions related to this draft (and to the arch draft):

In section Definition of Terms you define:

Network Forwarder (NF):  The entity, typically part of the network
       infrastructure, responsible for performing the transport function
       in traffic forwarding.

Service Controller (SC):  The entity, typically part of the network
       infrastructure, responsible for performing the transport function
       in traffic forwarding.

So if they are the same (NF = SC) why to have two different names? 

Why is optimum path in its best case starting and terminating at the classifier itself (in section 3). Is a null service path a service path? Do you add a NSH into that one? If not what makes the optimum path of null path a service path?

It is interesting choice that you do not ack transactions of offloading, action, etc but you allow capability exchange.   

Now this one is hard to me:

You write: Although SFs can signal SFFs by piggy backing on the serviced packet,
   SFFs cannot repeat the same towards upstream SFFs as the traffic is
   forwarded along the SFP while the signaling has to go back to the
   upstream SFFs.

But isn't NF in the same position to SFF as what SFFs are for SFs?

- Hannu

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of ext Surendra Kumar (smkumar)
Sent: Wednesday, June 25, 2014 4:47 AM
To: [email-masked]
Subject: [sfc] FW: New Version Notification for draft-kumar-sfc-sfp-optimization-00.txt

Hi,

Surendra.

>until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 25 Jun 2014 21:54:03 +0000

Hannu,

Thanks for reading and the comments. Comments/responses inline.

Surendra.

>So if they are the same (NF = SC) why to have two different names?
SK> I had a review comment to fix this but it still fell through; will
take care of it, thanks.
SC is the entity responsible for managing the service chains, including
create/delete/update actions as well as programming the service forwarding
state in the network - SFP distribution.

> 
>
>
>Why is optimum path in its best case starting and terminating at the
>classifier itself (in section 3). Is a null service path a service path?
>Do you add a NSH into that one? If not what makes the optimum path of
>null path a service path?
SK> Classifier is the one starting the service path on a packet/frame,
after which it may traverse many NFs/SFFs. In this reference example, if
the offloads are propagated to the source - the service path
originator/classifier, there is no need for steering of traffic altogether.
It is not a null service path as the path can be un-wound if the service
functions on that path require traffic to be steered to them at a later
point. We leave the details to the implementation.

>
>
>It is interesting choice that you do not ack transactions of offloading,
>action, etc but you allow capability exchange.
SK> I suppose ACKs can be added, which adds overhead. As it is, it does
not violate the correctness even if the offload is not honored for any
reason.

>But isn't NF in the same position to SFF as what SFFs are for SFs?
SK> That is correct. In general, the principle is to pass additional
metadata (such as offloads) with the packet at hand - in band, as opposed
to generating signaling only packets - out of band. For optimization to
work, SFFs have to signal the upstream SFF (for the SFP) of the offload.
However the packet itself goes downstream. Implementations can choose to
do the signaling out of band or can potentially use the opposite flow to
do it in band.

I will clarify this further in the next revision. We did not want to get
into the specifics of how the offloads are signaled between SFFs.