Re: [netmod] [OPSAWG] Question on draft-ietf-netmod-yang-model-classification

Dean Bogdanovic <ivandean@gmail.com> Mon, 30 January 2017 11:52 UTC

Return-Path: <ivandean@gmail.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5011D12945B; Mon, 30 Jan 2017 03:52:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 XVbAMWqMuj6U; Mon, 30 Jan 2017 03:52:33 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 5B0CD12945A; Mon, 30 Jan 2017 03:52:33 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id b65so29138647wmf.0; Mon, 30 Jan 2017 03:52:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5l6lPYx7EBol5g+pcU4YmvjbEOB9itPz8vi6SCTGX8o=; b=c/rl20bTdlHpwuEmFz9F8p8GK61b2Lj698xbiVBFmrAcJNIvliIusj4NW2m/Nr3LDQ pHYFbsoaDkpwwzrYYbf0VRX2BWZ/IzBHvfI6KY+jaOlMwiYJTqlXELK/FTPvyQoNb//q NU+oUE81vhbqPoCtz87vxeVsXiTV1at1/Ti7Lp6aIniNudgbL8VyfMh5CoMwAxSV5hxb 3k7mYZjl7kmlGmxZmZI+YUgNdKIzjdcAp4Am/Ei31RscYjEyojtg8W4ToEotFUVqoBW1 VPJ9pHACOe28WEiADL3WyQ89x+kgonRV4u5KRO/G10Sv4L5KLSjXz6XEfm+eRdZImUpu /6uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5l6lPYx7EBol5g+pcU4YmvjbEOB9itPz8vi6SCTGX8o=; b=W/wCuvbLZ0T6TgreJvpPHCpeEX57e8w3lYhST6jSBcBT1FedXPEVKBg8Q3LLekiXTJ CQnpyXk/CjYwoVQoOZyY0m7R97s4722oOonzmqdWALNvEC0yhD7tixB1OWN1Xiye5FBC qavO3VmhjkWqXfrUMdZBuLuGDKB/ENJRq0JChGdackowmFxC38GMKWHh+mfGVoozUVtB tGjoVO3z1aSd5fTf1uSafP3QX3jR5giXwxWz5GfCNti4RlylLMpCx8jtIB0O7U9qc21/ 4UzZTC0zjlfDAlKHl7pOCmr4LPItQRlIoQA+Xi7KwAyC/p2x0yVnHehajQLUjnRkDiyU zV2Q==
X-Gm-Message-State: AIkVDXLMs321p/XMsDgxVGXGvY7H67NNSdhstKljCdUjB6YH1s6QxUPmsWgV538D1IXDHQ==
X-Received: by 10.28.206.199 with SMTP id e190mr14179254wmg.98.1485777151797; Mon, 30 Jan 2017 03:52:31 -0800 (PST)
Received: from [10.12.12.35] ([37.205.61.206]) by smtp.gmail.com with ESMTPSA id l9sm18382907wmf.18.2017.01.30.03.52.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 03:52:31 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Dean Bogdanovic <ivandean@gmail.com>
In-Reply-To: <BBA82579FD347748BEADC4C445EA0F21A22A3DAE@NKGEML515-MBX.china.huawei.com>
Date: Mon, 30 Jan 2017 11:52:30 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <BB2EE1A6-CAC0-49F5-9A0B-548B7A8E02DD@gmail.com>
References: <067201d27270$a08cc790$e1a656b0$@olddog.co.uk> <BBA82579FD347748BEADC4C445EA0F21A22A3DAE@NKGEML515-MBX.china.huawei.com>
To: Tianran Zhou <zhoutianran@huawei.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/QCTmAxhACT76elSV3RKZD17Yykg>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, "draft-ietf-netmod-yang-model-classification@ietf.org" <draft-ietf-netmod-yang-model-classification@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] [OPSAWG] Question on draft-ietf-netmod-yang-model-classification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2017 11:52:35 -0000

