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

Dave,

sorry I missed to reply rapidly and then saw you had updated the draft.
I'm fine with progressing the new version.

Thanks
-m

Le 2018-04-22 à 5:23, Dave Dolson a écrit :
> 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
> 