> > 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: Should the set of base/extended RSVP modules be progressed separately or should they be clubbed with the TE modules set? Tarek Saad: The authors recommendation would be to have them progressed separately. Lou Berger: Any reservations to move these to LC? Lou Berger: Expect to see some of these progress to 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: Clarification question -- What is the ietf-eth-te-topology used for? Is this for setting up Ethernet LSPs? Haomian: Ethernet can be configured as a client signal in GMPLS-based networks, so with that configuration there can be an Ethernet topology; there doesn't need to be an Ethernet LSP setup. Lou: GMPLS allows Ethernet LSPs to be set up. Xufeng: This is no different than any other technology specific TE topology model. (Regarding Options 1&2) Haomian: Agree that both options work; But we need to evaluate if there any common sections that can be put in a generic types module. Xufeng: We did the evaluation -- can discuss further offline if needed Fatai: Besides Ethernet and MPLS-TP do we have any other modules augmenting the te-packet module? Xufeng: No so far. Tarek Saad: can IP Native use this? Xufeng: That is already covered in the L3 topology module Lou: There is some proposed work (RAW) that might come into play in this discussion Lou: Regarding SR-TE-Topo model, what is SR-TE? How many would be willing to work on a good definition of SR-TE? Enough people to work on it. Will work with Spring Chairs and work this out. > 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 Saad: Question on the 32 bit Association ID used in Slide 6. The notion of ASSSOCIATION is well defined in RSVP — it is typically specified with a type. How is the association specified here different from the RSVP Association? Italo Busi: This is different; Here the intent is to associate multiple paths in one tunnel Tarek: Using Association for what you are doing is confusing, maybe rename it. Dhruv: Agree with Tarek; Association has been specified in both pcep and teas. That aside, why is there a choice here between tunnel-ref and tunnel-association-id? Why can't the regular RSVP/PCEP Association be used? Sergio: We will explore this more. Tarek: at the very least, we may need to reconsider the term 'association' used here. Lou: It would be useful to clarify if this association is the same as existing "association". Italo: We have different variants of association -- all of them applicable. We'll explore this more. > 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: Regarding ACTN-VN yang, were all the comments from the previous meeting addressed, especially the ones raised by Qin Wu? Dhruv: Yes, we believe they have been addressed. Qin: I'm happy with the changes that have been made. Lou: Question for Dan King.. Does the ECA work in netmod have any applicability here? Dan: As co-author of ECA framework, there is definitely some applicability here. Lou: this work is more advanced, may make sense to have this influence the ECA work Adrian: L3NM is a recently adopted model by ops-area. Regarding the usage of this by L3NM, suggest a meeting between service-mapping authors (l3sm) and L3NM authors Lou (side comment): There are issues with the way L3NM currently describes protocols. It is unclear what the scope is. This should reference other work especially in RTGWG. The sit-down would those folks would be really useful. Dhruv: We have been engaging with them, we will continue to do so. Greg: There was some effort to define availability in CCAMP for specific technology. But it would be good to define what availability means in general in IETF. > 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 Jayant: Is it possible to do OAM on the segment as well as on e2e for the interdomain LSP Yi: yes, . > 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 Dan: Who has read the document? Decent number, 2 operators Dhruv: How is different from draft-lee-teas-actn-poi-applicability? Dan: They are complementary rather than competitive, we will make that clear in the document. > 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) Lou: How should the communication between IETF and ETSI happen? There is no currently no formal relationship. Julien: Mutual participation Adrian: Good news is that ACTN is being looked at beyond this WG. As Lou said, there is currently no formal relationship between IETF and ETSI and it would take a while to establish one. what you want really is an individual to be sending a mail to the WG list saying we're doing this stuff does and asking does this look right and getting other individuals to comment back; that's the most effective way to make progress Reza: How does this relate to the slicing work? Jeff T: ETSI leadership doesn't recognize IETF. It would be wrong to say there is an existing relationship. Daniele: This work has nothing to do with slicing > 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 David Sinicrope: The introduction to the draft talks about enhanced VPN and about deterministic transport in the existing VPN mechanisms, but in your presentation you are pitching the draft as an architecture for network slicing. Which is it? Is it a method of providing deterministic transport VPNs or is this the new architecture for network slicing. Jie: This is a framework for VPN+ and one of the use-case of this is network slicing. Lou: The presentation went a little afield from the actual WG adopted document and that is confusing things. In future, just focus on the WG draft and let the work of design team be covered by the design team's presentation Adrian Farrel: I think the draft is very clear on the slicing aspects, enhanced VPN could be used in Transport Network Slicing Pavan: The new version has new slicing specific definitions. My expectation was that the Slicing DT would come up with those and other relevant drafts would reference those. Jie: We will coordinate with the DT. Lou: Again, the recommendation is to limit the scope of the discussion of this document to enhanced VPN (and not the DT work). David Sinicrope: The document is currently too focused on Network Slicing, but network slicing is not the only use case of enhance VPN. This needs to be made clear. Lou: I also see some discussions about using enhanced VPNs in detnet. This is another use-case. > 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 seems to be about the network slice; Is it about the control plane for VPN+ or for Network Slicing? Jie: It is about the VPN+ Lou: How is this different from the control plane discussion in the previous draft? why is the context of this draft all about Network Slicing? Jie: Not different. This draft just provides more detailed considerations Daniele Ceccarelli(Remote): Agree with Lou, should avoid overlap with other drafts. There seems to be come confusion on the scope of the base enhanced vpn draft. Jeff: Agree with Lou. Is this management plane or control plane? It looks more like management plane with the name of control plane. See if you can extend this to cover both management plane and control plane considerations. Jayant: My understanding was the enhanced VPN architecture was not meant for a large scale deployment. Yet here you are talking about a large scale. Jie: Enhanced VPN is scalable. This draft provides more details on the considerations. Adrain: Agree with Jeff, management plane needs to be covered; Agree with Lou, it should to be consistent with framework; we have about half page in framework document discussing both management plane and control plane; we have 10 pages in this current document. Should we add more material to the framework document? Pavan: The details from the framework document were culled for a good reason and moved into this document. Given the current the text, I wouldn't be comfortable at all moving it back. 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, let's clarify that first. Uma: It would be useful if underlay and overlay discussion is kept separate. Lou(Daniele's comment?): In this draft, it is confusing whether it is about deterministic VPN or enhanced VPN, needs more clarity on scope. Jie: We will fix the problem with terminology in the next version. > 13 17:35 15 Title: Network Slicing Design Team update > 45 Draft: n/a > Presenter: Jari Arkko Himanshu Shah: Clarification question -- Is this covering Soft slices or Hard slices or something else? Jari: It is based on requirement Jeff: Idea is to build an API that caters to all types of requirements. Robin: As a member of IAB; What is the plan about handling the liaison from 3GPP? Jeff: We don't need to liaise with 3GPP for this work. Jari: The idea is to define functions that could be used Yi Lin: As part of this effort, suggest to explain the meaning of 'network slice' and its relationship with other terms, such as VPN.. Reza Rokui: Terms like VPN+ are a kind of 'implementation of transport slice'. In the current stage, we are keeping the discussion independent of implementation. > 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 consistent with the design team definition > 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 in RTGWG? Jeff T: Can be discussed in RTGWG, but this seems like deja vu. > 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 T: Why RSVP? Doesn't seem to be the right protocol. Prediction may not come true, so it is possible for the the configuration to never be used. Lou: Doesn't need to propagate state; Just an error code in signaling message may suffice. Italo: local 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 uninterested? A couple. > 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 and ADs > 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: This document is not specifying any new performance monitoring capabilities, it is just referring to existing mechanisms -- it would be good to have references to relevant specifications that define those mechanisms Haomian: No, there is no new concept, will try our best to add all references. 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 seem generic. Haomian: Perhaps 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. Italo: We could define possibly generic types. Lou: We should at least try and see if generalization is possible. Little more work needs to be done before a call can be made. Haomian: We'll try and report our findings. > Adjourn 18:40