Optional: Note takers add your name here Please take notes in-line with the corresponding slot below # Draft TEAS Agenda For IETF 115 {#draft-teas-agenda-for-ietf-115} Version: Oct 26, 2022 ## Tuesday, November 8 2022 {#tuesday-november-8-2022} 13:00-14:300 Session II (London local time, UTC+0) Time Zone Converter: https://www.timeanddate.com/worldclock/converter.html?iso=20221108T130000&p1=1440&p2=136 Materials: https://datatracker.ietf.org/meeting/115/session/teas Note taking: https://notes.ietf.org/notes-ietf-115-teas Meetecho: https://meetings.conf.meetecho.com/ietf115/?group=teas&short=teas&item=1 Onsite tool: https://meetings.conf.meetecho.com/onsite115/?group=teas&short=teas&item=1 Audio stream: https://mp3.conf.meetecho.com/ietf115/teas/1.m3u Zuilip https://zulip.ietf.org/#narrow/stream/teas WG ICS: https://datatracker.ietf.org/meeting/115/sessions/teas.ics Session ICS: https://datatracker.ietf.org/meeting/115/session/29911.ics ## Available post session: {#available-post-session} Recording: http://www.meetecho.com/ietf115/recordings#TEAS YouTube: # Slot# Start Duration Information {#slot-start-duration--information} ## 1) 13:00 10 min Title: Administrivia & WG Status {#1-1300-10-min-title-administrivia--wg-status} ### Draft: {#draft} ### Presenter: Chairs {#presenter-chairs} (About incoming Liason Statements) Loa Anderson: regarding the one from ITU-T SG-15 I have talked with Scott Mansfield and he agreed on coordinating the response to that. All the WGs listed are expected to provide inputs to him. Scott Mansfield: if anyone has something related to OTN standardization just send me an email. Lou Berger: CCAMP has taken the lead on answering OTN related LS in the past, will need to coordinate who takes the lead on this one. ## 2) 13:10 10 min Title: WG Draft updates {#2-1310-10-min-title-wg-draft-updates} ### Draft: Many {#draft-many} ### Presenter: Chairs {#presenter-chairs-1} Start time: 13:08 ## 3) 13:20 10 min Title: Updated Common YANG Data Types for Traffic Engineering {#3-1320-10-min-title-updated-common-yang-data-types-for-traffic-engineering} ### Draft: https://datatracker.ietf.org/doc/html/draft-ietf-teas-rfc8776-update-01 {#draft-httpsdatatrackerietforgdochtmldraft-ietf-teas-rfc8776-update-01} ### Presenter: Italo Busi {#presenter-italo-busi} Start time: 13:13 Lou Berger: WRT slide 4 - there is no new process defined in NetMod, just an idea. So only really have on option. Italo: We'll go ahead with the bis approach. ## 4) 13:30 10 min Title: IETF Network Slice Use Cases and Attributes for the Slice Service Interface of IETF Network Slice Controllers {#4-1330-10-min-title-ietf-network-slice-use-cases-and-attributes-for-the-slice-service-interface-of-ietf-network-slice-controllers} ### Draft: https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-use-cases-01 {#draft-httpsdatatrackerietforgdochtmldraft-ietf-teas-ietf-network-slice-use-cases-01} ### Presenter: Luis M. Contreras {#presenter-luis-m-contreras} Start time: 13:20 Pavan: Title too much verbose. Suggestion: IETF Network Slice use cases and service attributes. ## 5) 13:40 20 min Title: IETF Network Slice Service YANG Model {#5-1340-20-min-title-ietf-network-slice-service-yang-model} ### Draft: https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-nbi-yang-03 {#draft-httpsdatatrackerietforgdochtmldraft-ietf-teas-ietf-network-slice-nbi-yang-03} ### Presenter: Reza Rokui {#presenter-reza-rokui} Start time: 13:27 Adrian Farrel: Struggled to understand what the peer-sap-id is doing on the YANG model. The customer does not care what is inside the SDP. Reza Rokui: If customer does not care, it is not necessary to specify that. Adrian Farrel: I should have said, "The customer must not care what is on provider side." Ryan Hofman: The attachment circuit is related to physical attributes. When you deploy virtual functions (e.g., UPF in 5G) it could be useful to understand where those functions are. Adrian Farrel: I will sit down with Ryan and draw this. What I heard Ryan say was that he wants to be able to place the SDP in different places for virtual functions. I don't see why a different SAP is needed. Daniele Ceccarelli (from the chat): The SAP seems to me to be the SDP simply places on the PE instead of the SDP Dhruv Dhody (from the chat): SAP is defined per node in OPSAWG draft (https://datatracker.ietf.org/doc/draft-ietf-opsawg-sap/) Med Boucadair (from the chat): The value of having peer-sap-id (which is set to something that points to a CE/NF/etc.) is to ease request correlation, and thus, identification where to graft the service at the PE side. Med Boucadair (from the chat): There is a sap information grouping that can be used outside a node, if needed. Eduard Vasilenko: is the model suitable for assurance (closed loop control, etc)? Two choices: (1) augment existing YANG model, (2) a brand new model. Reza Rokui: Assurance is related to the model. Please, take a look at the model. Kireeti Kompella: I would suggest opaque correspondance between SDPs in CE and PE sides. Pavan Beeram: TE model provides information that basic topology does not have. It could be used while we do not specify the technology-related details. Joel Halpern: with respect to "connection group" - Different descriptions for the same concept in this document and in framework. Reza Rokui: Connection group concept is not in the framework, for the rest we use the terminology on framework document. Joel Halpern: if the concept is useful it should be then in the framework document. Italo Busi: why do you need opaque attribute definition? It can cause interoperability problems. Dhruv Dhody: the motivation for using opaque attributes is to avoid to change the model every time that a new parameter is needed. This is a common practice (RFC8876). If we want a single technology-agnostic this way avoid further augmentation for IP, OTN, etc. Italo Busi: Maybe we can split as we did for TE topology between a generic model and an augmentation for any technology-specific case. With augmentation the user can know what kind of configuration is supported or not (e.g., IP augmentation). Aihua Guo: with opaque attributes we will not be able to validate the attribute value with the YANG schema. Furthermore in case of complex attributes beyond a single value, it is difficult to capture them with a simple list. Lou Berger: It would be good to bring in this in early YANG Doctor review. Hard validation with opaque approach, it is more convenient to move towards automated validation of attributes. There are cases where we do augmentations for different technologies. Oscar Gonzalez: in L3SM we faced similar problems. For example for BGP peering we put the structure with the minumum set of parameters to be agreed among parties. A collection of opaque values may not fit all the cases. Dhruv Dhody: at the time of defining the model was to keep technology-agnostic as much as possible. If the WG feedback is to have more technology-related details we can be more explicit. Adrian Farrel (from the chat): On the SAP/SDP/AC debate, I find myself thinking that if the SDP is on the AC it is easy - everything is the same. If the SDP is in the PE, then there is the need to instruct the PE how to classify traffic into the SDP - this might be using the AC or some flowspec. If the SDP is in the CE then traffic is already in the slice when it reaches the PE and (presumably) a slice identifier is used. Of course, in this latter case, the realisation of the slice (slice network model) might indicate a different AC used as traffic for different slices is carried from CE to PE. ## 6) 14:00 10 min Title: Instantiation of IETF Network Slices in Service Providers Networks {#6-1400-10-min-title-instantiation-of-ietf-network-slices-in-service-providers-networks} ### Draft: https://datatracker.ietf.org/doc/html/draft-barguil-teas-network-slices-instantation-05 {#draft-httpsdatatrackerietforgdochtmldraft-barguil-teas-network-slices-instantation-05} ### Presenter: Luis M. Contreras {#presenter-luis-m-contreras-1} Start time: 14:02 Pavan Beeram: there are several network slice instantiation documents. We would like to request to the authors of those documents to see the opportunity of merging existing documents if possible. Lou Berger: this is a general comment, not particular for this document. ## 7) 14:10 10 min Title: IETF Network Slice Controller and its associated data models {#7-1410-10-min-title-ietf-network-slice-controller-and-its-associated-data-models} ### Draft: https://datatracker.ietf.org/doc/html/draft-contreras-teas-slice-controller-models-04 {#draft-httpsdatatrackerietforgdochtmldraft-contreras-teas-slice-controller-models-04} ### Presenter: Luis M. Contreras {#presenter-luis-m-contreras-2} Start time: 14:08 Joel Halpern: I'm concerned about standardadizing how mapper and realizer components are related. This constrains the implementation of the NSC. Luis Contreras: the idea in the document is to describe how to use the different models. We think it is necessary to have a kind of guidance on how to use the different models and how they are related. Going further and standardizing a single or fixed manner of doing that is not the purpose. Lou Berger: this is an informational document, not prescriptive. Luis Contreras: will add some text reflecting that this is just descriptive information. Dhruv Dhody: Not clear to me the relation of this document and the previous one. Separation seems arbitrary. Luis Contreras: this one is a zoom on the internals of the NSC, while the other looks at the boundaries (North and South) of the NSC. Poll: IS THERE INTEREST IN THIS WORK (CONTROLLER-MODELS) – RAISE HANDS FOR YES, NOT FOR NO/NOT YET, DON’T RESPOND IF DON’T CARE about 1/3 of the room responded, vast majority said yes a few said no Lou Berger: clear interest in this document. chairs will discuss adoption after this meeting or after next version/meeting. ## 8) 14:20 10 min Title: A YANG Data Model for Network Resource Partition (NRP) {#8----1420-10-min-title-a-yang-data-model-for-network-resource-partition-nrp} ### Draft: https://datatracker.ietf.org/doc/html/draft-wd-teas-nrp-yang-02 {#draft-httpsdatatrackerietforgdochtmldraft-wd-teas-nrp-yang-02} ### Presenter: Bo Wu {#presenter-bo-wu} Start time: 14:19 Pavan Beeram: Regular sync ups between authors of both NRP-related documents, trying to merge them. There is still some work to be done, targeting a common document for next meeting. Break 14:30 ## Tuesday, November 8 2022 {#tuesday-november-8-2022-1} 15:00-16:00 Session III (London local time, UTC+0) Time Zone Converter: https://www.timeanddate.com/worldclock/converter.html?iso=20221108T150000&p1=1440&p2=136 Materials: https://datatracker.ietf.org/meeting/115/session/teas Note taking: https://notes.ietf.org/notes-ietf-115-teas Meetecho: https://meetings.conf.meetecho.com/ietf115/?group=teas&short=teas&item=2 Audio stream: https://mp3.conf.meetecho.com/ietf115/teas/2.m3u Zuilip https://zulip.ietf.org/#narrow/stream/teas WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=teas Session ICS: https://datatracker.ietf.org/meeting/115/session/29912.ics Available post session: Recording: http://www.meetecho.com/ietf115/recordings#TEAS YouTube: Slot# Start Duration Information ## 9) 15:00 10 min Title: IETF Network Slice Application in 3GPP 5G End-to-End Network Slice {#9-1500-10-min-title-ietf-network-slice-application-in-3gpp-5g-end-to-end-network-slice} ### Draft: https://datatracker.ietf.org/doc/html/draft-gcdrb-teas-5g-network-slice-application-01 {#draft-httpsdatatrackerietforgdochtmldraft-gcdrb-teas-5g-network-slice-application-01} ### Presenter: Xuesong Geng {#presenter-xuesong-geng} Start time: 15:00 quick poll: ANY OBJECTIONS FOR ADOPTION (SLICE-APPLICATION)? RAISE HANDS FOR OBJECT TO ADOPTION, LOWER HAND FOR HAVE READ DOCUMENT AND READY FOR ADOPTION, NO VOTE = HAVE NOT READ not really sufficient time to conduct a proper time - few responded, slightly less than half of respondents objected. Lou Berger: not really enough time for a good poll (but still shows need for more work) ## 10) 15:10 10 min Title: A Realization of IETF Network Slices for 5G Networks Using Current IP/MPLS Technologies {#10-1510-10-min-title-a-realization-of-ietf-network-slices-for-5g-networks-using-current-ipmpls-technologies} ### Draft: https://datatracker.ietf.org/doc/html/draft-srld-teas-5g-slicing-02 {#draft-httpsdatatrackerietforgdochtmldraft-srld-teas-5g-slicing-02} ### Presenter: Julian Lucek {#presenter-julian-lucek} Start time: 15:12 Xuesong Geng: Valid document. Possible overlap with the previous draft. Suggestion to cooperate together or coordinate. Julian Lucek: certainly yes. Pavan Beeram: Motivation of the documents is different. Jie Dong: This document present one option of realization, there are others. Suggestion to include the limitations of existing technologies (e.g. for critical services) in the document. 5G-SLICING: INTEREST IN HEARING MORE ABOUT THIS TOPIC? RAISE HANDS = YES, LOWER HANDS FOR NO/WRONG DIRECTION, NO RESPONSE = DON'T CARE About 25% responded, majority showed interest ## 11) 15:20 10 min Title: IETF Network Slice Service Mapping YANG Model {#11-1520-10-min-title-ietf-network-slice-service-mapping-yang-model} ### Draft: https://datatracker.ietf.org/doc/html/draft-dhody-teas-ietf-network-slice-mapping-02 {#draft-httpsdatatrackerietforgdochtmldraft-dhody-teas-ietf-network-slice-mapping-02} ### Presenter: Dhruv Dhody {#presenter-dhruv-dhody} Start time: 15:22 Pavan Beeram: You mention you don't want to augment the TE service mapping model, is this because the technology-agnostic approach? Dhruv Dhody: Keep slicing case as separated document to not blocking the progress of TE service mapping. Additionally, NRP concept is only related to slice case. Pavan Beeram: with the augmentation from the slice service model, why don't consider to move this to the service model itself? Dhruv Dhody: putting this on the NBI would require the description of an NRP model. It makes more sense to keep them separated. Sergio Belotti: if you use augmentation of NBI model the prefix is ietf-nss not ietf-ns Dhruv Dhody: I will fix it. ## 12) 15:30 10 min Title: Traffic Mapping YANG model for Traffic Engineering (TE) {#12-1530-10-min-title-traffic-mapping-yang-model-for-traffic-engineering-te} ### Draft: https://datatracker.ietf.org/doc/html/draft-dhody-teas-te-traffic-yang-03 {#draft-httpsdatatrackerietforgdochtmldraft-dhody-teas-te-traffic-yang-03} ### Presenter: Dhruv Dhody {#presenter-dhruv-dhody-1} Start time: 15:30 Charles Eckel: in SD-WAN cases in MEF, it is usual to have an application id for classifying application traffic. Dhruv Dhody: please, send me the link. Lou Berger: possible sinergy with ACL discussion in Netmod about classification. Suggestion to look to ACL document to check for sinergies. Charles Eckel (from the chat): The MEF SD-WAN spec I mentioned at mic is MEF 70.1 https://www.mef.net/wp-content/uploads/MEF\_70.1.pdf (see Section 8, Application Flows and Policies) Med Boucadair (from the chat): Here is the draft about revised ACL: https://datatracker.ietf.org/doc/draft-dbb-netmod-acl/ ## 13) 15:40 5 min Title: YANG Data Model for Topology Filter {#13-1540-5-min-title-yang-data-model-for-topology-filter} ### Draft: https://datatracker.ietf.org/doc/html/draft-bestbar-teas-yang-topology-filter-04 {#draft-httpsdatatrackerietforgdochtmldraft-bestbar-teas-yang-topology-filter-04} ### Presenter: Vishnu Pavan Beeram {#presenter-vishnu-pavan-beeram} Start time: 15:38 Jie Dong: Is this topology filter applicable to perform TE or centralizaed path computation using filters as constraints? Can it be applied to multi-topology or flex algo? Can you clarify? Pavan Beeram: we can discuss this in the document Poll: INTEREST IN HEARING MORE ABOUT THIS TOPIC? RAISE HANDS = YES, LOWER HANDS FOR NO/WRONG DIRECTION, NO RESPONSE = DON'T CARE About 1/3 responded. Most rasied hands, but a good number did not Lou Berger: While there is interest in the work, some in the WG are not convinced. ## 14) 15:45 10 min Title: Precision Availability Metrics for SLO-Governed End-to-End Services {#14-1545-10-min-title-precision-availability-metrics-for-slo-governed-end-to-end-services} ### Draft: https://datatracker.ietf.org/doc/html/draft-mhmcsfh-ippm-pam-02 {#draft-httpsdatatrackerietforgdochtmldraft-mhmcsfh-ippm-pam-02} ### Presenter: Greg Mirsky {#presenter-greg-mirsky} Start time: 15:43 No time for comments. ## 15) 15:55 5 min Title: Applicability of ACTN to Packet Optical Integration (POI) extensions to support Router Optical interfaces. {#15-1555-5-min-title-applicability-of-actn-to-packet-optical-integration-poi-extensions-to-support-router-optical-interfaces} ### Draft: https://datatracker.ietf.org/doc/html/draft-mix-teas-actn-poi-extension-00 {#draft-httpsdatatrackerietforgdochtmldraft-mix-teas-actn-poi-extension-00} ### Presenter: Gabriele Galimberti/Jeff Bouquier {#presenter-gabriele-galimbertijeff-bouquier} Start time: 15:55 Pavan Beeram: Did you think about merging this with the WG adopted ACTN poi document? Gabrielle Galamberti:The draft is still 00 version, we are working as design team in the context of POI to progress and get feedback on the proposal. Need to check. # Adjourn 16:00 {#adjourn-1600}