Subject: [sfc] AD review for draft-ietf-sfc-hierarchical-07

From: Martin Vigoureux <[email-masked]>
Date: Tue, 10 Apr 2018 12:11:04 +0200

Hello,

I have reviewed this document, thanks to all of you for putting it 
together. Please see my comments below.

Thank you
-m

General:
I am in two minds about this document and maybe because the document 
itself seems to not have clear intent.

It is not clear whether this is simply describing what could be done or 
prescribing what should be done. I take the fact that this is an 
Informational document as leaning towards "description" but there are 
pieces of text which clearly look like prescriptive protocol/functional 
behaviour (although some are not detailed enough to allow for an 
implementation).

I would really appreciate if the objective of this document could be 
clarified so that the reader knows what to expect.

Also, I am not advocating for making this a Standard Track document as I 
believe it would require a lot of rework but on the other hand I am not 
sure how much help it provides to the persons that would want to use the 
concept of hierarchy when deploying SFC in a large domain, nor to those 
that would need to implement it before that. You'll find specific 
comments below but that bigger question remains.

Also, the Shepherd write-up does not seem to follow the template.
Any reason for that? I'd prefer if it was re-written according to the 
template. Thanks.

Specific:
Header:
please write the submission date in the correct format

1. Introduction
    Service Function Chaining (SFC) is a technique for prescribing
    differentiated traffic forwarding policies within an SFC-enabled
    domain.
I am concerned by the fact that this document seems to give another 
definition to SFC. I'm not saying this is wrong but I'd be much more 
comfortable if it was simply saying:

    The SFC architecture is described in detail in [RFC7665], and is not
    repeated here. This document simply uses that architecture.

    We assume that some Service Function Paths (SFPs) need to be selected
    on the basis of application-specific data visible to the network
What are the security implications of this assumption? Can we remove 
that? I think SFC has had it's share of security related discussions.

    So instead of considering a single SFC Control Plane ([I-D.ietf-
    sfc-control-plane])
I'd prefer not to reference a document which has been abandoned by the WG

    Decomposing a network into multiple SFC-enabled domains should permit
    end-to-end visibility of SFs and SFPs.
Is that a wishful outcome or a requirement?

    The criteria for decomposing a domain into multiple SFC-enabled
    sub-domains are beyond the scope of this document.  These criteria
    are deployment-specific.
While I understand this statement, it kind of defeats a good part of the 
purpose of the document, doesn't it?

2.  Hierarchical Service Function Chaining (hSFC)

    A hierarchy has multiple levels: the top-most level encompasses the
    entire network domain to be managed, and lower levels encompass
    portions of the network.  These levels are discussed in the following
    sub-sections.
Should it always be like that or is that just a way and there could be 
other ways? Can we have more-than-two-levels hierarchies or should they 
all be top-and-lower?

2.1.  Top Level
This section describes at length the figure/example but what are the 
take-aways?

    Considering the example depicted in Figure 1, a top-level network
    domain includes SFC data plane components distributed over a wide
    area, including:

    o  Classifiers (CFs),
    o  Service Function Forwarders (SFFs) and
    o  Sub-domains.
Is that an illustrative way to partition the components (e.g., CFs and 
SFFs part of the top-level) or is that the recommended way?

    We expect the system to include a top-level control plane having
    responsibility for configuring forwarding policies and traffic
    classification rules (see for example, [I-D.ietf-sfc-control-plane]).
again, I'd prefer not to reference this doc. More generally, is that 
needed? I don't think so.

2.2.  Lower Levels
Same general comment than 2.1. Also, in this section you largely discuss 
the IBN, which is in fact only introduced after.

3.  Internal Boundary Node (IBN)
This is the core of the proposal, in my opinion, but it comes very late 
in the document. If you don't want to rearchitect the whole document you 
should at least have some text (a sentence at bare minimum) early in the 
document that says something like :
    we introduce the concept of an IBN which acts as the gateway between
    the levels of the hierarchy. We also discuss the options for
    realizing this function.

3.1.x
Is there a recommended way of doing IBN Path Configuration out of the 5 
listed?

4.  Sub-domain Classifier
    Another goal of the hierarchical approach is to simplify the
    mechanisms of scaling in and scaling out SFs.  All of the
    complexities of load-balancing among multiple SFs can be handled
    within a sub-domain, under control of the classifier, allowing the
    higher-level domain to be oblivious to the existence of multiple SF
    instances.
I don't see the simplification here. You hide the complexity to the 
higher level, but it remains in the lower one, doesn't it?

9.1
Please remove:
    Generic security considerations related to the control plane are
    discussed in [I-D.ietf-sfc-control-plane].  These considerations
    apply for both high-level and low-level domains.

Nits:
s/NSH [RFC8300]  or a similar/NSH [RFC8300] or a similar/

    One path is shown from edge classifier to SFF1 to Sub-domain#1
    (residing in data-center1) to SFF1 to SFF2 (residing in data-center
    2) to Sub-domain#2 to SFF2 to network egress.
Shouldn't this text be taken out of the figure and integrated in the 
body of the doc?

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 Apr 2018 10:12:10 -0500

Bonjour Martin,

On Tue, Apr 10, 2018 at 5:11 AM, Martin Vigoureux <
[email-masked]> wrote:

> that would need to implement it before that. You'll find specific comments
> below but that bigger question remains.
>
>
Let me take this one and leave the others to the authors.

> You mean this template:
doc-writeup-essay-style.html
<https://www.ietf.org/iesg/template/doc-writeup-essay-style.html>?

Vis-a-vis this template, the Shepherd writeup misses to explain why the WG
chose this document to be Informational as opposed to Standard Track.
Sorry about that.
I think you explained why in the paragraph above.