> On Jan 23, 2017, at 9:32 AM, Tianran Zhou <zhoutianran@huawei.com> wrote:
> 
> To add more comments: 
> 
> On the L2SM meeting, several people (4 or more) believed the 3 service delivery model examples ([I-D.dhjain-bess-bgp-l3vpn-yang], [I-D.ietf-bess-l2vpn-yang] and [I-D.ietf-bess-evpn-yang]) are actually device models.
> 
> I think both of the two I-Ds ([draft-ietf-netmod-yang-model-classification] and [draft-wu-opsawg-service-model-explained]) can check if those YANG models are device models or service models.

The idea is that the classification drafts will provide guidelines for the authors to do their own classification. As mentioned in my previous email, the only people who will be able to do the right classification, are the module authors.

Please see I’m using distinction between module and model. Model can consist of multiple modules and in models you can get classification ambiguity. Modules are much more clear to classify.

Dean

> 
> Regards,
> Tianran
> 
>> -----Original Message-----
>> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Adrian Farrel
>> Sent: Friday, January 20, 2017 12:25 AM
>> To: netmod@ietf.org
>> Cc: opsawg@ietf.org;
>> draft-ietf-netmod-yang-model-classification@ietf.org
>> Subject: [OPSAWG] Question on draft-ietf-netmod-yang-model-classification
>> 
>> Hi,
>> 
>> We've been trying to ensure that draft-wu-opsawg-service-model-explained
>> is consistent with the latest version of
>> draft-ietf-netmod-yang-model-classification. In discussions with Tianran
>> a question has come up.
>> 
>> In section 2 you have a nice definition of Network Service YANG Modules
>> and this definition maps nicely to our definition of "service delivery
>> models".
>> Furthermore, your figure 1 shows Network Service YANG Modules on the
>> interface between OSS/BSS and the various network services.
>> 
>> We have further defined "customer service models" at a higher layer still.
>> That is, on the interface to the customer. This (of course?) assumes that
>> the OSS/BSS is not customer code :-)
>> 
>> However, your discussion of Network Service YANG Modules in section 2.1
>> seems slightly at odds, although this may be just ambiguity.
>> 
>> For example, when you say, "Network Service YANG Modules describe the
>> characteristics of a service, as agreed upon with consumers of that service,"
>> this is not the same as, "This model is used in the discussion between a
>> customer and a service provide to describe the characteristics of a service."
>> That is, the former case could be arrived at after processing based on the
>> latter case - processing that we have called "service orchestration" but
>> might (of course) be what leads to the operator poking the OSS/BSS.
>> 
>> This might all be fine and good, but later in the same section you say "Network
>> Service YANG Modules define service models to be consumed by external
>> systems.
>> These modules are commonly designed, developed and deployed by network
>> infrastructure teams." And there you introduce two terms that are previously
>> undefined and only server to add ambiguity. Specifically "external to what?"
>> I could make and argument that the OSS is developed and deployed by network
>> infrastructure teams, ad also that the OSS is external to the network itself.
>> 
>> And, in between these two quoted pieces of text, you have...
>> 
>>   As an example, the Network Service YANG Module defined in
>>   [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract
>>   model for Layer 3 IP VPN service configuration.
>> 
>> Per my other email, this reference needs to be fixed. But I struggle to
>> see the L3SM module as consistent with your figure. It may or may not be
>> consistent with your text dependent on the interpretation.
>> 
>> In draft-wu-opsawg-service-model-explained Figure 4 we have tried to show
>> how we (the authors) think L3SM fits into your classification. Here we place
>> L3SM further up the layering stack.
>> 
>> [Apologies for not spotting this sooner. The citation
>> "YANG-Data-Model-for-L3VPN-service-delivery" includes the term "service
>> delivery" which I took to imply a different module.]
>> 
>> Thanks,
>> Adrian
>> 
>> _______________________________________________
>> OPSAWG mailing list
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod