INSTRUCTIONS:
Please find the related presentation slot below and add/correct notes there.
Please DO NOT add notes at the end or beginning.
 
NOTE TAKERS ADD YOUR NAMES HERE (not required):

Daniel King
Haomian

> TEAS Agenda For IETF 104
> Version: Mar 13, 2019
> Session 1: Tuesday, March 26th 2019
> 11:20 - 12:20 Tuesday Morning Session II
> Location:       Congress Hall 2
> Slides: https://datatracker.ietf.org/meeting/104/session/teas
> Etherpad:       http://etherpad.tools.ietf.org/p/notes-ietf-104-teas?useMonospaceFont=true
> Meetecho:       http://www.meetecho.com/ietf104/teas/
> Audio stream:   http://mp3.conf.meetecho.com/ietf/ietf1044.m3u
> Jabber: xmpp:teas@jabber.ietf.org?join
> Available post session:
> Recording:      https://www.ietf.org/audio/ietf104/
> YouTube:        https://www.youtube.com/user/ietf/playlists

> Num Start Duration Information
> 1  11:20   10      Title:  Administrivia & WG Status
> Draft:
> Presenter:      Chairs


> 2  11:30   10      Title:  WG Draft updates
> Draft:  Many
> Presenter:      Chairs

Pavan: Authors have asked for LC of native-ip-scenarios
	•	- how many have read: more than expected
	•	- Since this is experimental, expect to LC soon

Pavan: WRT TE metric recording
	•	- There has been too little attention to this document, if not clos

> 3  11:40   15      Title:  A YANG Data Model for Traffic Engineering Tunnels and Interfaces
> A YANG Data Model for MPLS Traffic Engineering Tunnels
> A YANG Data Model for Resource Reservation Protocol (RSVP)
> A YANG Data Model for RSVP-TE Protocol
> Draft:  https://tools.ietf.org/html/draft-ietf-teas-yang-te
> https://tools.ietf.org/html/draft-ietf-teas-yang-te-mpls
> https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp
> https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te
> Presenter:      Tarek Saad

Dhruv: It would be useful to add source information for ephemeral tunnels (who initiated the setup?)
Igor: Reasonable ask. 

- There were no objections or reservations to this change 
Lou: Unless objections/comments are raised in Last Call (completing on Friday) the document will be resubmitted to the IETF next week
	•	


> 5  12:05   15      Title:  Yang model for requesting Path Computation
> Draft:  https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation
> Presenter:      Italo Busi/Sergio Belotti
(Continue discussion in the afternoon session)
Igor: we had a discussion during lunch with Italo and he reminded about the discussions we had before. The problem is, if you configure a tunnel in a pre-computation mode, even if you specify the time-out for how long you keep the state. The server can remove the state after the time-out; but the configuration will still suppose to be in the configuration datastore and need to be explicitly removed. If you do it via RPC, the datastore won't be a problem. The authors think this is important difference, I have no objection to that. 
Dhruv: the RPC should not be restricted to be used only between controller hierarches. Whoever wants should be capable to use the RPC. From the model points of view, I think the RPC should also be allowed for peer-to-peer fashion. Would this small change (from hierarchy to peer-to-peer) request a big change in your model? Why are you mandating? 
Sergio: It's not mandatory assumption, in fact this is the point for discussion. So the question for the WG is we suppose we can use that, the RPC usage should be application independent. The question is  if the WG thinks we need to modify the YANG, to cope with other aspect or not, if it is needed to have a description of the use cases or just say ... make a request independent of the factor of sequential, flat shape of architecture, etc. These are the question we would like to leave to the WG. 
Dhruv: again this model should not be binding with ACTN. If there is someone else want to use this model, he should be able to use it freely. 
Sergio: there is some discussion on distributed or hierarchical, we are not sure that this is needed and can discuss this further. Our position would be the RPC should be used independent of the architecture. The feature in the slide before is to deal with the representation on hierarchies and described how we can map between MDSC and PNC, typically in the ACTN context. 
Lou: it's supposed you are supporting both hierarchical and non-hierarchical. The only question now is whether you need a flag, and it's not convinced that with the current shape you can do both.

