Re: [Teas] I-D Action: draft-wd-teas-ietf-network-slice-nbi-yang-05.txt

Krzysztof Szarkowicz <kszarkowicz@gmail.com> Mon, 27 September 2021 07:44 UTC

Return-Path: <kszarkowicz@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 90F973A0837; Mon, 27 Sep 2021 00:44:13 -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 mE9P6C3QHffz; Mon, 27 Sep 2021 00:44:08 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 6E7B33A0836; Mon, 27 Sep 2021 00:44:08 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id 77-20020a9d0ed3000000b00546e10e6699so23312214otj.2; Mon, 27 Sep 2021 00:44:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MK/IS8nVvRb8UHBRf98KKJzF+GLLIkbJbiNe7qHiaaQ=; b=EDXyj6E8WASbrNaPHpOp9nCH67wQ4t5jXBErr3FbrQScQMet3V0j+JFnWpCfm8Xwj4 IxgmxvxoTJjpr/LoOvJSTZ5H0ObWgn8Em5c7Hg1Uacamo/RslptRXyxZKpNs0FxU1ve6 UuoS2q4mPX6aLNLg7hqPrrJ7z1HOq4im6Ns8282bwY9F6TUroWNChpZ8nGc3kvaATCQg DXocwnzYAS21H76OrNzjBGw1Ng6kwj+Nmt1r2sR3Msi7fBX80Bq2iMUtqPGvcSZS0iNj 2aojDNccnqtbabmheeEW7IvGzSDECHrvMLeqt4utCZrtZay2wK3FcYorPpU7gkjuyBoW 4Byg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MK/IS8nVvRb8UHBRf98KKJzF+GLLIkbJbiNe7qHiaaQ=; b=4eTKIVjMtU4odWRZosT5JzdJ9Y9v+ck9dHvt1sb8zuf/oGOyKsXn3DR76GLzAzTQZi AjghrzkRM0yUoO3zFlmVsIw5viPGID7Dtzd5vZQkRRoaenrv1gkDOIbuQ+VXuqWdYHac JVfzZY3cZ4ywNQK0ZpsE8F9HL5jklMnw9m6xG6/xwjnNNYzOC/bWDV70z47F1v/YOHab ncbPKjo+lfCsZ0HOu4l8Ikkxi3SyFa+AnuOYTmFa74WIIrTmjFaatBYM88xKUgWWImF+ ZKi4Z5evSpN40aKa0xGVqk7Ov3YPzbp2TeZkEOC454uZSfj4znWj3U5BxW27NaCvwSoO l8kQ==
X-Gm-Message-State: AOAM53389frJ4s1u47l/lmn+Xxm9/tXicQOR6gJobKlmn/9WG4I+6JoZ YBWBEzA43LhZHxcGyUUx9UjJiuY4MH8lGMQP
X-Google-Smtp-Source: ABdhPJxHJKurZbAJm3hE23V+Pg/3A4JA15HSyY3daK7u/F0sKLGmzpux5bGn0MsNSMw1Ljx1bnWESg==
X-Received: by 2002:a05:6830:2903:: with SMTP id z3mr15546912otu.132.1632728647370; Mon, 27 Sep 2021 00:44:07 -0700 (PDT)
Received: from smtpclient.apple (jpams-nat14.juniper.net. [193.110.49.14]) by smtp.gmail.com with ESMTPSA id 12sm3640859otg.69.2021.09.27.00.44.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Sep 2021 00:44:07 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Krzysztof Szarkowicz <kszarkowicz@gmail.com>
In-Reply-To: <2e931289ea3c429daac26c54e370c43d@huawei.com>
Date: Mon, 27 Sep 2021 09:44:04 +0200
Cc: "teas@ietf.org" <teas@ietf.org>, "draft-wd-teas-ietf-network-slice-nbi-yang@ietf.org" <draft-wd-teas-ietf-network-slice-nbi-yang@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <403A9878-FDB9-4D8A-83B7-4AB22B9B11B2@gmail.com>
References: <2e931289ea3c429daac26c54e370c43d@huawei.com>
To: "Wubo (lana)" <lana.wubo@huawei.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/eZfPPKZI8zHFLjIN9EhABaYTyU4>
Subject: Re: [Teas] I-D Action: draft-wd-teas-ietf-network-slice-nbi-yang-05.txt
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: Mon, 27 Sep 2021 07:44:14 -0000

