Minutes IETF106: teas
minutes-106-teas-00

IETF 106 Rough Notes

NOTE TAKERS ADD YOUR NAMES HERE (not required): Haomian

>
>                                         TEAS Agenda For IETF 106
>                                         Version: Nov 17, 2019
>
>                                         Tuesday, November 19, 2019 (+08)
>                                         Session 1: Tuesday, November 19th 2019
>                                         13:30 - 15:00 Tuesday Afternoon
Session I >                                         Session 2: Tuesday,
November 19th 2019 >                                         17:10 - 18:40
Tuesday Afternoon Session III >                                 Location:      
 Collyer > >                                 Slides:       
https://datatracker.ietf.org/meeting/106/session/teas >                        
        Etherpad:        https://etherpad.ietf.org/p/notes-ietf-106-teas >     
                           Meetecho:       
http://www.meetecho.com/ietf106/teas/ >                                 Audio
stream:        http://mp3.conf.meetecho.com/ietf/ietf1062.m3u >                
                Jabber:        xmpp:teas@jabber.ietf.org?join > >              
                          Available post session: >                            
    Recording: >                                 YouTube:
https://www.youtube.com/watch?v=Fn60DSxJLks > > Presentation               
Start Time        Duration        Information > 1                13:30        5
       Title:        Administrivia & WG Status >                               
 Draft: >                                 Presenter:        Chairs

> 2                13:35        10        Title:        WG Draft updates
>                                 Draft:        Many
>                                 Presenter:        Chairs

> 3                13:45        10        Title:        YANG Models Updates
>                    (13:40)        Draft:       
https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te-07 >                  
                     
https://tools.ietf.org/html/draft-ietf-teas-yang-te-mpls-02 >                  
                     
https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te-07 >                  
                      https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-11
>                                 Presenter:        Tarek Saad

Lou Berger: expect LC soon

> 4                13:55        10        Title:        YANG Models for L3 and
SR TE Topologies >                                 Draft:       
https://tools.ietf.org/html/draft-ietf-teas-yang-l3-te-topo-05 >               
                        
https://tools.ietf.org/html/draft-ietf-teas-yang-sr-te-topo-06 >               
                 Presenter:        Xufeng Liu

Tarek: why the ietf-eth-te-topology needed? do we expect Ethernet LSP?
Haomian: Ethernet can be configured as a client signal in GMPLS-based network,
so after the configuration there can be topology on Ethernet, no need to be a
LSP.

(Regarding Options 1&2)
Haomian: need to evaluate quantatively on how much common sections.
Xufeng: Option 1 should work, the packet model is augmenting some PM attributes.
Fatai: Besides Ethernet and MPLS-TP do we have other techniques can augmenting
the te-packet? Xufeng: No so far.

> 5                14:05        10        Title:        Yang model for
requesting Path Computation >                                 Draft:       
https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-06 >         
                       Presenter:        Sergio Belotti

