Subject: Re: [sfc] Regarding Hierarchical Service Function Chaining (hSFC)

From: <[email-masked]>
Date: Fri, 9 Dec 2016 13:48:42 +0000

WG,

I have reviewed the current version of the hSFC draft. Here's a few comments from my side, mostly questions for clarification with some rewording proposals/typo detection.

1. Abstract:
* s/compartmentalize/decompose
* s/to able/to
* s/operators/large organizations, for example (I don't think hSFC only applies to operators' environments)

2. Section 1:
* s/dispersed networks comprised/dispersed networks, potentially comprised
* s/involving/and which may involve
* Not sure I would keep the "We expect asymmetrical routing..." - I think this assumption is valid, but is not specific to hSFC designs, anyway.
* "...we decompose the network into smaller domains": As currently worded, this implicitly suggests that the aforementioned "omniscient control plane" might still be in charge. I would (1) remove "omniscient" from the previous wording and (2) elaborate a bit, possibly in the lines of: "...into smaller domains operated by as many SFC control plane components. Coordination between such components is further discussed in the document."
* s/decomposition/decomposing

3. Section 2.1:
* s/...configuring forwarding and classification/configuring forwarding policies and traffic classification rules
* s/configuring top-level/configures top-level
* s/transit/transit across
* s/not configure classification or forwarding/not configure traffic classification rules or forwarding policies
* "...paths are reclassified..." (top page 5): "are selected to forward traffic so that the relevant SFs of the sub-domain can be invoked accordingly"?.

4. Section 2.2:
* The IBN is seen as an SF by the top-level domain (page 6). I was wondering whether an IBN could be seen as many SFs from not only the top-level domain but also "neighboring" sub-domains the said IBN may also attach to?

5. Section 3.1:
* should we read "control plane element" instead of "operator" since the basic assumption is that a single administrative entity decomposes the SFC domain into sub-domains?  

6. Section 3.1.2:
* s/cause/add extra (last sentence of the section)

7. Section 3.1.3 (top page 10):
* s/controller/control plane

8. Section 3.1.4:
* s/header/headers (right below Figure 3)
* s/...upper-level domain, which will.../upper-level domain. This packet will be forwarded in the top-level domain according..."

9. Section 5 (top page 14):
* What does "humans to reason..." mean, since the global vision should be fed/detailed by the sub-domain organization? Besides, the said reasoning should also take into account "peering relationships", i.e., interactions between sub-domains without necessarily soliciting IBNs that connect a given sub-domain to the top-level domain.
* Top-level control does not need...": I would smooth this statement a bit. I think such visibility could facilitate consistency between decisions made by respective control plane elements (e.g., in case of SFP distortion or disruption caused by faulty SFs or SFFs, which may suggest traffic redirection as a function of the policies enforced by various candidate sub-domains. This would encourage  cooperation between control plane elements of the various sub-domains and the control plane of the top-level domain, imho.

10. Section 6 (title):
* s/Adopting/Adapting

I think the draft is in good shape overall and would suggest to move it forward.

Cheers,

Christian.

-----Message d'origine-----
De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern
Envoyé : mercredi 2 novembre 2016 23:52
À : [email-masked]
Objet : [sfc] Regarding Hierarchical Service Function Chaining (hSFC)

After the July IETF meeting, we adopted
https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/

The authors have some revisions as per earlier discussions.
There has not been much discussion of this document on the list.
Before we conclude that this is done, it would be good, as per the slides from that meeting (https://www.ietf.org/proceedings/96/slides/slides-96-sfc-7.pdf, last
slide) to have a couple of reviews.

Are there a couple of working group members (not authors of this
document) who can take the time and have the interest to review this?

Thank you,
Joel

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Dave Dolson <[email-masked]>
Date: Tue, 13 Dec 2016 15:02:34 +0000

Christian,
Thanks for the careful review. Mostly I'm in agreement.
See comments inline [DD].
I've made the changes in github.
https://github.com/dcdolson/draft-dolson-sfc-hierarchical

Changes:
https://github.com/dcdolson/draft-dolson-sfc-hierarchical/commit/c642d17ef091749b40c0ad9a69343deaef0b0592

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, December 09, 2016 8:49 AM
To: [email-masked]
Cc: Joel M. Halpern
Subject: Re: [sfc] Regarding Hierarchical Service Function Chaining (hSFC)

WG,

1. Abstract:
* s/compartmentalize/decompose
* s/to able/to
* s/operators/large organizations, for example (I don't think hSFC only applies to operators' environments)
[DD] Would not large organizations also be "network operators" ?

2. Section 1:

3. Section 2.1:
[DD] How about "packets are reclassified to paths directing them to the required SFs of the sub-domain."

4. Section 2.2:
* The IBN is seen as an SF by the top-level domain (page 6). I was wondering whether an IBN could be seen as many SFs from not only the top-level domain but also "neighboring" sub-domains the said IBN may also attach to?
[DD] Do you mean that there could be a chain of IBN-SFs in the top-level domain? That is intended. If you wonder whether an IBN  could be in multiple top-level domains, I think that gets confusing.

5. Section 3.1:
* should we read "control plane element" instead of "operator" since the basic assumption is that a single administrative entity decomposes the SFC domain into sub-domains?  
[DD] How about, "The lower-level domain may be provisioned with valid high-level paths or may allow any high-level paths."

6. Section 3.1.2:
[DD] "increase"

8. Section 3.1.4:

