[Teas] New Liaison Statement, "Further Information About IETF Work Relevant to Network Slicing"

Liaison Statement Management Tool <lsmt@ietf.org> Tue, 14 August 2018 19:16 UTC

Return-Path: <lsmt@ietf.org>
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 409BA124BE5; Tue, 14 Aug 2018 12:16:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Liaison Statement Management Tool <lsmt@ietf.org>
To: <3GPPLiaison@etsi.org>
Cc: TEAS Discussion List <teas@ietf.org>, l2sm-chairs@ietf.org, rtg-ads@ietf.org, teas-chairs@ietf.org, Adrian Farrel <adrian@olddog.co.uk>, DetNet Discussion List <detnet@ietf.org>, detnet-chairs@ietf.org, ops-ads@ietf.org, Qin Wu <bill.wu@huawei.com>, zoulan@huawei.com, L2VPN Service Model Discussion List <l2sm@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153427420818.27176.13203359648572620433.idtracker@ietfa.amsl.com>
Date: Tue, 14 Aug 2018 12:16:48 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/lloReykaui7P68Ap_jOYNl4hrgw>
Subject: [Teas] New Liaison Statement, "Further Information About IETF Work Relevant to Network Slicing"
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.27
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, 14 Aug 2018 19:16:48 -0000

Title: Further Information About IETF Work Relevant to Network Slicing
Submission Date: 2018-08-14
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1595/

From: Adrian Farrel <adrian@olddog.co.uk>
To: 3GPPLiaison@etsi.org
Cc: zoulan@huawei.com,Adrian Farrel <adrian@olddog.co.uk>,Qin Wu <bill.wu@huawei.com>,l2sm-chairs@ietf.org ,teas-chairs@ietf.org ,detnet-chairs@ietf.org ,ops-ads@ietf.org ,rtg-ads@ietf.org ,DetNet Discussion List <detnet@ietf.org>,L2VPN Service Model Discussion List <l2sm@ietf.org>,TEAS Discussion List <teas@ietf.org>
Response Contacts: Adrian Farrel <adrian@olddog.co.uk>,Qin Wu <bill.wu@huawei.com>
Technical Contacts: Adrian Farrel <adrian@olddog.co.uk>,Qin Wu <bill.wu@huawei.com>
Purpose: In response

