Please help capture the discussion in-line below.
No need to cover what is on the slides, just the discussion.
Please also (optionally) add you name here:
Adrian Farrel (doing his best)
Luis Contreras (reviewed from the recordings)
Version: Mar 08, 2022
12:00-13:00 Afternoon Session I (UTC) and 13:30-15:30 Afternoon Session II (UTC)
Time Zone Converter: https://www.timeanddate.com/worldclock/converter.html?iso=20220323T120000&p1=1440
Materials: https://datatracker.ietf.org/meeting/113/session/teas
Note taking: https://codimd.ietf.org/notes-ietf-113-teas
Meetecho: https://meetings.conf.meetecho.com/ietf113/?group=teas&short=&item=1
Audio stream: https://mp3.conf.meetecho.com/ietf113/teas/1.m3u
Jabber: xmpp:teas@jabber.ietf.org?join
WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=teas
Session ICS: https://datatracker.ietf.org/meeting/113/sessions/teas.ics
Recording: http://www.meetecho.com/ietf113/recordings#TEAS
Jabber log http://jabber.ietf.org/logs/teas
YouTube:
Draft:
Presenter: Chairs
Draft: Many
Presenter: Chairs
Lou Berger: To AD. Liaison from ETSI arrived as email rather than via formal liaison.
John Scudder: We’ll check with Liaison Manager.
Robin Li: IETF has no formal relationship with ETSI. Need to go to IAB’s liaison coordinator. Without formal liaison there is no responsibility of responding such liaison email.
(FYI : https://www.ietf.org/about/liaisons/ does not list ETSI)
Pavan Beeram: For document status, go through the slides in your own time and ask questions on list.
Draft: https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-poi-applicability-06
Presenter: Daniel King
Dhruv Dhody: Why limit to SR-TE only. Is SR-TE an example, or is scope limited to SR-TE.
Dan King: The authors had a requirement to include SR-TE. Haven’t seen specific requirements for other technologies.
Dhruv Dhody: How about saying SR-TE is “an example” and then other technologies will come easily.
Dan King: SR-TE needs a lot of options and details. But authors will try to highlight support of other technologies, referring SR-TE as the example that authors use in the draft.
Lou Berger: Good comment. SR-TE wasn’t the main technology during adoption. (SR-TE was mentioned just once and RSVP-TE was mentioned just once)
Daniele Ceccarelli: To Dhruv. Is your concern TE versus non-TE, or about SR?
Dhruv: Should also allow RSVP-TE, etc. ACTN-POI should not be limited to SR-TE.
Italo Busi: Problem is there are so many options. Authors are affraid that there will be too many cases to analyse. If people are interested in other technologies we could do that (expanding this document or in another one).
Pavan Beeram: The ideal scenario would be to describe the procedures in a path-control-technology (RSVP/SR) agnostic way and then add technology specific examples wherever there is a deviation.
Draft: https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-08
Presenter: Adrian Farrel
Additional material that turned up too late to go on the slides, but as spoken by the presenter…
-09 to be posted immediately after the meeting
Further change planned for -09 (beyond what is on the slides)
As described on the mailing list: an extra sentence will be
added to Section 4.1.2 (SLEs) to mention that realisation may
be an SLE, especially in the case of multicast. Thus, a
customer may have a way to ask the provider to deliver the
service using specific tools. Of course, the customer may
have no way to know whether this is actually done.
This is text that was in -07 (somewhere else in the document)
and got lost in the editorial tidy-up.
(on “Recent discussions on the list” slide)
Daniele Ceccarelli: Several question were raised in CCAMP mailing list such as 5G being unique use case or not for slicing, and if there is a limitation of slicing only to IP/MPLS. These have been extensively discussed. There were other questions that can be summarized from CCAMP to TEAS. We in CCAMP are satisfied with the answers we received so far.
Lou Berger: if you are satisfied with the answers there is no much to discuss.
(on “Worked examples” slide)
Luis Contreras: there are other docs that cover examples, one of them is being presented later in the day; not sure if it is needed in this document
Kiran Makhijani: willing to write examples if needed. There are too many things in the framework so may need multiple examples
Reza Rokui: examples are needed, and can help with a section on 5g.
Luay Jalil: (From chat) @adrian I can help with examples if needed but I’m of the other opinion to keep examples out of this draft
From Adrian:
Issues recently opened on the list and not yet resolved. (Thanks
to everyone for reading the draft and raising issues and concerns.)
A service is not the realisation. This is Adrian’s usual rant
about how our naming of “L3VPN” has confused the service delivered
to the customer with the technology used to realise the service.
Since this point keeps coming up, should we include a brief
piece of text on the subject?
Is an SDP a SAP?
Receiver SLOs
Still a very active debate on the list.
Do we need “group SLOs” that describe the SLO of a set of connectivity
constructs? I.e., not the same SLO that applies to each construct, but
an SLO that applies to the collection of constructs.
What extra text do we need on multiplexing?
This thread is at an early stage and I still need to understand what
is being multiplexed over what, where.
Wim Henderickx: point on multiplexing - relization should be presented in an abstract way before going into technology specifics. Does this need to be in it’s own document.
Reza Rokui: valid idea, lets discuss on the list
Dhruv Dhody: (from chat) @wim - For details about realisation, draft-contreras-teas-slice-controller-models could be a good place
Jie Dong: (from chat) regarding the realization of IETF network slices, draft-ietf-teas-enhanced-vpn describes a layered architecture and a set of candidate technologies.
Draft: https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-nbi-yang-01
Presenter: Reza Rokui
Kireeti Kompella: Make the service API technology agnostic. In the NBI I would prefer to refer to the layer of the access (i.e., layer-2 / layer-3) as opposed to VPN type (i.e., for layer-2 it could be vlan, VPLS, E-VPN, etc). In the SBI then it can be said to realize it as e.g. VPLS.
Reza: Yes. Adrian made the same point, that the document should be technology agnostic as possible.
Kireeti Kompella: On second open issue about common YANG model. If you can reuse is great, but it could require to be extended.
Kireeti Kompella: On the diagram with three types of connections on the same slice (blue, green and red). Can some SLOs being put together for all the three?
Reza Rokui: it would become more complex logic. Better to keep them separated.
Kireeti Kompella: Should desire for protection in the underlay paths an interesting SLO to be requested in the service API?
Reza Rokui: This is a question for the framework document. It would be probably an SLE. This document imports what is in the framework document.
Greg Mirsky: Protection is something should be left to the operator
Draft: https://datatracker.ietf.org/doc/html/draft-busi-teas-te-types-update-01
Presenter: Italo Busi
Lou Berger: two options were suggested by NETMOD. The first was a bis with only fully modules defined, without requiring new tooling. The second is practically suggesting to update in a separate document only the module that has been touched by the modification. No RFC-bis needed - just have an update with the full module (without requiring new tooling also in this case).
Italo Busi: The plan is to follow the suggestion for the second option (update).
Draft: https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet-08
Presenter: Tarek Saad
[no comments]
Draft: https://datatracker.ietf.org/doc/html/draft-liu-teas-transport-network-slice-yang-05
Presenter: Xufeng Liu
Pavan Beeram: We have a service model already adopted. You are presenting another model you clai complement the other. Can you talk about the relationship among them?
Xufeng Liu: This model can be used as service model supporting topology-aware services. You can have some middle abstract nodes specified by the user.
Greg Mirsky: The connections considered, are bidirectional or unidirectional?
Xufeng Liu: They are unidirectional
Greg Mirsky: there are several tyes of constructs, probably richer description could be required
Tarek Saad: MP2MP not clear. Could it be modelled with a set of P2MP constructs? Take it offline.
Tarek Saad: Framework draft only talks about slice demarcation points. Here, you can have nodes which are not endpoints in the topology. Should the frmaework document describe that?
Xufeng Liu: That would be my preference, we need to think about that.
Dhruv Dhody: In VN the followed was adding a reference to topo model, not augmenting. Is this the proper way? Could not be the NBI slice model augmented with a reference to the TE topology model?
Xufeng Liu: ACTN for type 2 uses TE topology model directly.
Dhruv Dhody: they use it as a reference, not as an augmentation of the TE topology model.
Xufeng Liu: I don’t see how reference point is easily doable from the current status of the NBI model development.
Dhruv Dhody: A cleaner solution would be to have the IETF NEtwork Slice as an independent model and then use the TE service mapping approach to add a reference to the topology
Bo Wu (from the chat): This model has YANG namespace conflict. It is suggested using another namespace. Current WG network slice service model use ietf-network-slice namespace.
Lou Berger: suggested to continue the discussion on the mailing list.
Draft: https://datatracker.ietf.org/doc/html/draft-contreras-teas-slice-nbi-06
Presenter: Luis M. Contreras
Dhruv Dhody: Any suggestions for the framework and Yang model based on this work?
Luis Contreras: Yes. For the framework, procedures that could be required for the slices. For the NBI, it should identify SLOs and SLEs as identified for the use cases reported.
Charles Eckel: interesting draft, will review and provide feedback on list
Tarek Saad: For the NFV use case can applications be identified
Luis Contreras: focusing on connectivity. Could be an option to complement the use case.
Lou Berger: there is clear interest in the document. Hope to see more discussion in the list. Interested to hear if there are objecttions in adoptng this work.
Draft: https://datatracker.ietf.org/doc/html/draft-dong-teas-nrp-scalability-01
Presenter: Jie Dong
Tarek Saad: Diagram on slide 2 don’t mention VTN. Do you yet feel the need of mentioning of VTN in relation with NRP in the document?
Jie Dong: The relationship between VTN and NRP is described in the VPN+ framework. In this document we have change the terminology from VTN to NRP.
Lou Berger: we’d like to allow some time for on-list discussion before polling for adoption
Draft: https://datatracker.ietf.org/doc/html/draft-bestbar-teas-yang-nrp-policy-00
Presenter: Tarek Saad
[no comments]
Draft: https://datatracker.ietf.org/doc/html/draft-wd-teas-nrp-yang-00
Presenter: Bo Wu
Greg Mirsky: can you give an example of link specific resource?
Bo Wu: Network wiede resources mean that almost every link has e.g. same BW resoruces like 100 Mbps, while link specific would meam that one link has 500 Mbps. It is NRP-related, not specific to a certain slice service.
Tarek Saad: As clarification, the NRP policy draft covers bandwodth reservation, as well as data plane ID and the topology associated with NRP. Question: do you want to use the topology model to configure or provision a device?
Bo Wu: This model cannot support device configuration. This model is a network model. IN the future we can consider if it can be used for device.
Tarek Saad: the attributes listed in the slide will be required to be configured in the device.
Bo Wu: agree.
Draft: https://datatracker.ietf.org/doc/html/draft-barguil-teas-network-slices-instantation-03
Presenter: Luis M. Contreras
Pavan Beeram: How does this draft is relate to draft-ietf-teas-applicability-actn-slicing? The ACTN applicability document recommends the use of the same set of data models specified in this draft.
Luis Contreras: there are commonalities. ACTN is an exampe fo how to realize this approach with an specific architecture. We intend to be more generic. We can go with ACTN or with any other solution.
Dhruv Dhody: maybe you could also add reference to the IETF Network Slice Service Mapping to TE in your list of YANG models Link
Draft: https://datatracker.ietf.org/doc/html/draft-contreras-teas-3gpp-ietf-slice-mapping-00
Presenter: Luis M. Contreras
Wim Henderickx: we should try to influence what paramerts are defined / exposed by 3GPP, not just use what they provide
Xuesong Geng: We have a similar document (audio not working from that point on). (From the chat: I will take the question to the list)
Draft: https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network-slicing-02
Presenter: Robin Li
Lou: please use the list for questions, no time.
Lou Berger: Please also address comment from last session; This is a super short document with 2-3 pages. (look what is missing from existing framework document and propose text there, rather than having a standalone document.)
Draft: https://datatracker.ietf.org/doc/html/draft-dong-teas-hierarchical-ietf-network-slice-01
Presenter: Jie Dong
[no comments]
Draft: https://datatracker.ietf.org/doc/html/draft-ma-teas-ietf-network-slice-deployment-00
Presenter: Zhibo Hu / Jie Dong
Lou Berger: Interesting to see this in IETF.
Tianji Jiang: From the cases reported, are real cases alredy deployed?
Jie Dong: They are real deployments.