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

[Liaison Statement Management Tool <[e-mail]>]

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 <[e-mail]>
To: [e-mail],[e-mail]
Cc: Ignas Bagdonas <[e-mail]>,Adrian Farrel <[e-mail]>,Warren Kumari <[e-mail]>,Gonzalo Camarillo <[e-mail]>,Qin Wu <[e-mail]>,L2VPN Service Model Discussion List <[e-mail]>
Response Contacts: Adrian Farrel <[e-mail]>,Qin Wu <[e-mail]>
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 [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 
[5].

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 
     months 
- [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 
      months 
- [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
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