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