Minutes IETF106: teas

The information below is for an old version of the document
Meeting Minutes Traffic Engineering Architecture and Signaling (teas) WG Snapshot
Title Minutes IETF106: teas
State Active
Other versions plain text
Last updated 2019-12-15

Meeting Minutes

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:  

> 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

(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-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     
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        
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

> 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:     
>                                 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: 
>                                 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 >                            
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