1. November 6-11, 2017 Nov. 10 version L. Ong
TAPI Agenda
November 6-11, 2017
Nov. 10 version
L. Ong

2. Work Items OIF Update, China Mobile report, FRD Review (Mon. 9-10:30)
TAPI/IM Ethernet Model (Mon. 11:15-12:45)
TAPI/MEF (Mon. 4-5:30)
TAPI/IM Spec Method (Tue )
TAPI FRD continued (Wed. 9-11)
TAPI/IM Resilience (Wed. 9-11)
TAPI/IM OTU/OTSi Model (Thu. 11:15-12)
OAM (Thu. 2-4)
TIP Review (Fri :30)
Overflow TAPI Work (Fri :30)

3. Summary Notes China Mobile TAPI Testing Discussions with CORD/ONOS
Generally satisfied with TAPI 2.0 work
Developed JSON directly from UML
Questions on VLAN tag push/pop control, synchronization of scheduled svcs.
Discussions with CORD/ONOS
Strong interest from CORD in the TAPI model
potentially helpful to CORD which does not have complex forwarding model
Strong interest from ONOS as well
Currently ONOS Intent NBI has simple single node model
ONOS folks will do comparison of TAPI JSON with ONOS JSON
ODTN project calls for TAPI NBI, needs resourcing from vendors
Also interest in TAPI translation to protobufs as possible target of work
TIP Review
TIP Open OLS group has adopted TAPI between Service APP and L0 Power Controller
Also TAPI flavor to Open OLS IF/YANG model and Open Device IF/YANG Model
Detailed notes in

4. CORD Build TAPI Booth Demonstration:
Bernd’s UML-YANG translator (popular)
Sedona OIF TAPI Testing video
TAPI Reference Implementation on laptop
Posters – see CORD%20Build%20Science%20Fair%20Posters%20v2.pdf?api=v2
Several visitors including Telstra

5. OIF Update 2018 Demo proceeding ahead
At least 9 carriers interested in participating
Vendor survey sent out with response due Dec. 1
Updated timetable as below
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
2017
2018
Tech Spec Start
Contract/NDA
Test start
Test end
Readouts
4Q OIF
ONF
1Q OIF
OFC
ONS
2QOIF
BTE
NGON
3QOIF
ECOC
L123

6. Functional Requirements Document Review
Currently in draft, posted on github
Terminology, main text and appendices
Terminology – check for alignment with MEF agreements
Main text – check for terminology consistency with UML, add section on OAM
Appendices – review, potentially add more examples
Appendix Extensions
Multilayer/Multidomain example with option B (separation of layer connectivity services)
Notification example – notification of state changes
OAM example – creation, activation of monitoring

7. Service Example 10G EPL (Option A)
Node Edge Point (Internal)
Service End Point
Node Edge Point (Edge)
Link
Transitional Link
Connection EndPoint
Service Interface Point 1 13
1.G
TAPI Context-G
10.G
2.R
TAPI Context-R
9.R
3.G
11.G
4.R
12.R
Multi-Domain Controller 2 12 3 5 6 8 9 11
1.D1
TAPI Context-1
5.D1
5.D2
TAPI Context-2
7.D2
7.D3
TAPI Context-3
11.D3
2.D1
6.D1
6.D2
8.D2
8.D3
12.D3
3.D1
4.D1
9.D3
10.D3 4
Domain-1 Controller 7
Domain-2 Controller 10
Domain-3 Controller
Domain-1
Domain-2
Domain-3
UNI
NNI
UNI
NNI
D1-4
D3-4
G-1
G-2 1
D2-1
D2-3 11
D1-1
D1-3 5 7
D3-3
D3-1
R-1 2
D1-2 6 8
R-2
D2-2
D3-2 12
UNI 3 4 9 10
UNI
G-3
R-3
R-4
G-4

8. Multilayer/multidomain example (Option B) - Multilayer View?
MD Controller Internal View (not exposed) D1 D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
9.D3
9.R
14.D3
13.D3
7.D1 D2
D1-o
D3-2o
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
D3-1o
8.D2
8.D3
6.D1
6.D2
D2-2o
D3-4o
Comments from Malcolm and Italo that layers should be separated with interdomain SIPs – see onf

9. Create server layer connectivity service
MD Controller Internal View (not exposed) D1 D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
9.D3
9.R
14.D3
13.D3
7.D1 D2
D3-2o
D1-o
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
D3-1o
8.D2
8.D3
6.D1
6.D2
D2-2o
D3-4o

