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

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 26 Mar 2014 17:54:02 +0000

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: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Mar 2014 16:00:16 -0400

Where does the long-lived flows case we presented in London fit?

Thank you,
Joel

On 3/26/14, 1:54 PM, Jim Guichard (jguichar) wrote:
> 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
>     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
> <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
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: <[email-masked]>
Date: Thu, 27 Mar 2014 08:07:45 +0100

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]
Objet : [sfc] Progression of use case documents in the SFC WG

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: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Mar 2014 10:59:28 -0400

This looks like a good idea to me.
One wide net, and then specific narrow nets where appropriate.
Liaising to appropriate SDOs or fora with the narrow documents is also 
very helpful.

Yours,
Joel

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Fri, 28 Mar 2014 08:10:50 +0000

I second Med.

According to what I heard during London meeting, I don't think the proposal here is in accordance with the discussion of audience.  There were voices supporting to have a generic use case document, that should not be ignored. I copied the part of discussion for SFC use case here for you convenience.

- SFC use cases/requirements Q&A (open-mic) - [10 minutes]

Jim: Now we will have an open mike session on questions for all presenters. We chairs also have questions for last.

Thomas: Guidance for the WG, we want to understand what we need to do as a WG.

Jim: Also, there will be asking questions on whether as a WG we want to have a separate item as requirements

... and listing those requirements or not. More later.

Linda Dunbar: Question for Walter. Can we show one slide with PCI, TDF, PCRF.

Jim: That will be difficult to show individual slides.

Linda: Curious about the metadata. We use to pass between PCI, TDF, PCRF. There is an interface passing

... metadata. How is that done today, and how is it different?

Walter: First of all, metadata is used on the mobile side. But also use info from the PCRF. For example,

... as I told you some days before, this slide (slide 7) can be considered metadata in an optimization scheme.

... so is chaining in general. Every service chain will start with a classifier. We want to ensure we have appropriate

... path through the set of service chains which means that we have to support the classifier as a certain set of the

... mobile context in place.

Linda: Can we still use that mechanism to pass metadata?

Walter: Today, you could think of simple protocols like RADIUS or diameter interfaces.

Linda: Can we still continue using diameter to pass metadata.

Jim: Let's take it offline, I do not want to get into specific details. Why is the TDF interface not acceptable today.

Linda: No, this is very important for the WG because there is a lot of discussion about metadata passing, and

... today we have metadata passing.

Jim: We will get to that discussion, but not on this particular document.

Someone 3: metadata, msec. diameter, hundreds of milliseconds.

Walter: As I already said, we should avoid diameter

Ken, NTT: How do we do bidirectional service chain? Is there a use case with handling metadata?

Thomas: I think we established that there is bidirectional passing. Your question is about whether have metadata.

Shin Shakoma (Japan - NTT): In terms of controlling incoming and outgoing packets for bidirectional.

... Is it implementation?

Jim: Does anyone want to comment on that?

Someone 5: Totally implementation issue how to handle that in bidirectional.

Jim: I want to clarify that question. If we assume we require bidir SFC. Is there a control push into the network

... to push bidirectionally or part of the service chain. I have my own opinion.

Lucy Yong from Huawei: I have a comment on how to document the use cases. It is useful to document the use cases

... as a single document with documented use cases.

Jim: One of the questions we are thinking through: if there are more detailed use cases, what do you include?

... we do not want duplication of 2 page documents. Frankly we do not know the answer.

Lucy: One document minimizes the problem.

Thomas: Do you want one doc period or also additonals?

Lucy: One document period. If there are use cases, you can use appendix.

Thomas: With the current drafts, there is too much content for a single doc.

Lucy: But there is overlap.

Jim: I am not sure we have that overlap. I've read the mobility and DC docs in detail, there is no overlap in those.

... but that feedback is important to the WG. My fear is a 100 page doc that we never finish.

Lucy: The main purpose of the use case is to drive architecture and requirements, we do not need 100 page.

Nicoli (Qosmos): Coming back to the discussion on subscriber ID. I am taking a very operational view. I saw in use cases

