Subject: [sfc] Comments on problem statement draft

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 10 Mar 2014 11:55:24 -0700

Hello folks,

I have some comments on draft-ietf-sfc-problem-statement-02.txt,
the problem statement draft.

Most of the comments are editorial suggestions, and can be found by 
looking at the following file which is the output of rfcdiff:

http://tools.ietf.org/wg/sfc/trac/attachment/wiki/WikiStart/Diff%20%20draft-ietf-sfc-problem-statement-02.txt%20-%20draft-ietf-sfc-problem-statement-02cep.txt.htm

The more substantive comments, which are also embedded in the above file,
I list below.

========================================================================

Abstract:

"set" implies no duplication.  Perhaps "set of instantiations"

========================================================================

1.  Introduction

 >            .....     Service functions may be delivered within the
 >  context of an isolated user group, or shared amongst many users/user
 >  groups.

"delivered" isn't right.  Maybe "deployed" or "instantiated"...

========================================================================

1.1.  Definition of Terms

 >  Service Function Chain (SFC):

CEP: the term "frame" is never used elsewhere in the document.
CEP: a chain is linear, but the same function may appear more than
     one time in the chain.  Moreover, it's not at all clear what
     "copy" means in this definition.
CEP: I reckon the group should really be considering "Service Function 
Graphs",
     but I guess that train has already left the station.

========================================================================

2.  Problem Space

              .....

 >       A common example involves web servers using a server load 
balancer as
 >       the default gateway.  When the web service responds to non-load
 >       balanced traffic (e.g., administrative or backup operations) all
 >       traffic from the server must traverse the load balancer forcing
 >       network administrators to create complex routing schemes or
 >       create additional interfaces to provide an alternate topology.

CEP: Doesn't IPv6 allow multiple interfaces, and thus directly
     resolve this difficulty?  Is it suggested that managing
     an abstract service function interface is easier than assigning
     a new IPv6 address (or, perhaps better, anycast address)?

========================================================================

 >  2.   Configuration complexity:
 >                .............                  All of this leads to
 >       very static service delivery deployments. Furthermore, the
 >       speed at which these topological changes can be made is not
 >       rapid or dynamic enough as it often requires manual
 >       intervention, or use of slow provisioning systems.

How is this different from the idea expressed in point #1?

 >                          ............ QoS-based, resilient VPN
 >       service offerings are a typical example of such complex service
 >       offerings.

CEP: Agreed, but this working group does not seem to be about
      reducing the inherent complexity of services.  I do not
      understand the relevance to point #2, but it is useful
      information to keep in mind when reading the draft and
      thus belongs in one of the introductory sections.

========================================================================

 >  4.   Consistent Ordering of Service Functions: Service functions are
 >       typically independent; service function_1 (SF1)...service
 >       function_n (SFn) are unrelated and there is no notion at the
 >       service layer that SF1 occurs before SF2. However, to an
 >       administrator many service functions have a strict ordering that
 >       must be in place, yet the administrator has no consistent way to
 >       impose and verify the ordering of the functions that are used to
 >       deliver a given service.

CEP: One could, indeed, say that SFC is about service topology
      independent of network topology.

========================================================================

 >  5.   Service Chain Construction: Service function chains today are
 >       most typically built through manual configuration processes.
 >       These are slow and error prone.  With the advent of newer
 >       service deployment models the control/management planes provide
 >       not only connectivity state, but will also be increasingly
 >       utilized for the creation of network services. Such control/
 >       management planes could be centralized, or be distributed.

CEP: Is chain construction and management intended to be one of the
      chartered work items of [sfc], or simply defining a mechanism to
      enable traffic to traverse a chain?  It is probably very important
      to carefully distinguish between control plane and management plane.
      So, the '/' character in the last sentence is worrisome.

========================================================================

 >  6.   Application of Service Policy:
...........                                        The
 >       topological information is often stale, providing the operator
 >       with inaccurate placement that can result in suboptimal resource
 >       utilization.

CEP: It's hard to imagine SFC as a remedy for stale topology information.
      That would need to be fixed before SFC could really work (right?).

========================================================================

 >  7.   Transport Dependence: Service functions can and will be deployed
 >       in networks with a range of transports, including under and
 >       overlays.

CEP: an underlay might be called a "transport", but I would not think
      to call an overlay a "transport".  Thus, the first sentence might
      need to be reworked.

========================================================================

 >  8.   Elastic Service Delivery: Given that the current state of the 
art for
 >       adding/removing service functions largely centers around VLANs
 >       and routing changes, rapid changes to the service deployment can
 >       be hard to realize due to the risk and complexity of such
 >       changes.

CEP: it would be nice to cite a reference for the claimed risk / complexity.

========================================================================

 >  9.   Traffic Selection Criteria: Traffic selection is coarse, that
 >       is, all traffic on a particular segment traverses service
 >       functions whether or not the traffic requires service enforcement.
                        ............

CEP: Hard to distinguish this from points #1 and #2.

========================================================================

 >  12.  Symmetric Traffic Flows: Service function chains may be
 >       unidirectional or bidirectional;    ............

CEP: It would be nice to show an example of this phenomenon.

========================================================================

 >  3.  Service Classification:
 >                    ..........              Initial classification is
 >      used to start the service function chain.

CEP: It seems better to say that initial classification determines the
      service function chain required to process the traffic.

========================================================================

6.  Security Considerations

 >  Security considerations are not addressed in this problem statement
 >  document.                 ..................

CEP: O.K. if the working group agrees, but I strongly suspect
      that security is "part of the problem" and deserves a bit
      more attention as part of the problem statement.
      In fact, each of the four solution components in Section 3
      deserves specific attention for this purpose.  The threats
      in each case are different, and the solutions that are likely
      appropriate will vary quite a bit.

========================================================================

-- 
Regards,
Charlie P.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 21 Mar 2014 14:27:59 +0000

Charlie,

Thank you very much for the comments.  Tom and I are finishing the latest round of updates to the draft and plan to submit next week.  In the meanwhile, please see some thoughts below.

Paul

On Mar 10, 2014, at 2:55 PM, Charles E. Perkins <[email-masked]> wrote:

> Most of the comments are editorial suggestions, and can be found by looking at the following file which is the output of rfcdiff:
> 

PQ>  Good clarification, updated.

> "delivered" isn't right.  Maybe "deployed" or "instantiated"…

PQ>  Updated as well.

PQ>  The document will be updated to be more specific: layer-2 frame.

> CEP: I reckon the group should really be considering "Service Function Graphs",

PQ>  Chain is a generalization, but one we've widely accepted and agreed to be a little loose with given the broad understanding of this term.  Having said that, there is an architecture draft (https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/) that describes graphs in more detail.

> >       A common example involves web servers using a server load balancer as

PQ>  I have a few points: 1) even with v4 you could create other (virtual) interfaces, but then you you have to maintain parallel topologies , 2) no way to perform classification, even if you have multiple interfaces, 3) this is only an example, you could do different things but it doesn't change this example.

PQ>  There is certainly some overlap but in #1 we focus on placement and traffic flows.  In #2, we broaden that discussion.  We could certainly make it one section, but I think having 2 highlights the points more strongly.

>     thus belongs in one of the introductory sections.

PQ>  I agree, this section seems out of place and doesn't bolster any points raised.  We will remove it.

PQ> Not only could one, this one does! :)

PQ>  You raise a good point, the next revision will remove the "/" and reference policy instead.

PQ>  The text is misleading, we'll make it clearer in -03.

PQ>  I will update: "range of over and underlay transports"

> >  8.   Elastic Service Delivery: Given that the current state of the art for

PQ>  Explicitly identifying classification which is only _implied_ in 1 and 2.

PQ>  Let me see how to phrase it.

PQ> Agreed.

 PQ>  This is a big ball of wax, but we've seen at least some amount of consensus: push security to architecture and protocol.  

> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc