Subject: Re: [sfc] Progression of use case documents in the SFC WG

From: "Ken Gray (kegray)" <[email-masked]>
Date: Thu, 27 Mar 2014 12:28:10 +0000

I'd give a +1 to the chairs …

If there is going to be more than one document (and we seemed hell bent on more than one at the BoF … we could, as a group, settle on "a small number"), that they have some focus.

I don't find the focus or organization described by the chairs onerous - in fact, GIVEN that we have the liaison(s) in place and that they do want a voice here, and that at least one of them has a "domain focus" I find it logical to start with broadband and develop use cases in a set of non-trivial domains.

They had to define "a small number" …or "a small number" becomes a big number.  Now we know how many "a small number" is.

If draft–liu is stripped of enough content by the categorization of the "small number" it's efficacy should be questioned.  To your specific point, as a group we can decide on moving the specific text you mention back to Problem or otherwise re-home it.  It shouldn't be the sole reason draft-liu exists.

I would have gone a bit further than the chairs, frankly.

There is SO much use case literature out there right now, I frankly don't want to see the IETF repeat any more than it has to.  I would hazard that most of us have read these things before in one of several forums.

So, IMO, the use cases should provide support for the problem statement and the development of a proposed header functionality (solution), and as such should illustrate significantly unique requirements …so that we can assess the efficacy of the proposed solutions.  I hope the "owner by area" described by the chairs will take on the responsibility of making sure that their examples are significantly unique for  consideration and addressable in the solution.

Because their work represents the work of many (whole organizations) and is hopefully further distilled by the author here into unique examples, in fairness their contributions should probably be credited to "various" with a nod to their organization.

And, because these use cases have been reviewed in other forums by many people, the process should be more expeditious.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 27, 2014 3:07 AM
To: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Progression of use case documents in the SFC WG

Dear chairs,

Some comments below:

·         The proposed actions are not aligned with the feedback received in this thread (Progression of use case documents within the SFC working group). Answers to that poll are in favor of having a generic use case document. IMHo, it is not fair to ignore what was voiced for by wg members in the mailing list as part of a formal call with clear questions.

·         Some of the text that was adopted by the WG as part of the Problem Statement (use case as part of the Problem statement) has been moved to the generic use case. That text is governed by this charter text: “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. Additionally, the working group will
normalize nomenclature and definitions for service function chaining.”. What to do for that text?

·         Having the generic use case document and some few detailed ones do not conflict. It is only a matter of scoping.

Given what is stated above, I disagree with your proposal.

If I have to choose (again), I would vote for having one single use cases document. Having one single document will help focusing on core aspects and would simplify the wg activity: review, last calls, etc.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : mercredi 26 mars 2014 18:54
À : [email-masked]<mailto:[email-masked]>
Objet : [sfc] Progression of use case documents in the SFC WG

WG:

In a message back in January, we (the chairs) proposed that the SFC WG handle the topic of use case documents as follows:

1) Have the WG develop one use case document that documents a small number of representative use cases.  The document presented by Hongyu Li at the Vancouver BOF could serve for this purpose
(http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cases).

3) For additional use cases not covered in 1) above, allow for a small number of documents that are applicable to specific
environments (e.g.  mobility, data center, broadband, and so forth.) These documents would provide more detailed information and applicability of SFC to these specific environments, and would need to go beyond what is covered in the general use case document (1). Note that it is not the intention to have every potential use case documented.

Since then, and based on the presentations/discussion in London, it appears that we have a number of documents that warrant being developed as standalone documents. Specifically:

1) A use case document on mobility, e.g., http://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/

2) A use case document on Data Centers, e.g., http://datatracker.ietf.org/doc/draft-kumar-sfc-dc-use-cases/

3) Possibly a use case document on Broadband scenarios. However, use cases from a broadband perspective are being developed in the BBF (see the liaison statement at https://datatracker.ietf.org/liaison/1304/). We also have http://datatracker.ietf.org/doc/draft-meng-sfc-broadband-usecases/.  It does not seem appropriate to adopt a WG document on the topic of broadband (at least at this time) without clarifying the relationship between draft-meng-sfc-broadband-usecases and the BBF work. In addition, we would need to understand why two efforts — one in BBF and one in the IETF -- on the same topic would be appropriate. Hence, at the present time, we do not intend to adopt a WG document on broadband scenarios, and expect to receive primary guidance on this topic from the BBF.

That leaves: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/, a more general document. But that document includes text on three topics that would be covered in more detail elsewhere (broadband, mobile, and DC). While this document could contain pointers to the other documents, that leaves the document with very little standalone content -- raising the question of what should be done with it, or what content it could incorporate in order to be worthwhile as a standalone document.

Thus, the chairs recommendation at this time is:

1) Call for WG adoption of draft-haeffner-sfc-use-case-mobility-00.txt and draft-kumar-sfc-dc-use-cases-00.txt as WG documents (target: informational).

2) Defer action on draft-liu-service-chaining-use-cases<http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cases>  and draft-meng-sfc-broadband-usecases<http://datatracker.ietf.org/doc/draft-meng-sfc-broadband-usecases/> per the above discussion.

Does this make sense?

Jim & Thomas

---

