Initial example for multi-layer topology management

[italobusi]

• [ ] @nigel-r-davis, @italobusi Prepare some discussion material for the initial multi-layer topology management use case.

Not intended to be detailed, ideally enough material for initial technical discussion.

[italobusi]

2023-12-21 TNBI DT Call

Initial slide presented by @nigel-r-davis

Clarification: the OTSiMC represents the Link which provides capacity to multiple OTSiMCs. These are the links currently modelled in the WSON, flexi-grid and OI topology models.

The current WSON and flexi-grid topology models do not expose the underlay topology for the WSON or flexi-grid link (e.g., to expose the in-line amplifiers). The OMS elements defined in the optical impairments (OI) topology model can be profiled to represent the in-line amplifiers as well.

• [ ] @ALL : check whether there is a need to expose the underlay topology below the "OTSiMC" link and whether this could be done profiling the OMS elements defined in the OI topology model

• [ ] @all : review the terminology and align with the current terminology used in IETF

We could also benefit to show some translation between the different terminologies

Clarification that OTN switching needs also to be considered in the multi-layer topology example: to be added in a future update of the slide

• [ ] @nigel-r-davis : upload the slide

• [ ] @italobusi : start an initial JSON example based on this slide

Assumption: only one topology instance exposing multiple-layers

The topology models to consider in this initial analysis are:

• OTN topology (OTN Link)
• Flexi-grid and OI topology (OTSiMC Link) and underlay links

[nigel-r-davis]

The figure as discussed on the T-NBI call 1 Feb 2024 is one slide 1 of the PowerPoint pack attached. TnbiRfc8345Scenarios.pptx

This is work in progress. This figure probably provides a sufficiently narrow example to start identifying YANG and generating JSON fragments to trial the approach.

The other slides in the pack are for background.

[danielkinguk]

Need to synchronise TAPI terms with IETF, including topology and service models.

• RFC8345 (Network Topology)
• https://datatracker.ietf.org/doc/draft-ietf-ccamp-l1csm-yang/
• https://datatracker.ietf.org/doc/draft-ietf-ccamp-layer1-types/
• https://datatracker.ietf.org/doc/draft-ietf-ccamp-optical-impairment-topology-yang/

Action: Need to map between TAPI/OIF Terminology like: OTS, OMS, OTSI, OTU, to IETF terminology.

[danielkinguk]

Another potential area for investigation is to show how mapping of models progresses to the photonic layer. For instance:

• Customer Service Models YANG Modules
• Network Service Models
• Network Element Models
• Photonic Service Models
• Photonic Element Models

BUT! Don't boil the ocean.

[danielkinguk]

Are we intending to include ROADM information, and other optical clients/components?

[danielkinguk]

Do we need to agree deployment architecture to agree the use case example?

[italobusi]

Slides updated to align with the terminology used in IETF: TnbiRfc8345Scenarios-ib.pptx