1. ACTN Clarifications and proposed update

2. 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 [ ] 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

3. Service Orchestrator L3SM + TE XXXXX L3VPN between CE1 and CE2 MDSC
- ACTN MPI: as defined in [ ] 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

4. 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

5. 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.

6. 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.