Minutes IETF 107 Interim
> Session 1: April 23rd 2020
Etherpad: https://etherpad.ietf.org:9009/p/notes-ietf-107-teas >
Jabber: xmpp:email@example.com?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
> Presenter: Chairs
> 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.
> 3 13:10 15 Title: RFC3272 Bis Design Team
> Presenter: Adrian Farrel
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
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)
> 4 13:25 50 Title: Network Slicing Design Team
> Presenter: Jari Arkko, Kiran Makhijani, Eric Gray
(discussion after definition presentation)
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
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
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
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
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
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)
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
Lou Berger: yes, that's the plan
> 5 14:15 10 Title: Applicability of Abstraction and Control of
Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) >
Presenter: Dan King Italo Busi
(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.
> 6 14:25 10 Title: 5G End-to-end Network Slice Mapping from the view
of Transport Network > Draft:
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
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.
> 7 14:35 10 Title: RSVP-TE Extensions in Support of Proactive
Protection > Draft:
Presenter: Yi Lin
Matt Hartley: Can you set up the protecting LSP fast enough for this to be
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
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
> 8 14:45 10 Title: A Yang Data Model for Transport Slice
Presenter: Bo Wu or Dhruv Dhody
Lou Berger: we do have questions but we're out of time, so please take those to
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
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