1. Yang model for requesting
Path Computation
draft-busibel-teas-yang-path-computation-00
IETF 97 – Seoul
Italo Busi (Huawei)
Sergio Belotti (Nokia)
Daniele Ceccarelli (Ericsson)
Victor Lopez, Oscar Gonzales de Dios (Telefonica)
Michael Scharf (Nokia)
Anurag Sharma (Infinera)
Yan Shi (China Unicom)
Ricard Vilalta (CTTC)
Karthik Sethuraman (NEC)
IETF Seoul, November 13-18, 2016

2. Status Initial draft presented at CCAMP WG in Berlin (IETF 96)
draft-busibel-ccamp-path-computation-api-00
Updated to address comments received during IETF 96
Moved to TEAS WG
Draft outline restructured
Applicability to ABNO and ACTN architectures clarified
Motivations for a YANG model added

3. Scope
Use cases for supporting path computation request via YANG-based protocols (e.g., NETCONF or RESTCONF).
Target interface is NBI of an SDN controller.
ABNO control interface
ACTN CMI and MPI
OUTLINE
Section 2 Use cases
Section 3 Interaction with TE-Topology
Section 4 Motivation for a Yang model
Section 5 Path optimization request (ffs)
Section 6 Yang model for path computation request

4. Use Cases Three use-cases are addressed in this version:
IP-Optical Integration
An optical domani is providing connectivity between IP routers
Multi-domain TE Network
TE (e.g., Optical) domains interconnected by multiple inter-domains links
Data Center interconnection
TE (e.g., Optical) domain is providing connectivity among data centers.

5. IP-Optical integration
OPTICAL NW
Optical NW
CONTR0LLER
IP NW
ORCHESTRATOR
Request a Path
NETCONF/RESTCONF
interface
TE Topology:
Abstract node

6. Multi-domain TE NetworksC H G F
TE NW
CONTR0LLER 2
CONTR0LLER 1
ORCHESTRATOR B
NETCONF/RESTCONF
interfaces

7. Data center interconnections
DC1
DC3
DC2
PE1
PE3
PE2 P
TE NW
CONTR0LLER
CLOUD ORCHESTRATOR
DC CONTR0LLER
NETCONF/RESTCONF
interfaces

8. Interactions with TE Topology
TE Topology is extending the TE Node «connectivity matrix» of RFC 7446 with specific TE attributes (e.g. delay, SRLGs, etc)
From «virtual node» model to «virtual link» model
Tradeoffs still to be considered when abstracting topology information
Accuracy versus Scalability and up-to-date information
Path Computation request allows requesting only the information that is needed and when it is needed
Abstract Topology Information can be still used to reduce the number of Path Computation requests (improving scalability with large number of domains)
Path computation request and TE topology model are complementary tools

9. Motivation for Yang model (1)
Common data model
Path computation request should be closely aligned with Yang data models providing abstract TE topology information and TE tunnel configuration and management
Same end-point ID
Path computation constraints based on same data model

10. Motivation for Yang model (2)
Single Interface
Simple authentication and authorization
E.g. avoid different security mechanism per interface (different credential, keys)
Consistency
Keeping data consistent over different interface not trivial
Testing
Middle-box friendliness
Complex environment scenario with also middle-box such firewall, load balancers etc.
Single protocol easier to deploy
Tooling reuse
Leveraging rapidly growing eco-system for Yang ttooling (tools, libraries)

11. Motivation for Yang model (3)
Extensibility
Yang language to cover other typical important functionality like path computation in a seamless way
Service configuration
Notification for topology changes and alarm integration
Performance management (data telemetry and monitoring)
OAM
QoS configuration

12. Yang model
Te-tunnel model already provides a statetful solution based on «compute-only» te-tunnel
Discussion have been hold in mailing list and in the te-tunnel weekly to elaborate pro and cons related RPC stateless vs. compute-only
The need for stateless solution have been recognized
A Yang model proposal for a stateless RPC is available on:
Plan to be added to the 01 version
Stateless RPC and compute-only te-tunnels are «complementary» solutions.

13. Stateless RPC
Pro
A simple atomic operation is a natural choice expecially with a stateless PCE
No need for persistent storage of state
No need for garbage collection (no states to be deleted)
Cons
RPC response must be provided synchronously
If collaborative computations are time consuming, it may not be possibe to immediate reply to client
Possible solutions to this problem still under investigation/discussion
Stateless operation without garantee that returned path is still available when path setup is requested

14. Compute-only te-tunnel
Pro
Support asychronous operation
Simple to model in the context of te-tunnel
Allow notifying client on changes of the computed path
Cons
Several messages required for any path computation
Requires persistent storage in the provider controller
Need for garbage collection for stranded paths
Process burden to detect changes on the computed paths in order to provide notifications update
Notifications may not be reliable nor develivered on time
Mitigate but does not solve the issue that the computed path may not be available at the setup time

15. Next Steps
Seeking comments and feedbacks from interested WGs to improve document
avoid duplicated information with existing RFCs or other Internet-Drafts
on going discussions about compute-and-delete te tunnel and te-tunnel actions
Yang solution for stateless RPC integration into te-tunnel model?
Complete with path optimization

16. Backup

17. IP+Optical: Path Computation Example
Cost= 50
Cost= 10
Cost= 10
VP1
VP4 R2 R1
VP5
VP2
Cost= 5
Cost= 5
Cost= 55
Orchestrator got «abstracted view» of physical resources (no optical path cost feasibility)
Orchestrator can ask DC for a «set of potential optimal path» based on optical constraints
Orchestrator select one based on its own constraints, policy and specific topology parameter (e.g. access link cost)

18. Data center interconnections
Virtual machine in DC1 needs to transfer data to another virtual machine (in DC2 or DC3)
Optimal decision based on optical cost (DC1-DC2 or DC1-DC3) and computing power
Cloud orchestrator use path computation request to Optical domain to compute the cost of feasible optical paths and to DC controller to compute the cost of computing power, and then take the decision.

19. Multi-domain Optical Networks:
(many domains)
Complementary use of TE topology and path computation
Abstract topology information provided by domain controllers limiting the number of potential optimal e2e paths
Path computation API to find optimal path within limited set.