ACTN Clarifications and proposed update

L3SM + TE L3VPN between CE1 and CE2 Service Orchestrator XXXXX Service Orchestrator to Controller i/f MDSC Service ACTN MPI TE Service Controller1 Controller2 Controller3 PNC PNC PNC - ACTN MPI: as defined in [https://tools.ietf.org/id/draft-zhang-teas-actn-yang-03.txt ] is based on TE-topology + TE-tunnel + Path computation API. TE-service: MISSING: L3SM enhanced with TE? LxSM ? TBD. Daniele,Young and Dhruv working on it. CE1 A B C D E CE2 Z AP1 AP2

Service Orchestrator L3SM + TE XXXXX L3VPN between CE1 and CE2 MDSC - ACTN MPI: as defined in [https://tools.ietf.org/id/draft-zhang-teas-actn-yang-03.txt ] is based on TE-topology + TE-tunnel + Path computation API. TE-service: MISSING: L3SM enhanced with TE? LxSM ? TBD. Daniele,Young and Dhruv working on it. Controller1 Controller2 Controller3 PNC PNC PNC CE1 A B C D E CE2 Z AP1 AP2

L3SM + TE L3VPN between CE1 and CE2 Service Orchestrator XXXXX Service Orchestrator to Controller i/f MDSC Service ACTN MPI TE Service Controller1 Controller2 Controller3 PNC PNC PNC CE1 B A E Z CE2 AP2

Architectural considerations A1 – The MDSC does not map 1:1 with the service orchestrator, it is a functionality inside it, the one dealing with the underlay infrastructure (i.e. Virtual Networks and Tunnels/LSPs) and mapping against the services A2 – The PNC does not map 1:1 with the (domain) controller, it is a functionality inside it, the one dealing with the underlay (i.e. Tunnels/LSPs) and mapping against the services A3 – The MPI, as defined now, is the interface between MDSC and PNC (blue dashed), not the only communication channel between orchestrator and controller. There is at least one more for overlay services. A4 – The MPI, as defined in draft-zhang-teas-actn-yang-03, is based on TE topology + TE tunnel + (opt.) Path computation API. A5 – TE-Service i/f is missing. It can be defined as augmentation of the MPI, based on the L3SM and augmented with TE or others. Work in progress.

Possible workflow Customer asks for a L3VPN between CE1 and CE2 (or between AP1 and AP2 if supported) with TE constraints using L3SM model enhanced with TE (missing). XXXX (I don’t have a name for that functionality) asks the MDSC if an underlay infrastructure meeting the requirements is available, if not create it. The MDSC interacts with the various PNCs via the MPI to provide the TE tunnels in the network and it is presented as a VN XXXX asks for the provisioning of the service to the service functionality and to bind it to the VN The service provisioning is done via TE service (dashed red) using the TE service model (missing). It can be defined as augmentation of the MPI, based on the L3SM and augmented with TE or others. Work in progress.