9. Section 5 (top page 14):
* What does "humans to reason..." mean, since the global vision should be fed/detailed by the sub-domain organization? Besides, the said reasoning should also take into account "peering relationships", i.e., interactions between sub-domains without necessarily soliciting IBNs that connect a given sub-domain to the top-level domain.
[DD] Controllers are designed by humans (as far as I know...). I think it is easier to think about smaller problems. (This is a feature of hierarchical systems in any area of human endeavor.)
[DD] Sorry, I don't understand your point about "peering relationships". Can you please clarify?

* Top-level control does not need...": I would smooth this statement a bit. I think such visibility could facilitate consistency between decisions made by respective control plane elements (e.g., in case of SFP distortion or disruption caused by faulty SFs or SFFs, which may suggest traffic redirection as a function of the policies enforced by various candidate sub-domains. This would encourage  cooperation between control plane elements of the various sub-domains and the control plane of the top-level domain, imho.
[DD] I would like to say that one should be able to understand a sub-domain as though it were an SF. So yes, it is useful to know what an SF is capable of in regards to connecting it to other SFs. I've tentatively added the parenthetical, " (Top-level control considers a sub-domain as though it were an SF.)"

10. Section 6 (title):
* s/Adopting/Adapting

Cheers,

Christian.

-----Message d'origine-----

Thank you,
Joel

---

From: <[email-masked]>
Date: Tue, 13 Dec 2016 17:36:51 +0000

Hello Dave, all,

Many thanks for your quick feedback and clarifications. Your proposed changes look good to me. A few more inline.

-----Message d'origine-----
De : Dave Dolson [mailto:[email-masked]] 
Envoyé : mardi 13 décembre 2016 16:03
À : JACQUENET Christian IMT/OLN; [email-masked]
Cc : Joel M. Halpern
Objet : RE: [sfc] Regarding Hierarchical Service Function Chaining (hSFC)

[CJ] [snip] 

[DD] Would not large organizations also be "network operators" ?
[CJ] I was think about large, multi-national companies that typically deploy intranet/VPN services that could take advantage of hSFC - banking, airline and oil companies come to mind. Of course, these companies may also be customers of network operators, but I can think of a couple of large organizations I had the opportunity to discuss with and which are not network operators.

[CJ] [snip]
[CJ] Fine by me.

4. Section 2.2:
* The IBN is seen as an SF by the top-level domain (page 6). I was wondering whether an IBN could be seen as many SFs from not only the top-level domain but also "neighboring" sub-domains the said IBN may also attach to?
[DD] Do you mean that there could be a chain of IBN-SFs in the top-level domain? That is intended.
[CJ] Agreed, but my question was more related to the sub-domains interconnected by IBNs: either sub-domains are cascaded (in which case, this would look like the chain of IBN-SFs you mention above) or they "peer" through IBNs. One example that comes to mind is an IoT service that would consist in dynamically monitoring a set of biometric data. Collected data would be forwarded along a SFP that would be associated to a SFC that would for example be comprised of 6lo encap/decap SFs, DPI SF and EXT setting SF. The SFP would be established between, say, the connected object and the nearest hospital facility (or emergency dispatch unit) and would evolve as people move from one town to another - each of the metropolitan regions corresponding to a SFC sub-domain, whereas the top level domain would be the nationwide epidemiologic network. In that case, I can think about IBNs connecting sub-domains with each other. I realize this may look like science fiction, but I can also provide equivalent example in the corporate market.
 If you wonder whether an IBN  could be in multiple top-level domains, I think that gets confusing.
[CJ] No, that was not my point.

5. Section 3.1:
[CJ] Fine by me.

6. Section 3.1.2:
* s/cause/add extra (last sentence of the section) [DD] "increase"

8. Section 3.1.4:

9. Section 5 (top page 14):
* What does "humans to reason..." mean, since the global vision should be fed/detailed by the sub-domain organization? Besides, the said reasoning should also take into account "peering relationships", i.e., interactions between sub-domains without necessarily soliciting IBNs that connect a given sub-domain to the top-level domain.
[DD] Controllers are designed by humans (as far as I know...). I think it is easier to think about smaller problems. (This is a feature of hierarchical systems in any area of human endeavor.) [DD] Sorry, I don't understand your point about "peering relationships". Can you please clarify?
[CJ] This peering notion refers to the above comment about possible cascaded sub-domains or sub-domains connected with each other by means of an IBN (IoT service example).

[CJ] OK.

Cheers,

Christian.

-----Message d'origine-----
De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern Envoyé : mercredi 2 novembre 2016 23:52 À : [email-masked] Objet : [sfc] Regarding Hierarchical Service Function Chaining (hSFC)

Thank you,
Joel

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 Dec 2016 12:57:40 -0500

We do many times want to talk about operational organizations, whether 
they are external service providers or internal organizations.  "Network 
operators" or "network operations" are terms frequently used for that. 
The issue with just saying "large organizations" is that most of the 
large organization is not involved in this.

Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Tue, 13 Dec 2016 18:13:12 +0000

Christian,
I'm confused by what you might mean by having sub-domains "peer" through IBNs. Can you describe the mechanism more concretely?
(Comments raised re: section 2.2 and section 5.)

I'm guessing you mean sub-domains elements communicate directly with elements in other sub-domains?
(I would not consider that to be proper hSFC.)

-Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, December 13, 2016 12:37 PM
To: Dave Dolson; [email-masked]
Cc: Joel M. Halpern
Subject: RE: [sfc] Regarding Hierarchical Service Function Chaining (hSFC)

Hello Dave, all,

-----Message d'origine-----

[CJ] [snip] 

[CJ] [snip]

4. Section 2.2:

5. Section 3.1:

6. Section 3.1.2:

8. Section 3.1.4:

Cheers,

Christian.

-----Message d'origine-----

Thank you,
Joel