Hi,

Let me chime in to provide some feedback on the draft-wd-teas-ietf-network-slice-nbi-yang, from the 5G slicing perspective. There are couple of comments, I would like to provide.


1. Single 5G slice can incorporate multiple traffic classes, denoted by 3GPP as 5QI (5G QoS Identifier), and represented at the transport level with different DSCP values in GTP packets. Obviously, these different traffic classes within single slice have different SLO requirements, and I don't see in the proposed NBI any ways to specify SLO per traffic class (as for example available in L3SM or L2SM models)

2. 5G slice might specify SLO requirements per connections, for example:

    UPF-1 ---> CU-1: guaranteed BW: 1G, maximum BW 2G
    UPF-1 ---> CU-2: guaranteed BW: 1.5G, maximum BW 2G
    UPF-1 ---> CU-3: guaranteed BW: 1.5G, maximum BW 3G

And additionally per groups of connections, i.e.:

   UPF-1 ---> <CU-1, CU-2, CU-3>: guaranteed BW: 4G, maximum BW 4G

I am not sure, how the above construct can be mapped to the proposed NBI (don’t even see the notation of both ‘guaranteed/max’, or CIR/PIR in MEF language, bandwidth).

3. Operators might have different strategies, how to implement traffic separation between the 5G slices at the transport level. As an example, operator A might decide to put N3 interfaces of one 5G slice in one L3VPN, while to put N6 interfaces on the same 5G slice in another L3VPN. On the other hand, operator B might decide to put both N3 and N6 interfaces of some 5G slice in common L3VPN. Each strategy has some disadvantage/advantage, but both strategies are valid. Similar, the control plane (i.e. A1, E2, O1 interfaces ), operators might decide that some 5G slices shares L3VPN for control plane, while some other 5G slices use separate L3VPN for control plane. I don’t see anything in the NBI to address this.

4. NBI attempts to be ‘abstract and technology-agnostic’, while when talking about mapping 5G slices to transport, folks are talking about L3VPNs, DCSP/Exp values, etc., which will require porting of significant part of current L3SM/L2SM models into proposed NBI model in order to make it applicable for 5G slicing.


All if this makes me believe, that augmenting of existing L3SM/L2SM models is better strategy for NBI for 5G slicing.

Best regards,
Krzysztof Szarkowicz

> On 2021 -Sep-26, at 11:13, Wubo (lana) <lana.wubo@huawei.com> wrote:
> 
> Hi all,
> 
> Revision-05 adds a new section, sec 4. Background on IETF Network Slice Service Modeling. We give an analysis on why a new network slice YANG model is needed instead of reusing LxSM or augmenting ACTN VN.
> 
> Thanks,
> Bo
> 
> -----邮件原件-----
> 发件人: Teas [mailto:teas-bounces@ietf.org] 代表 internet-drafts@ietf.org
> 发送时间: 2021年9月26日 16:42
> 收件人: i-d-announce@ietf.org
> 抄送: teas@ietf.org
> 主题: [Teas] I-D Action: draft-wd-teas-ietf-network-slice-nbi-yang-05.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF.
> 
>        Title           : IETF Network Slice Service YANG Model
>        Authors         : Bo Wu
>                          Dhruv Dhody
>                          Reza Rokui
>                          Tarek Saad
>                          Liuyan Han
>                          Luis Miguel Contreras
> 	Filename        : draft-wd-teas-ietf-network-slice-nbi-yang-05.txt
> 	Pages           : 49
> 	Date            : 2021-09-26
> 
> Abstract:
>   This document provides a YANG data model for the IETF Network Slice
>   service.  The model can be used by a IETF Network Slice Customer to
>   manage IETF Network Slice from an IETF Network Slice Controller
>   (NSC).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-wd-teas-ietf-network-slice-nbi-yang/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-wd-teas-ietf-network-slice-nbi-yang-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-wd-teas-ietf-network-slice-nbi-yang-05
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas