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

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

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

---

From: Ron Parker <[email-masked]>
Date: Tue, 14 Jan 2014 12:55:03 +0000

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?

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?

Thanks. 

   Ron

> On Jan 14, 2014, at 6:17 AM, "Jamal Hadi Salim" <[email-masked]> wrote:
> 
> Some context:
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 14 Jan 2014 13:19:03 +0000

Hi Jamal,

Thanks for this input. Comments inline.

>This view is missing from the problem space.

Jim> I agree. Do you have suggested text that can be reviewed and
discussed further?

>basic 32/64 bit constructs)

Jim> I think this is an area that will require some discussion as part of
the SFC architecture. The problem statement has no "solution" text and
simply states that metadata between the network and SF's, and between
SF's, is needed. The format of that metadata should be discussed outside
of the problem statement.

---

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

Hi Ron,

> 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 clear…

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…

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

---

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

Hi Jim,

> Jim> I agree. Do you have suggested text that can be reviewed and

Ok, let me re-scan the draft one more time and then i will suggest
some text.

> of the problem statement.

Fair enough. I am hoping i can bring it up later.

cheers,
jamal