(Regarding option 1 and option 2)
Lou: before we discussion do you have any recommendation to the WG, or you split? (Sergio: Split. ) Ok, that's useful information. 
Lou: how about the one issue we discussed in the last meeting? We did not see any discussion on the list, about the policy. Have you solved those issues? 
Sergio: Yes, we have discussed in the mailing list, all the attributes are used when requesting the tunnel model. It's not mandatory during the path computation. 
Lou: I was asking about the discussion, is there any different opinion? 
Sergio: we have solved the issue with an explicit grouping. 
Lou: So it sounds like the resolution of the discussion from Bangkok is that you think there is an agreement in the document on providing a partial of the attributes instead of all of them. 
Igor: This open issue we have discussed and made several changes. I personally do not like the idea for separate requesting working and protection, mainly because not only we need to link them, but also basically describe the relationships, how these path computation results should be related, e.g., what kind of disjointness is required, and what will happen if the requested disjointness is not available. Another problem is that (requesting separately) will duplicate some of the parameters. There are common source/destinations, bandwidth requirement, common affinities, etc. If you just provide a single request, these would be all taken care of. And finally there would be a lot of algorithms that compute the paths simultaneously. (For the separate path computation) you can solve it but it would be awkward, so rather to have a single request. 
Sergio: about the attributes that are repeated twice, to have double request, we already put in the table. 
Dhruv: A different opinion with Igor, I tend to remain the two separate path requests. option 2 for two path request will help retain the computed features. That would also be possible to fit into different tunnels. If you remove that, you miss a very important feature. Even two unrelated paths can be diverse from each other and one feature should still be there. It's better to have a new tunnel request. This issue would be decided by WG, but please don't take away the thing already have in the current document, which is two path requests per request.
Sergio: Ok. 
Himanshu: (ragarding option 1 and 2) is it possible to support both? Both has their advantage, and it would be flexible if we can support both. Let's start with unprotected tunnel, and later on when you want to add the protection, the two path requests give you that. For the same reason as Igor said, the diversity could be satisfied with single path request. So I think it would be nice if we can support both. 
Lou: To indicate what Igor said, the alternative approach for two separate path computation request is to sent in the same RPC, so it's possible for the computer to do k paths. The other point that Igor has was you end up duplicating information, and that's a value point particular what happen if you get, like some of the information get complex, it makes the progress harder. I think the scenario that 'add the protection later' drives you the both. (Himanshu: Yes. )
Julien: it makes sense if we support both. Some of the reasons are already discussed, and others may be algorithm dependent. Application can also be either single request or double common request. I support both ways to be considered. 
Igor: do protection you have to take care of not only protection itself, but also working paths, to guarantee such kind of disjointness. Do the request at once will not diminish either one. I don't mind that we have separate requests, it would be useful when you compute path for different tunnels. Different problems will be solved via different approaches. Other scenarios like share maximal/minimal common cost would better be done in single request. But I am good if we support both, as long as we have these approaches for tunnel request. 
Italo: Supporting both would bring bad impact for inter-operability. It is possible that there is an option that a controller don't like to be selected. For example, if one vendor prefer option A and the other prefer option B then there would be problem for inter-operability. All the issues raised can be solved by the other options. So the only issue is one request per tunnel or one request per path. We can find a solution to make sure that the same semantic and the same feature we have can be done with option 1 and option 2 as well. 
Julien: Assuming the standard is option 1, but how can people be prevented to use option 2? Standard one option will not stop anyone to use the other option. 
Igor; option 1 covers everything, including both unprotected and protected, and disjointness. 
Lou: a poll would help? 
 How many are in favor of option 1? A few. 
 How many thinks option 2 is sufficient ? Slightly more than a few. 

> Adjourn         12:20


> Session 2: Tuesday, March 26th 2019
> 13:50 - 15:50 Tuesday Afternoon Session I
> Location:       Grand Ballroom
> Audio stream:   http://mp3.conf.meetecho.com/ietf/ietf1046.m3u
> Available post session:
> Recording:      https://www.ietf.org/audio/ietf104/
> YouTube:        https://www.youtube.com/user/ietf/playlists

> Num Start Duration Information
> 1  13:50   5       Title:  Administrivia
> Draft:
> Presenter:      Chairs


Continued with discussion from #5 above, refer to #5 for the summary. 


> 6  13:55   15      Title:  ACTN applicability to YANG models
> Draft:  https://tools.ietf.org/html/draft-ietf-teas-actn-yang
> Presenter:      Haomian Zheng
No discussion. 