Tarek: association object has already been defined for rsvp-te. What do you
expect from association-id (32 bits)? do we need association type? e.g.
co-routed, etc. (regarding page #6)? Italo: the parameter tunnel-association
enables 'multiple path' into one tunnel. Tarek: Dhruv: association has been
specified in both pcep and teas. Regarding the modle here why a choice? instead
of using choice we can also specify during request? Sergio: Tarek: may need to
reconsider the meaning of term 'association', as specified in te-tunnel and
PCEP. Italo: can be used also as the primary and secondary path of the tunnel.
Lou: would be useful to clarify the usage of association. Italo: to emunerate,
associatoin between paths; association the paths within the same tunnel;
association tunnels and their paths.

> 6                14:15        10        Title:        ACTN Yang Models
>                                 Draft:       
https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-04 >                  
                     
https://tools.ietf.org/html/draft-ietf-teas-actn-pm-telemetry-autonomics-01 >  
                                     
https://tools.ietf.org/html/draft-ietf-teas-te-service-mapping-yang-02 >       
                         Presenter:        Dhruv Dhody Lou: xx Dan: as
co-author of ECA framework, there is applicability if delegation
event/condition that enable telemetry streaming Lou: this work is more
advanced, may make sense to inform ECA model Adrian: suggest a meeting between
service-mapping authors (l3sm) and L3NM authors Lou (side comment): There are
isssues with the way L3NM currently describes protocols. This should reference
other work especially in RTGWG

Greg: there was some effort to define availability in CCAMP for specificc
technology. It's good to define what availability means in IETF Haomian
(offline contribute) ITU-T G.827 should be the right reference document for
term 'availability'.

> 7                14:25        10        Title:        Interworking of GMPLS
Control and Centralized Controller System >                    32            
Draft:       
https://tools.ietf.org/html/draft-ietf-teas-gmpls-controller-inter-work-02 >   
                             Presenter:        Yi Lin Jain: is it possible to
do OAM on the segment as well on e2e for the interdomain LSP Yi: yes, Jain will
email/followup on the list.

> 8                14:35        10        Title:        Applicability of ACTN
to Packet Optical Integration (POI) >                     14:43           
Draft:       
https://tools.ietf.org/html/draft-peru-teas-actn-poi-applicability-02 >        
                        Presenter:        Daniel King

> 9                14:45        5        Title:        3272bis Design Team
update >                                 Draft:             
https://tools.ietf.org/html/draft-dt-teas-rfc3272bis >                         
       Presenter:        Adrian Farrel

> 10                14:50        10        Title:        ETSI Communication
>                                 Draft:        None
>                                 Presenter:        Daniele Ceccarelli (remote)

> Adjourn                15:00
>
>
>                                         Session 2: Tuesday, November 19th 2019
>                                         17:10 - 18:40 Tuesday Afternoon
Session IIIx >                                 Location:        Collyer > > >  
                                      Available post session: >                
                Recording: >                                 YouTube: 
https://www.youtube.com/watch?v=JMDuPgOjN3g > > Presentation               
Start Time        Duration        Information > 1                17:10        5
       Title:        Administrivia >                                 Draft: >  
                              Presenter:        Chairs > 11               
17:15        10        Title:        A Framework for Enhanced Virtual Private
Networks (VPN+) Service

>                                 Draft:       
https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-01 >                  
              Presenter:        Jie Dong Lou: The work of design team should be
showed by the design team's presentation Jie: I just mention that to show our
willing to coordinate. Adrain: I think the draft is very clear, and enhanced
VPN could be used in Transport Network Slicing David Sinicrope:It focuses on
Network Slicing too much, but network slicing is not the only use case of
enhance VPN Lou: I also see some disscussions about treating enhanced VPN as a
technolgoy to implement detnet

> 12                17:25        10        Title:        Control plane
considerations of enhanced VPN >                                 Draft:       
https://tools.ietf.org/html/draft-dong-teas-enhanced-vpn-control-plane-00 >    
                            Presenter:        Jie Dong Lou: Your title is VPN+,
but the context is about the network slice;It is about the control plane of
VPN+ or Network Slice Jie: It is about the VPN+ Lou: There are some
descriptions about control plane in the previous draft, why the contex of this
draft is all about Network Slice Jie£ºThis draft provides more detailed
considerations Daniele Ceccarelli(Remote): Agree with Lou, should avoid overlap
with other drafts Jeff: Management plane or control plane? It looks more like
management plane with the name of control plane. It is not distributed.
Jane(?): Jie: Enhanced VPN is scalable. Adrain: Agree with Jeff, it looks like
management plane; Agree with Lou, it should to go along with framework, we have
about half page in framework document discussing this but then 10 pages in this
document. Shall we add more materials to the framework document? Lou: we need
to understand the considerations for VPN+ control plane (not network slicing)
first. Adrian: so control & management plane should be in one or separate
document? Lou: we care more about the text, currently prefer one. Lou(Read some
else' comment?): In this draft, it is confusing whether it is about
deterministic VPN or enhanced VPN Jie: We will fix the problem of terminology.

> 13                17:35        15        Title:        Network Slicing Design
Team update >                          45       Draft:        n/a >            
                    Presenter:        Jari Arkko Himanshu Shah: Soft slices or
Hard slices or general? Jari: Based on Reuirement; Robin: As role of liason
responsible IAB; What is the plan about handling the Liason from 3GPP? Jeff: We
don't handle liason from 3GPP. Jari: Define functions that could be used Yi
Lin: suggest better to explain the meaning of 'network slice' and its
relationship with other terms, such as VPN, VN, ... Reza Rokui: all the term
(VPN, VN, etc.) is a kind of 'implementation of transport slice'. In the
current stage, we keep it implementation irrelevent

> 14                17:50        10        Title:        Transport Network
Slice YANG Data Model >                      605       Draft:       
https://tools.ietf.org/html/draft-liu-teas-transport-network-slice-yang-00 >   
                             Presenter:        Xufeng Liu Reza: keep the
terminology along with the design team defination Lou: Time out and bring it to
the list

> 15                18:00        10        Title:        Instant Congestion
Assessment Network (iCAN) for Data Plane Traffic Engineering >                 
      13         Draft:        https://tools.ietf.org/html/draft-liu-ican-01 > 
                               Presenter:        Joanna Dang Lou: this WG or
RTGWG, load based routing, e.g., ECMP, has typically been done there? Jeff: ?

> 16                18:10        10        Title:        RSVP-TE Extensions in
Support of Proactive Protection >                                 Draft:       
https://tools.ietf.org/html/draft-lin-ccamp-gmpls-proactive-protection-00 >    
                            Presenter:        Yi Lin Jeff: prediction may not
come true,so the configuration is possible to never be used. Lou: Jeff: Rather
to do path protection than RSVP extension for prediction. Italo: the path
protection may not be optimal especially for optical. Lou: how many people
think this topic is interesting to work on? A few.
   how many totally uninterest? None.

> 17                18:20        10        Title:        A YANG Model for
Network and VPN Service Performance Monitoring >                               
 Draft:       
https://tools.ietf.org/html/draft-www-bess-yang-vpn-service-pm-04 >            
                    Presenter:        Michael Wang

Lou: we need to talk to the bess chairs.

> 18                18:30        10        Title:        A YANG Data Model for
Client Signal Performance Monitoring >                                 Draft:  
     https://tools.ietf.org/html/draft-zheng-ccamp-client-pm-yang-00 >         
                       Presenter:        Haomian Zheng Dieter Beller:In my
understanding, this draft will not bring new monitoring technologies? Haomian:
No, ther is no new concept, and will try the best to reference. Lou: It is not
technology specific? Haomian: we monitor the performance for tech-specific
service, so the model should be tech-specific. Lou: But the parameters listed
in the table are generic for more than Ethernet. Haomian: Perhas what you would
like to see is have a generic model, and at least there is one
pm-telemetry-autonomics. Lou: You are not augmenting, at least you should try.
Haomian: okay, we will evaluate and report our findings. (Lou: ok.) Italo: We
could define generic types? Lou: make sure there is no layer tow or lower
technologies.

> Adjourn                18:40