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

From: [email-masked]
Date: Tue, 01 Apr 2014 03:37:34 -0700

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-03.txt
	Pages           : 18
	Date            : 2014-04-01

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 instances 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-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-03

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/

---

From: Lucy yong <[email-masked]>
Date: Tue, 1 Apr 2014 18:51:27 +0000

Here are some comments on this version.

1) The term of Classification entity is used in section 3.4 without defining it. IMO: it is good for us to treat this entity as a special SF and add the text in 3.3 to clarify that. The specialty is that the entity selects the traffic entering a service overlay compared to other SFs receives the traffic from service overlay.

2) Text in abstraction: The set of enabled service function chains reflect operator service offerings and is designed in conjunction with application delivery and service and network policy.

Suggested text: Text in abstraction: The set of enabled service function chains reflect operator service offerings and are designed in conjunction with application delivery, service, and network policy.

3) Text in 3.1 : 

   Service function chaining utilizes a service specific overlay that
   creates the service topology.  The service overlay provides service
   function connectivity and is built "on top" of the existing 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.

Suggested Text:  

   Service function chaining utilizes a service overlay that
   creates the service topology.  The service overlay provides service
   function connectivity and is built "on top" of the existing network
   topologies. SFC allows operators to use whatever overlay or underlay
   to create a path between a service function and service node, service nodes, 
   and to locate service functions in the existing networks as needed.

4) Text in 3.4

   Data plane metadata provides the ability to exchange information
   between classification entities and service functions, between
   service functions, service functions and classification entities and
   service nodes, and as such does not provide forwarding information
   used to deliver packet along the service overlay.

   Metadata can include the result of antecedent classification,
   information from external sources or forwarding related data.
   Service functions utilize metadata, as required, for localized policy
   decisions.

Comments: two paragraphs are conflict. Need to be fixed. If a classification entity can be seen as a special SF, it can be easily fixed.

Thanks,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, April 01, 2014 5:38 AM
To: [email-masked]
Cc: [email-masked]
Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt

Abstract:

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.

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

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 11 Apr 2014 00:46:14 +0000

Hi Lucy,

Thank you for your comments.

As you know this document is going to be nearing last call, so we (the editors) are being very careful with any changes going forward and need to ensure WG concensus.

Having said that I have some comments and questions for the WG below.

Thanks,
Paul

> 1) The term of Classification entity is used in section 3.4 without defining it. IMO: it is good for us to treat this entity as a special SF and add the text in 3.3 to clarify that. The specialty i…

PQ>  Perhaps a clarifying term: “SFC classifier” and define it as a logical component of the architecture.  By defining it as logical, it can take any implementation form required: distinct separate node, integrated into a network node, or into a service function.  

> Suggested text: Text in abstraction: The set of enabled service function chains reflect operator service offerings and are designed in conjunction with application delivery, service, and network po…

PQ>  Typo: “is” —> “are”, will be corrected.  

> Comments: two paragraphs are conflict. Need to be fixed. If a classification entity can be seen as a special SF, it can be easily fixed.

PQ> I’m not sure there’s a conflict, but perhaps the text can be updated to reflect the proposed defn of classifier and to clarify if the WG deems appropriate:

  Data plane metadata provides the ability to exchange information
  between SFC classifiers and service functions (and vice versa) and between
  service functions.  As such is not used as forwarding information to deliver packet along the service overlay.
  
  Metadata can include the result of antecedent classification and/or
  information from external sources.  Service functions utilize metadata, as required, for localized policy
  decisions.