From: Jerome Moisand <[email-masked]>
Date: Thu, 27 Mar 2014 12:55:20 +0000

Agreed with the chairs proposal.

There is no point duplicating work performed by other std bodies, it is much better to use it as a an input, while letting specialized discussions occur between groups of corresponding specialists. BBF leverages IETF work all the time, well, it's time to have IETF leverage BBF work.

Being co-editor of the BBF work, I'll make sure that new use cases identified by BBF will be communicated in a reasonably timely fashion to IETF. We do have a few new ones in the works. And we'll work with the authors of draft-meng-sfc-broadband-usecases to consolidate with BBF work.

Tx
Jerome

Side note: draft-meng-sfc-broadband-usecases seems to cover two topics:

1.       a basic form of service chaining ('BNAS' -I guess this means BRAS/BNG- to CGNAT) which is already covered by BBF use cases

2.       then a lot of material about IP v4/v6 transition matters (DS-Lite, MAP, etc), which doesn't seem to have a direct relationship with service chaining per se. Anyhoo, it turns out that there is another BBF work item in this respect, so corresponding material should find its rightful place.

From: sfc [mailto:[email-masked]] On Behalf Of Ken Gray (kegray)
Sent: Thursday, March 27, 2014 8:28 AM
To: [email-masked]; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] Progression of use case documents in the SFC WG

I'd give a +1 to the chairs ...

If there is going to be more than one document (and we seemed hell bent on more than one at the BoF ... we could, as a group, settle on "a small number"), that they have some focus.

They had to define "a small number" ...or "a small number" becomes a big number.  Now we know how many "a small number" is.

If draft-liu is stripped of enough content by the categorization of the "small number" it's efficacy should be questioned.  To your specific point, as a group we can decide on moving the specific text you mention back to Problem or otherwise re-home it.  It shouldn't be the sole reason draft-liu exists.

So, IMO, the use cases should provide support for the problem statement and the development of a proposed header functionality (solution), and as such should illustrate significantly unique requirements ...so that we can assess the efficacy of the proposed solutions.  I hope the "owner by area" described by the chairs will take on the responsibility of making sure that their examples are significantly unique for  consideration and addressable in the solution.

Dear chairs,

Some comments below:

·         Some of the text that was adopted by the WG as part of the Problem Statement (use case as part of the Problem statement) has been moved to the generic use case. That text is governed by this charter text: "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. Additionally, the working group will
normalize nomenclature and definitions for service function chaining.". What to do for that text?

Cheers,
Med

WG:

3) Possibly a use case document on Broadband scenarios. However, use cases from a broadband perspective are being developed in the BBF (see the liaison statement at https://datatracker.ietf.org/liaison/1304/). We also have http://datatracker.ietf.org/doc/draft-meng-sfc-broadband-usecases/.  It does not seem appropriate to adopt a WG document on the topic of broadband (at least at this time) without clarifying the relationship between draft-meng-sfc-broadband-usecases and the BBF work. In addition, we would need to understand why two efforts - one in BBF and one in the IETF -- on the same topic would be appropriate. Hence, at the present time, we do not intend to adopt a WG document on broadband scenarios, and expect to receive primary guidance on this topic from the BBF.

Does this make sense?

Jim & Thomas

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 27 Mar 2014 14:36:27 +0000

I'm with Ken and the chairs here.  We need a small set of concise documents that highlight key use cases, nothing more.

On Mar 27, 2014, at 8:28 AM, Ken Gray (kegray) <[email-masked]<mailto:[email-masked]>> wrote:

Dear chairs,

Some comments below:

Cheers,
Med

WG:

Does this make sense?

Jim & Thomas
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: <[email-masked]>
Date: Fri, 28 Mar 2014 08:37:36 +0100

Dear Ken,

I wouldn't commented your answer if it was not based on mines.

Please see inline.

Cheers,
Med

De : Ken Gray (kegray) [mailto:[email-masked]]
Envoyé : jeudi 27 mars 2014 13:28
À : BOUCADAIR Mohamed IMT/OLN; Jim Guichard (jguichar); [email-masked]
Objet : Re: [sfc] Progression of use case documents in the SFC WG

If there is going to be more than one document (and we seemed hell bent on more than one at the BoF ... we could, as a group, settle on "a small number"), that they have some focus.
[Med] The small number I'm suggesting in my answer is: "1 (ONE document)". IMHO, I see use cases as one of the inputs to the requirements effort. This is why I prefer to focus on the core aspects, extract common features, identify needs that are specific to a given use case to assess whether these aspects should be included as part of the core requirements or not, etc.

I don't find the focus or organization described by the chairs onerous
[Med] I have also concerns with the procedure:

·         there was a formal poll with clear questions...that has been ignored because of some discussion that have not be in the mailing list

·         There was text that was adopted by the WG and has been moved to another document as suggested by one of the chairs.

- in fact, GIVEN that we have the liaison(s) in place and that they do want a voice here, and that at least one of them has a "domain focus" I find it logical to start with broadband and develop use cases in a set of non-trivial domains.
[Med] This is orthogonal to document discussion. This can be implemented in one single document; no need to have a single document for that.

If draft-liu is stripped of enough content by the categorization of the "small number" it's efficacy should be questioned.  To your specific point, as a group we can decide on moving the specific text you mention back to Problem or otherwise re-home it.  It shouldn't be the sole reason draft-liu exists.
[Med] I didn't said it is the only one. The point is that document includes some text that was adopted by the WG. That is a point that should be considered too..

There is SO much use case literature out there right now, I frankly don't want to see the IETF repeat any more than it has to.  I would hazard that most of us have read these things before in one of several forums.
[Med] I'm not asking to have "SO much" use cases, but limited set documented in one single document.

So, IMO, the use cases should provide support for the problem statement
[Med] ...IMHo to the requirements.

and the development of a proposed header functionality (solution), and as such should illustrate significantly unique requirements ...so that we can assess the efficacy of the proposed solutions.  I hope the "owner by area" described by the chairs will take on the responsibility of making sure that their examples are significantly unique for  consideration and addressable in the solution.

And, because these use cases have been reviewed in other forums by many people, the process should be more expeditious.
[Med] I'm not sure what you mean by "use cases" here: do you mean the documents? The common draft discusses those use cases but it focuses on key points.

Dear chairs,

Some comments below:

Cheers,
Med

WG:

Does this make sense?

Jim & Thomas

---

From: <[email-masked]>
Date: Fri, 28 Mar 2014 08:44:10 +0100

Hi Jérome,

I fully agree there is no need to duplicate work.

If there is already text/document in the BBF side, wouldn't be efficient to cite those document rather than editing another with the IETF stamp?

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jerome Moisand
Envoyé : jeudi 27 mars 2014 13:55
À : [email-masked]
Objet : Re: [sfc] Progression of use case documents in the SFC WG

Tx
Jerome

From: sfc [mailto:[email-masked]] On Behalf Of Ken Gray (kegray)
Sent: Thursday, March 27, 2014 8:28 AM
To: [email-masked]<mailto:[email-masked]>; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Progression of use case documents in the SFC WG

Dear chairs,

Some comments below:

Cheers,
Med

WG:

Does this make sense?

Jim & Thomas

---

From: [email-masked]
Date: Fri, 28 Mar 2014 18:02:24 +0800

Hi, Med,

  I'm not sure if the aims of BBF are the same as IETF's. 
For a developing technology, I'd think use cases might be discussed
where the technology is developing.
  In some way, I don;t think that is not duplicative work.

Thanks,
Wei

"sfc" <[email-masked]>  2014-03-28 15:44:10:

> If there is already text/document in the BBF side, wouldn’t be 
> efficient to cite those document rather than editing another with 
> the IETF stamp?
> 
> Cheers,
> Med
> 
> There is no point duplicating work performed by other std bodies, it
> is much better to use it as a an input, while letting specialized 
> discussions occur between groups of corresponding specialists. BBF 
> leverages IETF work all the time, well, it’s time to have IETF 
> leverage BBF work.
> 
> Being co-editor of the BBF work, I’ll make sure that new use cases 
> identified by BBF will be communicated in a reasonably timely 
> fashion to IETF. We do have a few new ones in the works. And we’ll 
> work with the authors of draft-meng-sfc-broadband-usecases to 
> consolidate with BBF work.
> 
> Tx
> Jerome
> 
> 1.       a basic form of service chaining (‘BNAS’ –I guess this 
> means BRAS/BNG- to CGNAT) which is already covered by BBF use cases
> 2.       then a lot of material about IP v4/v6 transition matters 
> (DS-Lite, MAP, etc), which doesn’t seem to have a direct 
> relationship with service chaining per se. Anyhoo, it turns out that
> there is another BBF work item in this respect, so corresponding 
> material should find its rightful place.
> 
> 
> If there is going to be more than one document (and we seemed hell 
> bent on more than one at the BoF … we could, as a group, settle on 
> "a small number"), that they have some focus. 
> 
> I don't find the focus or organization described by the chairs 
> onerous - in fact, GIVEN that we have the liaison(s) in place and 
> that they do want a voice here, and that at least one of them has a 
> "domain focus" I find it logical to start with broadband and develop
> use cases in a set of non-trivial domains. 
> 
> They had to define "a small number" …or "a small number" becomes a 
> big number.  Now we know how many "a small number" is.
> 
> If draft–liu is stripped of enough content by the categorization of 
> the "small number" it's efficacy should be questioned.  To your 
> specific point, as a group we can decide on moving the specific text
> you mention back to Problem or otherwise re-home it.  It shouldn't 
> be the sole reason draft-liu exists.
> 
> There is SO much use case literature out there right now, I frankly 
> don't want to see the IETF repeat any more than it has to.  I would 
> hazard that most of us have read these things before in one of several 
forums.
> 
> So, IMO, the use cases should provide support for the problem 
> statement and the development of a proposed header functionality 
> (solution), and as such should illustrate significantly unique 
> requirements …so that we can assess the efficacy of the proposed 
> solutions.  I hope the "owner by area" described by the chairs will 
> take on the responsibility of making sure that their examples are 
> significantly unique for  consideration and addressable in the solution. 
 
> 
> Because their work represents the work of many (whole organizations)
> and is hopefully further distilled by the author here into unique 
> examples, in fairness their contributions should probably be 
> credited to "various" with a nod to their organization.
> 
> And, because these use cases have been reviewed in other forums by 
> many people, the process should be more expeditious.
> 
> 
> 
> 
> From: "[email-masked]" <[email-masked]>
> To: "Jim Guichard (jguichar)" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> ·         The proposed actions are not aligned with the feedback 
> received in this thread (Progression of use case documents within 
> the SFC working group). Answers to that poll are in favor of having 
> a generic use case document. IMHo, it is not fair to ignore what was
> voiced for by wg members in the mailing list as part of a formal 
> call with clear questions. 
> ·         Some of the text that was adopted by the WG as part of the
> Problem Statement (use case as part of the Problem statement) has 
> been moved to the generic use case. That text is governed by this 
> charter text: “1. Problem Statement: This document will provide a 
> summary of the
> ·         Having the generic use case document and some few detailed
> ones do not conflict. It is only a matter of scoping.
> 
> If I have to choose (again), I would vote for having one single use 
> cases document. Having one single document will help focusing on 
> core aspects and would simplify the wg activity: review, last calls, 
etc.
> In a message back in January, we (the chairs) proposed that the SFC 
> WG handle the topic of use case documents as follows:
> 
> 1) Have the WG develop one use case document that documents a small 
> number of representative use cases.  The document presented by 
> Hongyu Li at the Vancouver BOF could serve for this purpose
> 3) For additional use cases not covered in 1) above, allow for a 
> small number of documents that are applicable to specific
> environments (e.g.  mobility, data center, broadband, and so forth.)
> These documents would provide more detailed information and 
> applicability of SFC to these specific environments, and would need 
> to go beyond what is covered in the general use case document (1). 
> Note that it is not the intention to have every potential use case 
documented.
> 
> Since then, and based on the presentations/discussion in London, it 
> appears that we have a number of documents that warrant being 
> developed as standalone documents. Specifically:
> 
> 1) A use case document on mobility, e.g., http://datatracker.ietf.
> org/doc/draft-haeffner-sfc-use-case-mobility/
> 
> 2) A use case document on Data Centers, e.g., http://datatracker.
> ietf.org/doc/draft-kumar-sfc-dc-use-cases/
> 
> 3) Possibly a use case document on Broadband scenarios. However, use
> cases from a broadband perspective are being developed in the BBF 
> (see the liaison statement at https://datatracker.ietf.org/liaison/1304/
> ). We also have http://datatracker.ietf.org/doc/draft-meng-sfc-
> broadband-usecases/.  It does not seem appropriate to adopt a WG 
> document on the topic of broadband (at least at this time) without 
> clarifying the relationship between draft-meng-sfc-broadband-
> usecases and the BBF work. In addition, we would need to understand 
> why two efforts — one in BBF and one in the IETF -- on the same 
> topic would be appropriate. Hence, at the present time, we do not 
> intend to adopt a WG document on broadband scenarios, and expect to 
> receive primary guidance on this topic from the BBF.
> 
> That leaves: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/
> , a more general document. But that document includes text on three 
> topics that would be covered in more detail elsewhere (broadband, 
> mobile, and DC). While this document could contain pointers to the 
> other documents, that leaves the document with very little 
> standalone content -- raising the question of what should be done 
> with it, or what content it could incorporate in order to be 
> worthwhile as a standalone document.
> 
> 1) Call for WG adoption of draft-haeffner-sfc-use-case-mobility-00.
> txt and draft-kumar-sfc-dc-use-cases-00.txt as WG documents (target:
> informational).
> 
> 2) Defer action on draft-liu-service-chaining-use-cases  and draft-
> meng-sfc-broadband-usecases per the above discussion.
> 
> Does this make sense?
> 
> Jim & Thomas_______________________________________________
> sfc mailing list
> [email-masked]

---

From: [email-masked]
Date: Fri, 28 Mar 2014 18:03:18 +0800

Support chairs approach.

It's fine by me.

Thanks,
Wei

forums.
 
etc.
documented.

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 28 Mar 2014 08:52:44 -0400

I agree with the chairs' proposal as well.  Lets go with a small number and focus things down here a bit.

	--Tom

On Mar 27, 2014:8:28 AM, at 8:28 AM, Ken Gray (kegray) <[email-masked]> wrote:

> To: "Jim Guichard (jguichar)" <[email-masked]>, "[email-masked]" <[email-masked]>
> 2) Defer action on draft-liu-service-chaining-use-cases  and draft-meng-sfc-broadband-usecases per the above discussion.
>  
> Does this make sense?
>  
> Jim & Thomas

---

From: Jerome Moisand <[email-masked]>
Date: Fri, 28 Mar 2014 13:43:38 +0000

Hey Med,

Well, this is indeed the general idea, but it is a tad more complicated than that, because BBF has this rule that contributions and Study Documents (work in progress or finalized) are *by default* not public. Point being to allow industry players to speak more freely and protect IPR (well, I think? I never bought in this line of thinking to be honest, but it is the way it is!).

So BBF reps have to go through a few hoops to be able to liaise material to IETF that can indeed be shared in a public manner. We did a first round with the liaison that you guys have already seen. Since the BBF study document is a work in progress, we expect to send updates through subsequent liaisons.
https://datatracker.ietf.org/liaison/1304/

