Subject: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt)

From: <[email-masked]>
Date: Tue, 1 Apr 2014 13:42:23 +0200

Dear all,

I raised this point to the co-authors but I prefer to raise it also in the mailing list.

I suggest to remove Section 3 from the draft http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#section-3, because it goes beyond the problem discussion. That section is more a discussion that should be hosted in a framework document. 

Furthermore, some of the points mentioned in that section are questionable such as the use of metadata and the need of control protocols, etc. Let's avoid mixing objectives and limit the scope of the PS I-D to the identification to the problems to be solved. 

Aside not, the WG charter is clear about the scope of the PS I-D:

"
1. Problem Statement: This document will provide a summary of the
problem space to be addressed by the SFC working group including
example high-level use cases.
"

Cheers,
Med

>-----Message d'origine-----
>De : sfc [mailto:[email-masked]] De la part de internet-
>[email-masked]
>Envoyé : mardi 1 avril 2014 12:38
>À : [email-masked]
>Cc : [email-masked]
>Objet : [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt
>
>
>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/
>
>_______________________________________________
>sfc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sfc

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 1 Apr 2014 10:14:08 -0400

This has come up before, and there seemed to be a lot of folks who wanted to leave section 3 in the document, but I will let the chairs make the consensus call.

http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html

	--Tom

---

From: <[email-masked]>
Date: Tue, 1 Apr 2014 16:24:13 +0200

Re-,

Thanks for the pointer but that discussion occurred before the adoption of the document as a WG item. 

So, I re-iterate my comment. 

Cheers,
Med

>De : Thomas Nadeau [mailto:[email-masked]]
>Envoyé : mardi 1 avril 2014 16:14
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : [email-masked]
>Objet : Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D
>Action: draft-ietf-sfc-problem-statement-03.txt)
>
>
>	This has come up before, and there seemed to be a lot of folks who
>wanted to leave section 3 in the document, but I will let the chairs make
>the consensus call.
>
>> I suggest to remove Section 3 from the draft
>http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#section-3,
>because it goes beyond the problem discussion. That section is more a
>discussion that should be hosted in a framework document.
>>
>> Furthermore, some of the points mentioned in that section are
>questionable such as the use of metadata and the need of control protocols,
>etc. Let's avoid mixing objectives and limit the scope of the PS I-D to the
>identification to the problems to be solved.
>>

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Tue, 1 Apr 2014 18:43:46 +0000

My opinion has not changed, the section seems useful and I see no reason it should be removed.

-Darrel

---

From: <[email-masked]>
Date: Wed, 2 Apr 2014 07:45:57 +0200

Hi Darell,

That text is not related to the description of the problems; it goes beyond that. That section includes technical points that should be discussed more in a framework document. 

I don't understand why that section is useful to understand the problem space. 

I still object packaging a problem statement document with unbacked framework discussion.

Cheers,
Med

>De : Darrel Lewis (darlewis) [mailto:[email-masked]]
>Envoyé : mardi 1 avril 2014 20:44
>À : Thomas Nadeau
>Cc : Darrel Lewis (darlewis); BOUCADAIR Mohamed IMT/OLN; [email-masked]

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 2 Apr 2014 19:14:24 +0000

Med,

Instead of repeating the argument, please see
http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html
http://www.ietf.org/mail-archive/web/sfc/current/msg00897.html
http://www.ietf.org/mail-archive/web/sfc/current/msg00900.html

I would certainly *not* describe Section 3 as an "unbacked framework discussion". By the way, looking at the charter for SFC, the word /framework/i appears exactly zero instances.

Best,

-- Carlos.

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Thu, 3 Apr 2014 07:03:20 +0000

The problem statement is focussed specifically on service chaining, As a result I see the benefit of having in section 3 a clear
definition of the key concepts underlying the notion of service chaining that will be discussed in the documents produced by the group.

It provides a scope for the discussions.  For example,  Data Sharing / Metadata should probably discussed somewhere in the 
requirement and framework documents. Still I believe as written the problem statement has been instrumental is the decision 
to have a Metadata contribution to explore it fully.

As a result I would vote to keep section 3.

Nicolas
________________________________________
From: [email-masked] [[email-masked]]
Sent: Wednesday, April 02, 2014 7:45 AM
To: Darrel Lewis (darlewis); Thomas Nadeau
Cc: [email-masked]
Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt)

Hi Darell,

Cheers,
Med

---

From: <[email-masked]>
Date: Thu, 3 Apr 2014 10:37:15 +0200

Hi Carlos,

Thanks for pointing to these messages. 

