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

[xiechf01 <[e-mail]>]

Hi,all
I support to have one general use case document.

Chongfeng@CT




From: "Liushucheng (Will)" <liushucheng at huawei.com>
To: "mohamed.boucadair at orange.com" <mohamed.boucadair at orange.com>, "Jim Guichard (jguichar)" <jguichar at cisco.com>, "sfc at ietf.org" <sfc at ietf.org>
Date: Fri, 28 Mar 2014 08:10:50 +0000
In-reply-to: <[e-mail]>
References: <[e-mail]> <[e-mail]>
List-id: Network Service Chaining <sfc.ietf.org>


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:sfc-bounces at ietf.org] On Behalf Of mohamed.boucadair at orange.com
Sent: Thursday, March 27, 2014 3:08 PM
To: Jim Guichard (jguichar); sfc at ietf.org
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:sfc-bounces at ietf.org] De la part de Jim Guichard (jguichar)
Envoyé : mercredi 26 mars 2014 18:54
à : sfc at ietf.org
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  and draft-meng-sfc-broadband-usecases per the above discussion.
 
Does this make sense?
 
Jim & Thomas



References:
[sfc] Progression of use case documents in the SFC WG
From: Jim Guichard (jguichar)
Re: [sfc] Progression of use case documents in the SFC WG
From: mohamed.boucadair
Prev by Date: Re: [sfc] SFC as an IP or UDP application, pros and cons?
Next by Date: Re: [sfc] Progression of use case documents in the SFC WG
Previous by thread: Re: [sfc] Progression of use case documents in the SFC WG
Next by thread: Re: [sfc] Progression of use case documents in the SFC WG
Index(es):
Date
Thread
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.




xiechf01