... coarse and fine grained policies to identify which resources will be used. It is equally important to find network point

... identifier but also fine grained and coarse grained identifiers to where the packet is from. And how to use the packet

... for particular subscribers.

Jeff Haas, Juniper: I support Lucy that we need to take use case docs and summarize in a list of enumerated requirements.

IRS is going through the same thing right now. Braking requirements as a list will help. You can refer to things.

? (China Mobile): We can reference and not talk here. Merge 3 use cases into a general document. Use case

... discussed here is 3GPP. That's one recommendation.

Walter: This is not only for 3GPP what's here. What we see here is a packet gateway, could be a cable model

... gateway. The only remark is that what we need is interfacing between the context on the network side (cable,

... DSL, mobile, etc) so think about abstract interfaces. Carrier network is end-to-end from a used perspective.

... We have to understand the complete environment.

... It's more of a gateway function between the service chain environment with the rest of world.

Someone 6: I agree. That proves we have a general use case. We need a general use case here.

Parviz Yegani: We need to move forward. Maybe the next IETF is that time.

Regards,
Shucheng (Will)

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

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: Zhen Cao <[email-masked]>
Date: Fri, 28 Mar 2014 16:34:16 +0800

Dear Chairs,

I do not know how we come to this conclusion given the below facts
1) Email discussion on January,
http://www.ietf.org/mail-archive/web/sfc/current/msg00966.html, with
many supports of moving forward the  document draft-liu-sfc-use-cases.

2) London discussion as per
http://www.ietf.org/proceedings/89/minutes/minutes-89-sfc , where
several people voice out that we need one document

As for draft-liu-sfc-use-cases, I'd say it is not a simple 'general'
use cases write-up, actually it has already merged with one mobility
use case from Med, and it also describe the use cases from the
abstract point of view, i.e. two angles that try to summarize the
existing activities.

Technically, one use cases document is much better for people both
inside and outside to understand the sfc activities better. The
draft-liu-sfc-use-cases serves this target very well. And many use
cases are basically the same according the chaining logic, why we need
so many...

So based on previous discussion both on the list and f2f meeting,  I
am suggesting that we move forward the general document and consider
other documents in meanwhile as they turn out to be significant.

Many thanks,
zhen cao
china mobile

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 28 Mar 2014 11:03:47 -0400

One aspect in the chairs proposal that struck me has particularly useful 
was keeping the use case document for specific partners separate.  That 
way, it is MUCH easier to liaise with 3GPP or the BBF on the aspects of 
the use cases that are important to them.

Yours,
Joel

---

From: <[email-masked]>
Date: Fri, 28 Mar 2014 16:15:25 +0100

Joel,

What I understood from Jerome's answer is he is OK to cite the liaison document in the generic use case document (+ some text): 

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

There is no need to edit a specific use case document only for the sake to have an IETF stamp on it.

I'm sure we can adopt a similar position for the 3GPP case.

Cheers,
Med

>-----Message d'origine-----
>De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern
>Envoyé : vendredi 28 mars 2014 16:04
>À : Zhen Cao
>Cc : [email-masked]
>Objet : Re: [sfc] Progression of use case documents in the SFC WG
>
>that
>and

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 28 Mar 2014 17:25:12 +0000

Thank you Joel. Yes, this is the approach we plan to take and I see a lot
of support for that on the list.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 28 Mar 2014 17:44:30 +0000

I agree with the chair's proposal as well.

Surendra.

On 3/27/14 7:59 AM, "Joel M. Halpern" <[email-masked]> wrote:

>> we would need to understand why two efforts ‹ one in BBF and one in the

---

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

Hi Joel and all, 

The current recommendation is casting the narrow nets firstly.
Shouldn't we cast the wide net first and then the specific narrow nets?

Regards,
Yuanlong

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, March 27, 2014 10:59 PM
To: [email-masked]
Subject: Re: [sfc] Progression of use case documents in the SFC WG

Yours,
Joel

On 3/26/14, 1:54 PM, Jim Guichard (jguichar) wrote:
> we would need to understand why two efforts - one in BBF and one in the

---

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

Objection to this proposal, which is contrary to major voice in previous email discussion as well as in London.

Draft-liu has its value at least in following aspects:

1.      It provides a general view of where SFC could be applied to. New comers don’t have to go through each standalone use case draft and read through tens of pages to understand scenarios.

2.      It is a container for those valuable use cases that don’t have to be a standalone draft to make it clear, even though listing all possible use cases is unnecessary. A good example is draft-krishnan-sfc-long-lived-flow-use-cases. It also a good place for reference to pertinent work in other SDOs, e.g. BBF, which can avoid duplicated work.

3.      It provides an abstraction of common features of all use case, see section 4 in latest revision draft-liu-sfc-use-cases<http://tools.ietf.org/id/draft-liu-sfc-use-cases-04.txt>. This is a good guidance for requirements and architecture derivation.

Hongyu

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, March 27, 2014 1:54 AM
To: [email-masked]
Subject: [sfc] Progression of use case documents in the SFC WG

WG:

Does this make sense?

Jim & Thomas

---

From: Jiangyuanlong <[email-masked]>
Date: Sat, 29 Mar 2014 04:58:15 +0000

Joel,
This seems like a general use case which fits into DC, broadband, mobility and etc. 
Cheers,
Yuanlong

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, March 27, 2014 4:00 AM
To: Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] Progression of use case documents in the SFC WG

Thank you,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 29 Mar 2014 12:19:11 +0000

Jim, Thomas,

This sounds like a great approach. Thanks for organizing the use-case puzzle into this recommendation.

Thanks,

Carlos.

On Mar 26, 2014, at 1:54 PM, Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>> wrote:

WG:

Does this make sense?

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

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Sat, 29 Mar 2014 12:32:54 +0000

Hi Hongyu,

In our email to the list Thomas and I specifically said (with regards to draft-liu-sfc-use-cases):

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

You will note that this is not an outright rejection of draft-liu-sfc-use-cases but rather specific questions on the validity of adopting the document given that our preference (and the majority of responses from the WG support this view) is to produce standalone documents for mobility and data center, and liaise with BBF for broadband. Therefore, what content is left in the more general document to justify adopting as a separate document? Further if adopted how as a WG can we avoid duplication of content across multiple documents?

From: "Hongyu Li (Julio)" <[email-masked]<mailto:[email-masked]>>
Date: Saturday, March 29, 2014 at 12:47 AM
To: Jim Guichard <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Progression of use case documents in the SFC WG

Hongyu

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

WG:

Does this make sense?

Jim & Thomas

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sat, 29 Mar 2014 19:08:30 +0000

Hi Yuanlong,

And therefore I'd say it deserves a section by itself...

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Zhen Cao <[email-masked]>
Date: Sun, 30 Mar 2014 16:20:25 +0800

Hello Jim,

On Sat, Mar 29, 2014 at 8:32 PM, Jim Guichard (jguichar)
<[email-masked]> wrote:
> You will note that this is not an outright rejection of
> draft-liu-sfc-use-cases but rather specific questions on the validity of
> adopting the document given that our preference (and the majority of
> responses from the WG support this view) is to produce standalone documents

I do not think we can conclude if it is majority now. At least, I did
not see respect the previous email discussion and London meeting
minutes...

> for mobility and data center, and liaise with BBF for broadband. Therefore,
> what content is left in the more general document to justify adopting as a
> separate document? Further if adopted how as a WG can we avoid duplication
> of content across multiple documents?

I think Hongyu already justified below. Besides, it also has a cloud
CPE use case which has not been covered elsewhere.

> 3.      It provides an abstraction of common features of all use case, see
> section 4 in latest revision draft-liu-sfc-use-cases. This is a good
> guidance for requirements and architecture derivation.

---

From: Zhen Cao <[email-masked]>
Date: Sun, 30 Mar 2014 16:24:18 +0800

Hi Jim

