TEAS Minutes For IETF 118

Friday, November 10, 2023

13:00-15:00 Central European Time - Prague (11:00 - 13:00 UTC)
Materials: https://datatracker.ietf.org/meeting/118/session/teas
Note taking: https://notes.ietf.org/notes-ietf-118-teas
Zuilip https://zulip.ietf.org/#narrow/stream/teas
WG ICS: https://datatracker.ietf.org/meeting/118/session/31617.ics
Video: https://www.youtube.com/watch?v=wzg1IJgQYqU
Chat log: https://datatracker.ietf.org/meeting/118/materials/chatlog-118-teas-202311101530-00

Available post session:

Recording: https://play.conf.meetecho.com/Playout/?session=IETF118-TEAS-20231110-1200
YouTube: https://www.youtube.com/watch?v=wzg1IJgQYqU

Slot# Start Duration Information

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

Presenter: Chairs

02) 13:10 10 min Title: WG Draft updates

Draft: WG Drafts (not on agenda)

Presenter: Chairs

WRT: https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/

Poll (18:00): Can you live with dropping the VTN term and using NRP in its place?

RESULT: Unanimous among those who participated.

[Ketan Talaulikar]: Suggest use NRP-based VPN term and drop 'Enhanced'

[Greg Mersky]: Any enhanced VPN solution will ber NRP-based, suggest drop 'Enhanced'.

[Ketan Talaulikar]: From my review, the draft covers NRP-based VPN.

[Jie Dong]: Perfer Enhanced VPN

Poll: Do you prefer Enhanced VPN (YES) or NRP-based VPN (NO)?

RESULT: Fairly even, but NRP-based is slightly prefered. Will be discussed more on list.

[Rakesh Gandhi]: Enhanced VPN can be confused with EVPN, suggest avoiding this confustion

03) 13:20 10 min Title: A YANG Data Model for Virtual Network (VN) Operations

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-actn-vn-yang-21

Presenter: Dhruv Dhody

Italo Busi: Not clear if we need VN Type. Let's go through a use case example to see.

[Dhruv Dhody]: We got a similar comment from Tom Petch but this I-D is about VN and not on how to use TE topology so there is an example but quite simple

Italo Busi: I think we can make a simple example with 3 or 4 nodes and just identifiers but it would be good to show the workflow

[Dhruv Dhody]: I think what you need is already in the draft, please check it.

Italo Busi: Let's check offline.

[Rob Wilton]: Agee, examples belong in an appendix.

[Oscar Gonzalez]: It's interesting that there are some boubts in how to use this model

[Dhruv Dhody]: This is a fundamental model. So we need to make sure that, like, you know, we have clarity on this. And if there is some good example that the working group agrees, we can make it available.

[Visnu Pavan Beeram]: There was an example draft that we can revive or take from.

04) 13:30 10 min Title: Common YANG Data Types for Traffic Engineering

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

Presenter: Italo Busi

[Lou Berger]: (as contributor): I think the appendix is quite useful

[Oscar Gonzalez]: Does the change impact TE tunnel

Italo Busi: Not significantly

[Tarek Saad]: As coauthor on TE tunnel, I am fine with the proposed modification to TE tunnel.

[Oscar Gonzalez]: There is more changes needed.

[Lou Berger]: We will last call once the changes are available.

05) 13:40 10 min Title: A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-34

Presenter: Tarek Saad

[Lou Berger]: The deadline for WG LC was set to last friday to discuss them during this meeting. We are receiving WG LC comments this week and it is better to address them before the IETF last call. Authors please inform the WG once the draft is updated and summarize what changes have been done to address WG last call comments. If the changes are not significant, we will progress with Publication Request without a 3rd WG last call.

06) 13:50 10 min Title: A YANG Data Model for requesting path computation

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-path-computation-21

Presenter: Sergio Belotti

[Chaode Yu]: In CCAMP WG I have raised some discussion points and requirements related to service path computation and for enhancements to OTN tunnel path computation so would like to better align the drafts in the future.

[Vishnu Pavan Beeram]: The changes are needed in CCAMP or in this draft?

