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