Re: [Teas] WG Adoption Poll - draft-king-teas-applicability-actn-slicing-10

Xufeng Liu <xufeng.liu.ietf@gmail.com> Tue, 07 September 2021 01:23 UTC

Return-Path: <xufeng.liu.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 E3C783A07B1 for <teas@ietfa.amsl.com>; Mon, 6 Sep 2021 18:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 5o9Q5RxTCP9s for <teas@ietfa.amsl.com>; Mon, 6 Sep 2021 18:23:20 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 07F1C3A07A9 for <teas@ietf.org>; Mon, 6 Sep 2021 18:23:19 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id u19so11617501edb.3 for <teas@ietf.org>; Mon, 06 Sep 2021 18:23:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5zGPjjn+r5aUoLpMIVtbqDgJVTOiOvAi8BROFPwc840=; b=WAfKSDL9L0g/06TZ+HHoralYzyGIIjmJHD4jF/DpMUpSlEq6TvJ/4wXxDT8lo9BQt+ kHFsRdsqauTrCpkB6lPWW/1nyLhDjkd4eQ22fP9tXMGi+lih8D4eiBzjWYz+Qwlw5tkR /BY7iN1QZEgcu9F9S+0GFE2JV6xNAtyd2Qu3tL4D17D9KamAP/ph4hYdKQirsfY6ja+Z 05LofyfeDjrI2UqXpGDmB3S7Nly+cFhmKmnlW0gWWnubMTBpuAvte191hdS98YhHCBQg djIrsXsK9vO4JTKGFUOSesvWPUQTV3BlnyN1aBsW1q8dtlUigC6msNI4ZcfL81dWQ0sU Zdhw==
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; bh=5zGPjjn+r5aUoLpMIVtbqDgJVTOiOvAi8BROFPwc840=; b=P6lHBahiYcMFc9VzmpSRwl3nm9pR6GHXFwicKjqfb7zHtki7uJ5V7FmQ4URh0EQFvM j608tV3/sze+MwEkak7Oo2RSmoIKeo8ICroDGi/d3OWKgf0oEGy5zSumQ0kt7pMLPvmC 9Y+1Z3U3BuimRkc0GjwPASwwGgGAvdnuSSPkc1a2R7xO4vbru9VgzIU3MqPx9x96ol/s OFtkO2UY5A4L3Z+uutu8K9xnTSvS/VD2jJoWOqVUoANenBsU6gt9Abbt/6BTYEC8zJXr khsDxGDvR034A1nxRnVQrBEDN/aOXR6W92WHJy+biMv7ZI6kfuCNXBorojf1IByk2Kn0 SkXQ==
X-Gm-Message-State: AOAM533n5IwL2H3nPxI9f1DnqWIaQEOKV1nCbf4j1JMOlG6y5hU3sG0S lcy4YWRS5/Jw0UstsOSYrHIkBremDutfleSHULU=
X-Google-Smtp-Source: ABdhPJwM7a4iVj+x+HHNOK7kfQJhfHsuwKl5RGDkqmqcadVNc3QZpIk5NhuNMub22gZ5Zs+fYL3tapsT8usqOUHfgKE=
X-Received: by 2002:aa7:c945:: with SMTP id h5mr16077982edt.350.1630977796568; Mon, 06 Sep 2021 18:23:16 -0700 (PDT)
MIME-Version: 1.0
References: <6f076887-1887-4e41-a48d-6c92b282c29c@AM5EUR02FT020.eop-EUR02.prod.protection.outlook.com> <AM8PR07MB82954D0C1EE5202964645F88F0CB9@AM8PR07MB8295.eurprd07.prod.outlook.com> <0cb401d79f6a$9f8767c0$de963740$@olddog.co.uk> <AM8PR07MB8295CA78F9489190DE3207BBF0CE9@AM8PR07MB8295.eurprd07.prod.outlook.com> <0d5701d79fe0$7e26ed50$7a74c7f0$@olddog.co.uk> <AM8PR07MB82956D54B6F6C9B249D2273EF0CE9@AM8PR07MB8295.eurprd07.prod.outlook.com> <0d9301d79ff7$2825e6b0$7871b410$@olddog.co.uk> <AM8PR07MB8295EC5B81C753EF566F3AFFF0CE9@AM8PR07MB8295.eurprd07.prod.outlook.com> <TY2PR01MB35626EC78D7F7E5BA443F27890CF9@TY2PR01MB3562.jpnprd01.prod.outlook.com>
In-Reply-To: <TY2PR01MB35626EC78D7F7E5BA443F27890CF9@TY2PR01MB3562.jpnprd01.prod.outlook.com>
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Mon, 6 Sep 2021 21:23:05 -0400
Message-ID: <CAEz6PPRwvyuqdKEW=2nVcE5oygdAb=gsO0AzFBSg+H1g3FpiMQ@mail.gmail.com>
To: "Ogaki, Kenichi" <ke-oogaki@kddi.com>
Cc: Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000337bab05cb5d9c31"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/blHJdWO73i6SwAP0Fa03yOV3-xo>
Subject: Re: [Teas] WG Adoption Poll - draft-king-teas-applicability-actn-slicing-10
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: Tue, 07 Sep 2021 01:23:27 -0000

Inclined to agree with Kenichi. To the list of existing models that Daniele
listed, the draft
https://datatracker.ietf.org/doc/html/draft-liu-teas-transport-network-slice-yang-04
augments the topology model, keeping all existing ACTN related capabilities.

Thanks,
- Xufeng

On Thu, Sep 2, 2021 at 9:52 PM Ogaki, Kenichi <ke-oogaki@kddi.com> wrote:

> Hi Adrian, Daniele,
>
>
>
> Thanks for discussion to my comment.
>
>
>
> See comment [KO] inline, please.
>
>
>
> Thanks,
>
> Kenichi
>
>
>
>
>
> *From:* Teas <teas-bounces@ietf.org> *On Behalf Of *Daniele Ceccarelli
> *Sent:* Friday, September 3, 2021 1:17 AM
> *To:* adrian@olddog.co.uk
> *Cc:* 'TEAS WG' <teas@ietf.org>
> *Subject:* Re: [Teas] WG Adoption Poll -
> draft-king-teas-applicability-actn-slicing-10
>
>
>
> Hi Adrian,
>
>
>
> We’re getting there.
>
> Let’s try in line this time.
>
> Cheers,
>
> Daniele
>
>
>
>
>
> *From:* Adrian Farrel <adrian@olddog.co.uk>
> *Sent:* den 2 september 2021 14:37
> *To:* Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
> *Cc:* 'TEAS WG' <teas@ietf.org>
> *Subject:* RE: [Teas] WG Adoption Poll -
> draft-king-teas-applicability-actn-slicing-10
>
>
>
> Hi, yet again,
>
>
>
> I’d be surprised if draft-ietf-teas-actn-yang suggested the use of the NBI
> at the moment because the NBI is still an individual draft – we don’t even
> know whether the working group wants to adopt it yet.
> draft-ietf-teas-actn-yang  cannot hope to list all possible future customer
> service models. But maybe a future version will include the NBI in the list
> in Section 4.1 when the NBI is stable.
>
> *[DC] I said it is suggesting to use the existing models like service
> network models (LxNM), TE models (TE topo, TE tunnel, VN) and the TE
> service mapping etc, not the network slicing one.*
>
>
>
> [KO] We don't mind the NBI will be included in the list in Section 4.1,
> but our intention is that it should be an enhanced/augmented actn-vn-yang.
> Same for your comments below.
>
>
>
>
>
> I don’t think that Figure 1 of
> draft-king-teas-applicability-actn-slicing-10 says that the NSC NBI can be
> replaced with the CMI. Rather, it says that the NSC NBI can be used to
> instantiate the CMI. That is, the CMI is an abstract interface in the
> architectural model, and a number of YANG models can be used to instantiate
> the CMI depending on the function being offered. That is, I think, exactly
> what Section 4.1 of draft-ietf-teas-actn-yang says.
>
> *[DC] I don’t disagree with you here. In the context of ACNT the term CMI
> means a set of models, in the context of network slicing another (the NS
> NBI), in none of them it could just be a subset (e.g. L3NM). I would have
> preferred that the NS NBI would have augmented them instead of defining
> something orthogonal. *
>
>
>
> Which model(s) an operator chooses to use at the CMI depends does not
> depend on whether they support ACTN or not. If they don’t support ACTN,
> they don’t have a CMI, end of story. But if they **do** use the ACTN
> architecture, they may offer one or more services to their customer. For
> each service they offer, they (may) use a different customer service model.
>
>
>
> If the provider wants to use slicing based on the VN model or the L3SM
> then that’s OK, and they don’t need to use the NSC NBI. On the other hand,
> they can offer ”slicing as a service” and may choose to use the NSC NBI for
> this.
>
> *[DC] Agree. Can we call the draft: “A service model for IETF network
> slice NBI” ? And in the text say that the model is one of the options that
> can be used as a “network model” ? *
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
> *Sent:* 02 September 2021 12:54
> *To:* adrian@olddog.co.uk; 'Vishnu Pavan Beeram' <vishnupavan@gmail.com>om>;
> 'TEAS WG' <teas@ietf.org>
> *Cc:* 'TEAS WG Chairs' <teas-chairs@ietf.org>
> *Subject:* RE: [Teas] WG Adoption Poll -
> draft-king-teas-applicability-actn-slicing-10
>
>
>
> Hi Adrian,
>
>
>
> Good point, you’re right...not accurate from my side.
>
>
>
> Since ACTN, in addition to being a framework, is also suggesting which
> models to use, when I speak about ACTN I’m implying also the usage of those
> models: i.e. service network models (LxNM), TE models (TE topo, TE tunnel,
> VN) and the TE service mapping etc.
>
> I’m referring to draft-ietf-teas-actn-yang-07 <https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-yang-07> section 4.1 for the CMI and 4.2 for the MPI.
>
>
>
> I don’t have anything against the usage of this model as service model, but I see competition with the existing ones as a network model.
>
> I think Kenichi explained it extremely well in his mail:
>
>
>
> “1) According to Figure 1 of
> draft-king-teas-applicability-actn-slicing-10, NSC NBI can be replaced with
> CMI. If the new nbi is created, we have to parallelly implement two nbis or
> just wrap CMI with NSC NBI. From one of mobile operators' capex
> perspective, we don't want to do such effort, since we believe major ietf
> network slice requirements can be covered by ACTN.”
>
>
>
> BR
> Daniele
>
>
>
>
>
>
>
>
>
> *From:* Adrian Farrel <adrian@olddog.co.uk>
> *Sent:* den 2 september 2021 11:54
> *To:* Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>om>; 'Vishnu Pavan
> Beeram' <vishnupavan@gmail.com>om>; 'TEAS WG' <teas@ietf.org>
> *Cc:* 'TEAS WG Chairs' <teas-chairs@ietf.org>
> *Subject:* RE: [Teas] WG Adoption Poll -
> draft-king-teas-applicability-actn-slicing-10
>
>
>
> Hi again Daniele,
>
>
>
> > That’s a quibble that only solves the issue partially.
>
> > Should we use ACTN to do network slicing in networks that support
>
> > ACTN and the Network Slicing NBI model in networks that’s don’t
>
> > support it?
>
>
>
> You are comparing two things that are not the same.
>
> The Network Slicing NBI is a YANG model for use on the customer service
> interface. That is, it allows the customer and provider to communicate
> about the network slice that is to be provided.
>
> ACTN is an architecture. That is, it describes how the management
> components may be arranged/structured to deliver function in a network.
>
>
>
> You can use the Network Slicing NBI at an interface in the ACTN
> architecture.
>
> It could be used at the CMI (in the same way that the L3SM and L2SM can
> be): see Section 4.1.
>
> Or it could be used above the CNC: see Section 4.2
>
>
>
> Best,
>
> Adrian
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>