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

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. 11-12) 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. 11-12:30) Overflow TAPI Work (Fri. 11-12:30)

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 https://wiki.opennetworking.org/pages/viewpage.action?pageId=279543813

CORD Build TAPI Booth Demonstration: Bernd’s UML-YANG translator (popular) Sedona OIF TAPI Testing video TAPI Reference Implementation on laptop Posters – see https://wiki.opennetworking.org/download/attachments/259719184/otcc2017.LYO.003- CORD%20Build%20Science%20Fair%20Posters%20v2.pdf?api=v2 Several visitors including Telstra

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

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

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

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 onf2017.041

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

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

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

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

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

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 onf2016.303 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

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

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

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

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

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

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

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