> 7  14:10   15      Title:  ACTN VN YANG
> Draft:  https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang
> Presenter:      Dhruv Dhody
No discussion. 

> 8  14:25   15      Title:  Traffic Engineering and Service Mapping Yang Model
> Draft:  https://tools.ietf.org/html/draft-ietf-teas-te-service-mapping-yang
> Presenter:      Young Lee
Lou: the comments from Tom Petch, need to be solved on the list. 
Young: will do that. 
Pavan: for availability, do you have any reference?
Young: I think we can have some reference, some operators expressed the demand, I don't know which reference is the best fit, maybe ITU-T, will figure out. 
Lou: some previous comments also mentioned this, we need a reference.
Young: Tom Petch is also chasing, we need to solve anyhow.

> 13 15:20   10      Title:  A Framework for Enhanced Virtual Private Networks (VPN+)
> Draft:  https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn
> Presenter:      Jie Dong
Lou: There is a draft in LSR WG, is it worth to talk about that work here today? (later this week. ) It would be headed our way and I suspect some overlap with this document. Would be good to, if someone is available, going there to see what is going on and sync up the content. (Jie： OK. ) It's in the second LSR session. 
Jie: I learn about the document, which is specific segment routing. This work is more generic like framework. 
Lou: they do have some generic text as well, that's the reason to sync up. 
Jie: Ok, we will talk offline. 

> 9  14:40   10      Title:  RFC3272bis -- Design Team report
> Draft:
> Presenter:      Adrian Farrel
No discussion. 

> 10 14:50   10      Title:  YANG models for ACTN TE Performance Monitoring Telemetry and Network Autonomics
> Draft:  https://tools.ietf.org/html/draft-lee-teas-actn-pm-telemetry-autonomics
> Presenter:      Young Lee

Pavan: Please add a reference for availability
Dieter: there is no direct description on subscription, which means the text need to be polished. 
Young: agreed. Already done in the YANG description but not in the main body.
Dieter: people don't like to search and read the YANG code, need to do it in the text. (Yes. )
Lou: Some comments from last meetings were not fully solved, be careful on what part is ACTN-specific and what part is generic, e.g. in introduction section. Please go ahead using the list for discussion and look for adoption before Montreal. 
Young: So you mean the draft need to be updated to avoid the ACTN context. (Yes. )
Pavan: Moreover, just make sure the reference on scaling in/out is added (Yes, Section 4). 
Lou: it would be useful if you can find reference when you have something new. 
Young: that's before adoption ? 
Lou: yes, before adoption. Be aware that Dieter's comments are valid, the readability should be improved. 
Daniel King: This document is almost two years old now, I am wondering how much more polish it needs before being adopted. 
Lou: Dieter raised an issue, and there outstanding issues from the last (IETF 103?) discussion. These need to be addressed before we can adopt. 
Daniel King: Ok, we have clear objectives. We will update.  