With all due respect, only the first one you cited tries to motivate the need for such section. But the argument you provided does not make sense to me, since it is the role of the charter to do that... not to froze them in an RFC. 

IMHO, the group should be open to any proposal that claim to solve the problems listed in the problem statement. 

Let us shape a problem statement that is solution-neutral.

Cheers,
Med

>De : Carlos Pignataro (cpignata) [mailto:[email-masked]]
>Envoyé : mercredi 2 avril 2014 21:14
>Cc : Darrel Lewis (darlewis); Tom Nadeau; [email-masked]
>I would certainly *not* describe Section 3 as an "unbacked framework
>discussion". By the way, looking at the charter for SFC, the word
>/framework/i appears exactly zero instances.
>
>Best,
>
>-- Carlos.
>
>> That text is not related to the description of the problems; it goes
>beyond that. That section includes technical points that should be
>discussed more in a framework document.
>>
>>> My opinion has not changed, the section seems useful and I see no reason
>it
>>> should be removed.
>>>
>>> -Darrel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 3 Apr 2014 14:25:34 +0000

Hi, Med,

I apologize but I still do not fully understand your point.

You say: ³Let us shape a problem statement that is solution-neutral²,
which to me seems to imply you believe the problem statement is not
³solution-neutral², and you seem to blame Section 3 for that.

But Section 3 starts by saying: ³Concretely, the SFC working group will
investigate solutions that address the following elements², and then goes
about defining elements, not solutions. The *solutions* that will later
solve the problem defined in this *problem statement* need to address the
*elements* of Section 3. Like I said, it¹s impossible to describe a
problem without putting names and boundaries to what SFC is (not a
solution).

We might need to agree to disagree on this...

Thanks,

Carlos.

-----Original Message-----
From: Med Boucadair <[email-masked]>
Date: Thursday, April 3, 2014 at 4:37 AM
To: Carlos Pignataro <[email-masked]>
Cc: "Darrel Lewis (darlewis)" <[email-masked]>, Tom Nadeau
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [sfc] Remove Section 3 from the problem statement (was RE:
I-D Action: draft-ietf-sfc-problem-statement-03.txt)

>With all due respect, only the first one you cited tries to motivate the
>need for such section. But the argument you provided does not make sense
>to me, since it is the role of the charter to do that... not to froze
>them in an RFC. 
>
>IMHO, the group should be open to any proposal that claim to solve the
>problems listed in the problem statement.
>
>>>>>> I raised this point to the co-authors but I prefer to raise it also
>>>>>>in
>>>> the mailing list.
>>>>>>
>>>> etc. Let's avoid mixing objectives and limit the scope of the PS I-D
>>>>to
>>the

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 3 Apr 2014 19:21:35 +0000

IMHO, the Section 3.4 "Dataplane metadata" is solution oriented. For many environment, the Metadata can be passed down by control plane. I think this section should be simply called  "metadata", with the detailed solution of passing down metadata out of the problem statement. 

The Section 3.3 "Service Classification" can be so easily mis-interpreted as for the purpose of differentiating Service types (mentioned the Section 3.2). 

Based on the description of the Section 3.3, the title should be "Traffic classification". 

Linda

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Thursday, April 03, 2014 9:26 AM
To: [email-masked]
Cc: Darrel Lewis (darlewis); [email-masked]; Tom Nadeau
Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt)

Hi, Med,

You say: ³Let us shape a problem statement that is solution-neutral², which to me seems to imply you believe the problem statement is not ³solution-neutral², and you seem to blame Section 3 for that.

But Section 3 starts by saying: ³Concretely, the SFC working group will investigate solutions that address the following elements², and then goes about defining elements, not solutions. The *solutions* that will later solve the problem defined in this *problem statement* need to address the
*elements* of Section 3. Like I said, it¹s impossible to describe a problem without putting names and boundaries to what SFC is (not a solution).

Thanks,

Carlos.

-----Original Message-----
From: Med Boucadair <[email-masked]>
Date: Thursday, April 3, 2014 at 4:37 AM
To: Carlos Pignataro <[email-masked]>
Cc: "Darrel Lewis (darlewis)" <[email-masked]>, Tom Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [sfc] Remove Section 3 from the problem statement (was RE:
I-D Action: draft-ietf-sfc-problem-statement-03.txt)

