Re: [Teas] New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt

"Wubo (lana)" <lana.wubo@huawei.com> Thu, 15 July 2021 11:15 UTC

Return-Path: <lana.wubo@huawei.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 712A23A2775 for <teas@ietfa.amsl.com>; Thu, 15 Jul 2021 04:15:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 PMRsPACAl26x for <teas@ietfa.amsl.com>; Thu, 15 Jul 2021 04:15:00 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65B03A2745 for <teas@ietf.org>; Thu, 15 Jul 2021 04:14:58 -0700 (PDT)
Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GQWhJ23WMz6L7t4 for <teas@ietf.org>; Thu, 15 Jul 2021 19:03:44 +0800 (CST)
Received: from dggeme701-chm.china.huawei.com (10.1.199.97) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Thu, 15 Jul 2021 13:14:55 +0200
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme701-chm.china.huawei.com (10.1.199.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Thu, 15 Jul 2021 19:14:53 +0800
Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.2176.012; Thu, 15 Jul 2021 19:14:53 +0800
From: "Wubo (lana)" <lana.wubo@huawei.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt
Thread-Index: Add5If0XplKlj4TdRY62B0FVVedSbw==
Date: Thu, 15 Jul 2021 11:14:53 +0000
Message-ID: <ecbb6d688dad459890beeeb180c36dc0@huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.123.156]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/wKkQsb5Um1gy7aTyUOpKvmQTrN4>
Subject: Re: [Teas] New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.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: Thu, 15 Jul 2021 11:15:05 -0000

Hi Med,

Thanks for the reply. Please see inline.

Regards,
Bo

-----邮件原件-----
发件人: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] 
发送时间: 2021年7月13日 15:08
收件人: Wubo (lana) <lana.wubo@huawei.com>om>; teas@ietf.org
主题: RE: New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt

Hi Bo, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Teas [mailto:teas-bounces@ietf.org] De la part de Wubo (lana) 
> Envoyé : lundi 12 juillet 2021 12:05 À : BOUCADAIR Mohamed INNOV/NET 
> <mohamed.boucadair@orange.com>om>; teas@ietf.org Objet : Re: [Teas] New 
> Version Notification for draft-wd-teas-ietf- 
> network-slice-nbi-yang-03.txt
> 
> Hi Med,
> 
> Many thanks for your valuable review and comments. It is not the 
> intention to ignore your suggestion. We will address the comments in 
> the next revision.
> Please see inline for the detailed answer with [Bo].
> 
> Best regards,
> Bo
> 
> 
> -----邮件原件-----
> 发件人: mohamed.boucadair@orange.com
> [mailto:mohamed.boucadair@orange.com]
> 发送时间: 2021年7月9日 20:06
> 收件人: Wubo (lana) <lana.wubo@huawei.com>om>; teas@ietf.org
> 抄送: teas-chairs@ietf.org
> 主题: RE: New Version Notification for draft-wd-teas-ietf-network- 
> slice-nbi-yang-03.txt
> 
> Hi Bo, all,
> 
> Thank you for sharing this updated version.
> 
> I'm supportive of this work, but I think we have a fundamental point 
> to clarify: the document is currently missing data nodes that makes a 
> slice, a slice!
> 
> If we don't have such data nodes, the current module can be used to 
> provision any form of connectivity. If we omit the "ns-" prefix, the 
> module can be used for provisioning the connectivity of VoIP, 
> multicast, etc. services. That’s actually good (as the applicability 
> scope is wider) but we need also to think about network slice 
> specifics.
> 
> I have touched on some of these points in a review I shared with you 
> back in 02/21, but unless I'm mistaken I don't think it was
> addressed:
> https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-
> wd-teas-ietf-network-slice-nbi-yang-02-rev%20Med.doc
> 
> Below an extract of my main comments:
> 
> (1) A proposal to rationalize the discussion and ease progressing the 
> spec is to clearly call that a network slice can be defined as a 
> collection of at least three components: (1) connectivity component,
> (2) storage component, and (3) compute component. Having a provision 
> for this since early stages of the model will ease grafting other 
> components of an IETF slice easily, but also allows to avoid having a 
> linear model.
> [Bo]: I think this comment relates with the thread discussion of SFC

[Med] Not only. This is important as we are modelling a slice not any connectivity service. We need to make sure slice specifics are covered and that the structure can evolve to cover all future slice components.  

If there are no slice specifics, we just need to cast the module as a general connectivity service module. Slicing will be one use case. 
[Bo] Thanks. I see your point. The current model does covers only slice connectivity services. How about the following changes:
OLD definition of an IETF network slice in section 4: 
An IETF network slice is a logical network connecting a number of endpoints with specified SLOs.
The connectivity type can be Hub-and-Spoke, any-to-any, or custom connectivity type. A minimum set of SLOs is defined, including but not limited to bandwidth, latency, and etc.