> 11 15:00   10      Title:  Basic YANG Model for Steering Client Services To Server Tunnels
> Draft:  https://tools.ietf.org/html/draft-bryskin-teas-service-tunnel-steering-model
> Presenter:      Igor Bryskin
Pavan: what's the relationship between this model and other service mapping models? Have you discussed this offline? 
Igor: The service mapping model work is constructing the map between explicit service and tunnels, they basically need to specify the tunnel names. This draft bring the possibility to have the capability of mapping instead of specifying tunnel name, just a pool-id. 
Lou; I took what Pavan was saying as not from Chairs but more general. 
Igor: I have also answered that as a general question. 
Dhruv: I think this work is needed, but we can also start the te-service-mapping to work on the same problem rather than have independent model. when you have TE tunnels on one side and the services in the other, and you create another model. Why not augment the existing models to include all the information there? But now we are creating a rather new model and introducing the pool id. Is it a small subset of what we have been done before? Is it possible to have one model solve both the TE service mapping problem and the steering problem? That would be better than two disjoint models. 
Lou: the semantics are quite different, and they are solving different problems. There may still be value on bringing these together, and optimize the complete solution, rather than looking them as pieces. The answer we came up before was a very specific scope, on 1-for-1 mapping, wasn't a pool concept. 
Dhruv: even if in this tunnel pool, the tunnel can be shared across services. From the YANG's perspective it's not big changes, we have created a new YANG model solving this problem. That what I was commenting. 
Lou: if we look into previous SR-TE discussion, we are not creating a single model, but use the information across multiple models, in order to have composite and useful information. So there were two models contributive instead of one. 
Igor: Expect the proposal here. 
Lou: Yes but he's not another document. 
Igor: No, here we complement the solution and helping on particular problem. For example what happens if there is subscription, if you put more services on a tunnel than they can carry. Would you always need to re-map the services to the tunnels? 
Dhruv: We did do another abstraction called VN, our thinking was that the services getting mapped to VN, and tunnels are like your tunnel pool, i.e., they can come and go and things can change. But you have a bigger abstraction called VN which remain unchanged in this scenario. So I think it's the same problem being solved by different way, we can call it either tunnel pool or VN. 
Igor: we don't really have your model in mind. For example there are layer 2/3 VPN services, mapping signals to Ethernet tunnels can be done via another model (in ccamp). There is just no method to understand mapping to one or multiple tunnels, so many remapping would happen afterwards. We are suggesting to make it brief. Even further, you can steer services to slices, it's much general problem. 
Dhruv: I just want to remind there is still overlap. I have to implementing both the TE-service-mapping and te-pool, I still need to understand when to use which one, to make sure using the right model. 
Igor: The pool is between tunnels and your services as a complementary solution. We make it easier to manage that. 
Himanshu: Do you cover the tunnels going to the same destination? (Igor: Yes. ) So in that scenario is there any discipline to have min/max constraints for distributing the traffic on the tunnel? 
Igor: we are indicating what source we are mapping to a pool, the device can take any tunnel from the pool to their necessary destination. How you do multi-path is a separate question. In our work you don't say what tunnel you are gooing to use but you only say use one tunnel (from the pool) to achieve Himanshu. The constraints on this tunnel selection is not in the scope of this work. 
Himanshu: I was thinking more about the traffic distribution to achieve load balancing. If you are subscribing the services, and putting the services on the tunnel, which tunnel should you choose in discipline? Min-fill, max-fill? FIFO or other mechanism? 
Igor: but this is a multi-path problem, right? 
Himanshu: ok, we can take (offline). 
Pavan: we still have two documents talking about mapping services to tunnels, even though they are complementary. It would be valuable to be cover under the same umbrella. Please the author talk with each other. 
Igor: I have aware more other works, so in future we may have a bigger umbrella? Given the previous experience we think it would be better to have separate work. 
Lou: Come to the other authors, and come back with your conclusion and proposal to the WG. 
Igor: OK. 
Lou: in terms of the other question you have. In abstract you may have additional information which is not traditional TE networks, but do you think it makes sense to be included in this model? We may probably do augmentation for those (non-TE) informations. But it may be arguable if we should do it or not. Make sure our AD is happy with what we are doing here. 
Igor: so we are doing enhanced VPNS, for example, right? 
Lou: yes, we are already doing that. 
Igor: if we have a context of enhanced VPN, then we want to keep this VPN regardless of how it is proceeded. 
Lou: So the interworking function, the entry function into the TE network, we don't know where do we define that? For EVPN/L3VPN services, if we want to map them to TE, we will probably talk about augmentation to a TE model or an augmentation to BESS model to do it. Based on the proposal, we can talk about where is the right place to do it. Either way would need a synchronized group. 
Igor: we still keep in the tunnel level, but allowing some abstractions. 
Lou: Thank you. 

> 12 15:10   10      Title:  Interworking of GMPLS Control and Centralized Controller System
> Draft:  https://tools.ietf.org/html/draft-zheng-teas-gmpls-controller-inter-work
> Presenter:      Haomian Zheng
Loa: (regarding to slide 2) why LMP is a 'distributed' not 'centralized'?
Haomian: actually it's a part of GMPLS, but no harm if put as 'centralized' as well.
Lou: How many have read this document? Very many.
Lou: How many from Design team read this document ? A few. 
Lou: Do you think the scope of this work fold into the Design Team (per RFC3272bis)? We can have the centralized control, distributed control, and hybrid, this work is about hybrid. 
Adrian: 'fold in' may not be the right word. If you look into the size, we certainly will not take it in the 3272bis. But they are related, so in RFC3272bis we prefer to give a short description and point to this work. This work folds in the TEAS scope, and is quite useful. 
Andrew: I have read the draft, and this is an useful work especially when describing hybrid systems. I prefer to see it move ahead. 
Lou: Another comments (not blocking one), although in presentation ACTN is used as an example, in the draft there ia a lot of ACTN. We should not make it ACTN-specific. 
Haomian: Agree, in the last update (-03) many terms of ACTN has been removed to be more generalized. Only a few left as an example. 
Lou: How many thinks this should be the work that WG should work on? A reasonable number. 
   How many have read this draft? Almost same. 
   How many think it's a good start point for WG? More than previous two. 
   How many think we should not accept this work and start? No one. 