>With all due respect, only the first one you cited tries to motivate 
>the need for such section. But the argument you provided does not make 
>sense to me, since it is the role of the charter to do that... not to 
>froze them in an RFC.
>
>>De : Carlos Pignataro (cpignata) [mailto:[email-masked]] Envoyé : 
>>mercredi 2 avril 2014 21:14 À : BOUCADAIR Mohamed IMT/OLN Cc : Darrel 
>>Lewis (darlewis); Tom Nadeau; [email-masked] Objet : Re: [sfc] Remove 
>>Section 3 from the problem statement (was RE:
>>I-D
>>> I don't understand why that section is useful to understand the 
>>> problem
>>space.
>>>
>>>> De : Darrel Lewis (darlewis) [mailto:[email-masked]] Envoyé : 
>>>> mardi 1 avril 2014 20:44 À : Thomas Nadeau Cc : Darrel Lewis 
>>>> (darlewis); BOUCADAIR Mohamed IMT/OLN; [email-masked] Objet : Re: 
>>>> [sfc] Remove Section 3 from the problem statement (was RE:
>>I-D
>>>> wanted to leave section 3 in the document, but I will let the 
>>>> chairs
>>make
>>>> the consensus call.
>>>>>
>>>>>> I raised this point to the co-authors but I prefer to raise it 
>>>>>>also in
>>>> the mailing list.
>>>>>>
>>>>http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#secti
>>>>on-
>>3,
>>>> because it goes beyond the problem discussion. That section is more 
>>>> a discussion that should be hosted in a framework document.
>>>>>>
>>>> etc. Let's avoid mixing objectives and limit the scope of the PS 
>>>>I-D to
>>the
>>>>>>> [email-masked] Envoyé : mardi 1 avril 2014 12:38 À : 
>>>>>>> [email-masked] Cc : [email-masked] Objet : [sfc] I-D 
>>>>>>> Action: draft-ietf-sfc-problem-statement-03.txt
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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"
>>>>>>> The set of enabled service function chains reflect operator 
>>>>>>> service offerings and is designed in conjunction with 
>>>>>>> application delivery and service and network policy.
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>

---

From: <[email-masked]>
Date: Fri, 4 Apr 2014 07:45:45 +0200

Hi Carlos,

I still don't see no answer to my initial question: how that section describe the problem or to understand the problem. Your explanation on what the WG will do is not to be stoned in the document; there are charters for that purpose. 

Yes, calling out metadata is an example of a discussion that is close to the solution part. 

My suggestion is to avoid any confusion and scope the document to what it is supposed to do. Why such resistance?

Cheers,
Med

>Envoyé : jeudi 3 avril 2014 16:26

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 4 Apr 2014 19:57:22 +0000

Hi, Med,

The way that I look at draft-ietf-sfc-problem-statement is that Section 2
describes problematic aspects, and Section 3 describes areas of focus or
elements, both needed to define the problem. The first is about current
problems to be optimized, the second about functional elements. Both
sections say “SFC should investigate solutions to address these [problems
and areas]”. This is likely similar to what I wrote before but with
different words. I apologize in advance if I am not clear.

Are you saying that SFC *should not* investigate the areas listed in
Section 3?

Let me give you an example, hoping this will be clarifying: the problem
statement in I2RS:
http://tools.ietf.org/html/draft-ietf-i2rs-problem-statement-00

Section 2 of draft-ietf-i2rs-problem-statement lists a model and problem
areas, even relationships of modules. Is that a solution?

Best,

Carlos.

-----Original Message-----
From: Med Boucadair <[email-masked]>
Date: Friday, April 4, 2014 at 1:45 AM
To: Carlos Pignataro <[email-masked]>
Cc: "Darrel Lewis (darlewis)" <[email-masked]>, Tom Nadeau

>Hi Carlos,
>
>I still don't see no answer to my initial question: how that section
>describe the problem or to understand the problem. Your explanation on
>what the WG will do is not to be stoned in the document; there are
>charters for that purpose.
>
>>>>>> Objet : Re: [sfc] Remove Section 3 from the problem statement (was
>>>>>>RE:
>>>>I-D
>>>>>>>>also
>>>>>>http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#sectio
>>>>>>n-
>>>>3,
>>>>>>a
>>>>>>>>>service

---

From: <[email-masked]>
Date: Fri, 11 Apr 2014 08:30:12 +0200

Hi Carlos,

What I'm saying is: what should be investigated by the WG is to be captured in a charter not in an RFC. 

The problem statement should not be bound to some reasoning that may be obsolete in the future while the problems may still be there even with the solution flavors we have on the table today. I provided an example in another thread where I'm talking about hidden complexity of dynamic SFC or the complications related to classification entries management, cross-layer diagnosis and troubleshooting, etc.

Cheers,
Med

>Envoyé : vendredi 4 avril 2014 21:57