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

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:
> 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.
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.
>
> 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
Agreed.

>
> 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.
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.

>
>    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
I propose leaving the discussion of control plane, and just removing the 
document references.

>
>    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?
I'm not sure myself what that means. I think it can be removed.
>
>    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?
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...

>
>
> 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?
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.

>
> 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?
There would need to be CFs and SFFs at each level. Maybe I miss your point.

>
>    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.
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.

>
> 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.
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.

>
>
> 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?
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.

>
>
> 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.
>
OK
>
>
> Nits:
> 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"

>
>    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?
OK
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc