Subject: [CCAMP] Minutes of the Transport NBI DT - December 21, 2016

From: <[email-masked]>
Date: Fri, 23 Dec 2016 15:42:53 -0000

Happy Holidays CCAMP'rs and Transport NBI list.  

Please find the minutes for this week's Transport NBI call below. They also
accessible on our GitHub page: 

https://github.com/danielkinguk/transport-nbi/tree/master/Meetings/2016-12-2
1

BR, Dan. 

Date: 21 December 2016

Attendees: Italo Busi, Daniel King, Ricard Vilalta, Sergio Belotti, Young
Lee, Carlo Perocchio, Karthik Sethuraman, Dieter Beller, Luis Miguel
Contreras Murillo, Haomian Zheng, Jonathan Sadler, Yuji Tochio, Xiang YUN

Agenda 

1. Recap of the unofficial gap analysis group work
2. Overview of use cases from ONF
3. Any other business

1. Recap of the unofficial gap analysis group work (led by Sergio)

We reviewed the current use cases: 

* Use Case 1: Single Topology (one domain and one layer)
* Use Case 2: Multilayer/single domain Topology
* Use Case 3: Single layer/multi-domain Topology

Special mention of the mapping from Service/EVC to NRM Connections across
different providers. This MEF slide is provided in the following file (slide
5): 

https://github.com/danielkinguk/transport-nbi/blob/master/Meetings/2016-12-2
1/Gap%20Analysis-%20Recap%20what's%20been%20discussed%20(Xian%20%20Sergio)-r
evised%20-%20updated.pptx

Clarified (slides 6 and 7) that Use Case 1 can be split into two use cases:
one where the ODU is terminated between CE routers and another where an EPL
service, supported by an ODU terminated between the PEs, is setup between
the CE routers.

OTU4 TPs removed (slide 6): still need to discuss the need for ODU4 and ODU2
supporting TPs shown in the slide.

Current open issues (slide 8): 

1. OTN Topology type defined in L1Topology
2. NE Type and Version should be optional. Cleaner solution is to have NE
capability, e.g. ODU hierarchy, Mux levels, etc. in a OTN TE Topology model
3. Generic attributes (including LayerProtocol) should be added to the
augmented Transport Model

[Slide 5] general discussion on which model do we augment: TEAS, OTN, I2RS,
et al? Should we constrain or make this implementation specific?

2. Overview of use cases from ONF
Karthik presented the ONF T-API Multi-layer Multi-domain Topology and
Connectivity example:

https://github.com/danielkinguk/transport-nbi/blob/master/Meetings/2016-12-2
1/onf2016.303_TAPI_Multi-layer_Multi-D.02.pptx
ONF TAPI Concepts include: 

* All T-API interaction between an API provider (e.g. SDN Controller) and an
API Client (e.g. Application, Orchestrator or another SDN Controller) occur
within a shared "Context"
* T-API Context is defined by a set of ServiceEndPoints (and some policy)
* T-API provider creates(provisions) one or more Connections in response to
a successful 
* A T-API provider may expose one or more abstract Topology within the
shared Context
* A Topology is expressed in terms of Nodes and Links between them

Specific Discussions on ONF Use Cases

1. [Slide 1] Young asked if the TAPI will use augmentations of the YANG
models, and Karthik confirmed "Yes" this is the case.

2. [Slide 3] Dieter asked if there is a distinction between service
end-points at the UNI and NNI? Yes, there are some distinctions, dependent
on a domain service, and end-to-end service.

3.  [Slide 4] Italo discussed how the Multi-domain controller will combine
the abstract topologies for each domain environment: it is still an open
point to clarify within ONF.

4.  [Slide 10] Young asked if the model is assumed to be symmetrical. No.
Also, a description of the Context Topology abstraction model is provided in
the T-API 2.0 model document.

5.  [Slide 20] Young highlighted that the multi-domain controller was
concatenating views. The burden of path computation is very complex on the
multi-domain controller, as the domain controller will expose internal
topology and not perform the computation itself.  Karthik mentioned that
this would support both expose physical connectivity or abstracting, to
minimise complexity on the multi-domain controller. 

Italo noted that this could be additional scenarios to those described by
Sergio covering the multi-domain and multi-layer use case, perhaps also with
and without domain abstraction (based on Young's earlier comments). 

In summary, we saw one additional use case for inclusion on the current NBI
DT use case pack (this will be use case 4). We will agree offline and update
the slides to reflect all four scenarios. 

3. Any other business

* Next call with be after holidays and New Year (planned for Wednesday 11th
January, 3-5pm CET)
* We will switch to WebEx as Uber Conference was limited for some
participants as VoIP was filtered
<<