[Chaode Yu]: We need to have the discussion to determine what is needed.

[Vishnu Pavan Beeram]: We are in the middle of the 2nd WG last call, please let us know asap if there are changes needed on this document.

07) 14:00 15 min Title: A YANG Data Model for the IETF Network Slice Service

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

Presenter: Reza Rokui

[Bo Wu]: From the discussions with Med I think the "per-CoS" actually is also technology-agnostic. Its class of service can be used to define it. As coauthor of the draft I can accept that. We can see if there is some method to simplify the definition. We would like to hear feedback from the working group wethere there is some bad aproach to model that.

[Reza Rokui]: So, in summary you say it is a good idea to have "per-CoS", but wether or not we take the model exactly as proposed or with some revision is still a question.

[Krzysztof Szarkowicz ]: I second comments from Bo. For example, when we try to apply this to 5G slicing, one 5G slice can have multiple 5QIs. 5QI is the kind of QoS in the mobile network and if we like to map this to our network slice service model we need to have "per-CoS" capability and defining "per-CoS" limits.

[Luis Contreras]: My question is if this QoS has implications, not only in the SLO/SLEs but also on the match criteria to apply to the slices

[Reza Rokui]: When it goes to realization it as an effect. If you specify the northbound it goes all the way to realization and will have some effect.

[Reza Rokui]: As summary, it is a good idea to go with the green model (in screen the green model shows the proposal that also includes "per-CoS") and next logical question is if it is a good idea to take exactly the same and put in our model or revise it. We will make a proposal and send it to the mailing list.

[Vishnu Pavan Beeram]: Please summarize the proposal on the list. The working group seems to be leaning towards an option.
It has been a long road and we appreciate the effort.

[Dhruv Doddy]: Check the name (RFC XXX) in the documenbt

[Reza Rokui]: Hope that when this document becomes RFC the framework will already have a number.

08) 14:15 10 min Title: Scalability Considerations for Network Resource Partition

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

Presenter: Jie Dong

[Lou Berger]: I think this is the first document that uses "RFC XXX Network slices". It says we can refer tho these as that. I'm not sure that's a great way to do it and reading the text it looks cumbersome. As a working group we need to figure out if we're going to have a short name for what the framework describes as "Network slices built using IETF technologies". Its a mouthful, but "RFC XXX Network slices" is awkward and not necessarily understandable. We need to grapple that in the working group and see if it makes sense to use XXX.

[Luis contreras ]: I was wondering if this scalability issues leads to some work in the benchmarking working group or find a way to benchmarking the scalability of the different options and solutions, because somehow you are putting there a kind of framework for comparing scalabilty, so it might be interesting to have some ideas on how to benchmark this.

[Jie Dong]: Good suggestion. We can take a look wether wee need to coordinate with Benchmarking working group.

[Rob Wilton]: Can you put the reference in the terminology section so that network slice means this in the document (without RFC XXX)?

[Adrian Farrel]: It's good to hear an AD say that, because we are only doing this because our ADs have told us to do this. Lou, don't ask non-native speakers to review the text and decide if it feels good or not.

[Lou Berger]: I meant to say whether it adds value. We can do the review offline.

[Vishnu Pavan Beeram]: I sent earlier an email with the work being done by other working groups related to NRPs. The only ask that we have at this point is for these document (in the other WGs) to ahve a scalabilily consideration section that talks about the impact of that particular extension or feature on scalability in the network and to keep this group updated about their work.

09) 14:25 15 min Title: A Realization of RFC XXXX Network Slices for 5G Networks Using Current IP/MPLS Technologies

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

Presenter: Krzysztof Szarkowicz

[Vishnu Pavan Beeram]: Thanks for working with the authors of the other drafts and making sure the scopes are clarified in both documents. That was useful.

10) 14:40 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-02

Presenter: Luis M. Contreras

[Krzysztof Szarkowicz]: I wanted to comment here on 3GPP as well. From release 18.5 3GPP includes the reference to the attachment circuit draft, so it is officially referencing, even though they are still individual drafts from IETF perspective. 3GPP acknowledges that it is important, so they reference the draft in their schema. ORAN as well is referencing this draft.