I do not think ease to liaison is a good reason. Does IETF produce
documents based on the ease to liaison? And one document is even
easier :)

Many thanks,
zhen

---

From: Qiong <[email-masked]>
Date: Mon, 31 Mar 2014 10:19:06 +0800

Hi all,

I agree with Will. The general use case draft is a good place to put
together the general use cases for sfc as discussed in the previous
meeting. It is better for understanding and producing future work.

Best wishes
Qiong

On Fri, Mar 28, 2014 at 4:10 PM, Liushucheng (Will)
<[email-masked]>wrote:

>  I second Med.
>
>
>
> According to what I heard during London meeting, I don’t think the
> proposal here is in accordance with the discussion of audience.  There were
> voices supporting to have a generic use case document, that should not be
> ignored. I copied the part of discussion for SFC use case here for you
> convenience.
>
>
>
> Jim: Now we will have an open mike session on questions for all
> presenters. We chairs also have questions for last.
>
> … and listing those requirements or not. More later.
>
>
>
> … metadata. How is that done today, and how is it different?
>
> … as I told you some days before, this slide (slide 7) can be considered
> metadata in an optimization scheme.
>
> … so is chaining in general. Every service chain will start with a
> classifier. We want to ensure we have appropriate
>
> … path through the set of service chains which means that we have to
> support the classifier as a certain set of the
>
> … mobile context in place.
>
> Jim: Let’s take it offline, I do not want to get into specific details.
> Why is the TDF interface not acceptable today.
>
> … today we have metadata passing.
>
> … Is it implementation?
> … to push bidirectionally or part of the service chain. I have my own
> opinion.
>
>
>
> … as a single document with documented use cases.
>
> … we do not want duplication of 2 page documents. Frankly we do not know
> the answer.
>
> Jim: I am not sure we have that overlap. I’ve read the mobility and DC
> docs in detail, there is no overlap in those.
>
> … but that feedback is important to the WG. My fear is a 100 page doc that
> we never finish.
>
> Nicoli (Qosmos): Coming back to the discussion on subscriber ID. I am
> taking a very operational view. I saw in use cases
>
> … coarse and fine grained policies to identify which resources will be
> used. It is equally important to find network point
>
> … identifier but also fine grained and coarse grained identifiers to where
> the packet is from. And how to use the packet
>
> … for particular subscribers.
>
>
>
> Jeff Haas, Juniper: I support Lucy that we need to take use case docs and
> summarize in a list of enumerated requirements.
>
> … discussed here is 3GPP. That’s one recommendation.
>
> Walter: This is not only for 3GPP what’s here. What we see here is a
> packet gateway, could be a cable model
>
> … gateway. The only remark is that what we need is interfacing between the
> context on the network side (cable,
>
> … DSL, mobile, etc) so think about abstract interfaces. Carrier network is
> end-to-end from a used perspective.
>
> … We have to understand the complete environment.
>
> … It's more of a gateway function between the service chain environment
> with the rest of world.
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *
> [email-masked]
> *Sent:* Thursday, March 27, 2014 3:08 PM
> *To:* Jim Guichard (jguichar); [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
> 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] <[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:
>
>
>
> 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.
>
>
>
> appears that we have a number of documents that warrant being developed as
> standalone documents. Specifically:
>
>
>
> 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
> 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.
>
>
>
> 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
> 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
>

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/
<http://sourceforge.net/projects/laft6/>*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/
<http://sourceforge.net/projects/pcpportsetdemo/> *
===============================================

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 31 Mar 2014 03:57:46 +0000

Hi Diego,

Yes, I agree, and a section in draft-liu-service-chaining-use-cases will make more sense rather than repeat it in both draft-haeffner-sfc-use-case-mobility-00 and draft-kumar-sfc-dc-use-cases-00.

Cheers,
Yuanlong

-----Original Message-----
From: Diego R. Lopez [mailto:[email-masked]] 
Sent: Sunday, March 30, 2014 3:09 AM
To: Jiangyuanlong
Cc: Joel M. Halpern; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] Progression of use case documents in the SFC WG

