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

[Qiong <[e-mail]>]

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)
<[e-mail]>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.
>
>
>
> - 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:[e-mail]] *On Behalf Of *
> [e-mail]
> *Sent:* Thursday, March 27, 2014 3:08 PM
> *To:* Jim Guichard (jguichar); [e-mail]
> *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:[e-mail] <[e-mail]>] *De la
> part de* Jim Guichard (jguichar)
> *Envoyé :* mercredi 26 mars 2014 18:54
> *À :* [e-mail]
> *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
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>
>


-- 
==============================================
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/> *
===============================================