Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Dhruv Dhody <dhruv.ietf@gmail.com> Thu, 23 April 2020 16:23 UTC

Return-Path: <dhruv.ietf@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1569C3A0C02 for <teas@ietfa.amsl.com>; Thu, 23 Apr 2020 09:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 wSfSt5vocKss for <teas@ietfa.amsl.com>; Thu, 23 Apr 2020 09:23:16 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 6897F3A0BF8 for <teas@ietf.org>; Thu, 23 Apr 2020 09:23:16 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id i19so6965067ioh.12 for <teas@ietf.org>; Thu, 23 Apr 2020 09:23:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7ODY6e1jmiAKjmfnUCc1/XiVpgMr98fHZ1A/Hx0TIIw=; b=erCGDg+kZwUo4JA1plwrz2eL2nyNbOVTURWs/uSU9R4U054P0PdqmNnAx5pkBY2bAm sAtQ+y9glyGCganUfBW0+KlEF3h+HwIn9um0PgwdV3UecqHZ9jmHYvb7g/jQW0VItSHA czb8IBwQbpA2d4uFdS+dEF2iEG94ehKza4RbMjpL5FZelqU09JgYkAa+NFX1y67zgJP5 5bBW2mFISlCToS2mjByGvC9/sr3nYhg8Zh3zNnr20I9b4nLZmtXs1p6sXJXTbHpQPlJ4 U3hQjG5Isi/68wm9BaGHVNNYkppAk5Ctppoo+PYS4RSY4vYDbGhONQOIFbmGZc9m/SSA Y+sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7ODY6e1jmiAKjmfnUCc1/XiVpgMr98fHZ1A/Hx0TIIw=; b=fNLqFx4eDxDCm3OI/Vx4Z02qKF+R4Sqf+KaX8gZM2/fYuBrhF0HUsFp/o9qgpsJSWN FDupyQnJcL23Uwr+3xYI4BFl0p55pBXrE8wKy2KwhsItUtXmpJq7vdOs8zQhoTiKZYZS 0T67o0IFB4Bq7QZ16y8inf4/2q6SMMRu91nVlcw2lzvtB6odIquRIbzanDcH0g3Rz0YI 6YdLS4FtnUTWx3gEtJipwLUyZ+Yk88dwcDjnvAg/wHM59m0VOk5E++B4ggvmvkS/ae/V dJO+OhQjClIRTedvMsOBkJjerWcxjg+vq2LrA6k64Id17FoNUZ+Lo8aUSo7Or8ui3ZQT KxEg==
X-Gm-Message-State: AGi0PubjjXKhuvVDtco7DHJ1exp1ukDjxVhnHURIQXJ/R2+ZzMQXzg+S 2PmRIV718TUjRVT0CBF+PtQODBuofVvm95tmJF6qCbVF
X-Google-Smtp-Source: APiQypLBfOGQnBPaL0DiOlTcuVb5RMglO0Apvf3j36ZxAaqcoSO9KhmZ/vlFldE3HX6b1NHVyPeM+qwg4gO0kD4ATNM=
X-Received: by 2002:a5d:8d0e:: with SMTP id p14mr4501117ioj.0.1587658995232; Thu, 23 Apr 2020 09:23:15 -0700 (PDT)
MIME-Version: 1.0
References: <016d01d61986$4cf2a210$e6d7e630$@ndzh.com>
In-Reply-To: <016d01d61986$4cf2a210$e6d7e630$@ndzh.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Thu, 23 Apr 2020 21:52:39 +0530
Message-ID: <CAB75xn6hRMDoNCy7GX=f=XKb_rSfTb2y7X-=5CWa=1Oda33saw@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Cc: "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/auLapPTpibkt-XfktUlOzSN5cIw>
Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2020 16:23:18 -0000

Hi Sue,

Thanks for your email. Yes, our work for TS-NBI is closer to the
customer service models and in fact uses the same design philosophy by
creating an independent model with a customer view (of the slice)
rather than the network view. The network view would be useful for the
slice realization by the TS-controller as described in the framework
draft.

It would be good idea to capture this discussion in the Appendix of
our I-D. Further, there are some technical challenges such as modeling
TS-endoint as an augmentation of a termination point in RFC8345; our
preference is to maintain TS-endpoint to be a logical identifier with
either CE-side details or PE-side details or both.

Thanks!
Dhruv

On Thu, Apr 23, 2020 at 9:16 PM Susan Hares <shares@ndzh.com> wrote:
>
> Bo Wu, Dhruv, Reza, and Liuyan:
>
>
>
> Thank you for your presentation in TEAS on the draft-wd-teas-transport-slice-yang-01.    I had hoped to ask this question on the mike:
>
>
>
> “Would you provide more details on why you felt the base model (RFC8345) was not appropriate to utilize? “
>
>
>
> It seems to me that you are proposing a customer level model  to monitor and set-up the traffic slicing?    RFC8345 provides a base model with a customer level.   The models L2SM and L3SM provided a customer level for general VPNs.   You seem to be providing the equivalent for a traffic slicing.
>
>
>
> If you are looking to utilize the base model then providing a customer level model is a good idea.  It is much cleaner than mixing it with the network layer.  When network slicing was starting its work, I prepared this suggestion as part of the first BOF.
>
>
>
> Would you do me a favor in your presentation of “customer level”,  would you careful distinguish between the following customer levels?
>
>
>
> End –customer ---
>
>         |
>
> VPN customer (person/tools configuring)
>
> Service
>
>     |
>
> VPN of network
>
>     |
>
> Base network
>
>
>
> Thank you!
>
>
>
> The I2RS WG (which chair) standardized RFC8345.   Your application was one of the ones that caused us to work through the model and the issues with yang.
>
>
>
> I’m excited to see your work in TEAS.
>
>
>
> Sue
>
>
>
>
>
>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas