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

[[e-mail]]

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 <[e-mail]> 
发件人:  "sfc" <[e-mail]>
2014-03-27 20:55

收件人
"[e-mail]" <[e-mail]>
抄送

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






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:[e-mail]] On Behalf Of Ken Gray (kegray)
Sent: Thursday, March 27, 2014 8:28 AM
To: [e-mail]; Jim Guichard (jguichar); [e-mail]
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. 
 
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: "[e-mail]" <[e-mail]>
Date: Thursday, March 27, 2014 3:07 AM
To: "Jim Guichard (jguichar)" <[e-mail]>, "[e-mail]" <
[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]] 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  and 
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