New: 
   An IETF Network Slice is a logical network topology connecting a number of endpoints using a set of shared or dedicated network
   resources that are used to satisfy specific service requirements. The logical topology types are: point-to-point, point-to-multipoint,
   multipoint-to-point, or multipoint-to-multipoint. The endpoints are conceptual points that could map to a device, application or a network
   function. And the specific service requirements, typically expressed as bandwidth, latency, latency variation, and other desired or required 
   characteristics, such as security, MTU, traffic-type (e.g., IPv4, IPv6, Ethernet or unstructured) or a higher-level behavior to process traffic according to user-application (which may be realized using network function).

> and slicing. If my understanding is correct, we will add this when WG 
> decides the SF aware network slice is within the scope of draft- 
> ietf-teas-ietf-network-slices. But based on the discussion, I am 
> afraid that someone would suggest a separate YANG model for this.
> 
> (2) For the connectivity part, the following items are important to 
> cover as well:
> * Traffic steering and advanced services: a slice may require the 
> invocation of service functions (firewall, for example) in a given 
> order. These policies have to be captured in the slice request. This 
> is also useful when the customer request that its slice should not 
> cross some networks or not span some regions.
> [Bo] Thanks. If I understand correctly, we will add SLE(Service Level 
> Expectation)-specific steering policies applied per slice or per slice 
> connection. Are there any other modelling suggestion?

[Med] That would be a first approach, but what is important is have a provision for this in the module. A kind if information model can be seen at rfc7297.html#section-4.

One aside note: I don't think we need to overload our design with SLO/SLEs subtleties. We just need to call these service requirements or something similar. I'm still waiting for a follow-up from Adrian on this as this point is related to the framework draft. 

[Bo] How about modelling like this:
OLD:
+--rw slo-policy
|  +--rw policy-description?   string
|  +--rw ns-metric-bounds
|     +--rw ns-metric-bound* [metric-type]
|        +--rw metric-type          identityref
|        +--rw metric-unit          string
|        +--rw value-description?   string
|        +--rw bound?               uint64
+--rw sle-policies
   +--rw security-sle*          identityref
   +--rw isolation?             identityref
   +--rw max-occupancy-level?   uint8
NEW:
+--rw slo-sle-policy
   +--rw policy-description?     string
   +--rw ns-metric-bounds
   |  +--rw ns-metric-bound* [metric-type]
   |     +--rw metric-type          identityref
   |     +--rw metric-unit          string
   |     +--rw value-description?   string
   |     +--rw bound?               uint64
   +--rw security-sle*           identityref
   +--rw isolation?              identityref
   +--rw max-occupancy-level?    uint8
   +--rw mtu      uint16     ------------new leaf
   +--rw steering-constraints  ------------new container
      +--rw path-constraints
      +--rw service-function
Note: The definition of "slo-sle-policy" and "steering-constraints" will be updated when WG converge on the terms. 
> 
> * What to do for out of profile traffic: See the traffic conformance 
> discussion in RFC7297.
> [Bo] I'm not sure I understand this. Do you mean that MTU attributes 
> should be included?

[Med] MTU is related to the conformance traffic. It should be included because a slice may be tweak for specific data lengths.

Some shaping/policing may be agreed for the conforming traffic, however the slice request can include the agreed behavior for out-of-profile. Such traffic can be redirected to another slice, discarded, etc. 
[Bo] Please see YANG tree of the previous reply for the MTU. About shaping/policing for the conforming traffic, could you elaborate or suggest how to model this?

> 
> * Activation means: may need to be included in a slice definition.
> Think about a slice that can be implemented as a VPN service. Such 
> service may require the activation of a given routing protocol between 
> a CE and a PE, otherwise the service won’t be offered.
> [Bo] I do agree. Current YANG model has a container of "ep-protocol"
> under "ns-endpoint", and also previous revision of the model had nodes 
> of "BGP" and "static routing". But there is some arguments that some 
> scenarios, for example, optical networks don't need these nodes.

[Med] BGP or static routing are good example of activation means. Other attachment circuit specific technologies can be included.  
[Bo] How about the updates like this:
+--rw ep-protocol
	+--rw bgp
	|  +--rw bgp-peer-ipv4*   inet:ipv4-prefix
	|  +--rw bgp-peer-ipv6*   inet:ipv6-prefix
	+--rw static
	|   +--rw static-route-ipv4*   inet:ipv4-prefix
	|   +--rw static-route-ipv6*   inet:ipv6-prefix  
	+--rw multicast
