Minutes IETF 107 Interim > > Session 1: April 23rd 2020 > > Slides: https://datatracker.ietf.org/meeting/interim-2020-teas-01/session/teas > Etherpad: https://etherpad.ietf.org:9009/p/notes-ietf-107-teas > WebEx https://ietf.webex.com/ietf/j.php?MTID=m916f47c946e087412962045dec6eae53 > Jabber: xmpp:teas@jabber.ietf.org?join > > Reminder webex chat is only for session info and queue control: Virtual Queue Control via Webex Chat: Type "+q" and "-q" to enter/leave > Times in UTC > # Start Len Information > 1 13:00 5 Title: Administrivia & WG Status > Draft: > Presenter: Chairs 13:05 > 2 13:05 5 Title: WG Draft updates > Draft: Many > Presenter: Chairs Adrian Farrel: re the PCECC use-cases draft: what do we do with this? Do we put something in datatracker to say what its status is so we don't have to keep coming back to it? Pavan Beeram: previous conclusion was keep it active as long as people want to discuss use cases; after that we can discuss again. 13:10 > 3 13:10 15 Title: RFC3272 Bis Design Team > Draft: > Presenter: Adrian Farrel https://datatracker.ietf.org/doc/slides-interim-2020-teas-01-sessa-3-rfc3272-bis-design-team/ Lou Berger (as contributor): I agree with the need for a short definition that other WGs can refer to. I've already provided one to another WG. What's the best way to send that to you? Adrian Farrel: email to me/design list, raw text is fine. Adrian Farrel: A thought for ADs: it's worth noting when we charter new WGs whose charter mentions TE, we need to define what does it mean when mentioning 'traffic engineering', or which part. Deborah Brungard: we did have that in the charter for tree engineering and that they had to collaborate with TEAS, and so they changed their definition Lou Berger: I think this is definitively necessary Pavan Beeram: adoption seems like the most viable option, so we can get that started Adrian Farrel: that's fine, but please be careful about the IPR poll. I you count all of the DT and original doc authors as contributors your poll will go on for a very long time. Lou Berger: we can assume that existing authors abide by IPR (for old work). Contributors for new work need to be polled; we'll have to defer to you and other authors to determine who they are. Traditionally the people who actually did real work are noted as authors/contributors, and other DT members go in acknowledgments (or are left out entirely) 13:28 > 4 13:25 50 Title: Network Slicing Design Team > Draft: > Presenter: Jari Arkko, Kiran Makhijani, Eric Gray https://datatracker.ietf.org/doc/slides-interim-2020-teas-01-sessa-4a-ns-dt-introduction/ (discussion after definition presentation) https://tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-02 https://datatracker.ietf.org/doc/slides-interim-2020-teas-01-sessa-4b-network-slicing-design-team-definitions/ Joel Halpern: I appreciate the DT's effort, but there's serious problems with the doc as is. Your description of SLOs is reasonable but doesn't match section 4.1, e.g. unidirectional vs bidirectional. You need to ensure the text and your intentions line up. I'll be sending a mail to the list on this. There's problems with the descriptive text, e.g. protecting against some kinds of failures and not others. A customer doesn't care about this - they just want protection. From an SLA perspective there's no difference between failure due to competing traffic, fiber cut, router failure, etc. I'd expect resolution to correspond to the way operators deliver services. Isolation shouldn't be in the document - I'd suggest removing section 4.1.1 entirely. Isolation is just a means of achieving a goal, and there are many ways of doing it,. but they're not part of the definition of the abstraction. Kiran Makhijani: for each SLO we mention whether they're unidirectional or not. For isolation, I agree it's not observable, and that's why it's not part of the SLO - it's there as a discussion of what it means Joel Halpern: so why discuss it at all? Kiran Makhijani: DT members want it Joel Halpern: it still doesn't belong in the document Kiran Makhijani: I think it brings clarity to the doc. Some of the interesting examples are where a user may want an entire physical link. Lou Berger: we look forward to seeing Joel's mail. We should take further discussion to the list Adrian Farrel: 1. Is there a proposal on how to resolve the conflict between definitions in this work and other work that's already progressing in the wg? 2. What's the definition of transport? The DT task was to discuss slicing, and this work appears to have picked up 'transport' without explaining what that means in this context. 3. I think SLO means nothing - an objective without a guarantee is a wish, and if it has a guarantee it's an agreement - you have "guarantee" on some of your slides so SLO is just a rebranding of SLA. Kiran Makhijani: SLO/SLA difference is the level of granularity. SLA is for the lifetime of a service, but SLO is for a flow, and you can have multiple flows per service. On definition conflict - we've worked with people working on the enhanced VPN draft to resolve conflicts there. The transport term is to ensure... Reza Rokui: Terminology is important. We refer to a transport slice because we have an end-to-end slice composed of different slices... Adrian Farrel: thanks - your answers didn't really convince me so we'll go to email discussion Haomian Zheng: The definition of transport slice is claimed to be technology agnostic, but do all slices have to have a TE feature? Reza Rokui (as co-author): transport slice is a logical description of connectivity. This is just a mapping, so it describes connectivity + SLO. It doesn't say how that's realized. Haomian Zheng: endpoints: this is a very widely used term. Can we use a more specific term, eg transport slice endpoint, to avoid confusion with other types of endpoint? We already have transport and service endpoints in the draft. Reza Rokui: we (DT) had a long discussion early on about this. There are other terms such as access point, termination point, etc. We wanted to be very clear on what we meant. Haomian Zheng: I'm no tasking for a very explicit definition. Mapping transport slice endpoints to other kinds of endpoint is something that may happen but varies by implementation Reza Rokui: maybe discuss by email Kiran Makhijani: maybe explain via an example sent to the list? Italo Busi: slide 8: why do we have a transport slice that's composed of other slices? Kiran Makhijani: there's a duality on slices. it's not just a description - you have to realize it into the network and how you do that depends on the technology in use in the network. It's not a single end-to-end tunnel Italo Busi: so slice 1 is a transport slice, and other technologies implement another slice, and you can stitch them together Kiran Makhijani: the term used in 5G and elsewhere (other SDOs) is sub-slices. We chose not to use that term and just talk about aggregation of slices Reza Rokui: technology could be different, eg using SR. Italo Busi: so you see hierarchical slices Reza Rokui: yes, we didn't want to use the term 'hierarchical' but that's logically correct Italo Busi: so on slide 9, I could request a slice between endpoints Reza Rokui: if you already have a slice you can re-use it Kiran Makhijani: for scalability you can .... so you have one slice with the same SLO Eric Gray: it's important that the discussion we've had in the DT gets airtime. In future we can cut down the discussion text to a summary and I think that'll help readability, but we need it for now. Jie Dong: to reply to question about isolation from Joel: isolation wasn't invented by this doc. it appears in many other documents. Jie Dong (in chat): check RFC3809, 4031, 4110 for isolation Lou Berger: I think the comment is that isolation isn't unique to this doc Kiran Makhijani: yes, we found it relevant. (discussion after framework presentation) https://tools.ietf.org/html/draft-nsdt-teas-ns-framework-03 https://datatracker.ietf.org/doc/slides-interim-2020-teas-01-sessa-4c-draft-nsdt-teas-ns-framework/ Lou Berger: I'm surprised we don't have a queue for this, but we have time for more discussion for the whole DT Reza Rokui: we wanted to go with adoption of these two docs - it's important for us unless there's strong objections. Lou Berger: I think based on the level of discussion I'm inclined to look at the emails that will be coming, and get those comments together with comments raised today addressed, and then move the documents to adoption together Kiran Makhijani: which list? Lou Berger: WG list, not DT list. Pavan Beeram: I'm fine with this approach. Lou Berger: for the people who raised comments, please continue on the list. Authors, please address what you heard today. And once there's a draft that's ready for adoption please send a mail to the list to say how you resolved the issues and we can see if that triggers more discussion. Eric: This all sounds like a good plan to me. Igor Bryskin: I want to take a look at what Joel has to say before we discuss adoption Lou Berger: yes, that's the plan 14:20 > 5 14:15 10 Title: Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) > Draft: https://tools.ietf.org/html/draft-peru-teas-actn-poi-applicability > Presenter: Dan King Italo Busi https://datatracker.ietf.org/doc/slides-interim-2020-teas-01-sessa-5-draft-peru-teas-actn-poi-applicability/ (presentation by Italo Busi as Dan had to leave) Lou Berger: we can't poll the room,so Chairs will talk and decide how to gauge interest -- will do virtual hum or adoption poll. 14:27 > 6 14:25 10 Title: 5G End-to-end Network Slice Mapping from the view of Transport Network > Draft: https://tools.ietf.org/html/draft-geng-teas-network-slice-mapping > Presenter: Geng Xuesong Reza Rokui: (slide 4): the terminology her is heavily 3GPP. All the terminology here should reference the terminology we're using for the transport slice work. Also this is talking about the data path and how the traffic relates to transport slices. I don't think TEAS is the best WG for this - it relates more to DMM(?) Xuesong Geng: thanks. On terminology - we've considered whether to reuse 3GPP terminology. Maybe they aren't suitable for IETF people. We're open to how to define terminology. The terminology isn't the important thing - we're focusing on the procedures. We can fix the terminology once there's consensus on it. Haomian Zheng: I think the draft hits a key problem for transport slicing. But I'm shocked to see the data plane on slide 3 as there are still many layers between the top of the transport network and the data plane. And since there are multiple technologies in the DP there may be multiple mapping solutions so we have to be careful about how we organize this. The example on slide 4 only applies to packet. So more work is needed. Lou Berger: no time for reply, please respond on the list Eric Gray: I think we need to discuss on list. Re the slice identifier - are you talking about putting an identifier into encapsulation? If so we'd have to define the encapsulation. Lou Berger: again, please respond on the list Pavan Beeram: current focus of the WG is to get the DT's docs adopted and then we can revisit. Lou Berger: authors, please respond to these questions on the list without waiting for them to be asked again. 14:46 > 7 14:35 10 Title: RSVP-TE Extensions in Support of Proactive Protection > Draft: https://tools.ietf.org/html/draft-lin-teas-gmpls-proactive-protection > Presenter: Yi Lin Matt Hartley: Can you set up the protecting LSP fast enough for this to be useful? Lou Berger: they aren't introducing new mechanisms Matt Hartley: yes, I'm asking about how fast you can do this. Lou Berger: authors, please send the answer to the list as we're very short on time Pavan Beeram: in terms of protocol extensions, you are defining a couple of new flags in the error spec and another couple of flags in the protection object; imho, the protection object flags that are being proposed should be carried in the LSP attribute; please respond-to/discuss this on the list 14:55 > 8 14:45 10 Title: A Yang Data Model for Transport Slice > Draft: https://tools.ietf.org/html/draft-wd-teas-transport-slice-yang > Presenter: Bo Wu or Dhruv Dhody Lou Berger: we do have questions but we're out of time, so please take those to the list. Lou Berger: based on WG discussion on the list we can have another interim virtual meeting irrespective of what happens with IETF 108, so please contact the Chairs if think that would be useful. > Adjourn 14:55 > Virtual Blue-sheet -- please add your name and affiliation NAME AFFILIATION Lou Berger LabN Vishnu Pavan Beeram Juniper Networks Eric Gray Ericsson Dhruv Dhody Huawei-India Jari Arkko Ericsson Haomian Zheng Huawei Technologies Adrian Farrel Old Dog Consulting Quan Xiong ZTE Matt Hartley Cisco Joel Halpern Ericsson Yingzhen Qu Futurewei Tomonobu Niwa KDDI Greg Mirsky ZTE Julien Meuric Orange Gabriele Galimberti CISCO Luis M. Contreras Telefonica Kiran Makhijani Futurewei Shunsuke Homma NTT Yuji Tochio Fujitsu Alvaro Retana Futurewei Tarek Saad Juniper Zheng Zhang ZTE MIAO FUYOU? Huawei Aihua Guo Futurewei Rakesh Gandhi Cisco Italo Busi Huawei Reza Rokui Nokia Kazunori Fujiwara JPRS Deborah Brungard ATT Bo Wu Huawei Jeff Tantsura Apstra Yali Wang Huawei Jie Dong Huawei Aijun Wang China Telecom Dieter Beller Nokia Susan Hares Huawei Yunan Gu Huawei Sergio Belotti Nokia Daniel King Lancaster University Daniele Ceccarelli Ericsson Xuesong Geng Huawei Roberta Maglione Cisco Loa Andersson BDC Boris Khasanov Huawei Yi Lin Huawei Xiaobing NIU ZTE Xufeng Liu, Volta Networks Hannu Flinck, Nokia Xavier de Foy, Interdigital Zhenbin Li Huawei Huaimo Chen Futurewei