Lou: very useful feedback, will take the poll to the list, make it adopted as -00 and include the open actions. 
    
> 14 15:30   10      Title:  RSVP-TE P2MP Tunnels on RMR
> Draft:  https://tools.ietf.org/html/draft-zzhang-teas-rmr-rsvp-p2mp
> Presenter:      Jeffrey Zhang

Lou: this document is like the other RMR document? It was sent to us from another WG. Do you think it belongs to here? Last time the other side believed that this work belongs to here, and I suspect if same thing happens here. I need to check whether Loa nod or disagree. (Loa Nod) He is nodding, so yes they want to publish by teas. It would be put in the normal process here. We do have other RMR documents as WG documents, and seems like reasonable companion. 
Loa: The RMR documents, we have two in MPLS, the base document, under WG LC. There is no dependency on other documents to accept this document. You can do that. There is also LLDP document and I think there would be a P2MP document going to a framework document in MPLS. There is potentially a document in spring for segment routing. 
Jeffery: to clarify, for multi-cast and P2MP, there is an informational document in MPLS WG, generally talking about the ring or topology with rings how the multi-cast works. This work here is explicitly about RSVP-TE P2MP tunnel optimizations, including the procedures and the encoding to achieve that. 
Lou: How many in the room are focusing on RMR, on the topic? just a few.
   How many has read the document? Maybe a couple more.
   How many think we should adopt this? About same number from different people. 
   How many think we should not adopt this work? 1, then why?
Adrian: I am not opposing the work, I just went to MPLS list and see how much discussion has been there, and could not find any. A little bit nerves on the future. 
Lou: Do you know the other RMR document we are having? 
Adrian: Yes, and also the MPLS WG. I am not still thinking where it belongs, it's a specific multi-cast RMR, seems to have discussion. 
Himanshu: I strongly support this work, because many of the mobile networks are ring-based. We see the scaling issues, and we really need this solution. We were willing to revive the RMR work and happy to see this work coming along. In fact we want to see more stuff, but take it offline. 
Lou: Comments on the floor, please use the mailing list. Did you mention the base document in MPLS? 
Jeffery: it does not mention the base document. Currently uni-cast and multi-cast are proceeded in parallel. 
Lou: is that a WG adopted work or individual? 
Jeffery: Individual, I think we are also requesting WG adoption. 
Loa: There is one reason why we have not start the poll, we think it's ready for adoption, but we want to wait until we have done the WG LC for the other RMR base document. Again there is no reason not to adopt here because of any MPS work. 
Lou: is the base one about the data plane work? I don't think the data plane work need to be done here. 
Jeffery: No, forwarding plane is no different. There is no changes even for unicast RMR. 
Lou: no need to argue about the adoption order here and in MPLs. 
Loa: we talked about the informational document right? The base one is under WG LC and wait for publication. The other one will be adopted in the near future. 
Lou: then teas will adopt this work afterwards. 
Loa: Ok. WG LC for base -> MPLS adoption on informational -> TEAS adoption this work. 
Lou: the first order is under MPLS WG, the next is our decision. 
Loa: Do you know the document talk about 'soon'?
Lou: Hopefully before Montreal. 

> 15 15:40   10      Title:  YANG Data Models for Multiprotocol Label Switching - Transport Profile)
> Draft:  https://tools.ietf.org/html/draft-busizheng-teas-mpls-tp-yang
> Presenter:      Italo Busi
Lou: unless the MPLS chairs disagree, out position is that TP is a profile of TE, not its own thing. It would be the best to integrate with TE models. 
Italo: I just want to make sure that's the opinion from the WG. 
Lou: is there anyone who wants to disagree? No.
Lou: that seems the direction to go. I suggest when you think it's necessary to have a change, send to the list and we just discuss there. 
Italo: Of course. 

> Adjourn         15:50