Note: The model needs to be optimized for better extension of other protocols or AC technologies. 
> 
> * Invocation means: Think about a multicast service that requires 
> IGMP/MLD and so on.
> [Bo] Is this similar with the previous one that you suggest to add 
> IGMP/MLD nodes under "ns-endpoint"?

[Med] Invocation means are distinct from the activation: You may have a multicast slice that is in place, but in order to access some specific channels or (S,G), the CE will need to send specific queries within the slice itself (MLD, for example). 
[Bo] Understood. I add a place holder for multicast and a note for further improvement.
> 
> * Notification means: these are important for service assurance and 
> fulfillment purposes.
> [Bo] Yes. The current model includes network slice, endpoint, and 
> connection status. Do you think there are other nodes that are 
> necessary?
> 

[Med] What I had in mind is more notifications to the slice customer. 
[Bo] We will add a note "More critical events affecting service delivery need to be added.".
> 
> (3) The model seems to be inspired from the opsawg vpn I-Ds 
> (network-access structure, for example). That's great and appreciated, 
> but I would formalize that by using I-D.ietf-opsawg- vpn-common for 
> data nodes such as connectivity-type, endpoint-role, status-params, 
> etc.
> Bo: Yes. VPN is one of important technologies of realizing network 
> slice. But there are some discussions that VPN is not mandatory to 
> realize network slice, e.g. optical mechanism could be used.
> Therefore we don't reuse the YANG nodes defined in I-D.ietf-opsawg- 
> vpn-common.

[Med] The types in the common I-D are more generic than the te-types as they can be applied for service requests :-) You may at least cite it in the text and explain that you prefer to copy some data nodes rather than importing them. That would be fair.  
[Bo] Agree. Will update to add reference to common I-D and a note of "Reuse the common I-D type definition".
> 
> (4) One last comment, I still don't get what is an "underlay IETF 
> network".
> Bo: Thanks for pointing this out. Will remove 'underlay'.
> 

[Med] I actually have an issue with "IETF network" :-)
[Bo] Understood. We can change to "provider network" if there are no objections.

> Thank you.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Teas [mailto:teas-bounces@ietf.org] De la part de Wubo (lana) 
> > Envoyé : vendredi 9 juillet 2021 12:18 À : teas@ietf.org Cc :
> > teas-chairs@ietf.org Objet : Re: [Teas] New Version Notification
> for
> > draft-wd-teas-ietf- network-slice-nbi-yang-03.txt
> >
> > Dear WG and chairs,
> >
> > The draft has been aligned with changes in the IETF Network Slice 
> > framework WG I-D.
> >
> > The Authors believe that it has been maturing with the inputs from
> the
> > WG, and can be evaluated as a candidate for WG adoption.
> > Diff: https://www.ietf.org/rfcdiff?url2=draft-wd-teas-ietf-
> network-
> > slice-nbi-yang-03
> >
> > Best regards,
> > Bo (on behalf of the co-authors)
> >
> >
> > -----邮件原件-----
> > 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > 发送时间: 2021年7月9日 17:32
> > 收件人: Wubo (lana) <lana.wubo@huawei.com>om>; Dhruv Dhody 
> > <dhruv.ietf@gmail.com>om>; Liuyan Han <hanliuyan@chinamobile.com>om>;
> Reza
> > Rokui <reza.rokui@nokia.com>om>; Tarek Saad <tsaad@juniper.net>
> > 主题: New Version Notification for draft-wd-teas-ietf-network-
> slice-
> > nbi-yang-03.txt
> >
> >
> > A new version of I-D, draft-wd-teas-ietf-network-slice-nbi-yang-
> > 03.txt
> > has been successfully submitted by Bo Wu and posted to the IETF 
> > repository.
> >
> > Name:		draft-wd-teas-ietf-network-slice-nbi-yang
> > Revision:	03
> > Title:		A Yang Data Model for IETF Network Slice NBI
> > Document date:	2021-07-09
> > Group:		Individual Submission
> > Pages:		45
> > URL:            https://www.ietf.org/archive/id/draft-wd-teas-
> ietf-
> > network-slice-nbi-yang-03.txt
> > Status:         https://datatracker.ietf.org/doc/draft-wd-teas-
> ietf-
> > network-slice-nbi-yang/
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-wd-
> teas-
> > ietf-network-slice-nbi-yang
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-wd-teas-
> > ietf-network-slice-nbi-yang-03
> >
> > Abstract:
> >    This document provides a YANG data model for the IETF Network
> Slice
> >    Controller (NSC) Northbound Interface (NBI).  The model can be
> used
> >    by a IETF Network Slice customer to request configuration, and
> >    management IETF Network Slice services from the IETF NSC.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org
> > https://www.ietf.org/mailman/listinfo/teas
> 
> ____________________________________________________________________
> _____________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, Orange decline toute responsabilite si ce message a ete 
> altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.