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

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 4 Mar 2015 18:48:43 +0000

Hi all:

We posted a new draft, but with old content. After the presentation on
simple offloads + Optimization at HNL, we received a lot of feedback.

In including it, we have split the SFP Path Optimization draft into two:
1) this one which limits itself to the offload between SF and SFF
2) the original sfp optimization draft, which focuses on optimization of
the SFP among the SFFs

#2 will be updated to reflect the split

Thanks and we appreciate your comments/questions,
Surendra.

On 3/4/15, 10:36 AM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-kumar-sfc-offloads-00.txt
>has been successfully submitted by Surendra Kumar and posted to the
>IETF repository.
>
>Name:		draft-kumar-sfc-offloads
>Revision:	00
>Title:		Service Function Simple Offloads
>Document date:	2015-03-04
>Group:		Individual Submission
>Pages:		15
>URL:            
>http://www.ietf.org/internet-drafts/draft-kumar-sfc-offloads-00.txt
>Status:         https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/
>Htmlized:       http://tools.ietf.org/html/draft-kumar-sfc-offloads-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 shorter SFC forwarding paths with improved
>   latencies, reduced resource consumption and better user experience.
>
>   This document describes the rationale, techniques and necessary
>   protocol extensions to achieve such optimization, with focus on one
>   such technique termed "simple offloads".
>
>
>                  
>        
>
>
>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: <[email-masked]>
Date: Thu, 5 Mar 2015 08:59:08 +0000

Hi Surendra,

Thank you for sharing this I-D that touches on classification complications in an SFC architecture. Interesting!

I have some quick comments about the draft: 

* It seems that you are assuming that SF and SFF are always separate nodes. SF and SFF are functional elements that may be co-located or not. Whether those are collocated in the same physical node or not is deployment-specific. 

* What would be the behavior when a node hosting several SFs, serviced by the same SFF, receives the offload indication?

* In addition to the potential classification issue you mentioned in your draft, there are other issues that are worth to be considered, e.g.,
   o  Rationalize the management of classification rules.
   o  Help assessing the impact of removing or modifying a
      classification rule.
   o  Check the coherency of instantiated classification rules.
   o  Help aggregating rules: this allows to optimize the classification
      rule table and therefor accelerate packet/flow processing (mainly
      reduce lookup delays).
   o  Adjust classification rules when rules are based on volatile
      identifiers (e.g., IP address).
   o  Maintain an global overview of instantiated rules in involved
      Network Elements.
   o  Rapidly restore state during failure events.
   o  Network Elements can retrieve their table after failure events
      whiteout requiring permanent storage capacity.

Whether classification-related issues should be discussed as a package or individually can be useful to discuss. IMHO, classification burden and SFC OAM are the KEY challenging parts of an SFC architecture. 

* It would be fair to cite this I-D for the control part discussion: https://datatracker.ietf.org/doc/draft-ww-sfc-control-plane/ 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Surendra Kumar
> (smkumar)
> Envoyé : mercredi 4 mars 2015 19:49
> À : [email-masked]
> Objet : [sfc] FW: New Version Notification for draft-kumar-sfc-offloads-
> 00.txt
> 
> Hi all:
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Mar 2015 05:55:19 -0500

I am not sure I understand your concern about co-location.
The mechanisms proposed has to, and as far as I can tell does, work 
whether the SFF is colocated with the SF or in a separate node.  Is the 
confusion caused by some of the example discussion?

As for the case where there are multiple SF handled by the same SFF, 
that is the assumed case.  The SFF can tell which SF is requesting the 
bypass, and apply it only to that SF.

Yours,
Joel

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 5 Mar 2015 15:31:42 +0000

Med,

The offload decision is cached only against the SF requesting it. We don¹t
assume their co-location.

Further, these offload decisions are assumed to be on a flow boundary and
any changes to SF or other classification aspects will take effect with
control actions that lead to the clearing of the offload cache.

Thanks for reviewing the draft,
Surendra.

On 3/5/15, 2:55 AM, "Joel M. Halpern" <[email-masked]> wrote:

>> Thank you for sharing this I-D that touches on classification
>>complications in an SFC architecture. Interesting!
>>
>> * It seems that you are assuming that SF and SFF are always separate
>>nodes. SF and SFF are functional elements that may be co-located or not.
>>Whether those are collocated in the same physical node or not is
>>deployment-specific.
>>
>> * What would be the behavior when a node hosting several SFs, serviced
>>by the same SFF, receives the offload indication?
>>
>> * In addition to the potential classification issue you mentioned in
>>your draft, there are other issues that are worth to be considered, e.g.,
>> Whether classification-related issues should be discussed as a package
>>or individually can be useful to discuss. IMHO, classification burden
>>and SFC OAM are the KEY challenging parts of an SFC architecture.
>>
>> * It would be fair to cite this I-D for the control part discussion:
>>https://datatracker.ietf.org/doc/draft-ww-sfc-control-plane/
>>
>> Thank you.
>>
>> Cheers,
>> Med
>>