Optional: Note takers add your name here

Please take notes in-line with the corresponding slot below

Draft TEAS Agenda For IETF 115

Version: Oct 26, 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:

Recording: http://www.meetecho.com/ietf115/recordings#TEAS
YouTube:

Slot# Start Duration Information

1) 13:00 10 min Title: Administrivia & WG Status

Draft:

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

Draft: Many

Presenter: Chairs

Start time: 13:08

3) 13:20 10 min Title: Updated Common YANG Data Types for Traffic Engineering

Draft: https://datatracker.ietf.org/doc/html/draft-ietf-teas-rfc8776-update-01

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

Draft: https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-use-cases-01

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

Draft: https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-nbi-yang-03

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

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

Presenter: Luis M. Contreras

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

Draft: https://datatracker.ietf.org/doc/html/draft-contreras-teas-slice-controller-models-04

Presenter: Luis M. Contreras

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)

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

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

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

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

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

Draft: https://datatracker.ietf.org/doc/html/draft-srld-teas-5g-slicing-02

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

Draft: https://datatracker.ietf.org/doc/html/draft-dhody-teas-ietf-network-slice-mapping-02

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)

Draft: https://datatracker.ietf.org/doc/html/draft-dhody-teas-te-traffic-yang-03

Presenter: Dhruv Dhody

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

Draft: https://datatracker.ietf.org/doc/html/draft-bestbar-teas-yang-topology-filter-04

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

Draft: https://datatracker.ietf.org/doc/html/draft-mhmcsfh-ippm-pam-02

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.

Draft: https://datatracker.ietf.org/doc/html/draft-mix-teas-actn-poi-extension-00

Presenter: Gabriele Galimberti/Jeff 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