[Greg Minsky]: I was wondering if it is possible that we have a more formalized and organized way of communicating with 3GPP and ORAN using Liasion? because that would be more definitive, not only on this subject but in general.

[Vishnu Pavan Beeram]: We sent out a formal liaison to 3GPP and various other standard bodies about Network slicing related work. We haven't received any answer back.

[Greg Minsky]: My understanding was for 3GPP release 19 work they will approach QoS modelling, so it seems we are ahead of them. There might be a risk that we define something that will not be used.

[Vishnu Pavan Beeram]: We will keep sending updates.

[Krzysztof Szarkowicz]: I wanted to commment on the liason with my O-RAN hat on. We received the liaison from IETF at ORAN alliance and we probably will issue a liason back to IETF with current status of slicing in our alliance.

11) 14:50 10 min Title: A YANG Data Model for Network Resource Partitions (NRPs)

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

Presenter: Bo Wu

Adjourn 15:00

[Lou Berger]: In this merged version you referet to PHB, per-behaviour profiles. Where are those defined? Where do you expect them to be defined?

[Bo Wu]: I think for PHB profile it's similar like a QoS policy profile, so we can add more text.

[Lou Berger]: They were previously defined in draft-bestbar document wich you derive from, but in this version there is no definition, so either you need to reference where it is defined or bring that definition forward, because now it is hanging. You don't need to have any incomplete definitions. Just bring in the definition or the reference.

Friday, November 10, 2023

15:30-17:00 Central European Time - Prague (13:30 - 15:00 UTC)
Materials: https://datatracker.ietf.org/meeting/118/session/teas
Note taking: https://notes.ietf.org/notes-ietf-118-teas
Zuilip https://zulip.ietf.org/#narrow/stream/teas
WG ICS: https://datatracker.ietf.org/meeting/118/session/31618.ics

Available post session:

Recording: https://play.conf.meetecho.com/Playout/?session=IETF118-TEAS-20231110-1430
Video: https://www.youtube.com/watch?v=AwuNUVOsffs

Slot# Start Duration Information

-- 15:30 5 min Title: Intro (slides from slot 1)

Presenter: Chairs

12) 15:35 10 min Title: IETF Network Slice Topology YANG Data Model

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

Presenter: Luis M. Contreras

[Vishnu Pavan Beeram]: Given how the model is constructed, can someone pick this up and use it as a "network slice service model"?

[Luis Contreras]: This is not to be used as a stand-alone model; it complements the existing service model.

[Vishnu Pavan Beeram]: I understand that is not the intent, but does it open the door for this type of interpretation?

[Aihua Guo]: This model is complementary to the service model. A user may request a customized topology with SLOs/SLOs up-front if needed and then use the service model to request a network slice service referencing this customized topology.

[Vishnu Pavan Beeram]: Again, I understand the intent; but the way the model is put together, my concern is that it subsumes the service model.

Italo Busi: There is a distinction to be made between topology as a service and connectivity as a service; this model just caters to the notion of "topology as a service" and not to "connectivity as a service".

[Vishnu Pavan Beeram]: Let's take this to the list.

[Bo Wu]: Is this model defining the NRP topology?

[Luis Contreras]: I don't believe that is the case, but will look into it.

Italo Busi: Please revisit the discussion that we had when progressing RFC8453. The same arguments can be made to justify the need for this model.

[Oscar Gonzalez]: Couple of questions. (1) Is it possible for the customer to ask for a specific topology and for the provider to give something different than what was requested? (2) Is this request made just once at the beginning of the service request -- in other words is it expected to keep modifying the requested customized topology?

[Luis Contreras]: For the first question -- it is always customer driven; the provider specified topology is out of scope. For the second question, yes, it is possible for the customer to make modifications after the initial request is made.

[Dhruv Dhody]: Going back to Bo's question, this is not meant to be used for "NRP as a service". We should maybe add explicit text in the document to make this clear. Also agree with Italo's point about revisiting the ACTN discussion.

