Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-02.txt

From: "Mcdysan, David E" <[email-masked]>
Date: Sun, 2 Mar 2014 09:57:41 -0500

Hi,

I read this draft and overall it is a very good statement of many of the
problems that we see and that I have heard from other operators. I had the
following major comments/suggestions:

Section 2 - Problem Space, item 3 Constrained High Availability: Suggest
adding something along the lines of: "Many current service chain
deployments use statically configured 1:1 redundancy so that restoration
of the failure of any service function or network topology occurs. src
should enable solutions that can achieve more efficient resiliency; for
example, 1:N restoration of service functions and/or more dynamic
interaction with network and service topology."

Section 3 - Service Function Chaining, item 1 Service Overlay: "The
service overlay is independent of the network topology and allows
operators to use whatever overlay or underlay they prefer to
create a path between service functions, and to locate service functions
in the network as needed." I don't believe the service overlay is
independent of the network topology and in fact is constrained by it.
Segregation of service functions (think web server tiers) is a way to make
service chains more secure. Being able to more effectively and
automatically implement such segregation as an aspect of security is
another problem that src can help solve. Suggest that this be mentioned in
section 6, security considerations.

Section 3 - Service Function Chaining, IMO what is needed is a service
graph that is not always a set of service functions traversed in a strict
order. The graph (or chain) should be able to have branches, replicate,
sampled replication and terminate. Some of these are mentioned in
quinn-sfc-arch, but boucadair-sfc-framework assumes only a simple chain.
Branching is important if subsequent classification occurs in a service
chain. Replication can be quite useful for transitioning between SF
instances, recording information. Sampled replication is quite useful for
collecting statistics and performing diagnostics. Finally, terminating a
part of the service graph/chain is quite important; for example, a
statistic collection service function is a termination point of the
service graph/chain.

I also had a few minor comments/suggestions:

Section 2 - Problem Space, item 1 Topological Dependencies: "In such
topologies, all traffic, whether a service function needs to be applied or
not, often passes through the same strict order." In general this is not
true. Other drafts mention this as a special case where the order is
symmetric, but it need be. Suggest alignment of concept and terminology.

Section 4 - Related IETF Work, LISP: Are we sure that LISP cannot help
src? If a service function had an ID and there was a need to locate it,
could LISP help with this aspect?

I will send some editorial and consistency comments separately to the
authors.

Thanks,

Dave

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 3 Mar 2014 04:21:38 -0500

Quick comment since this document is going to move towards WG doc:
On related IETF work, ForCES applies.
1) ForCES could be used to provision and control service chains.
2) The ForCES LFB topology could be used to model a service chain
3) The ForCES interFE LFB is work in progress attempting to define passing
of data and metadata across nodes using ForCES.

cheers,
jamal

On Fri, Feb 14, 2014 at 1:01 PM,  <[email-masked]> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Service Function Chaining Working Group of the IETF.
>
>         Title           : Service Function Chaining Problem Statement
>         Authors         : Paul Quinn
>                           Thomas Nadeau
>         Filename        : draft-ietf-sfc-problem-statement-02.txt
>         Pages           : 18
>         Date            : 2014-02-14
>
> Abstract:
>    This document provides an overview of the issues associated with the
>    deployment of service functions (such as firewalls, load balancers)
>    in large-scale environments.  The term service function chaining is
>    used to describe the definition and instantiation of an ordered set
>    of such service functions, and the subsequent "steering" of traffic
>    flows through those service functions.
>
>    The set of enabled service function chains reflect operator service
>    offerings and is designed in conjunction with application delivery
>    and service and network policy.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-02
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt