Subject: [nsc] comments on draft-quinn-nsc-problem-statement-03.txt

From: Andre Beliveau <[email-masked]>
Date: Tue, 3 Sep 2013 14:54:49 +0000

Hi,

Thank you for pursuing the definition of the problem statement,  I am glad to see that it covers both the technical issues and the operational issues.  I have concentrated my comments on the problem statement part, chapter 2 as it has gone through a couple of iterations already and is more complete.

As section 3 and 4 are more related to the framework, is there an intention to write a separate document for the framework or to rename the document to problem statement and framework as indicated on the BoF page?

Here is a few specific comments on the problem area section.

5. Service Chain construction:  The last statement "Such a control / management plane could be centrally controlled and managed , or be distributed between a subset of end-systems" seem to refer more to a solution rather than a problem.  I would simply remove this last sentence.

6. Application of Service Policy:  I would definitely add the definition of Service Policy into the Definition of Terms section. Here is a possible definition: "A set of rules to administer, manage and control network resources so that policy specific actions can be taken by Service Functions"

8. Elastic Service Delivery:  We should also add the additional complexity which Cloud/DC bring by the fact that instances can be added quickly and in different locations within but also across DC's.  Adjusting networks with the same elasticity is hard to realize today.

10. Limited End-to-End Service Visibility:  Beyond troubleshooting, there are a number of similar O&M issues which should also be addressed.  Namely, how Service Chains can be validated or how Service Chaining statistics can be collected and correlated.  It is very complex to verify that the chain has been setup properly, that correct flows are directed to the ingress of the chain and that packets directed to a chain actually flows through all Service Functions properly.

Regards,

André Béliveau, Ing.
Expert, Software and System Architecture
Ericsson Research, Packet Technologies
Mobile: +1 (514) 502 9592  mailto:[email-masked]

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 3 Sep 2013 16:35:34 +0000

Hi Andre,

On Sep 3, 2013, at 7:54 AM, Andre Beliveau <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Thanks a lot for taking the time to review it!

There is a proposed framework document (http://datatracker.ietf.org/doc/draft-boucadair-service-chaining-framework) as well that is in the process of being reviewed.  We are working to align terminology.  Having said that, I think that section 3/4 belong in the problem statement: section 3 describes, at a high level, the problems solved, and section 4 will provide an overview of how chaining is used.  We expect detailed, per vertical, use case drafts as well.

5. Service Chain construction:  The last statement “Such a control / management plane could be centrally controlled and managed , or be distributed between a subset of end-systems” seem to refer more to a solution rather than a problem.  I would simply remove this last sentence.

That sentence was added to ensure that readers understand that we are addressing the requirement for both centralized and distributed control planes.

6. Application of Service Policy:  I would definitely add the definition of Service Policy into the Definition of Terms section. Here is a possible definition: “A set of rules to administer, manage and control network resources so that policy specific actions can be taken by Service Functions”

Thanks, I'll add a definition for -04.

8. Elastic Service Delivery:  We should also add the additional complexity which Cloud/DC bring by the fact that instances can be added quickly and in different locations within but also across DC’s.  Adjusting networks with the same elasticity is hard to realize today.

Makes sense, do you have suggested text?

All good points, do you have text in mind?  If not, I can broaden the scope in the next revision.