[L2sm] New Liaison Statement, "Further Information About IETF Work Relevant to Network Slicing"
Liaison Statement Management Tool <email@example.com> Tue, 14 August 2018 20:52 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 306A8126CC7; Tue, 14 Aug 2018 13:52:19 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Liaison Statement Management Tool <firstname.lastname@example.org>
To: <email@example.com>, <3GPPLiaison@etsi.org>
Cc: Ignas Bagdonas <firstname.lastname@example.org>, Adrian Farrel <email@example.com>, Warren Kumari <firstname.lastname@example.org>, Gonzalo Camarillo <email@example.com>, Qin Wu <firstname.lastname@example.org>, L2VPN Service Model Discussion List <email@example.com>
Date: Tue, 14 Aug 2018 13:52:19 -0700
Subject: [L2sm] New Liaison Statement, "Further Information About IETF Work Relevant to Network Slicing"
List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" <l2sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2sm>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2sm>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Tue, 14 Aug 2018 20:52:19 -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/1596/ From: Adrian Farrel <firstname.lastname@example.org> To: email@example.com,3GPPLiaison@etsi.org Cc: Ignas Bagdonas <firstname.lastname@example.org>,Adrian Farrel <email@example.com>,Warren Kumari <firstname.lastname@example.org>,Gonzalo Camarillo <email@example.com>,Qin Wu <firstname.lastname@example.org>,L2VPN Service Model Discussion List <email@example.com> Response Contacts: Adrian Farrel <firstname.lastname@example.org>,Qin Wu <email@example.com> Technical Contacts: Purpose: In response Referenced liaison: Further Information About IETF Work Relevant to Network Slicing (https://datatracker.ietf.org/liaison/1595/) 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  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 . DetNet's use of the IP  and MPLS  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 ( and ) 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 . - VPN delivery models are being specified in the BESS working group . 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 , the YANG Data Model for BGP/MPLS L3 VPNs , and the YANG Data Model for EVPN . - The TEAS working group  is developing a YANG model for the configuration and management of Traffic Engineering (TE) interfaces, tunnels and Label Switched Paths (LSPs) . 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) . 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  and . 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 , while a further individual document  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: -  Still needs work: may be an RFC within 12 months -  Unknown timing -  Unknown timing -  Unknown timing -  Complete and in RFC Editor processing: likely to be an RFC within two months -  Already an RFC -  Already an RFC -  Still needs work: may be an RFC within 12 months -  Still needs work: may be an RFC within 12 months -  Still needs work: may be an RFC within 12 months -  Still needs work: may be an RFC within 6 months -  Complete and in RFC Editor processing: likely to be an RFC within two months -  Still needs work: may be an RFC within 6 months -  Still needs work: may be an RFC within 6 months -  Unknown timing -  Unknown timing Best regards, Adrian Farrel and Qin Wu (IETF L2SM Working Group chairs)  https://datatracker.ietf.org/wg/detnet/about/  https://tools.ietf.org/html/draft-ietf-detnet-architecture  https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-ip  https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-mpls  https://tools.ietf.org/html/draft-geng-detnet-conf-yang  https://www.ietf.org/id/draft-ietf-l2sm-l2vpn-service-model-10.txt  https://www.rfc-editor.org/rfc/rfc8299.txt  https://www.rfc-editor.org/rfc/rfc8309.txt  https://datatracker.ietf.org/wg/bess/about/  https://www.ietf.org/id/draft-ietf-bess-l2vpn-yang-08.txt  https://www.ietf.org/id/draft-ietf-bess-l3vpn-yang-03.txt  https://www.ietf.org/id/draft-ietf-bess-evpn-yang-05.txt  https://datatracker.ietf.org/wg/teas/about/  https://www.ietf.org/id/draft-ietf-teas-yang-te-16.txt  https://www.ietf.org/id/draft-ietf-teas-actn-framework-15.txt  https://www.ietf.org/id/draft-ietf-teas-actn-yang-01.txt  https://www.ietf.org/id/draft-ietf-teas-actn-vn-yang-01.txt  https://www.ietf.org/id/draft-king-teas-applicability-actn-slicing-03.txt  https://www.ietf.org/id/draft-wu-model-driven-management-virtualization-01.txt Attachments: Microsoft Word version of this LS https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-08-14-l2sm-3gpp-tsg-sa-wg5-further-information-about-ietf-work-relevant-to-network-slicing-attachment-1.doc Attachments: No document has been attached
- [L2sm] New Liaison Statement, "Further Informatio… Liaison Statement Management Tool