Subject: Re: [forces] [sfc] comments on draft-quinn-sfc-problem-statement-02

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 14 Jan 2014 09:04:58 -0500

Hi Ron,

On Tue, Jan 14, 2014 at 7:55 AM, Ron Parker
<[email-masked]> wrote:
> Hi, Jamal.
>
> I'm not very familiar with the details of FORCES, so I have a few questions.
>
> Just as the referenced slide points out that DPI at every service function is undesirable, it may be that fully qualified flow tracking at every service function is undesirable, too, although clearly some will need to in order to perform their function.   How would FORCES handle that?   Would full flow learning become mandatory?
>

The whole point behind  pipeline indexing is to avoid things of that sort.
It would be upto the service definition: as an _example_,
something like DPI would happen at  one stage of the pipeline and
the results are useable further down stream.

> In FORCES, Is there a signaling component operating at the fully qualified flow level?  In a network with 10's or 100's of millions of active fully qualified flows, what are the scaling properties of FORCES?
>

I am not sure i understood the context of "fully qualified flow level"
but let me see if i can
answer your question (and i worry this list is the wrong place for
such a discussion,
come to the ForCES list which I am CCing with any further discussion).

ForCES defines a model per network function.
(ForCES term for a network function would be LFB).
A service  would then be a graph of instantiated network functions
To your scaling question. You scale the service either:
- vertically by using a higher performing network function
(eg an ASIC assisted DPI engine as opposed to purely software running
in user space)
- horizontally as specified by creating appropriate service graphs
that pipeline (as pointed
in that draft) or you could go further and use systolic approaches (as
an example take a look
at: http://tools.ietf.org/search/draft-haleplidis-forces-packet-parallelization-04)
Now - dont let the two drafts confuse you because they take a very fine grained
approach to what a network function.

The protocol is designed to be scale for control activities where
throughput and latency are
relevant attributes. It is also used for management where usability
maybe more of value.

So scaling was an important part of the initial design.
Not sure if i answered your question.
If you want a quick dump on the features:
http://www.ietf.org/proceedings/86/slides/slides-86-sdnrg-2.pdf

We are working to publish a tutorial RSN.

cheers,
jamal

> Thanks.
>
>    Ron
>
>
>> On Jan 14, 2014, at 6:17 AM, "Jamal Hadi Salim" <[email-masked]> wrote:
>>
>> Some context:
>> ForCES is defining what is known as the inter-FE LFB
>> (http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-03)
>> to describe chaining of network functions.
>>
>> One of the desires ForCES has is for horizontal scaling of
>> network functions/service.
>> We would like to take a network function or service and split
>> its parts across several processing resources. This requires to
>> pass around relevant "Pipeline stage indices"
>> Brad McConnell did touch on it here (slide 6):
>> http://www.ietf.org/proceedings/87/slides/slides-87-nsc-6.pdf
>>
>> This view is missing from the problem space.
>>
>> Additionally - we have a requirement to be able pass arbitrary
>> metadata between nodes (means desire to have more than just
>> basic 32/64 bit constructs)
>>
>> cheers,
>> jamal
>> _______________________________________________
>> sfc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sfc