Re: [OPSAWG] WG LC for Service Models Explained
<daniel@olddog.co.uk> Wed, 02 August 2017 11:34 UTC
Return-Path: <dk@danielking.net>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE81413202C for <opsawg@ietfa.amsl.com>; Wed, 2 Aug 2017 04:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.20150623.gappssmtp.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 TLi_8kkBWAxY for <opsawg@ietfa.amsl.com>; Wed, 2 Aug 2017 04:34:27 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 ABA5412EC13 for <opsawg@ietf.org>; Wed, 2 Aug 2017 04:34:26 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id t201so38858785wmt.1 for <opsawg@ietf.org>; Wed, 02 Aug 2017 04:34:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=+6q2ywqtrFJ6Do6MxaFL8nJ+gOqAj252jUZsxU7Vxdo=; b=0hXPcXppN/ExycJ8Z8lGyVL2CBYxR0b5OOBr0FS/EH6gK4DZSfK9t4rbkFJIaqIwVG GKXLJFcVBCzfZrKaQju8VlHKRKLpEe0/yHrLFgyR3c8zz2Rl5Rj7Lp6b6njNJVCU/LAz rrmeH6zWi2nrpuShjkdV1VdrmWMdElyWs0tqAmTrqvg1QsijxvM9aD2ZapsH6D1myEgd TWDm708z0OjvIalgvSqTlq/PjlROkoNw4KYt0DOm/ujEVpFmO8E0K4/PY1DXnX3JLs5h z6XpaqSOosgtVSzaOaeIKpsNpGEJtbstQbF7Y50eWnn9/IFnfdpK9tanjcIkRnpy+1De M5mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=+6q2ywqtrFJ6Do6MxaFL8nJ+gOqAj252jUZsxU7Vxdo=; b=p4nVGzdIH3FuoAPggiJYqpehW+Qor2OIuisluS+dR1DmBcaHqho9SwLuneF2cfVr2V RIaeDGGaqy8kMjqAUndYDVg7J/C9HdvqPAs/1zA6kwdyNoU+duunauJ1whUSQJTOD2rF pvVM96a+mdK0L1WzzFKJqUw/kT7+QJDXo0azAkaOWbyUCVnjyRnQ4AsY/Yjzl2ODl220 jIy8l6dAR6BhfjYvO5IqwEI+y5UNqIGfgkrxnPZXNNdkpt+i+c3XK23JDNnnN33Hzd1W hA+YRAR9pqCa49j5uz5x5lqGOhezVH6hPAcBm4T308vFXDfveVejkB9wqgEjVvXHGnkO OKlw==
X-Gm-Message-State: AIVw1114VZ7YOf3b18lmrH2GEiC0j2dX2fx7hjUiWPb7sFMtqVeuqwkT GVeTcKDyCQMxSFTU
X-Received: by 10.28.30.14 with SMTP id e14mr3404147wme.10.1501673665120; Wed, 02 Aug 2017 04:34:25 -0700 (PDT)
Received: from INARA ([87.101.243.155]) by smtp.gmail.com with ESMTPSA id y35sm12893146wrd.60.2017.08.02.04.34.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 04:34:24 -0700 (PDT)
Sender: Daniel King <dk@danielking.net>
X-Google-Original-Sender: "Daniel King" <dk@danielking.net>
From: daniel@olddog.co.uk
To: adrian@olddog.co.uk, opsawg@ietf.org
References: <010301d30968$186c8410$49458c30$@olddog.co.uk> <01c601d30b7a$23af8f20$6b0ead60$@olddog.co.uk>
In-Reply-To: <01c601d30b7a$23af8f20$6b0ead60$@olddog.co.uk>
Date: Wed, 02 Aug 2017 14:34:15 +0300
Message-ID: <004f01d30b83$4a6990d0$df3cb270$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFqyy8irvd3/FbyVkKh1BMxk4t9NAMfxVMpoyhuUOA=
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/L1oO92ANkLnTxYx9G8TaW18fSEU>
Subject: Re: [OPSAWG] WG LC for Service Models Explained
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Aug 2017 11:34:29 -0000
Thanks Adrian, all good. BR, Dan. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: 02 August 2017 13:29 To: daniel@olddog.co.uk; opsawg@ietf.org Subject: RE: [OPSAWG] WG LC for Service Models Explained Dan, thanks! > Comment #1 - The current abstract could be simmered down to: > > The IETF has produced a number of data modules in the YANG modelling > language. The majority of these modules are used to construct data > models to model devices or monolithic functions. > > A small number of YANG modules have been defined to model services > (for example, the Layer Three Virtual Private Network Service Model > produced by the L3SM working group and documented in RFC 8049). > > This document describes the role of an IETF service model, and where a > service model might fit into a Software Defined Networking architecture. > Note that service models do not make any assumption of how a service > is engineered and delivered to the customer; details of how network > protocols and devices are engineered to deliver a service are captured > in other models that are not exposed through the Customer-Provider Interface. OK. Appreciate reducing the Abstract. Most changes good. Some "not far enough". But I would like to keep the mention of config and operational status. So... The IETF has produced a number of data modules in the YANG modelling language. The majority of these are used to construct data models to model devices or monolithic functions and they allow access for configuration and to read operational status. A small number of YANG modules have been defined to model services (for example, the Layer Three Virtual Private Network Service Model documented in RFC 8049). This document describes the role of an IETF service model, and shows where a service model fits into a Software Defined Networking architecture. Note that service models do not make any assumption of how a service is engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other models that are not exposed through the Customer-Provider Interface. > Comment #2 - A mix of "modelling" and "modeling" usage in the document. > British or American is fine, but maybe not both. Oh, yes. Fixing. > Comment #3 - Section 1. Introduction, second paragraph, last sentence: > ""There may also be a hierarchy of such components with > super-controllers, domain controllers, and device controllers all > exchanging information and instructions using YANG models" > > The only reference to "super-controller" I found (using a popular > search > engine) was an accessory for the Nintendo Entertainment System video > game console. Maybe the authors might want to use the term "super controller". Isn't the Super Controller a character in Guardians of the Galaxy? > Comment #4 - Section 1. Introduction, third paragraph, last sentence: > "Ultimately they could be used in online, software-driven dynamic systems." > > Why not use the term "software defined networks" or "SDN systems", > instead of "online, software-driven dynamic systems". You use the term > "software defined networks" in the abstract and earlier in the > introductory text, and again in section 4. Yes. Actually we should say both since "online, software-driven dynamic systems" is only a step on the path to SDN. Hence... Such models may be used in manual and even paper-driven service request processes with a gradual transition to IT-based mechanisms. Ultimately they could be used in online, software-driven dynamic systems, and eventually as part of an SDN system. > Comment #5 - Section 3. Using Service Models, third paragraph, last > sentence: > > "However, co-located software components might use an API, while > systems with more direct human interactions might use web pages or > even paper forms." > > Indeed RFC6241 and RFC8040 are data-model/schema-driven APIs. Should > the sentence read ("internal API" or "private API"), as in: > > "However, co-located software components might use an internal API, > while systems with more direct human interactions might use web pages > or even paper forms." O tempera, o mores. Once upon a time there were APIs and remote APIs (which weren't really APIs at all but rather a communications library accessed via an API and delivering remotely via another API). But language is a living medium :-) I don't object to "internal API". > Comment #6 - The document uses capitalised and non-capitalised > instances of "Control Plane". Ack > Comment #9 - Section 9. Manageability Considerations > > You use the term "Service Orchestration" in this section but I found > no reference, or previous definition, in the document. Figure 3 introduces the "Service Orchestrator". Do you think we should add more text to explain its function? > Overall, really minor NITs. Good job with the document. Thanks. All nits are good nits. Adrian
- [OPSAWG] WG LC for Service Models Explained Tianran Zhou
- Re: [OPSAWG] WG LC for Service Models Explained mohamed.boucadair
- Re: [OPSAWG] WG LC for Service Models Explained daniel
- Re: [OPSAWG] WG LC for Service Models Explained Adrian Farrel
- Re: [OPSAWG] WG LC for Service Models Explained Adrian Farrel
- Re: [OPSAWG] WG LC for Service Models Explained daniel
- Re: [OPSAWG] WG LC for Service Models Explained Tianran Zhou
- Re: [OPSAWG] WG LC for Service Models Explained Qin Wu
- Re: [OPSAWG] WG LC for Service Models Explained Adrian Farrel
- Re: [OPSAWG] WG LC for Service Models Explained Adrian Farrel
- Re: [OPSAWG] WG LC for Service Models Explained Adrian Farrel