Note takers, plases add you names here (optional)

Only discussion need be captured

Lou Berger
Adrian Farrel

Draft Minutes from TEAS Agenda for September Interim (Virtual)

Version: September 17, 2021

WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=teas

Monday 2021-09-27 14:00-15:30 UTC

Time Zone Converter: https://www.timeanddate.com/worldclock/converter.html?iso=20210927T140000&p1=1440&p2=tz_pt&p3=tz_mt&p4=tz_et&p5=tz_bst&p6=tz_cest&p7=tz_cst-china&p8=tz_jst
Session ICS: https://datatracker.ietf.org/meeting/interim-2021-teas-01/sessions/teas.ics
Meeting URL: https://meetings.conf.meetecho.com/interim/?short=edd4759b-fab1-44f0-8ff3-03bc5b73f907
Jabber: xmpp:teas@jabber.ietf.org?join
Jabber Logs: http://jabber.ietf.org/logs/teas

Materials: https://datatracker.ietf.org/meeting/interim-2021-teas-01/session/teas
Note taking: https://notes.ietf.org/notes-ietf-interim-2021-teas-01-teas

Youtube: https://www.youtube.com/watch?v=RfwnuiCkrfY

#1 14:00 5 min Title: Intro

Presenter: Chairs

#2 14:05 (14:07) 20 min Title: Open issues: Framework for IETF Network Slices

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/
Presenter: Adrian Farrel

Adrian Farrel: Can a slice service include multiple connectivty matrices? In this model, a connectivity matrix is in the model of a tunnel.
Tarek Saad: You are proposing a matrix per type? [yes] Then I think this is useful. If creating multiple connectivity matrices is for loadbalancing (or redudancy purposes), then this ideally be taken for in the realization step.
[Observation from chairs: There seemed to be general agreement on having multiple connectivity matrices per slice service]

Luis Contreras: Using this definition, there is an idea of only specifying transmission characteristics and not receiver metrics. Need also reception.
Adrian Farrel: Will discuss on list to see if there are different opinions

Adrian Farrel: Are there opinions on if this document needs more details on abstract definition of service specification
Pavan Beeram: Info model could be overkill in this document. Would benefit from some extra text explaining how the service is requested. [Adrian takes this to be Pavan volunteering to write text]

[Back to discussion of connectivity matrices]
Igor Bryskin: If have more than one connectivity matrix that can be used, how do you choose?
Adrian Farrel: The way of solving could be solution dependent. E.g. different vlan tag for each matrix.
Igor Bryskin: Why not one slice per matrix?
Adrian Farrel: This is based on the definition and if you want one slice with multiple matrices or lots of slices. Why should we stop those who want one slice?
Igor Bryskin: Because then need to add semantics to suppor this case
Adrian Farrel: Identifiers can be used to identify slices or matrices within a slice. A coonectivity matrix aplies only to the PE (headend) of the connectivity matriz, and it is identify within the context of the slice through an identifier decided between CE and PE.
Joel Halpern: Different matrices for different traffics to be suported in the slice. There are properties for the slice and properties for the connectivity matrices. We need to allow this.
Adrian Farrel: There is an action for me to draw a Venn diagram of the functionality being delivered and how the identifiers would work.
John Drake: Technology specific identifiers (e.g., fields in L2 and L3) to identify particular slices and associated conectivity matrices.
[unclear if consensus reached on this topic – Note from Lou Berger as Chair]

Adrian Farrel: Are we OK with supporting all four potential endpoint locations?
Reza Rokui: Agree on considering the all four potential locations for endpoints
[Obersvation from chairs: There seemed to be agreement on allowing for all four endpoint locations]

Adrian Farrel: In the discussion of the realisation architecture we are down to ‘resource partition’ or ‘resource group’. There are different nuances.
Reza Rokui: Please elaborate on Filter Topology
Adrian Farrel: A topology built on links and nodes that have well known ability to deliver a typre of service (quality aspect, securtity aspects, isolation, etc).
Lou Beger: What is the relationship between resource partition/group and filter topology?
Adrian Farrel: The partition/group is built from the resources in only one filter topology.
Lou Berger: As participant, resource partition make sense in relation to a topology.
Tarek Saad: Very useful diagram. I would like to see this diagram on the IETF Network Slice document.

Discussion on next steps on NBI

#3 14:25 (14:36) 5 min Title: Summary of WG Adoption Poll: IETF Network Slice Service YANG Model

Presenter: Chairs
Draft: https://datatracker.ietf.org/doc/draft-wd-teas-ietf-network-slice-nbi-yang/

#4 14:30 (14:38) 20 min Title: IETF Network Slice Service YANG Model (Overview)

Presenter: Bo Wu
Draft: https://datatracker.ietf.org/doc/draft-wd-teas-ietf-network-slice-nbi-yang/

#5 14:50 (14:55) 15 min Title: A view on concerns

Presenter: Daniele Ceccarelli

Open Discussion (15:13)

Adrian Farrel: three points for Daniele: (1) be careful in the usage of term consumer and customer; we moved to using consumer in the slicing work (2) we need a network slice consumer service model, we should agree and move on; (3) you mention network slice connection, it should be considered the differentce between VN and connectivity matrix, since VN is a collection of connection matrices.
Bo Wu: We are doing a customer service model, not a network service model. Dan’s model is quite useful, but different then our model.
Reza Rokui: Important to differentiate consumer and customer. Depend on the use case this consumer could be an orchestrator. We cannot dictate what is that, it depends on the use case. In the ACTN consumer / customer has a specific meaning, but not in IETF NEtwork Slice case. A further comment on Daniele’s presentation, it considers realization vs technology agnostic.
Tarek Saad: The mappings provided in Daniele’s presentation are not always straightforward. It shoud be in the framework and definitiosn draft where such kinds of mappings could facilitate to make such kinds of extensions.
Italo Busi: Not clear wheter Bo’s YANG model is customer service model.
Dhruv Dody: MSDC not a single box.
Igor Bryskin: if network slice has several connectivty matrices, what does it mean in this case ? Regarding VN, it is not possible to have more than one connectivity matrix per VN.
Bo Wu: the model currently does not support multiple matrices, under discussion by co-authors.
Adrian Farrel: regarding customer/consumer. It is important not to consider customers as end users or paying people. Think better that customers and consumers are synonymous. Move to consumer in slicing. When we wrote RFC8309 it was in the context of L3SM and “customer” was good enough. If we rewrote it today, we would probably have used “consumer”
Aihua Guo: regarding agonosticity, is packet switching a technology specific term? At the time of defining a model we need to consider some parameters, so not clear if that can be assumed to be agnostic or not.
Tarek Saad: A connection can require multiple traffic types, or alternatively multiple connections can deal with different traffic types. If the idea of multiple matrices is for load balancing, redundancy, etc, it should be hidden. Still one connection at the end of the day.

15:25 (15:28) Wrap up

Lou Berger: General agreement on NBI being a consumer/customer facing model, i.e, has customer/consumer facing scope – will confirm on list. Chairs will take an action on look back to the discussion and take next step on adoption poll.
Pavan Beeram: We will try to summarize questions.
Lou Berger: We also reached some notable agreements on Adrian’s questions.

Adjourn 15:30 (15:31)