So I would suggest that the 'core' use case document (e.g. http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cases, if I properly followed the chairs proposal) would indeed include a citation, but a citation to the latest BBF liaison, instead of the BBF Study Document itself. And such citation/pointer (+ a few words of context) would become *the* reference for fixed-broadband use cases, removing the need for a specialized I-D in this respect.

Those are just technicalities though, at the end, we're saying the same thing.

Tx
Jerome

PS. hey Hongyu, since you're on both sides of the fence, maybe we could work together to create a short section in draft-liu to provide proper context + such citation?

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 28, 2014 3:44 AM
To: Jerome Moisand; [email-masked]
Subject: RE: [sfc] Progression of use case documents in the SFC WG

Hi Jérome,

Cheers,
Med

Tx
Jerome

Dear chairs,

Some comments below:

Cheers,
Med

WG:

Does this make sense?

Jim & Thomas

---

From: "Jeffrey Napper (jenapper)" <[email-masked]>
Date: Fri, 28 Mar 2014 18:30:42 +0000

I agree here (+1 to the chairs) and would like to respond to some specifics.

[further responses inlined below]

Cheers,
Jeff

From: "Ken Gray (kegray)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 27, 2014 at 5:28 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Progression of use case documents in the SFC WG

[JN] I also agree with the point made elsewhere in the thread that combining the general and specific use case documents will produce a too long document, which is why I support a limited number of focused, separate domain documents.

[JN] I believe the main point is to generate a smallish set of requirements (the smaller the better of course) within a deadline. There is plenty of use case literature, and the value of the use case documents here is to produce a concrete set of requirements directly related to the specific use cases so that we can come to a consensus on whether a solution meets all the requirements. Equally important is that the chairs put a deadline on production of use case/requirements documents so we can move on to solutions. To that end, I applaud the chairs for moving forward.

[JN] Speaking for our use case only, we are considering additional use cases with the caveat that each one must provide new requirements or weaknesses to current approaches. It keeps a definite reasonable limit on the number of use cases. Our approach is to start with simple cases and add complex cases where/if needed.

[JN] We are trying to work with other representatives in 3GPP individually. IIRC, they are developing a use case document, but it is not complete. We are of course, happy to give credit where applicable. :)

[JN] You'd think that, but some of the other documents I've seen don't follow the simple approach of each successive use case providing new requirements unique to the previous cases in the document. They simply divide up the requirements of a set of similar use cases.

Dear chairs,

Some comments below:

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : mercredi 26 mars 2014 18:54
À :[email-masked]<mailto:[email-masked]>
Objet : [sfc] Progression of use case documents in the SFC WG

WG:

Does this make sense?

Jim & Thomas

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Sat, 29 Mar 2014 02:33:04 +0000

I agree with Jerome’s proposal. Allowing BBF maintaining broadband use cases is a better choice. No repeated work, less burden for IETF. As a co-author of draft-liu, I will add some text in the broadband use case section providing a summary and reference to the work in BBF (to the liaison for now technically). Besides, the reference to liaison could be replaced by referencing to a whitepaper in BBF if possible in a later time.

Cheers,
Hongyu

From: Jerome Moisand [mailto:[email-masked]]
Sent: Friday, March 28, 2014 9:44 PM
To: [email-masked]; Hongyu Li (Julio)
Subject: RE: [sfc] Progression of use case documents in the SFC WG

Hey Med,

So I would suggest that the ‘core’ use case document (e.g. http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cases, if I properly followed the chairs proposal) would indeed include a citation, but a citation to the latest BBF liaison, instead of the BBF Study Document itself. And such citation/pointer (+ a few words of context) would become *the* reference for fixed-broadband use cases, removing the need for a specialized I-D in this respect.

Those are just technicalities though, at the end, we’re saying the same thing.

Tx
Jerome

PS. hey Hongyu, since you’re on both sides of the fence, maybe we could work together to create a short section in draft-liu to provide proper context + such citation?

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, March 28, 2014 3:44 AM
To: Jerome Moisand; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] Progression of use case documents in the SFC WG

Hi Jérome,

If there is already text/document in the BBF side, wouldn’t be efficient to cite those document rather than editing another with the IETF stamp?

Cheers,
Med

There is no point duplicating work performed by other std bodies, it is much better to use it as a an input, while letting specialized discussions occur between groups of corresponding specialists. BBF leverages IETF work all the time, well, it’s time to have IETF leverage BBF work.

Being co-editor of the BBF work, I’ll make sure that new use cases identified by BBF will be communicated in a reasonably timely fashion to IETF. We do have a few new ones in the works. And we’ll work with the authors of draft-meng-sfc-broadband-usecases to consolidate with BBF work.

Tx
Jerome

1.       a basic form of service chaining (‘BNAS’ –I guess this means BRAS/BNG- to CGNAT) which is already covered by BBF use cases

2.       then a lot of material about IP v4/v6 transition matters (DS-Lite, MAP, etc), which doesn’t seem to have a direct relationship with service chaining per se. Anyhoo, it turns out that there is another BBF work item in this respect, so corresponding material should find its rightful place.

