> TEAS Agenda For IETF 99 > > Tuesday July 18th 2017 > 0930-1200 Morning Session I > Grand Hilton Ballroom > > Slides: https://datatracker.ietf.org/meeting/99/session/teas > Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-99-teas?useMonospaceFont=true > Meetecho: http://www.meetecho.com/ietf99/teas > Audio stream: http://ietf99streaming.dnsalias.net/ietf/ietf996.m3u > Jabber: xmpp:teas@jabber.ietf.org?join > > Available post session: > Recording: https://www.ietf.org/audio/ietf99/ > YouTube: https://www.youtube.com/user/ietf/playlists > > > Num Start #Min Information > 0 9:30 10 Title: Administrivia & WG Status > Draft: > Presenter: Chairs Lou Berger: IETF Note Well has changed recently. In particular, we have new IPR disclosure document (RFC8179) > 1 9:40 10 Title: WG Draft updates > Draft: Many > Presenter: Chairs (regarding draft-ietf-teas-scheduled-resource) Julien Meuric (PCE Chair hat): PCE WG has already adopted the solution draft. No identified showstopper during the adoption call so nothing to prevent TEAS progressing the document. Lou Berger: The reason for us to wait was to ensure that the general direction of this draft is correct; it sounds like the PCE WG thinks that it is. Pavan Beeram: (poll) How many have read the latest version of this: a few How many think document is ready: about the same (conclusion) we'll take it to the list [for confirmation] > 2 9:50 10 Title: Recommendations for RSVP-TE and Segment Routing LSP co-existence > Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-sr-rsvp-coexistence-rec/ > Presenter: Harish Sitaraman Lou Berger: (poll) How many have read draft? (a few) How many think document is ready? (about the same) Does anyone think there are outstanding issues? (none) (conclusion) we'll take it to the list [for confirmation] > 3 10:00 15 Title: YANG Data Models - TE Topologies > Drafts: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ > https://datatracker.ietf.org/doc/draft-liu-teas-yang-l3-te-topo/ > https://datatracker.ietf.org/doc/draft-liu-teas-yang-sr-te-topo/ > Presenter: Xufeng Liu TE Topology: Lou Berger: do you have any concerns with the alignment with I2RS? Xufeng Liu: no pending issue with I2RS alignment. They have agreed on the changes needed so we can augment their model. Lou Berger: any other outstanding issue, that may impact the process of this work? Xufeng Liu: we don't see any. Lou Berger: This model defines some types that are used by other TE models? Xufeng Liu: we have moved all the types in the te-type module Lou Berger: So is there anything that prevents this document moving forward? Xufeng Liu: we have a few references to other models (TE tunnels, netmod scheduling) Lou Berger: informational references are fine. Do you think it makes sense to hold this document waiting for the TE Tunnel? Xufeng Liu: I do not think we need to wait Lou Berger: how many have read this version? A few, more than I expected how many have read any version? A good number how many think the document is ready for WG LC? More than those who have read this version Lou Berger: We'd like to progress this as rapidly as possible. Given the amount of changes in the last version, we are thinking about having an extended WG LC L3 TE Topology: Lou Berger: (poll) How many have read any version of this draft: a few How many think document is a reasonable foundation for the WG: about the same (conclusion) we'll take it to the list [for confirmation] SR and SR TE Topology Lou Berger: (poll) does the WG think we should be working on this? A reasonable number. How many have read draft: a few How many think document is a reasonable foundation for the WG: about the same Daniele Ceccarelli: why should a NMS care whether a topology is using SR or not? Xufeng Liu: we have generic topology model and technology-specific (as SR) for different topology. Daniele Ceccarelli: So the TE topology is enough if I don't care about the dataplane, and if I want to know that there's a SR dataplane I can get that information? Xufeng Liu: Yes. Lou Berger: Back to the polling: conclusion is that we'll take it to the list [for confirmation] > 4 10:15 15 Title: YANG Data Models - TE Tunnels and Interfaces, RSVP-TE > Drafts: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/ > https://datatracker.ietf.org/doc/draft-ietf-teas-yang-rsvp-te/ > Presenter: Rakesh Gandhi Igor Bryskin: TE Topology and TE Tunnel model have a lot of commonalities and are complementary and so people could assume they can only be used together, but they could be used independently. It therefore doesn't make sense to hold back the TE Topology model waiting for TE Tunnel, or vice versa. Lou Berger: do you have any specific concern on structure of the models and dependencies between them? Igor Bryskin: we designed the model carefully, and no issue found at this moment. We have the same group of people working on both models. Lou Berger: What needs to be done before documents are ready for LC? Rakesh Gandhi: the RSVP model is stable; we just need to make updates for NMDA. Lou Berger: so the plan is to update the structure for NMDA and then ask for last call? Rakesh Gandhi: yes Lou Berger: Please let the WG know when these updates are complete and ready for LC Lou Berger: (poll) How many people have read these docs? (about the same as the previous drafts) Does anyone have any reservations on this set of documents? Dieter Beller (via jabber): support moving forward > 5 10:30 10 Title: Framework for Abstraction and Control of Traffic Engineered Networks > Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/ > Presenter: Young Lee Pavan Beeram: let's discuss the WG LC after the requirements and abstraction methods documents Lou Berger: how many have read this document? More than the other documents; a good number > 6 10:40 10 Title: Requirements for Abstraction and Control of TE Networks > Information Model for Abstraction and Control of TE Networks > Drafts: https://datatracker.ietf.org/doc/draft-ietf-teas-actn-requirements/ > https://datatracker.ietf.org/doc/draft-ietf-teas-actn-info-model/ > Presenter: Sergio Belotti Pavan Beeram: do we need to progress the info model before the TE Tunnel yang model? Sergio Belotti: I think the document is stable, we have just fixed some mistakes we have discovered while working with TE Tunnel Lou Berger: I am asking whether info model depends on TE Tunnel model Sergio Belotti: I do not think so. The info model can precede the TE tunnel model. Young Lee: info model is very high level so that TE tunnel model details are not affecting the info model. Haomian Zheng: I also think the models are separate and don't need to progress together. Lou Berger: how many have read the requirements? A good number how mnay have read the info model? Still a good number, but less how many think the info model is ready for WG LC? Almost the same number Lou Bergber: Pavan and I will talk offline and discuss whether we should link the documents or not. Daniele Ceccarelli: in any case, I think the correct order is requirements, then framework, then info model. > 7 10:50 10 Title: Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks > Abstraction and Control of TE Networks (ACTN) Abstraction Methods > Draft: https://datatracker.ietf.org/doc/draft-zhang-teas-actn-yang/ > https://datatracker.ietf.org/doc/draft-lee-teas-actn-abstraction/ > Presenter: Daniele Ceccarelli Applicability of YANG models to ACTN: Lou Berger: Previously, content like this has been part of the framework. Do we need a separate document or could we move this material to the framework draft? Daniele Ceccarelli: This is not just gap analysis; it's guidelines and applicability. We've discussed whether this document needs to be informational or standard-track. Lou Berger: so now that you've decided not to make it standrad-track, why not bring it in to the framework? Similar to the TP control plane document. Daniele Ceccarelli: that would make for a very large framework document. Lou Berger: so it is better to have one large document, or two separate ones? Haomian Zheng: current framework draft is self-contained and complete, we don't need to include every possible solution/gap/applicability in the framework. Moving the corresponding work into framework will be endless and make the framework document too heavy. We suggest to move the framework first, and then look at this applicability analysis to be aligned with both ACTN framework and IETF YANG model. Young Lee: I agree with Haomian. Framework is technology independent and in PCE WG we have applicability of ACTN to PCE, and we don't want to tie the applicability data model in this WG to the framework. Daniele Ceccarelli: even if this is applicability, in the end it's the solution to the problem identified by the framework. Lou Berger: do you think we need to wait for other documents before progressing it? Daniele Ceccarelli: Making a WG document can be done without any dependency. Lou Berger: I'm jumping ahead because if we're going to end up holding it up, that strengthens the argument to keep it as a separate document. If not, it doesn't matter. Daniele Ceccarelli: I would wait for the mandatory functionality to be approved before progressing it. Jeff Tantsura: This document should stay informational. Also, this doesn't describe how the models interact together, and there's additional work required to do that for the people who will implement it. Lou Berger: (poll) how many people think it makes sense to move this into the framework? zero (conclusion) sounds like that's the way to go. Lou Berger: (poll) how many people this information is needed? A reasonable number how many have read the docuemnt? almost the same how many think it is a good foundation? almost the same conclusion: take to the list ACTN Abstraction Methods Pavan Beeram: to confirm, last time it was mentioned to integrate into the framework, now are you still prefer to have this separate draft? Daniele Ceccarelli: Yes. Lou Berger: it would be good to discuss why there's value in keeping it separate. It's almost as if the framework and requirements can't stand alone without this document. Daniele Ceccarelli: to read the framework you need to understand the concepts of black, white and grey topologies which is now in the framework but not all the other details in this document. Lou Berger: it seems unnecessary. Last time the WG agreed that this was good material. It seems that it would be natural to incorporate it into the requirements and framework docs. Daniele Ceccarelli: I don't have strong objections. I don't want to overload the framework document. Young Lee: I think that the remaining content of this document is quite advanced material that a reader of a framework should not necessarily need to read Lou Berger: I am thinking at least about the abstraction factors to be moved in the framework draft Haomian Zheng: there is enough information in the framework draft about abstraction and the basic terminology. This draft discusses how different methods may be used to do the abstraction and I think that's different. I suggest moving the framework draft first and new abstraction techniques can use that as a reference. Michael Scharf (speaking for Dieter Beller): there is a risk of inconsistencies with many documents, so it would be good to reduce the number if possible Lou Berger: how may people would object to moving this material into existing ACTN WG documents? (no hands) Young Lee: whether this goes to the framework doc or not, I don't want the process to be delayed again. If we merge this, can we still proceed to WG LC for the framework? What's the Chairs' position on this? We don't want to wait until the next IETF. Lou Berger: my position is that it would be best to produce the best document that the WG can. If that's by a simple cut/paste that's great, but I would think that a real integration would produce a better document. We'll LC the document when it's ready; we won't LC it until then. I can't make any promises. I think we should do the right thing rather than drop text in to move the document past a milestone. Italo Busi: I share the concerns about moving this information to the framework since it is too much advanced for a framework but I do not see any other WG document where it can be moved, so I'd prefer to keep it separate for now. We might merge into this document any future advanced ACTN topic. Loa Andersson: I didn't raise my hand to object, but I was very close to it. I dont' really see the implications of merging the documents. We should do what's reasonable, but the question is probably too involved for an open meeting. Jeff Tantsura: I'm in favor of merging, given that the content definitely aligns; I'm against a simple copy-and-paste. I think the detail could go in an appendix while the use cases should be a sub-section in the framework. Daniele Ceccarelli: the whole text could go to an appendix Lou Berger: since you're interested in trying to make it work, have a go at it. It the authors like it, they can publish as a new revision; if not, put it somewhere for people to look at and see what the WG thinks. It's tough to talk about hypotheticals. > 8 11:00 10 Title: A Yang Data Model for ACTN VN Operation > Draft: https://datatracker.ietf.org/doc/draft-lee-teas-actn-vn-yang/ > Presenter: Dhruv Dhody (remote) (presented by Young Lee due to remote communication issues) Michael Scharf: from my understanding, type 1 and type 2 is quite different, and why we must have the same model to describe them? From a customer perspective the use of VNs 1 and 2 seems different. Young Lee: all containers are optional in the YANG model so you can pick and choose. Dhruv Dhody: the first reason is, if you look at the VN model, the only difference between type 1 and type 2 is a reference to the abstrct TE topology, so the yang model constructs are the same irrespective of how they're used. You just have an extra mechanism for type 2. I agree that they look different at a higher level, but they look very similar in the yang model. Michael Scharf: for me, VN1 is just a list of tunnels and there's no added value in that. Do we really need a yang model for it? There are also other ways to do things, e.g. adding policy to a list of tunnels - you don't need a yang model for that. Same with path calculations for multiple tunnels - you can do this in software. Dhruv Dhody: main question is: as a customer, what's the best way to communicate my requirements to a service provider? In the framework, everything's referenced in terms of the VN, so shouldn't we use the same construct in the yang model? Michael Scharf: Just adding one identifier to a list of tunnels doesn't give a lot of benefit. Do we really need a YANG model for this sort of list? Igor Bryskin: tend to agree with Michael, the concern is valid, because client usualy need to specify how they want to use the Tunnel/resource. The topology is sufficient for this Young Lee: That's exactly why type 1 and 2 are differentiated; you're referring to type 2. Some clients don't need the complexity so they would choose to implement only the type 1 where clients don't need any of network details just expressing their service policy and QoS/SLA for their e2e connectivity. Igor Bryskin: If I have a set of OTN tunnels, how can I use them? Can I send ethernet traffic, or SDN traffic? How does the client know that? Lou Berger: Sorry to cut off an interesting discussion, but we're running late. Please continue discussing on the list. Let's not wait until the next meeting. > 9 11:10 10 Title: Traffic Engineering and Service Mapping Yang Model > Draft: https://datatracker.ietf.org/doc/draft-lee-teas-te-service-mapping-yang/ > Presenter: Dhruv Dhody (remote) Lou Berger: this module has a dependency on the VN model? Dhurv Dhody: yes Michael Scharf: The L3SM model (RFC 1849) is more complex (e.g., a site can be multi-homed, cloud access) and I do not see how this model would work in more complex cases Dhruv Dhody: I agree and I would provide more text to clarify this point Lou Berger: If we just want to add TE to the L3 service model, why does it have to be specific to how L3 is supported? Do you really need to know the internal details? Jeff Tantsura: we need the reverse feedback. It's missing at the moment. Dhruv Dhody: you can use telemetry to get the feedbacks (next presentation) Young Lee: To address Lou's question, this model does not necessarily depend on VN YANG model since we can use the TE Tunnel model instead as an option (in case statement) to provide the mapping Lou Berger: we should discuss further on the list. > 10 11:20 5 Title: YANG models for ACTN TE Performance Monitoring Telemetry and Network Autonomics > Draft: https://datatracker.ietf.org/doc/draft-lee-teas-actn-pm-telemetry-autonomics/ > Presenter: Young Lee Lou Berger: Does this depend on VN YANG model? Young Lee: We have two modules, one that augments TE tunnel model and the other that augments VN YANG model. Lou Berger: Further discussion to the list, but could consider moving some of this into the base TE tunnel module. > 11 11:25 10 Title: TE Topology and Tunnel Modeling for Transport Networks > Draft: https://datatracker.ietf.org/doc/draft-bryskin-teas-te-topo-and-tunnel-modeling/ > Presenter: Igor Bryskin Lou Berger: it looks a good and useful informative text Lou Berger: how many thinks it is a useful document: a good number how many have read the document: almost the same number how many think the WG should take it: a little bit less conclusion: take to the list > 12 11:35 10 Title: Use Cases for SF Aware Topology Models > Draft: https://datatracker.ietf.org/doc/draft-bryskin-use-cases-sf-aware-topo-model/ > Presenter: Igor Bryskin (no time for discussion) > 13 11:45 10 Title: CCDR (Centrally Control Dynamic Routing) Scenario, Simulation and Suggestion > Draft: https://datatracker.ietf.org/doc/draft-wang-teas-ccdr/ > Presenter: Aijun Wang (Remote)/Sun Qiong/Li Chen (presented by Lu Huang due to remote access issues) Lou Berger: do we want to discuss TE for native IP in this WG? Our charter is TE, and we have things like MPLS and SR in scope. Julien Meuric: I still struggle to map this to my actual operational needs, so at this stage my answer is no Lou Berger: are you saying no to the specific proposal or to the topic? Julien Meuric: the way it is presented today is no, if the problem is better explained, I can change my position Michael Scharf: This a good starting point, but other IP solutions exist and it is not clear what the value of this solution is compared with those Zhong Chen? (China Telecom): we have a big IP network and need a solution for this problem Lou Berger: I think for the group, talking more about what is the problem you are trying to solve would be useful before jumping to a solution Deborah Brungard (AD hat): it is a very early work so it is difficult to judge if it fits or not. We need to more more specific about the problem and use case Lu Huang: We have both pure IP and MPLS networks. An MPLS-TE solution would not fit for our existing IP networks Lou Berger: I think there's a problem to be solved here, but we need a bit more education. Please discuss further on the list. At the moment people are disagreeing with the solutions, so maybe discussing the problem will get more people on board. Lou Berger: we're over time. See you on Thursday > 14 11:55 5 Title: BGP Community based PCE in native IP network > Draft: https://datatracker.ietf.org/doc/draft-huang-teas-bgp-community-pce > Presenter: Lu Huang (not presented) > Adjourn 12:00 Minutes by: Haomian Zheng, Italo Busi, Matt Hartley