Liaison statement
Further Information About IETF Work Relevant to Network Slicing

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