Minutes interim-2020-teas-01: Thu 13:00
minutes-interim-2020-teas-01-202004231300-00

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. <connection lost> 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