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

Martin Vigoureux <martin.vigoureux@nokia.com> Tue, 10 April 2018 10:11 UTC

From: Martin Vigoureux <martin.vigoureux@nokia.com>
To: draft-ietf-sfc-hierarchical@ietf.org
Cc: "sfc-chairs@ietf.org" <sfc-chairs@ietf.org>, sarikaya@ieee.org, sfc@ietf.org
Message-ID: <49f64a48-cd4c-db01-7741-66f6c613c77d@nokia.com>
Date: Tue, 10 Apr 2018 12:11:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Apr 2018 10:11:12.2054 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 632c8973-6aa4-4c48-abb6-08d59ecb6340
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2144
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/-5_wdsYQC5e9r1tPemftIpN_yeA>
Subject: [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 10:11:21 -0000

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.

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

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