Referenced liaison: Reply LS on IETF work related to the management and orchestration of network slicing (https://datatracker.ietf.org/liaison/1588/)

Body: Thank you for your liaison statement "Reply LS on IETF work related to the 
management and orchestration of network slicing" from 3GPP-TSG-SA-WG5 dated
7/23/18. This has been passed to the chairs of the IETF's L2SM working group to
coordinate a response. 

Our understanding of the 3GPP's definition of a "Transport Network" is that it 
covers any network that underlies and provides connectivity for 3GPP networks or 
services. There are, of course, many other definitions of "Transport Network" so 
it is important that we are clear on this. 

The IETF works on IP and MPLS dataplane technologies as well as higher layer 
encapsulations such as UDP, TCP, and HTTP all of which may be applicable to your 
requirements. Additionally, the IETF works on control and management plane 
specifications applicable to all technology layers including IP and sub-IP 
transport networks. 

You may be interested in the work of the DetNet working group [1] which is 
collaborating with the IEEE802.1 TSN task group to develop mechanisms to provide 
deterministic data paths that operate over Layer 2 bridged and Layer 3 routed 
segments, where such paths can provide bounds on latency, loss, and packet delay 
variation (jitter), and high reliability. These features may prove to be 
particularly useful in supporting connectivity (or slices) for 5G services. The
DetNet Architecture is largely complete and is described in [2].  DetNet's use
of the IP [3] and MPLS [4] date planes is still being defined in the working
group.  You may also be interested in early work on configuration control in 

With regard to your specific enquiry about management interfaces there are 
several layers of interaction that you should consider: 

- The L2VPN and L3VPN service models ([6] and [7]) are intended to allow a 
  customer to request a VPN connectivity service from an operator. These
  models may be used as a 'paper procedure' allowing a common format for
  service requests, or may facilitate automation so that one software
  component may make requests to another component responsible for 
  orchestrating the underlying network. The services described by these
  two models would normally be provided by IP or MPLS networks, but the
  details of how the service is provided are deliberately out of scope. 
  Thus, direct control of transport resources do not fall within the 
  scope of these service models. What is in scope are the points of 
  attachment (connection end points), the type of attachment circuit, and
  the quality of connectivity that is required (such as bandwidth and 
  quality of service). The way that service models fit into the management
  of networks is described in RFC 8309 [8]. 

- VPN delivery models are being specified in the BESS working group [9]. 
  These models allow an operator to manage a network for the delivery of a
  VPN connectivity service, and would normally be provided by IP or MPLS
  networks. These models describe the details of how the service is 
  implemented within the network. Examples include the YANG Data Model for
  MPLS-based L2VPN [10], the YANG Data Model for BGP/MPLS L3 VPNs [11], and
  the YANG Data Model for EVPN [12]. 

- The TEAS working group [13] is developing a YANG model for the 
  configuration and management of Traffic Engineering (TE) interfaces,
  tunnels and Label Switched Paths (LSPs) [14]. While this is a service
  delivery model, it closely matches the corresponding service model for
  'connectivity as a service'. 

- The TEAS working group is also working on the Abstraction and Control of 
  Traffic Engineered Networks (ACTN) [15]. This approach allows a network 
  user to request and manipulate 'topology' in the form of a virtual 
  network and is accessed through YANG models such as [16] and [17]. This
  is applicable to all forms of traffic engineered network from MPLS
  through Ethernet, TDM, and OTN, to WDM. Virtual network creation and 
  operation may be similar to 'network slicing' that you describe: this is
  discussed in an individual contribution Internet-Draft [18], while a
  further individual document [19] describes an architecture for data
  model driven network management of virtual networks. 
Further dialogue is needed around the topic of traffic isolation in network 
slicing in particular with respect to its application to shared packet or frame 
networks. The IETF has developed techniques to protect against misdelivery of 
traffic and to secure customer traffic as it is transmitted over the network. 
Similarly, there are protocol mechanisms to reserve and dedicate network 
resources to specific traffic flows or to provide statistical accounting that, 
combined with traffic policing, ensure that network resources are not 
over-committed. Nevertheless, it has to be understood that packet and frame 
networks are essentially shared-media networks where separation or isolation of 
traffic is logical not physical. 

It is often hard to provide a firm roadmap for delivery of IETF specifications 
as the work only completes when it is technically sound and has sufficient 
consensus for publication: it is not tied to any formal schedule. However, we 
can suggest the following information: 

- [2] Still needs work: may be an RFC within 12 months 
- [3] Unknown timing 
- [4] Unknown timing 
- [5] Unknown timing 
- [6] Complete and in RFC Editor processing: likely to be an RFC within two 
- [7] Already an RFC 
- [8] Already an RFC 
- [10] Still needs work: may be an RFC within 12 months 
- [11] Still needs work: may be an RFC within 12 months 
- [12] Still needs work: may be an RFC within 12 months 
- [14] Still needs work: may be an RFC within 6 months 
- [15] Complete and in RFC Editor processing: likely to be an RFC within two 
- [16] Still needs work: may be an RFC within 6 months 
- [17] Still needs work: may be an RFC within 6 months 
- [18] Unknown timing 
- [19] Unknown timing 

Best regards, 
Adrian Farrel and Qin Wu (IETF L2SM Working Group chairs) 

[1] https://datatracker.ietf.org/wg/detnet/about/ 
[2] https://tools.ietf.org/html/draft-ietf-detnet-architecture
[3] https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-ip
[4] https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-mpls
[5] https://tools.ietf.org/html/draft-geng-detnet-conf-yang
[6] https://www.ietf.org/id/draft-ietf-l2sm-l2vpn-service-model-10.txt 
[7] https://www.rfc-editor.org/rfc/rfc8299.txt 
[8] https://www.rfc-editor.org/rfc/rfc8309.txt 
[9] https://datatracker.ietf.org/wg/bess/about/ 
[10] https://www.ietf.org/id/draft-ietf-bess-l2vpn-yang-08.txt 
[11] https://www.ietf.org/id/draft-ietf-bess-l3vpn-yang-03.txt 
[12] https://www.ietf.org/id/draft-ietf-bess-evpn-yang-05.txt 
[13] https://datatracker.ietf.org/wg/teas/about/ 
[14] https://www.ietf.org/id/draft-ietf-teas-yang-te-16.txt 
[15] https://www.ietf.org/id/draft-ietf-teas-actn-framework-15.txt 
[16] https://www.ietf.org/id/draft-ietf-teas-actn-yang-01.txt 
[17] https://www.ietf.org/id/draft-ietf-teas-actn-vn-yang-01.txt 
[18] https://www.ietf.org/id/draft-king-teas-applicability-actn-slicing-03.txt 
[19] https://www.ietf.org/id/draft-wu-model-driven-management-virtualization-01.txt

    Microsoft Word version of this LS