-----Original Message-----
From: Joel M. Halpern [mailto:jmh@...]
Sent: Sunday, March 06, 2016 11:38 PM
To: Zhou, Danny; Jim Guichard (jguichar); tsc@...
Cc: Ed Warnicke (eaw); Gasparakis, Joseph; Keith Burns (krb);
afredette@...; therbert@...; J.Hendergart@...; Emran
Chaudhry (emran); markus.magnusson@...;
hakan.jonsson@...; ashlee@...; Jan Medved
(jmedved)
Subject: Re: Project Proposal for NSH-Based Service Function Chaining

Comments in line.
Thank you for the suggestions.

On 3/6/16 3:17 AM, Zhou, Danny wrote:

Hi Jim,

I have a few comments below after reviewing the proposal:

1)Do we need to add a bullet mentioning to-be-supported NSH transport,
such as VxLAN-GPE, GRE and Ethernet. I think VxLAN-GPE and GRE are
mandatory, and Ethernet is optional.

We started out by putting a list of the detailed encaps in the charter.
Ed then pointed out that the charter is the scope, not the release plan. The
question of which encaps to do first / later / never is a release plan question, so
we removed the details. We do need to do a release plan. I expect that which
encaps wil be fully supported at first will depend upon which ones people are
interested in making work.
From a scope perspective, any and all encaps are in scope. Thus, we left the
bullet under Forwarding rather vague.

Ok, makes sense to me now. Thanks.

2)How about add "Support NSH Timestamping" to the miscellaneous section.
We have a DPDK based PoC to implement IETF draft
https://tools.ietf.org/html/draft-browne-ietf-sfc-nsh-timestamp-00 per
customer requirement about breakdown of end-to-end SFC latency to
diagnostic potentiation performance issue. It is based on MD Type 2 so
should be a middle term feature, but like NSH traceroute it will be
very useful in the production environment.

Maybe, following the logic above, we should reword the first bullet under
miscellaneous to be NSH OAM support, which would include in scope work on
both traceroute and timestamping, as well as other OAM work we may want to
support?

NSH OAM support covers too many different features (some of them will be submitted
to IETF SFC working group as new drafts in the future), unlike NSH transport case above
which implicitly points out supported transport type as defined in the NSH draft. We could
mention a OAM framework where those individual OAM features could fit it.

3)Can we add "Support TCP proxy for symmetric L4 flows". Though this
feature depends on VPP to add L4 protocol, it will be very useful for
including those stateful L4-l7 network services to SFC in the long term.

This looks like it would cause scope creep into the various service functions that
people want to support using VPP. I am not opposed to fd.io doing such work. I
even think it is useful. I am unclear whether that belongs in this project, or some
other affiliated project. (The charter talks about the ability to create groups of
projects for coordination, which would seem applicable when we get there.)

There are four kinds of components in NSH dataplanes: Classifier, SFF, NSH-proxy and SF.
Obviously, the current scope covers first three but not the SF one. The basic feature NSH manipulation
feature such as Decrement SI for SF use case should be easily added, even though it is not mentioned
in the scope. The TCP proxy such as L4-L7 load balancer, is widely used in in Cloud and Telco environment
as a SF in the SFC.

Do we position NSH SFC to cover SF as well? If we position VPP itself as SF, at least its currently available
code only support coupled VxLAN-GPE and NSH header push/pop, and there is no way to decrement SI
as well as support stateful SFs. I was hoping the NSH SFC project could fill the gap.

Yours,
Joel

-Danny

*From:*Jim Guichard (jguichar) [mailto:jguichar@...]
*Sent:* Friday, March 4, 2016 11:44 PM
*To:* tsc@...
*Cc:* Ed Warnicke (eaw) <eaw@...>; Gasparakis, Joseph
<joseph.gasparakis@...>; Keith Burns (krb) <krb@...>;
afredette@...; therbert@...; J.Hendergart@...; Emran
Chaudhry (emran) <emran@...>; Joel M. Halpern
<jmh@...>; markus.magnusson@...;
hakan.jonsson@...; Zhou, Danny <danny.zhou@...>;
ashlee@...; Jan Medved (jmedved) <jmedved@...>;
Jim Guichard (jguichar) <jguichar@...>
*Subject:* Project Proposal for NSH-Based Service Function Chaining

Please accept this project proposal for NSH-based Service Function
Chaining for consideration. We would like to request scheduling for
the first TSC meeting after 2 weeks have passed to allow for public review.



https://wiki.fd.io/view/Project_Proposals/NSH_SFC

Thank you!