Please add notes inline with the appropriate slot below.
Only discussion need be captured, not material on slides.
Also please feel free to add your name here as
Note Takers:

Draft Minutes For TEAS IETF 120

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

Thursday, July 25, 2024

09:30-11:30 America - Pacific Time - Vancouver
https://www.timeanddate.com/worldclock/converter.html?iso=20240725T163000&p1=256
Room: Regency A/B -- https://datatracker.ietf.org/meeting/120/floor-plan?room=regency-a-b

Materials: https://datatracker.ietf.org/meeting/120/session/teas
Note taking: https://notes.ietf.org/notes-ietf-120-teas
Onsite tool: https://meetings.conf.meetecho.com/onsite120/?session=33101
Video stream: https://meetings.conf.meetecho.com/ietf120/?session=33101
Audio stream: https://mp3.conf.meetecho.com/ietf120/33101.m3u
Zuilip: https://zulip.ietf.org/#narrow/stream/teas
ICS: https://datatracker.ietf.org/meeting/120/session/teas.ics

Available post session:

Recording: http://www.meetecho.com/ietf120/recordings#TEAS
YouTube: https://www.youtube.com/watch?v=meSLY9inRfE

Slot#) Start | Duration | Information

01) 09:30 | 10 min | Title: Administrivia & WG Status

Presenter: Chairs

02) 09:40 | 10 min | Title: WG Draft updates

Draft: WG Drafts (not on agenda)

Presenter: Chairs

03) 09:50 | 10 min | Title: A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-5g-ns-ip-mpls/08/

Presenter: Krzysztof Szarkowicz

Adrian Farrel: Were you asking for specific further action from me? I am not 100% happy with the way my comments are addressed but we have got enough consensus to move forward.

Jie Dong: I will review the latest verision and send my comments.

Greg Mirsky: I would like your answer to my comments to be reflected into the document. It would be useful to have the draft go through another round of review.

Vishnu Pavan Beeram: About inter-PE transfer plane, I think we can reword the relevant section without coining a new term.

Lou Berger: If we want to reuse an existing term, Underlay transport seems reasonable to me
(+1 on chat for this from Daniele Ceccarelli, Dhruv Dhody and Jie Dong)

Krzysztof Szarkowicz: If there is agreement with underlay transport, it looks ok to me

Mohamed Boucadair (chat): We will move to underlay-transport and move on.

04) 10:00 | 10 min | Title: YANG Data Models for Network Resource Partitions (NRPs)

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-nrp-yang/02/

Presenter: Bo Wu

Ketan Talaulikar: Should we rename the NRP ID to NRP policy ID?

Bo Wu / Vishnu Pavan Beeram: The "name" leaf is for identifying the policy and the "nrp-id" leaf is for identifying the NRP instantiated by the application of the policy. The "nrp-id" leaf is meant for use in the management/control plane.

Joel Halpern (chat): Then, maybe the ID should be called NRP-mgmt-id?

Ketan Talaulikar: I think that selector specific modeling should be extensible since the data plane specifications are still work in progress.

Vishnu Pavan Beeram: Acknowledge that this is work in progress; the model will evolve as the corresponding specifications also evolve; input is welcome to improve the model.

Jie Dong: I think that with the ACL matching rules, the model is already quite flexible

05) 10:10 | 10 min | Title: Scalability Considerations for Network Resource Partition

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-nrp-scalability/05/

Presenter: Jie Dong

Ketan Talaulikar: There is a contradiction in the principles listed (Slide 6); On one hand you say "routing protocols" do not need to be involved and on the other hand you say "but when they need to be involved, use so and so mechanisms"; This contradiction needs to be discussed further and elaborated upon. We have to be very careful to not stress the existing protocols at scale. We need an explicit list of items that are okay to be added and another list of items that are NOT okay to be added.

Jie Dong: This text is not specific to any routing protocol, it is meant to be generic. The intention is not to impact the stability of existing routing protocols. Agree that this needs more discussion.

Greg Mirsky: I concur with Ketan. This isolated information from existing routing information is a bit vague. More detailed analysis of IGP, BGP, BGP-LS should be done. Maybe this analysis can be done in another document and not in this document.

Jie Dong: In this draft we already have a recommendation to provide scalability considerations in all the drafts which extend the routing protocols to support NRPs.

Ketan Talaulikar: We need some proposal on what information is needed to consider the scalability.

Jie Dong: That's why I think that the details should be defined in the specific protocol extension / solution drafts.

Vishnu Pavan Beeram: Please continue the discussion on the list. We will try to find avenues to get some more focused discussion on this topic.

Oscar de Gonzalez: If required, at some point we can consider having a dedicated interim meeting.

Daniele Ceccarelli (on chat): Not debating whether the draft is useful, but is it something that needs to be published once it has served its purpose?

Adrian Farrel (on chat): Archiving our work is helpful.

06) 10:20 | 10 min | Title: IETF Network Slice Application in 3GPP 5G End-to-End Network Slice

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-5g-network-slice-application/03/

Presenter: Luis Miguel Contreras Murillo

No comments/questions

07) 10:30 | 10 min | Title:IETF Network Slice Controller and its associated data models

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-ns-controller-models/02/

Presenter: Luis Miguel Contreras Murillo

Vishnu Pavan Beeram: This is a WG adopted document that focues on the models at the SBI of the NSC, while the next document on the agenda is focusing on the models applicable at the NBI of the NSC; have you consider merging these two drafts?

Luis Contreras: It could make sense to do the merge.

08) 10:40 | 10 min | Title: Applicability of IETF-Defined Service and Network Data Models for Network Slice Service Management

Draft: https://datatracker.ietf.org/doc/draft-barguil-teas-network-slices-instantation/10/

Presenter: Luis Miguel Contreras Murillo

Poll #1: Is there interest in this topic?

Lou Berger: There is some support and interest in this work

Poll #2: Are there any objections to merging this work with the existing WG document (NS-controller-models)

Clarification (Poll #3 - Repolling #2): yes means that there is objection to merge and come to the mic explaining why

Daniel King: The only concern is that the WG document has progressed for some time and is relatively more mature and the merging effort might slow down the progress of this work.

Lou Berger: That is a helpful comment. There is some support for merging the documents (Poll #3). Discussion will continue on the mailing list.

09) 10:50 | 10 min | Title: IETF Network Slice Topology YANG Data Model

Draft: https://datatracker.ietf.org/doc/draft-liu-teas-transport-network-slice-yang/10/

Presenter: Aihua Guo

Poll #4: Transport slice yang - Is there interest in the topic?

Lou Berger: Positive but not overwhelming

Poll #5: Is the transport slice yang draft a good starting point for tackling this topic?

Lou Berger: Not much difference, maybe a few more with no opinion

Dhruv Dhody (chat): Suggest to move these comparisons (VN and NS relationship) to appendix if this works progresses.

Mohamed Boucadair(chat): They can even be removed once they achieve their objective: show how the draft complements or is better than the VN model

Dhruv Dhody(chat):I prefer appendix for a future reader who might have a questions on why VN type 2 was not used.

10) 11:00 | 10 min | Title: 5QI to DiffServ DSCP Mapping Example for Enforcement of 5G End-to-End Network Slice QoS

Draft: https://datatracker.ietf.org/doc/draft-cbs-teas-5qi-to-dscp-mapping/02/

Presenter: Krzysztof Szarkowicz

Greg Mirsky: Do you think you can sufficiently implement 3GPP network slices over an existing IP/MPLS without implementing an NRP selector?

Krzysztof Szarkowicz: Yes

Zafar Ali: Map to per hop behavior through DSCP is a good attempt. But then also you have routing in addition to satisfy your other intent on top of what QOS or per hop behavior can give you.

Jie Dong: Is the scope of the QoS mapping in this document within a specific network slice?

Krzysztof Szarkowicz: Scope is clarified in Slide 4.

David Black: The individual draft on TSV WG has expired; I have not seen any interest to revive this draft; Encourage this draft to be looked at as a standalone document.

Swamynathan Balasundaram: I think the grouping is a necessary condition but not sufficient to cater to the requirements.

Krzysztof Szarkowicz: Well, we have still 8 queues, so I need to map all 5QIs into 8 queues

Joel Halpern（chat）：It is not clear to me what it would mean for this to be a WG Informational draft. Such a status would seem to imply that the IETF is recommending this approach to 3GPP.

David Black: A liaison to 3GPP will be required if the WG intends to adopt this. Subir Das and Charles Eckel (on chat) support this view.

11) 11:10 | 10 min | Title: Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance

Draft: https://datatracker.ietf.org/doc/draft-poidt-teas-actn-poi-assurance/03/

Presenter: Paolo Volpato

Oscar de Gonzalez: Is the work expected to focus on the YANG data model at the MPI or is it expected to also extend the requirements of the communication between the NE and the controller?

Paolo Volpato: For sure we will look at the MPI but we can consider also the device, if needed.

Chaode Yu: I have a draft on resource PM which is applicable to IP and optical technologies and it could be applicable to this I-D

Paolo Volpato: Yes, you are welcome to send your contribution.

Italo Busi: Regarding the gaps on the device models, for optical networks most of them are vendor specific so we are not considering it in the scope of our analysis. For the IP domain, we can follow the same approach or analyse if there is any gap with standard IP device models.

Oscar de Gonzalez: Yes, we need to focus on the gaps and also on the communication between the components.

Adjourn 11:20