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

Dean Bogdanovic <dean@voltanet.io> Mon, 30 January 2017 11:49 UTC

Return-Path: <dean@voltanet.io>
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 A567712945D for <netmod@ietfa.amsl.com>; Mon, 30 Jan 2017 03:49:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=voltanet-io.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 euMrVZ7Lw45k for <netmod@ietfa.amsl.com>; Mon, 30 Jan 2017 03:49:55 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 EEF9212945B for <netmod@ietf.org>; Mon, 30 Jan 2017 03:49:54 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id b65so29039074wmf.0 for <netmod@ietf.org>; Mon, 30 Jan 2017 03:49:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voltanet-io.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tq4TnJPSzvGz9oeQhLHoi+p5ukp2NbfZWOmakWlFbGk=; b=VP4FeKRkFoR0DthpRWQoF8BnOtH7s3Eiuj9BQaM4UEkga/VgNNVz63imWXVeHaDoEL nkqqcOf+sCkFgnIr3giXicYvFeA0XD+HRXZRsFFMPLdm1ZbLhCCTYmtTPYWz1sOxiA6l URdC4HlGc9xML+1yQZZGM9WJFGOg3dDBBNlhtf/7Jxg3/F1g+V0i5pMqbdCnaHjaoGoj LQxr8MgmDDwudZXDFEmwU0PMSuH1peQuc6DtcYzMNU2XDJOae46vhhUI7ufonLcxhlZP DNJz0vuQiuyvtZySEM1B4pVHwJeRkXtvJI14hXYfNScyD1BsR3pyr0mNccMtP07lIux/ UMZA==
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=tq4TnJPSzvGz9oeQhLHoi+p5ukp2NbfZWOmakWlFbGk=; b=JUdYab1YjinJZUDLItsn7L+p1vCe4ixXHVaJPR7SXpE1gW4RoUqoNj3/LSHF2fVf4G nCT1e6Z2OAydajOGbUUHsWAuy40+kmdZ2xCdxLJAAznaC+xaCyDSedxOZgWr6UrXIFs4 L7tN68GMWlYh5NJ+lzvw+ImPRPs6q54FXVnEL3IMX5ySwX93wybA8scsEw7feeWeiR2M 0y/ljwn0i95fabCntNMOD3Ih9xqCyFe0Xrpdwej5IoM8clU8t09qX+7vB9QMwaTSdUWD 0eeD7zR2Ie1IDlxM8FqTusa2HXYJV6TNaNGTCSNwRM2vBjkNOBfDT3USoas02fZuAkHu ccbQ==
X-Gm-Message-State: AIkVDXJQ1lNDzRNjRYvJ1FcEaC8d8QzpKNUceUNLw8b2ih/xE6ynrQKrARnLY2shRqJoGg==
X-Received: by 10.28.131.72 with SMTP id f69mr14912870wmd.140.1485776993176; Mon, 30 Jan 2017 03:49:53 -0800 (PST)
Received: from [10.12.12.35] ([37.205.61.206]) by smtp.gmail.com with ESMTPSA id b8sm22341744wrb.17.2017.01.30.03.49.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 03:49:52 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Dean Bogdanovic <dean@voltanet.io>
In-Reply-To: <067201d27270$a08cc790$e1a656b0$@olddog.co.uk>
Date: Mon, 30 Jan 2017 11:49:50 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <4248688C-E0AC-4302-A281-0622D824FA4D@voltanet.io>
References: <067201d27270$a08cc790$e1a656b0$@olddog.co.uk>
To: adrian@olddog.co.uk
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/fQLHPgTtnHgj97u-ng1bRKo3Itg>
Cc: opsawg@ietf.org, draft-ietf-netmod-yang-model-classification@ietf.org, netmod@ietf.org
Subject: Re: [netmod] 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:49:56 -0000

> On Jan 19, 2017, at 4:25 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> 
> 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.

Adrian, I can see the ambiguity. The point of service module is to be consumed by the customer and there can be some modifications of the service module to adapt to the customer specifics.
> 
> 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.

Agree that external systems are not defined and this text has to be clarified. The external systems can be OSS and BSS.
> 
> 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.

My question is where do you see the L3SM model 

above or below OSS?

Because there are some nuances in the service module, but at the end we decided not to do sub classification

one is the business and one technical service.

When i read the YANG-Data-Model-for-L3VPN-service-delivery, it looked to me much more like a technical model, then the business model, as didn’t see SLA definitions to track the business parameters of the service use.

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

Sure, we can fix that reference, but the authors of L3SM module should do their own module classification, as they are the only ones that know the intent of the module.

> 
> 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.]
> 

No worries and sorry for late reply

Dean

> Thanks,
> Adrian
>