Dear chairs,

Some comments below:

Cheers,
Med

WG:

Does this make sense?

Jim & Thomas

---

From: Jiangyuanlong <[email-masked]>
Date: Sat, 29 Mar 2014 03:31:17 +0000

Hi Ken and all,

Considering your viewpoint "the use cases should provide support for the problem statement and the development of a proposed header functionality (solution), and as such should illustrate significantly unique requirements", I totally agree with you on the first part, but have some doubts on the conclusion. If each use case document only illustrate its unique requirements,  which use case document should serve the common requirements?  IMHO, most requirements from these use cases must be general enough for the SFC, otherwise the use case can hardly fit into the scope of SFC. Therefore, a general use case document can serve this purpose fairly.

Thanks,
Yuanlong

From: sfc [mailto:[email-masked]] On Behalf Of Ken Gray (kegray)
Sent: Thursday, March 27, 2014 8:28 PM
To: [email-masked]; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] Progression of use case documents in the SFC WG

Dear chairs,

Some comments below:

Cheers,
Med

WG:

Does this make sense?

Jim & Thomas

---

From: [email-masked]
Date: Mon, 31 Mar 2014 15:58:24 +0800

Hi, Jerome

  As a co-author of draft-meng, maybe I have to highlight some points in 
our draft. As you mentioned:
        Side note: draft-meng-sfc-broadband-usecases seems to cover two 
topics:
1.       a basic form of service chaining (‘BNAS’ –I guess this means 
BRAS/BNG- to CGNAT) which is already covered by BBF use cases
2.       then a lot of material about IP v4/v6 transition matters 
(DS-Lite, MAP, etc), which doesn’t seem to have a direct relationship 
with service chaining per se. Anyhoo, it turns out that there is another 
BBF work item in this respect, so corresponding material should find its 
rightful place.

  It seems that I hold the different opinion of you.  CGNAT is just one 
SFC use case in Broadband Network per se, as well as NAT64 and other 
IPv4/v6 transition technology. They are distinctive from each other and 
they go through different SFC. So we put them together in this draft.  And 
here, we also want to mention is Subscriber-management function in BNG, 
which is suggested to be referred as a SF, because BNG's capacity of 
subscriber is also a bottleneck, it seems reasonable to consider 
Subscriber-management function as a SF.
  In addition, after listing and comparing them, it turns out that we can 
not only deploy SFC Domain between BNG and CR, but also we can consider a 
SFC Domain deployment between CPE and BNG, which is called unify home 
router in our draft. It means that CPE only support simple L2/L3 
functionalities including encapsulating and decapsulating. Wherever the 
traffic go is decided by the SFC Domain. This seems a bit like your Cloud 
CPE.
  Also, we propose some considerations (e.g. standalone mode, directly 
connecting mode  and pool consideration). As for standalone mode and 
directly connecting mode, which are the main two architecture in IPv6 
transition deployment, we think maybe this consideration can  introduce 
into SFC architecture. As for more details such as pool management, we 
just give our proposal and the reason for this proposal is for steering 
the income traffic.
 
Hope I have clearly highlighted our draft : )

Many thanks!
Linda

Jerome Moisand <[email-masked]> 
发件人:  "sfc" <[email-masked]>
2014-03-27 20:55

收件人
"[email-masked]" <[email-masked]>
抄送

主题
Re: [sfc] Progression of use case documents in the SFC WG

There is no point duplicating work performed by other std bodies, it is 
much better to use it as a an input, while letting specialized discussions 
occur between groups of corresponding specialists. BBF leverages IETF work 
all the time, well, it’s time to have IETF leverage BBF work.
 
Being co-editor of the BBF work, I’ll make sure that new use cases 
identified by BBF will be communicated in a reasonably timely fashion to 
IETF. We do have a few new ones in the works. And we’ll work with the 
authors of draft-meng-sfc-broadband-usecases to consolidate with BBF work.
 
Tx
Jerome
 
Side note: draft-meng-sfc-broadband-usecases seems to cover two topics:
1.       a basic form of service chaining (‘BNAS’ –I guess this means 
BRAS/BNG- to CGNAT) which is already covered by BBF use cases
2.       then a lot of material about IP v4/v6 transition matters 
(DS-Lite, MAP, etc), which doesn’t seem to have a direct relationship 
with service chaining per se. Anyhoo, it turns out that there is another 
BBF work item in this respect, so corresponding material should find its 
rightful place.

 
If there is going to be more than one document (and we seemed hell bent on 
more than one at the BoF … we could, as a group, settle on "a small 
number"), that they have some focus. 
 
I don't find the focus or organization described by the chairs onerous - 
in fact, GIVEN that we have the liaison(s) in place and that they do want 
a voice here, and that at least one of them has a "domain focus" I find it 
logical to start with broadband and develop use cases in a set of 
non-trivial domains. 
 
They had to define "a small number" …or "a small number" becomes a big 
number.  Now we know how many "a small number" is.
 
If draft–liu is stripped of enough content by the categorization of the 
"small number" it's efficacy should be questioned.  To your specific 
point, as a group we can decide on moving the specific text you mention 
back to Problem or otherwise re-home it.  It shouldn't be the sole reason 
draft-liu exists.

There is SO much use case literature out there right now, I frankly don't 
want to see the IETF repeat any more than it has to.  I would hazard that 
most of us have read these things before in one of several forums.
 
So, IMO, the use cases should provide support for the problem statement 
and the development of a proposed header functionality (solution), and as 
such should illustrate significantly unique requirements …so that we can 
assess the efficacy of the proposed solutions.  I hope the "owner by area" 
described by the chairs will take on the responsibility of making sure 
that their examples are significantly unique for  consideration and 
addressable in the solution. 
 
Because their work represents the work of many (whole organizations) and 
is hopefully further distilled by the author here into unique examples, in 
fairness their contributions should probably be credited to "various" with 
a nod to their organization.
 
And, because these use cases have been reviewed in other forums by many 
people, the process should be more expeditious.

 
 
Dear chairs,
 
Some comments below:
·         The proposed actions are not aligned with the feedback received 
in this thread (Progression of use case documents within the SFC working 
group). Answers to that poll are in favor of having a generic use case 
document. IMHo, it is not fair to ignore what was voiced for by wg members 
in the mailing list as part of a formal call with clear questions. 
·         Some of the text that was adopted by the WG as part of the 
Problem Statement (use case as part of the Problem statement) has been 
moved to the generic use case. That text is governed by this charter text: 
“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. Additionally, the working group will
normalize nomenclature and definitions for service function chaining.”. 
What to do for that text? 
·         Having the generic use case document and some few detailed ones 
do not conflict. It is only a matter of scoping.

If I have to choose (again), I would vote for having one single use cases 
document. Having one single document will help focusing on core aspects 
and would simplify the wg activity: review, last calls, etc.
 
Cheers,
Med
 
De : sfc [mailto:[email-masked]] De la part de Jim Guichard 
(jguichar)
Envoyé : mercredi 26 mars 2014 18:54
À : [email-masked]
Objet : [sfc] Progression of use case documents in the SFC WG
 
WG:
 
In a message back in January, we (the chairs) proposed that the SFC WG 
handle the topic of use case documents as follows:
 
1) Have the WG develop one use case document that documents a small number 
of representative use cases.  The document presented by Hongyu Li at the 
Vancouver BOF could serve for this purpose
(http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cases).
 
3) For additional use cases not covered in 1) above, allow for a small 
number of documents that are applicable to specific
environments (e.g.  mobility, data center, broadband, and so forth.) These 
documents would provide more detailed information and applicability of SFC 
to these specific environments, and would need to go beyond what is 
covered in the general use case document (1). Note that it is not the 
intention to have every potential use case documented.
 
Since then, and based on the presentations/discussion in London, it 
appears that we have a number of documents that warrant being developed as 
standalone documents. Specifically:
 
1) A use case document on mobility, e.g., 
http://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/
 
2) A use case document on Data Centers, e.g., 
http://datatracker.ietf.org/doc/draft-kumar-sfc-dc-use-cases/
 
3) Possibly a use case document on Broadband scenarios. However, use cases 
from a broadband perspective are being developed in the BBF (see the 
liaison statement at https://datatracker.ietf.org/liaison/1304/). We also 
have http://datatracker.ietf.org/doc/draft-meng-sfc-broadband-usecases/. 
It does not seem appropriate to adopt a WG document on the topic of 
broadband (at least at this time) without clarifying the relationship 
between draft-meng-sfc-broadband-usecases and the BBF work. In addition, 
we would need to understand why two efforts — one in BBF and one in the 
IETF -- on the same topic would be appropriate. Hence, at the present 
time, we do not intend to adopt a WG document on broadband scenarios, and 
expect to receive primary guidance on this topic from the BBF.
 
That leaves: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/, a 
more general document. But that document includes text on three topics 
that would be covered in more detail elsewhere (broadband, mobile, and 
DC). While this document could contain pointers to the other documents, 
that leaves the document with very little standalone content -- raising 
the question of what should be done with it, or what content it could 
incorporate in order to be worthwhile as a standalone document.

1) Call for WG adoption of draft-haeffner-sfc-use-case-mobility-00.txt and 
draft-kumar-sfc-dc-use-cases-00.txt as WG documents (target: 
informational).
 
2) Defer action on draft-liu-service-chaining-use-cases  and 
draft-meng-sfc-broadband-usecases per the above discussion.
 
Does this make sense?

---

From: Jerome Moisand <[email-masked]>
Date: Mon, 31 Mar 2014 14:28:29 +0000

Hi Linda,

The subscriber management function in a BNG is clearly a Service Function (and a Service Classifier) on its own right. All the BBF use cases are based on such premise, this is the starting point of the service chains. We’re in clear agreement here, and I don’t think we need a new draft to repeat this point.

I still do not understand how DS-Lite and MAP are related to service chaining. There is no need to do any new form of traffic steering to perform such functions. Yes, sure, the CPE needs to do its part of the work, according to corresponding IETF documents (e.g. as defined in the IETF Softwire WG), but again, where is the service chaining? I do not believe that the Softwire group expressed any need for further mechanism besides what they defined. Sorry, I don’t quite get it. I can see how service chaining and IP v4/v6 gets intertwined for the CGNAT approach though, we do agree on this one. If you think there is more than that, then please contribute to BBF (SD-326, SIMR group). We’d welcome more use cases while the Study Document is being refined.

In general, the point remains that it would be greatly appreciated to discuss both service chaining and IPv4/v6 transition use cases, broadband network architecture and nodal requirements in the BBF context, and liaise to IETF when appropriate (e.g. need for protocol work). Same for CPE discussions, including Cloud-CPE. We’re all stretched pretty thin, and could really benefit from discussing in the most appropriate context without undue duplication across std bodies.

Tx
Jerome

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 31, 2014 3:58 AM
To: Jerome Moisand
Cc: [email-masked]; sfc
Subject: 答复: Re: [sfc] Progression of use case documents in the SFC WG

Hi, Jerome

  As a co-author of draft-meng, maybe I have to highlight some points in our draft. As you mentioned:
          Side note: draft-meng-sfc-broadband-usecases seems to cover two topics:
1.       a basic form of service chaining (‘BNAS’ –I guess this means BRAS/BNG- to CGNAT) which is already covered by BBF use cases
2.       then a lot of material about IP v4/v6 transition matters (DS-Lite, MAP, etc), which doesn’t seem to have a direct relationship with service chaining per se. Anyhoo, it turns out that there is another BBF work item in this respect, so corresponding material should find its rightful place.

  It seems that I hold the different opinion of you.  CGNAT is just one SFC use case in Broadband Network per se, as well as NAT64 and other IPv4/v6 transition technology. They are distinctive from each other and they go through different SFC. So we put them together in this draft.  And here, we also want to mention is Subscriber-management function in BNG, which is suggested to be referred as a SF, because BNG's capacity of subscriber is also a bottleneck, it seems reasonable to consider Subscriber-management function as a SF.
  In addition, after listing and comparing them, it turns out that we can not only deploy SFC Domain between BNG and CR, but also we can consider a SFC Domain deployment between CPE and BNG, which is called unify home router in our draft. It means that CPE only support simple L2/L3 functionalities including encapsulating and decapsulating. Wherever the traffic go is decided by the SFC Domain. This seems a bit like your Cloud CPE.
  Also, we propose some considerations (e.g. standalone mode, directly connecting mode  and pool consideration). As for standalone mode and directly connecting mode, which are the main two architecture in IPv6 transition deployment, we think maybe this consideration can  introduce into SFC architecture. As for more details such as pool management, we just give our proposal and the reason for this proposal is for steering the income traffic.

Many thanks!
Linda

Jerome Moisand <[email-masked]<mailto:[email-masked]>>
发件人:  "sfc" <[email-masked]<mailto:[email-masked]>>

2014-03-27 20:55

收件人

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

抄送

主题

Tx
Jerome

Dear chairs,

Some comments below:
•         The proposed actions are not aligned with the feedback received in this thread (Progression of use case documents within the SFC working group). Answers to that poll are in favor of having a generic use case document. IMHo, it is not fair to ignore what was voiced for by wg members in the mailing list as part of a formal call with clear questions.
•         Some of the text that was adopted by the WG as part of the Problem Statement (use case as part of the Problem statement) has been moved to the generic use case. That text is governed by this charter text: “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. Additionally, the working group will
normalize nomenclature and definitions for service function chaining.”. What to do for that text?
•         Having the generic use case document and some few detailed ones do not conflict. It is only a matter of scoping.

Cheers,
Med

WG:

Does this make sense?

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Mon, 31 Mar 2014 14:42:59 +0000

Dear all,

1+ ---- I also fully support the WG director's approach for domain specific use case drafts.

In my humble opinion Jim and Thomas proposed the most pragmatic and most efficient way to work out, how network and DC operators utilize SFCs today. To fully understand, we have to analyze and document the domain specific characteristics of today's more advanced SFC deployments, their potential weaknesses and what are the expectations on future-oriented approaches the WG is working on. A detailed understanding of the real thing is key to successful work.

Even though e.g. DCs and mobile networks may be part of one and the same service delivery chain, their SFC use cases and requirements may be quite different. Even if we claim they both use the same middleware boxes/middleware VMs. On the other hand, typical operator use cases for fixed networks are (very often) a small subset of what is seen in mobile. The difference between them is basically in the amount and representation of metadata.

If we have a more clear picture on the domain specific use cases including their metadata dependence and metadata handling we may proceed to try to generalize the documented use cases to support a flexible enough,  but still unique and future proof  SFC specification. I already had a f2f meeting with Hongyu Li last week and suggested such an approach.

Best regards,
Walter

Von: sfc [mailto:[email-masked]] Im Auftrag von Thomas Nadeau
Gesendet: Freitag, 28. März 2014 13:53
An: Ken Gray (kegray)
Cc: Guichard Jim; [email-masked]; [email-masked]
Betreff: Re: [sfc] Progression of use case documents in the SFC WG

            --Tom

On Mar 27, 2014:8:28 AM, at 8:28 AM, Ken Gray (kegray) <[email-masked]<mailto:[email-masked]>> wrote:

Dear chairs,

Some comments below:

Cheers,
Med

WG:

Does this make sense?

Jim & Thomas