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

From: Thomas Narten <[email-masked]>
Date: Fri, 02 May 2014 13:10:16 -0400

A few comments on this topic.

At Tue, 1 Apr 2014 13:42:23 +0200, <[email-masked]> wrote:
> 
> 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.

I think we should be careful about being too strict about "problem
only" on the problem statement and not allowing any discussion about
solution direction. The entire point of SFC (and indeed any WG problem
statement) is to layout the problem and/or "pain points", but also to
show the general direction of a solution. If we end up with a document
that only outlines the problems, but provides no hint as to what sort
of solution direction is being contemplated, we have done a disservice
to the reader.

That said, we of course don't want so much in the solution direction
that it ends up restricting the architecture. But I don't think we are
anywhere close to that. And, even if we were, the architecture
document could overrule any such direction. The WG architecture
document is where the WG makes real decisions and adds detail to
them. 

> 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.

We most certainly will be using metadata. I don't see how anyone who
can suggest we won't, given all the discussion so far on the
topic. Also, we will need some sort of control protocol (or management
protocol). Otherwise there is no way to coordinate the state carried
in SFC packets and the various SFs that process packets. What we
haven't worked out is the details of what that metadata looks like
(that's a solution) or what the protocol/management protocols will
look like (again a solution -- plus per the charter, we have at best
only a vague idea of what this might entail). But this is normal for a
WG at this stage of existence.

> 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.
> "

Let's please not be strict constructionists in reading the words of
the charter. Let's do what makes sense for the WG. The charter is a
guideline and what is important is that we stay within the spirit of
the charter, rather than the letter. I have no doubt that should we
start straying from our charter in a significant way, we'll hear about
it. And I'd be one of the first to raise such an alarm.

Thomas

---

From: <[email-masked]>
Date: Mon, 5 May 2014 09:08:19 +0200

Thomas,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Thomas Narten [mailto:[email-masked]]
>Envoyé : vendredi 2 mai 2014 19:10
>À : 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)
>
>show the general direction of a solution.

[Med] I agree on those. 

 If we end up with a document
>of solution direction is being contemplated, we have done a disservice

[Med] Disagree. The scope of a PS IMO is to discuss problems not hinting solutions. I think we need to be humble here: chaining won't solve all the problems listed in the PS: this is typically the case of the complications related to the management of classification entries, inter-layer correlation for diagnosis and troubleshooting, etc. 

>document is where the WG makes real decisions and adds detail to

[Med] So why including "hints" at the first place in a PS document? 

>WG at this stage of existence.

[Med] This is a typical discussion for an architecture document.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 5 May 2014 13:56:19 +0000

Hi, Med,

Please see inline two small comments in the context of the WGLC of this document.

> [Med] Disagree. The scope of a PS IMO is to discuss problems not hinting solutions. I think we need to be humble here: chaining won't solve all the problems listed in the PS: this is typically the…

I agree with part of this statement, but I see the conclusion differently. A Problem Statement (spelling it out to avoid aliasing with PS == Proposed Standard) document ought to constrain and focus the problem space. I agree with being humble. Now, to me, that's what Section 3 does: bounds, frames, and scopes the problem statement.

> [Med] So why including "hints" at the first place in a PS document? 

Summarizing the WG thinking in how the problem is seen is useful (and common). Otherwise we have a hand-waving document, IMHO.

Thanks,

Carlos.

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