10. Create client layer connectivity service
MD Controller Internal View (not exposed) D1 D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
9.D3
9.R
14.D3
13.D3
7.D1 D2
D3-2o
D1-o
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
D3-1o
8.D2
8.D3
6.D1
6.D2
D2-2o
D3-4o

11. Create additional client layer service
MD Controller Internal View (not exposed) D1 D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
9.D3
9.R
14.D3
13.D3
7.D1 D2
D3-2o
D1-o
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
D3-1o
8.D2
8.D3
6.D1
6.D2
D2-2o
D3-4o
Red TAPI Context R
2.R
R1.e
R3.e 01 03
12.R
G1.e
1.G
3.G 01 03 G
Green TAPI Context
11.G
10.G 04 02
Note: does transitional SIP have enough ability to identify where a flow should be mapped to in the server domain?
4.R 02 14 16
R2.e 04
9.R 15
R1.o 05
R3.o 12 06 13 07 11 08
R2.o 09 10

12. TL with multiple client layers – different topologies (from .041)
Access Links 1 and 2 are STM-N while access links 3 and 4 are ETH. A common set of server-layer OTN potential TTPs exist in NEP-07
If a server layer connection is created to support one client layer link, the server layer available capacity is reduces for both client layers
TAPI Context-1
Physical Box View (internal)
Node Edge Point (Internal)
Service End Point
Node Edge Point (Edge)
Link
Transitional Link
Mapping
Topology
Node
Connection EndPoint
Connection
Connectivity Service
D1s
Domain-1
1.D1
D1-s
UNI 01
NNI
3.D1 03
D1-4
D1-e
G-1
2.D1 02 09 1
D1-1
D1-3 5
4.D1 04
D1e 08
R-1 2 6
TL.D1
D1-2 07
D1-o
Added during the T-API call on April 18
UNI 3 4 05
5.D1
G-3
R-3 06
6.D1
D1o

13. TL with multiple client layers – different topologies (from .041)
Access Links 1 and 2 are STM-N while access links 3 and 4 are ETH. A common set of server-layer OTN potential TTPs exist in NEP-07
If a server layer connection is created to support one client layer link, the server layer available capacity is reduces for both client layers
TAPI Context-1
Physical Box View (internal)
Node Edge Point (Internal)
Service End Point
Node Edge Point (Edge)
Link
Transitional Link
Mapping
Topology
Node
Connection EndPoint
Connection
Connectivity Service
D1s
Domain-1
1.D1
D1-s
UNI 01
NNI
3.D1 03
D1-4
D1-e
G-1
2.D1 02 09 1
D1-1
D1-3 5
4.D1 04
D1e 08
R-1 2 6
TL.D1
D1-2 07
D1-o
Added during the T-API call on April 18
UNI 3 4 05
5.D1
G-3
R-3 06
6.D1
D1o

14. 10G EPL Service setup: MD Controller Internal view
MD Controller Internal View (not exposed) 2 12
1.G
1.D1
D1-e 01
D3-1e 43
11.D3
11.G 9
2.R
2.D1 02 11
12.D3
12.R 60 44
3.G
3.D1 03 5
D3-2e
10.D3
10.G 3 45 12
TL1.D3
4.R
4.D1 04
9.D3
9.R D3 46 59
TL2.D3 08 D1
TL.D1 6 07 8
D3-2o 57
D1-o 56
D2-1o 54
Slide 17 of onf
To be updated as per comments in slide 11 25
D2-3o 30 05 21 55 5
5.D1
5.D2 24
7.D2
7.D3
D3-3o 47 41 58 26 05 D2 29
D3-1o 53
8.D2
8.D3 42 48
6.D1
6.D2 52 06
D2-2o 27 28 50
D3-4o 49 51 06 22 23 11
* An controller internal model may not be based on TAPI

15. Notification Example Static object state change
Link deterioration/failure
Link update
Dynamic object state change
Connectivity Service to Installed
Connectivity Service to Deleted
Steps
Identification of object for state change notification
Subscription to state change notification
Unsubscription to state change notification or object deleted

16. Use Cases (distinguish Demo and FRD)
Link failure (port?) – topology update – path computation input
Automatic? Or subscribe -
Currently only poll, do not get autonomous notification of change
connService provisioning state (demo vs. FRD)
Automatic subscription – could be by creator or other, e.g,. Alarm center (for all services)
Optimization – automatically subscribe on creating service? Or automatically subscribe to all service creation – for Demo
Note CT testing – used websockets but did not have explicit subscription needed
Bandwidth change?
connService failure
MEPs– OAM service – MIPs – fault analysis – retrieve log?
More complex – pkt counter not changing, queue overflow?
Lower priority (need understanding) - “telemetry” – instantaneous or periodic update of current state (or “no change”)
Fault isolation?
YANG
Configuration state change
Operational state change – against services? Current TAPI – initial focus

17. Notification Model Telemetry Processor Multi-Domain Controller
Node Edge Point (Network Internal) 1
Service Interface Point
Node Edge Point (Network Edge)
1.G
TAPI Context-G
10.G
2.R
TAPI Context-R
9.R
Telemetry Processor
3.G
11.G
4.R
12.R
Multi-Domain Controller
Notification Client
Notification Client
1.D1
TAPI Context-1
5.D1
5.D2
TAPI Context-2
7.D2
7.D3
TAPI Context-3
11.D3
2.D1
6.D1
6.D2
8.D2
8.D3
12.D3
3.D1
4.D1
9.D3
10.D3
Domain-1 Controller
Domain-2 Controller
Domain-3 Controller
Notification Server
Notification Server
Notification Server
MD Controller Internal View (not exposed) D1 D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
9.D3
9.R
TL1.D3
TL.D1 D2
TL2.D3
D1-o
D3-2o
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
D3-1o
6.D1
6.D2
8.D2
8.D3
D2-2o
D3-4o

18. Use cases (additional)
Carrier creates service, monitoring sent to client
Same context, different channels – REST + websocket (different lines)
Different contexts? Different channels (outside of previous scope)
Same interface, different contexts?
config
monitor
Config
(operator)
Monitor
(client)
Client 1
VPN 1
VPN 2
VPN 3
VPN 1
VPN 2
VPN 3

19. issues Source – notification server Event Sourcing (CQRS)
How do you decide what state to indicate, what to present to user?
E.g., multi-connection service, multipoint service
Protect connection
Bundled link
Types of notification
Status change
Config data change (including by someone else)
Scope of interest (for TAPI – svces)
Health/alarm
Current state (periodic update) (overhead penalty)
Alarm
TCA
Others
Log
View alignment/synchronization
SNMP Trap – prompt for further info
OpenConfig YANG
Multiple possible streams (raw, processed)
Source – notification server
Could be device or separate server
Source must know view appropriate for client
Event Sourcing (CQRS)
Team – Chris (has slides – aviva solutions)
Filtering (rapidly changing objects? Scaling)
How often, what type (e.g., overall state)
Losing events (acked/not acked? Replay? Sequence number?)
Event bundling

20. Notification Examples
GET notification types and availability
POST subscribe to notification of all connService state changes
Notifications via websocket
POST subscribe to notification of Link state changes with new destination
Notifications via websocket to destination
Notification Examples
Node Edge Point (Network Internal) 1
Service Interface Point
Node Edge Point (Network Edge)
1.G
TAPI Context-G
10.G
2.R
TAPI Context-R
9.R
Telemetry Processor
3.G
11.G
4.R
12.R
Multi-Domain Controller
Notification Client
Notification Client 5
1.D1
TAPI Context-1
5.D1 4
5.D2
TAPI Context-2
7.D2 1 2
7.D3
TAPI Context-3
11.D3 3
2.D1
6.D1
6.D2
8.D2
8.D3
12.D3
3.D1
4.D1
9.D3
10.D3
Domain-1 Controller
Domain-2 Controller
Domain-3 Controller
Notification Server
Notification Server
Notification Server
MD Controller Internal View (not exposed) D1 D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
9.D3
9.R
TL1.D3
TL.D1 D2
TL2.D3
D1-o
D3-2o
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
D3-1o
6.D1
6.D2
8.D2
8.D3
D2-2o
D3-4o

21. TIP Service App TAPI L0 Power Controller OpenOLS IF/YANG Model
OLS Controller
OLS Controller
OpenDevice IF/YANG Model
Mediator
Mediator
Mediator
ROADM
ILA
ROADM
ROADM
ILA
ROADM
Lumentum OLS Segment
Infinera OLS Segment