Re: [sfc] AD review for draft-ietf-sfc-hierarchical-07
Behcet Sarikaya <sarikaya2012@gmail.com> Tue, 10 April 2018 15:12 UTC
Return-Path: <sarikaya2012@gmail.com>
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 6365E12D95D; Tue, 10 Apr 2018 08:12:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 AKa5zLrmR1Pm; Tue, 10 Apr 2018 08:12:11 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EFE12711E; Tue, 10 Apr 2018 08:12:11 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id h143-v6so16318007ita.4; Tue, 10 Apr 2018 08:12:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bXfAEBSMY10bQmSJp7LruqqYf8yd2v+3j9aBx4ZU1OA=; b=bnig0hg52cQFerJRPAetJYCHsmzEL+o/QKRA/IdKCN3gbOGnBnM36VcedGVBWY7xRm pzoWJbFC1bsTfNHCijiRMpGQYv6jLjWwY4WXKUGmc8cnCVF4ruJExFasHmiYLRBvIczx 0n2tLbiGarGXbtYOjlX1a1Yz5MHRoPBRVPrQ+1O9m0Djm8YjuFuAZZPy7meG8+mwDAHf EI6fyp1I8c8rbG28tSx7ryVwBXxvvl0cnNJnQOu5FyrVUzLCBD98KBNDDQXBJKoT2g3N oXxAubzWsxSQgXxzex2+br6nvStQCj444jiNTJ1g49zlg7zJek8VJqM1Xof7yqP94vTL u+gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=bXfAEBSMY10bQmSJp7LruqqYf8yd2v+3j9aBx4ZU1OA=; b=MrH9F457lKD7cIIBLTyZIVvmT8A8HID5vGXsGyK2fZanWBN2xvVkUUl7qu/3BopIY4 oUJ6IbH+fRicPFtfAScfBfxBMYLl/tLxuIXPjG08yxAcxC4/UYKWYoNTUb43B+fLbY+R irEFMELI9hucF990Tw0OLdp4PW1261W1tN7GfURzUPkLhC/29JAFZF9OL3wWm1Q07nqj RGe07WiWagdGYJ9yRHNLZ+GHd6neeGa+Q14OfUA6lj/mrscKDvoWFLyGweEK5qQdxK01 C0x9cSKsOa1mYfAyF2R5Gd3UuOz8Y6tTcG6RJMIJGxC63LppbHlKSZopzpmKY2Q6i8IN 8HuA==
X-Gm-Message-State: ALQs6tC3NcfTo7cGRV6OO+/HfoNZVuU51U7AOq7FKQTeAb9K5GpEFtqO dZflGK4OIDhOHMvfOPiXeboFU+xjJzQA3SyKyzb1Vw==
X-Google-Smtp-Source: AIpwx49XXLTj2IE7EqpJ+JR9WsKljswQ1atBo42L0ydwPKY5rOiI8wXGRM12wQWSI8jtaFnyIM1o/7b7M9j/eizHx9w=
X-Received: by 2002:a24:61c5:: with SMTP id s188-v6mr2781695itc.98.1523373130500; Tue, 10 Apr 2018 08:12:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.192.168.125 with HTTP; Tue, 10 Apr 2018 08:12:10 -0700 (PDT)
Reply-To: sarikaya@ieee.org
In-Reply-To: <49f64a48-cd4c-db01-7741-66f6c613c77d@nokia.com>
References: <49f64a48-cd4c-db01-7741-66f6c613c77d@nokia.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Tue, 10 Apr 2018 10:12:10 -0500
Message-ID: <CAC8QAcd=b+D==ezrx+DZuVpmND17As-V=rYzQU0EOvBHwkhw9A@mail.gmail.com>
To: Martin Vigoureux <martin.vigoureux@nokia.com>
Cc: draft-ietf-sfc-hierarchical@ietf.org, "sfc-chairs@ietf.org" <sfc-chairs@ietf.org>, sfc@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004df2c005697ff234"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/gN42hCg4bseu4OP0Nf2AtRv7ejQ>
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: Tue, 10 Apr 2018 15:12:16 -0000
Bonjour Martin, On Tue, Apr 10, 2018 at 5:11 AM, Martin Vigoureux < martin.vigoureux@nokia.com> 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. > > 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. > > Let me take this one and leave the others to the authors. 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. > > 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 > > 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? >
- [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