[Lou Berger]: It is clear that we need more discussion before we can consider this for WG adoption. Please continue the discussion on the list.

13) 15:45 10 min Title: Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE Use Cases

Draft: https://datatracker.ietf.org/doc/draft-busi-teas-te-topology-profiles-06

Presenter: Italo Busi

[Lou Berger]: One minor comment. The Geo-Location model is addressed elsewhere -- there is a standalone RFC for it; Drop it from this document.

[Oscar Gonzalez]: May be a reference to the standalone model is needed.

[Lou Berger]: With the model in the standalone RFC, we don't need the TE topology model to be used for Geo Location any more. From a TE topology profile standpoint, this can be dropped.

Poll Question 1: Is there interest in the topic?

[Lou Berger]: There seems to some reasonable interest; Wouldn't say it is overwhelming interest but there is reasonable interest.

Poll Question 2: Is this draft a good starting point for tackling this topic?

[Lou Berger]: About the same number that was interested in the topic, think that this draft is a good starting point. The chairs will discuss on where to go next with this document.

Italo Busi: We will drop the Geo-Location use-case in the next version.

[Lou Berger]: That can be done as part of the adoption call. Please do check the number of authors listed on the document and make sure it follows the guidelines

[Oscar Gonzalez]: It does look like we can add more use-cases to this.

14) 15:55 10 min Title: A YANG Data Model for MPLS-TE Topology

Draft: https://datatracker.ietf.org/doc/draft-busizheng-teas-yang-te-mpls-topology-06

Presenter: Italo Busi

Poll Question 1: Is there interest in the topic?

[Lou Berger]: About a quarter of the session participants have responded to the poll and all of them are supportive.

Poll Question 2: Is this draft a good starting point for tackling this topic?

[Lou Berger]: Same numbers as before. Everyone who is interested in the topic agree that this draft is a good starting point.

15) 16:05 10 min Title: A YANG Data Model for Bandwidth Availability Topology

Draft: https://datatracker.ietf.org/doc/draft-ietf-ccamp-bwa-topo-yang-01

Presenter: Scott Mansfield

[Oscar Gonzalez]: Is it correct to assume that this is information provided by the node (and not provisioned)?

[Oscar Gonzalez]: The fluctations in bandwidth availability in microwave networks is expected and there are probably other technologies where this could happen as well. From a TE path placement point of view, it would be important to take this information into account when computing and placing paths.

[Luis Contreras]: The draft is currently focused on microwave networks, the narrative in the draft can can be generalized. There is also a need to discuss at which layer this information is made available and what is the frequency at which this information is reported.

Scott Mansfield: Agree that there is some work needed to make this draft generic.

[Lou Berger]: There seem to be various other options for a home for this draft - IVY, MANET, TVR, RAW to name a few. We would need to have a discussion among the various chairs and the authors and determine an appropriate home for this.

[Lou Berger]: It may be useful to have all radio related parameters discussed in a single place.

[Oscar Gonzalez]: We may end up discussing this elsewhere, but it is some thing that TE systems would need to take into account (bandwidth availability or unavailability) when computing and placing paths.

[Lou Berger]: Agree that this is work that is needed; just need to figure out where it gets done. We would need to discuss with the relevant ADs.

16) 16:15 10 min Title: BGP SR Policy Extensions for Network Resource Partition

Draft: https://datatracker.ietf.org/doc/draft-dong-idr-sr-policy-nrp-04

Presenter: Jie Dong

[Vishnu Pavan Beeram]: As noted earlier (on the list), the chairs have stated the expectations for drafts from other WGs that are proposing NRP specific extensions. The authors of this draft have added a scalability section and have also introduced the WG to the TEAS WG. If there are any objections to this work, please do state those on the thread opened for this topic on the list.

[Dhruv Dhody]: With the PCE WG chair hat on, the same feedback is requested for the equivalent draft in PCE.

[Vishnu Pavan Beeram]: The thread opened on the list is for getting feedback on both the drafts (IDR and PCE).

Adjourn 16:25