I don't see any other deviation, please let me know if any.

Regards,
Behcet

> What are the security implications of this assumption? Can we remove that?
> I think SFC has had it's share of security related discussions.
>
> other ways? Can we have more-than-two-levels hierarchies or should they all
> be top-and-lower?
>
> 2.1.  Top Level
> This is the core of the proposal, in my opinion, but it comes very late in
> the document. If you don't want to rearchitect the whole document you
> I don't see the simplification here. You hide the complexity to the higher
> level, but it remains in the lower one, doesn't it?
>
>
> 9.1
> Please remove:
> Shouldn't this text be taken out of the figure and integrated in the body
> of the doc?
>

---

From: Dave Dolson <[email-masked]>
Date: Sat, 21 Apr 2018 23:23:44 -0400

Martin,

Thank you for the careful review.

My comments below are as an individual contributor.

As an editor, I welcome feedback from the working group.

-Dave

On 2018-04-10 6:11 AM, Martin Vigoureux wrote:
> It is not clear whether this is simply describing what could be done 
> or prescribing what should be done. I take the fact that this is an 
> pieces of text which clearly look like prescriptive 
> protocol/functional behaviour (although some are not detailed enough 
> to allow for an implementation).
>
As an original author, my intention was to show a network architecture 
that allows SFC to scale. Hence it would be informational and optional. 
We could make that explicit in the introduction and abstract.

>
> Also, I am not advocating for making this a Standard Track document as 
> I believe it would require a lot of rework but on the other hand I am 
> not sure how much help it provides to the persons that would want to 
> use the concept of hierarchy when deploying SFC in a large domain, nor 
> to those that would need to implement it before that. You'll find 
> specific comments below but that bigger question remains.
>
Agreed.

> that? I think SFC has had it's share of security related discussions.
I think that can be changed to

    We assume that
    some Service Function Paths (SFPs) need to be selected on the basis
    of transport-layer coordinates.

> I'd prefer not to reference a document which has been abandoned by the WG
I propose leaving the discussion of control plane, and just removing the 
document references.

> Is that a wishful outcome or a requirement?
I'm not sure myself what that means. I think it can be removed.
> While I understand this statement, it kind of defeats a good part of 
> the purpose of the document, doesn't it?
I think the idea is that there are lots of ways one could divide 
functions into different sub-domains. We don't want to tell the operator 
why they would want to do different things, just explain the tools 
available. Like explaining a programming language without trying to 
explain all of the programs one could write...

> other ways? Can we have more-than-two-levels hierarchies or should 
> they all be top-and-lower?
Should it always be like that? Hierarchical is optional, if that's what 
you mean.
I think "multiple levels" means more than two are possible.
In a hierarchy the higher levels are more encompassing... I don't think 
I understand your concern.

> SFFs part of the top-level) or is that the recommended way?
There would need to be CFs and SFFs at each level. Maybe I miss your point.

> needed? I don't think so.
We can remove the reference.

>
> 2.2.  Lower Levels
> Same general comment than 2.1. Also, in this section you largely 
> discuss the IBN, which is in fact only introduced after.
The IBN is introduced here, and explained in greater detail in a later 
section.

> This is the core of the proposal, in my opinion, but it comes very 
> late in the document. If you don't want to rearchitect the whole 
> document you should at least have some text (a sentence at bare 
> minimum) early in the document that says something like :
Thanks. I think we can add this to the introduction.
>
> 3.1.x
> Is there a recommended way of doing IBN Path Configuration out of the 
> 5 listed?
We did not take any such conclusion.

> higher level, but it remains in the lower one, doesn't it?
If there are multiple sub-domains, they can each be managed 
independently, each dealing with a subset of the complexity. If the 
deployment were flat, a single controller would have to manage scaling 
of multiple clusters.
So it is simpler in the scope handled by each controller.

>    apply for both high-level and low-level domains.
OK
> s/NSH [RFC8300]  or a similar/NSH [RFC8300] or a similar/
If you are complaining about the extra space, this is a function of the 
XML-->TXT rendering.
The XML is "<xref target="RFC8300">NSH</xref> or a similar"

> Shouldn't this text be taken out of the figure and integrated in the 
OK
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Dave Dolson <[email-masked]>
Date: Sun, 29 Apr 2018 10:37:37 -0400

I have uploaded a new version of the draft reflecting my suggestions below.

On 2018-04-21 11:23 PM, Dave Dolson wrote:
> that allows SFC to scale. Hence it would be informational and 
> optional. We could make that explicit in the introduction and abstract.
>
>>
>> Also, I am not advocating for making this a Standard Track document 
>> as I believe it would require a lot of rework but on the other hand I 
>> am not sure how much help it provides to the persons that would want 
>> to use the concept of hierarchy when deploying SFC in a large domain, 
>> nor to those that would need to implement it before that. You'll find 
> I propose leaving the discussion of control plane, and just removing 
> the document references.
>
>>
> functions into different sub-domains. We don't want to tell the 
> operator why they would want to do different things, just explain the 
> tools available. Like explaining a programming language without trying 
> to explain all of the programs one could write...
>
>>
>>
>> Should it always be like that or is that just a way and there could 
>> be other ways? Can we have more-than-two-levels hierarchies or should 
> Should it always be like that? Hierarchical is optional, if that's 
> what you mean.
> In a hierarchy the higher levels are more encompassing... I don't 
> think I understand your concern.
>
>>
>> 2.1.  Top Level
>> Is that an illustrative way to partition the components (e.g., CFs 
>> and SFFs part of the top-level) or is that the recommended way?
> If you are complaining about the extra space, this is a function of 
> the XML-->TXT rendering.