Re: [sfc] AD review for draft-ietf-sfc-hierarchical-07
Dave Dolson <ddolson@acm.org> Sun, 29 April 2018 14:37 UTC
Return-Path: <ddolson@golden.net>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2B11201FA; Sun, 29 Apr 2018 07:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jip4Z8nxkYoA; Sun, 29 Apr 2018 07:37:41 -0700 (PDT)
Received: from smtp1.execulink.net (smtp1.execulink.net [69.63.44.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C25B120713; Sun, 29 Apr 2018 07:37:41 -0700 (PDT)
Received: from node-3067.tor.pppoe.execulink.com ([216.59.251.251] helo=[192.168.123.13]) by smtp1.execulink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <ddolson@golden.net>) id 1fCnSN-0006vh-Ue; Sun, 29 Apr 2018 10:37:40 -0400
To: Martin Vigoureux <martin.vigoureux@nokia.co>, draft-ietf-sfc-hierarchical@ietf.org
Cc: sarikaya@ieee.org, "sfc-chairs@ietf.org" <sfc-chairs@ietf.org>, sfc@ietf.org
References: <49f64a48-cd4c-db01-7741-66f6c613c77d@nokia.com> <31459972-303b-004d-2b8d-2138916876d3@golden.net>
From: Dave Dolson <ddolson@acm.org>
Message-ID: <9a4565a8-a2d3-6ec9-1a49-ae5420ec4568@golden.net>
Date: Sun, 29 Apr 2018 10:37:37 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <31459972-303b-004d-2b8d-2138916876d3@golden.net>
Content-Type: multipart/alternative; boundary="------------25D176468192954FCD7FEB86"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/31Vkz83JHXG-E-2MowGPhlMdCO4>
Subject: Re: [sfc] AD review for draft-ietf-sfc-hierarchical-07
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Apr 2018 14:37:44 -0000
I have uploaded a new version of the draft reflecting my suggestions below. On 2018-04-21 11:23 PM, Dave Dolson wrote: > > 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 >
- [sfc] AD review for draft-ietf-sfc-hierarchical-07 Martin Vigoureux
- Re: [sfc] AD review for draft-ietf-sfc-hierarchic… Behcet Sarikaya
- Re: [sfc] AD review for draft-ietf-sfc-hierarchic… Dave Dolson
- Re: [sfc] AD review for draft-ietf-sfc-hierarchic… Dave Dolson
- Re: [sfc] AD review for draft-ietf-sfc-hierarchic… Martin Vigoureux