Hi Yuanlong,

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: <[email-masked]>
Date: Mon, 31 Mar 2014 08:41:51 +0200

How can you judge the support of your suggested position at this stage? What does mean "a lot of support" here?!. 

As a chair you should not bias the discussion. 

Cheers,
Med

>Envoyé : vendredi 28 mars 2014 18:25
>À : Joel M. Halpern; Zhen Cao
>Cc : [email-masked]
>>>>While

---

From: <[email-masked]>
Date: Mon, 31 Mar 2014 09:58:04 +0200

Re-,

I don't know how you came to the conclusion regarding majority!

This is your second message in which you are raising "the majority" argument. Raising it is not enough to dismiss the concerns raised in the mailing list.

The point is that use cases are not here to ease liaison with SDOs (there are specific documents for that purpose), but to help identifying requirements and guidelines for the solution design phase.

Having one single document will encourage focusing on this key mission: identify commonalities, aspects that may be specific to a given use case, generalize key features, etc. Note also that SDOs have their own documents, the IETF does not need to repeat what has been documented elsewhere; citing those documents is enough.

You can decide to ignore the opinions expressed in this thread, but IMHO that is not aligned with the spirit of IETF as I see it (see the excellent document wrote by Pete: draft-resnick-on-consensus).

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : samedi 29 mars 2014 13:33
À : Hongyu Li (Julio); [email-masked]
Objet : Re: [sfc] Progression of use case documents in the SFC WG

Hi Hongyu,

"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.      It provides a general view of where SFC could be applied to. New comers don't have to go through each standalone use case draft and read through tens of pages to understand scenarios.

2.      It is a container for those valuable use cases that don't have to be a standalone draft to make it clear, even though listing all possible use cases is unnecessary. A good example is draft-krishnan-sfc-long-lived-flow-use-cases. It also a good place for reference to pertinent work in other SDOs, e.g. BBF, which can avoid duplicated work.

Hongyu

WG:

Does this make sense?

Jim & Thomas

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 31 Mar 2014 13:45:58 +0100

I assume that the plan is to write down the use cases, then to distill from
the use cases the requirements, to write the architecture (or framework)
based on the the requirements and the to write the solutions to satisfy the
requirements consistent with the architecture.

It that is the plan, and that would be the normal method of progression,
the key question regarding the use cases is the efficiency of the data
collection, documentation and review.

Since use case is a data collection process then I can see a good case
for running these separately at least for the immediate future since
this allows different groups to focus on their scenarios and talk to the
external bodies in a way that was uncluttered by disparate applications.

The point where we need to reduce to a single document and deal
with conflicts is when producing the requirements document, and
at that point there needs to be a single document.

A comment in the thread concerned how things got pulled together
so that a reader would know about all the pieces, I would suggest that
the requirements document (which would need to reference the use
cases) would be a fine first single document.

Stewart

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Mon, 31 Mar 2014 15:11:44 +0000

Fully agree - Walter

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Stewart Bryant
Gesendet: Montag, 31. März 2014 14:46
An: Jim Guichard (jguichar); [email-masked]
Betreff: Re: [sfc] Progression of use case documents in the SFC WG

I assume that the plan is to write down the use cases, then to distill from the use cases the requirements, to write the architecture (or framework) based on the the requirements and the to write the solutions to satisfy the requirements consistent with the architecture.

It that is the plan, and that would be the normal method of progression, the key question regarding the use cases is the efficiency of the data collection, documentation and review.

Since use case is a data collection process then I can see a good case for running these separately at least for the immediate future since this allows different groups to focus on their scenarios and talk to the external bodies in a way that was uncluttered by disparate applications.

The point where we need to reduce to a single document and deal with conflicts is when producing the requirements document, and at that point there needs to be a single document.

A comment in the thread concerned how things got pulled together so that a reader would know about all the pieces, I would suggest that the requirements document (which would need to reference the use
cases) would be a fine first single document.

Stewart

---

From: <[email-masked]>
Date: Mon, 31 Mar 2014 17:33:54 +0200

Dear Stewart,

"running these separately at least for the immediate future" is just fine. We can do that without adopting each use case I-D as a working group document, but instead have one single document that sketch the core high-level use cases with some analysis. Doing so would be at least consistent with the WG charter: 

" 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

>De : sfc [mailto:[email-masked]] De la part de Stewart Bryant
>Envoyé : lundi 31 mars 2014 14:46
>À : Jim Guichard (jguichar); [email-masked]

---

From: Lucy yong <[email-masked]>
Date: Mon, 31 Mar 2014 16:07:07 +0000

+1. 

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 31, 2014 1:42 AM
To: Jim Guichard (jguichar); Joel M. Halpern; Zhen Cao
Cc: [email-masked]
Subject: Re: [sfc] Progression of use case documents in the SFC WG

Cheers,
Med

>Thank you Joel. Yes, this is the approach we plan to take and I see a 
>lot of support for that on the list.
>
>>One aspect in the chairs proposal that struck me has particularly 
>>useful was keeping the use case document for specific partners 
>>separate.  That way, it is MUCH easier to liaise with 3GPP or the BBF 
>>on the aspects of the use cases that are important to them.
>>
>>Yours,
>>Joel
>>
>>> cases are basically the same according the chaining logic, why we 
>>> need so many...
>>>
>>>> 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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 31 Mar 2014 17:16:13 +0100

On 31/03/2014 16:33, [email-masked] wrote:
> Dear Stewart,
>
> "running these separately at least for the immediate future" is just fine.
> We can do that without adopting each use case I-D as a working group document,
We can, but in doing so the WG has no control over the content, and
I am not convinced that would be a good thing.

A WG doc means that the WG is working on and own the content. Whether
the final product is n RFC or a single RFC with editor chosen by the
chairs is for consideration at a later date.
> but instead have one single document that sketch the core high-level use cases with some analysis. Doing so would be at least consistent with the WG charter:
>
The Chairs can surely direct a merger when there is agreed content in
WG texts.

The chairs might also want to talk to the ADs to see how strictly they
will interpret that line item. Normally it resolves to "do the right thing
to make expeditious progress".

Stewart

> .

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 31 Mar 2014 15:26:05 -0400

> not see respect the previous email discussion and London meeting

	I think you misunderstand the job of the WG Chairs. It is their job to determine consensus, nor yours.	

	--Tom

---

From: Zhen Cao <[email-masked]>
Date: Tue, 1 Apr 2014 10:54:51 +0800

>         I think you misunderstand the job of the WG Chairs. It is their job to determine consensus, nor yours.

I do know co-chairs have the privilege.  I am also serving as a
co-chair of some group.

I am asking HOW you do that, with no respect to previous email
discussion and London meeting minutes...

I do not see answers to my previous message, so quoted again.
===============

2) London discussion as per
http://www.ietf.org/proceedings/89/minutes/minutes-89-sfc , where
majority of people voice out that we need one document

-Zhen

---

From: Zhen Cao <[email-masked]>
Date: Tue, 1 Apr 2014 10:58:44 +0800

+ 1

and expecting an answer...

---

From: Hui Deng <[email-masked]>
Date: Tue, 1 Apr 2014 11:59:49 +0800

Speaking as a non author of any drafts here, and also voice made during the
F2F meeting.

I am getting lost why IETF needs to document 3GPP components here, they
have already started their work, what we IETF usually do is just refer to
theirs document, this is how standard bodies work together today. Even if
we document here, they maynot agree with the text, are we asking 3GPP to
refer IETF's document about their scenario, that will be weird.

Even during the F2F meeting discussion, I heard from authors of mobility,
he is proposing a general case, ==> check with minutes.

So my recommendation is that one general case would help people to
understand better about technologies and their coherence.

Best regards,

-Hui

2014-03-27 1:54 GMT+08:00 Jim Guichard (jguichar) <[email-masked]>:

> cases from a broadband perspective are being developed in the BBF (see the
> would need to understand why two efforts -- one in BBF and one in the IETF