Subject: [sfc] Questions to draft-ma-sfc-decomposition-01.txt

From: Linda Dunbar <[email-masked]>
Date: Fri, 11 Apr 2014 16:10:01 +0000

Kevin and Ron, 

Your draft described a very interesting use case of metadata exchange between (component) service functions. 

For Figure (page 9) under Section 2.3 (Non-SFC Service Decomposition), is the intent for describing how it works without Service Function Chain? Whereas the Figure under 2.2 is to show how it works with Service Function chain? 

Why it is necessary to have "Classifier" between "Service Request Routing" and "Subscriber Entitlement Lookup" in non-SFC case? Whereas, in the 2.2, there is no "Classifier"? 

In the second figure under Section 2.3, the only difference between the two boxes under "M1" vs. "S2" is "HLS Manifest Rewrite" vs. "Segment decrypt/remux". Why can't branching happen after the "HLS Policy Enforcement"?

Thanks,

Linda
-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: Sunday, February 09, 2014 10:33 PM
To: [email-masked]
Subject: [sfc] FW: New Version Notification for draft-ma-sfc-decomposition-00.txt

Hi All,

  I've uploaded a new draft dealing with service decomposition.
  In some respects it also addresses some of the recent discussion
  about bidirectional flow association and re-classification, using
  an HLS video delivery optimization use case.  Comments welcome.

Jim/Thomas,
 
  If there is space in the agenda, I would like to request a slot.
  The draft primarily relates to use cases.

thanx.

--  Kevin J. Ma

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, February 09, 2014 11:14 PM
To: Kevin J Ma; Kevin J Ma
Subject: New Version Notification for draft-ma-sfc-decomposition-00.txt

A new version of I-D, draft-ma-sfc-decomposition-00.txt
has been successfully submitted by Kevin J. Ma and posted to the
IETF repository.

Name:		draft-ma-sfc-decomposition
Revision:	00
Title:		SFC Service Decomposition
Document date:	2014-02-10
Group:		Individual Submission
Pages:		12
URL:            http://www.ietf.org/internet-drafts/draft-ma-sfc-decomposition-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ma-sfc-decomposition/
Htmlized:       http://tools.ietf.org/html/draft-ma-sfc-decomposition-00

Abstract:
   This document discusses the role of composite (monolithic) service
   functions in service function chaining, and describes a method for
   supporting composite service function decomposition.

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.

The IETF Secretariat

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

---

From: Ron Parker <[email-masked]>
Date: Sun, 13 Apr 2014 20:25:47 +0000

Hi, Linda.

Thanks for taking interest in our draft!

Please see comments inline, below.

   Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]] 
Sent: Friday, April 11, 2014 12:10 PM
To: Kevin J Ma; [email-masked]; Ron Parker
Subject: Questions to draft-ma-sfc-decomposition-01.txt

Kevin and Ron, 

For Figure (page 9) under Section 2.3 (Non-SFC Service Decomposition), is the intent for describing how it works without Service Function Chain? Whereas the Figure under 2.2 is to show how it works with Service Function chain? 
Ron>> Yes, that is correct.

Why it is necessary to have "Classifier" between "Service Request Routing" and "Subscriber Entitlement Lookup" in non-SFC case? Whereas, in the 2.2, there is no "Classifier"? 
Ron>> The SFC case shows the finer level of decomposition that is made possible/feasible vs. the non SFC case.

In the second figure under Section 2.3, the only difference between the two boxes under "M1" vs. "S2" is "HLS Manifest Rewrite" vs. "Segment decrypt/remux". Why can't branching happen after the "HLS Policy Enforcement"?
Ron>> I think that is a problem domain issue that Kevin could better answer.   However, this is meant to be an example of how SFC can enable finer grained decomposition on a transaction (portion of flow) basis.

Thanks,

Linda
-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: Sunday, February 09, 2014 10:33 PM
To: [email-masked]
Subject: [sfc] FW: New Version Notification for draft-ma-sfc-decomposition-00.txt

Hi All,

Jim/Thomas,

thanx.

--  Kevin J. Ma

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, February 09, 2014 11:14 PM
To: Kevin J Ma; Kevin J Ma
Subject: New Version Notification for draft-ma-sfc-decomposition-00.txt

Abstract:

The IETF Secretariat

---

From: Kevin Ma J <[email-masked]>
Date: Sun, 13 Apr 2014 21:01:26 +0000

Hi Linda,

  Thank you for the comments.  responses inline:

thanx.

--  Kevin J. Ma

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Sunday, April 13, 2014 4:26 PM
To: Linda Dunbar; Kevin J Ma; [email-masked]
Subject: RE: Questions to draft-ma-sfc-decomposition-01.txt

Hi, Linda.

   Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]] 
Sent: Friday, April 11, 2014 12:10 PM
To: Kevin J Ma; [email-masked]; Ron Parker
Subject: Questions to draft-ma-sfc-decomposition-01.txt

Kevin and Ron, 

[KJM] In 2.2, the figure shows a composite service function is viewed by the network as a single monolithic service function.  The use or non-use of SFC in this case probably doesn't matter; it could be either.  This figure is really to setup the scenario for decomposing the composite service function into component service functions.

[KJM] In 2.2, the composite service function is viewed by the network as a single monolithic service function.  In 2.3, the decomposition into three separate ingress service function allows independent scaling and redundancy for more granular service function definitions.  wrt the classifier after "Component Service 2", as mentioned in the text, TCP termination may be employed for header/URL rewrite, but also "Component Service 2" needs a way to convey whether or not "Component Service 3" (i.e., whether or not back-end TLS) should be used for a given flow, which in a non-SFC case would likely be via a specific outbound VLAN or VIP, to be recognized by the subsequent classifier.

[KJM] I probably could've made this more clear, but the types of policy enforcement performed on segments vs on manifests is different depending on what specific
features are being deployed.  Perhaps the figure could be updated to reflect a distinction between "Manifest-based HLS policy enforcement" for M1 and "Segment-based HLS policy enforcement" for S2?

Thanks,

Linda
-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: Sunday, February 09, 2014 10:33 PM
To: [email-masked]
Subject: [sfc] FW: New Version Notification for draft-ma-sfc-decomposition-00.txt

Hi All,

Jim/Thomas,

thanx.

--  Kevin J. Ma

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, February 09, 2014 11:14 PM
To: Kevin J Ma; Kevin J Ma
Subject: New Version Notification for draft-ma-sfc-decomposition-00.txt

Abstract:

The IETF Secretariat