For the Dec. 18, 2014 TEAS Virtual Interim see http://www.ietf.org/proceedings/interim/2014/12/18/teas/minutes/minutes-interim-2014-teas-1 > TEAS Agenda For IETF 92 > Version: Mar 18, 2015 > > > THURSDAY, March 26, 2014 > 0900 - 1130 - Thursday Morning Session I > Room: Far East > > # Start Time Duration Information > 0 9:00 8 Title: Administrivia & WG Status > Draft: > Presenter: Chairs (Lou Berger, Vishnu Pavan Beeram) Thanks to Adrian for his efforts as AD. He's now our Technical Advisor. Thanks to Deborah for being Chair... she's now our responsible AD Pavan is our new Chair Matt is the new Secretary We have no new RFCs, but three docs that are almost there. We have one doc that's through LC and waiting on edits Oscar Gonzalez de Dios: minor updates to be done, we'll do it soon Please use the mailing list for Working Group discussions. Not everyone can attend the physical meetings and we don't have time for everything > 1 9:08 7 Title: WG Document Status > Draft: > Presenter: Chairs Lou Berger: Please take a look at draft-ietf-teas-interconnected-te-info-exchange before it goes to WGLC. Lou Berger: draft-ietf-teas-egress-protection: how many have read? (a good number). Please read and comment before we get to LC. Huaimo Chen (on draft-ietf-teas-rsvp-ingress-protection): we're trying to resolve issues raised Lou Berger: since it's a WG doc, it's appropriate to have the discussion on the list. If you have it in private then you have to have it again on the list when you update the doc. Dhruv Dhody: I sent comments to MPLS on draft-ietf-teas-te-express-path when it was in that WG. They haven't been addressed yet. Matt Hartley: does draft-ietf-teas-rsvp-te-srlg-collect need a new shepherd now Deborah is the AD? Lou Berger: Yes. > 2 9:15 10 Title: Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route > Draft: http://tools.ietf.org/html/draft-ietf-teas-lsp-diversity > Presenter: Dieter Beller Lou Berger: does 3209 use the term RSVP-FEC? Dieter Beller: yes Lou Berger: I don't recall that, and I wrote it Adrian Farrel: section 1.1 of 3209 Lou Berger: OK then :) Dieter Beller: editors believe this is ready for WG LC Lou Berger: almost everything is a SHOULD. Can I just do nothing and claim to comply? It'd be good to go through the doc and work out what's really a SHOULD and what should be a MUST, or we'll end up with interoperability problems. Dieter Beller: OK > 3 9:25 10 Title: RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing > Draft: http://tools.ietf.org/html/draft-ietf-teas-gmpls-resource-sharing-proc > Presenter: Haomian Zheng Lou Berger: how many have read the new version? (A few). Lou Berger: there's been a lot of changes. Given that it's Informational, keep it that way; if you want to change procedures then it's no longer Informational. The introduction reads like it's preparing to change things. Haomian Zheng: authors' intent is that it be Informational Lou Berger: introduction needs some work then. > 4 9:35 15 Title: YANG Data Model for TE Topologies > Draft: http://tools.ietf.org/html/draft-liu-teas-yang-te-topo > Presenter: Vishnu Pavan Beeram Lou Berger: when you say "use-cases", do you mean that or examples? V. Pavan Beeram: examples of how we use the model. Paul Doolan: I support this work. Note that there's similar work elsewhere. Also Scott's presentation later. I don't understand the distinction between provider and abstract topology. V. Pavan Beeram: we've made some changes to address this - you can see them in github. Paul Doolan: Data models are extremely terse and having some explanation of how to use it would be good. Perhaps a separate doc? Xian Zhang: I'd also like to see an example of applicability. Also, schedule shouldn't be here V. Pavan Beeram: schedule will go somewhere more general. Lou Berger: we have a general problem with covering things that are general but not specified yet. We also need to ensure that we tie in switching technology stuff properly. CCAMP works on that and we need to be able to augment the generic TEAS doc. V. Pavan Beeram: that's the intent. This doc still has a bit of technology-specific stuff (link bandwidths) Igor Bryskin: difference between provider and abstract topologies is that the provider topology may contain elements that the client may not understand and so can't be used for path-calculation; the abstract topology is usable by everyone who can see it and can be used for path computation. Lou Berger: different authors are saying different things. Igor Bryskin: I think we're agreeing... V. Pavan Beeram: we're not using those terms any more. Forget provider topology; we now just have a flag for a link to say whether it's abstract or not Igor Bryskin: we're still discussing it. Lou Berger: so when a topology is provided do you expect everything to be abstract, or a combination of abstract and non-abstract? V. Pavan Beeram: could be a mixture Young Lee: not clear whether you're talking about abstraction on the controller device or at the customer level. I support a recursive model V. Pavan Beeram: yes, it's recursive. Young Lee: need to ensure the connectivity matrix container is augmentable, so should talk to CCAMP to ensure this is the case. Lou Berger: document needs and intro Young Lee: need some sort of information model - I got a bit lost reading it. Igor Bryskin: model should be expandable. It's meant to be a base for all sorts of augmentations. Provider vs abstract is a discussion that needs to continue, but abstract vs provider link isn't enough. We need to know whether the topo as a whole is abstract or not. Dieter Beller: I agree that we need an introduction Lou Berger: procedural question: design team was tasked with delivering a doc for Dallas, which they have done. Does this carry on as an individual doc, or does the WG adopt it? Any reservation on closing the design team and taking this as a WG document? That doesn't mean it's finished. Eric Osborne: next few slots are the same. We need to ensure we don't have a lot of docs saying the same thing. Lou Berger: other docs don't cover topology so this is easy. Jeff Haas: in I2RS we have a model that will overlap. We should not have significantly overlapping topoogy models. Lou Berger: Pavan said that the hope is to make this an augmentation to the I2RS topology Jeff Haas: good! Paul Doolan: Don't have issue with taking on as WG doc but how do we deal with suggestions to split it up or address other problems? Lou Berger: I hope we'll produce a single TE topology core model. Everything that's not part of that needs to be split out and go to the appropriate WG. Xian Zhang: prefer if we add examples before we consider adoption Lou Berger: we're getting to the point where we know there's a lot of work, but I don't think that's a necessary hurdle Xian Zhang: I can make better comments if there's examples Lou Berger: A lot of people will think the same. I'd like to poll the list and ask what people would like to see done once it's a WG doc. When we have a to-do list we can address it. > 5 9:50 15 Title: YANG Data Model for Traffic Engineering Tunnels and Interfaces > Draft: http://tools.ietf.org/html/draft-saad-teas-yang-te > Presenter: Tarek Saad > 6 10:05 10 Title: YANG Data Model for RSVP/RSVP-TE > Draft: http://tools.ietf.org/html/draft-saad-teas-yang-rsvp > Presenter: Tarek Saad (both presented together) Jeff Haas: you've left GMPLS, etc out of scope for now. Please keep in mind that not just IETF but other SDOs may augment this. Please talk to the yang doctors to see how best to do this. Lou Berger: I hope Anees will also take that comment on board for the routing area yang discussions. Lou Berger: I think we have to wait and see how this and the related models come together before we can proceed. Tarek: we'd welcome comments from the WG Lou Berger: we know that MPLS is the driver for this but we need to make sure the full scope of TEAS is covered. Don't forget the other technologies. And remember that GMPLS is the more general case, not packet-TE. A big issue going forward is who augments who. > 7 10:15 10 Title: OpenConfig MPLS YANG Model > Draft: http://tools.ietf.org/html/draft-openconfig-mpls-consolidated-model > Presenter: Ina Minei Kireeti Kompella: being vendor-neutral is a good goal but may end up being least-common-denominator. How do you deal with that? Ina Minei: I believe it's a goal across the IETF :) Vendor-specific extensions can be done but we don't want those to define the entire functionality. Kireeti Kompella: but the IETF doesn't do vendor-neutral :) Lou Berger: how do we ensure there isn't double the work in terms of implementing the models? This is a general question... Ina Minei: we've talked tothe design team and had good conversations on alignment Lou Berger: can we combine the drafts/work? Ina Minei: we're going to experiment separately for now. We're talking to each other but not merging yet Tarek Saad: are you open to breaking the draft down into separate pieces for LDP, TE, etc? Ina Minei: we haven't explored that. No religious reasons against it but we need to think about the implications Lou Berger: we need models that fit together eventually, but we also need stable docs that vendors can claim support for (or not) which will tend to drive towards separate docs. It's still one model, but separate docs. Igor Bryskin: I saw your presentation about the service model and OpenConfig expectations on that. I haven't heard any opinion from OpenConfig on topologies yet. Ina Minei: we don't have a topology model yet Igor Bryskin: can you look at what we've got and tell us what we're missing? Rob Shakir: yes, we can look at it. We've had a brief conversation about it at OpenConfig but there's debate on whether we need to do this. If we don't see a need operationally we won't bother. Rob Shakir: it's good to align drafts. Main questions is what are we trying to achieve with the network? I'd rather do that work right now and then look at alignment of models later. Otherwise we might get an unusable standard (didn't catch name): does this cover specific use for LSPs? Should we add a section with a time period? Ina Minei: we should discuss the use-cases Lou Berger: we should take to the list - out of time here. Luyuan Fang: we're trying to illustrate the building-blocks rather than cover all the details Lou Berger: are you willing to take the IETF's details? Ina Minei: we've thought about it. If it can be added as an augmentation that'd be nice. Dhruv Dhody: there's no operational state yet. Are you thinking similar to what was presented in netmod WG? Ina Minei: yes (conversation to be continued on the list) Lou Berger: there was some discussion about where this draft belongs. The ADs didn't want too many common topics in Routing WG, so things like this will be worked out between TEAS and MPLS. There will be more discussions on Friday in MPLS. > 8 10:25 10 Title: A generic YANG Data Model for Label Switch Path (LSP) > Draft: https://tools.ietf.org/html/draft-zhang-mpls-lspdb-yang > Presenter: Dhruv Dhody Kireeti Kompella: when you say this is operational, that's post-signaling? Dhruv Dhody: yes Kireeti Kompella: should say this up front. Lou Berger: prior drafts take a different approach to the problem Adrian Farrel: can look at LSPs at three places: ingress node, transit node, and network-wide (e.g. a PCE LSP database). I'm not clear which you're addressing here. Also some of the LSP concepts are informed by a P2P-MPLS-TE view of the world and it may be better to step back. Things like MP2MP LDP LSPs are very different Dhruv Dhody: agreed Jeff Haas: you should move this stuff into groupings. BFD design team has yang elements that can be used outside their modules. If you do the same then you have stuff that other people can use in their models. Lou Berger: the task is to align this with the two prior drafts/discussions; authors should do this offline. > 9 10:35 10 Title: Usage of IM for network topology to support TE Topology YANG Module Development > Draft: https://tools.ietf.org/html/draft-lam-teas-usage-info-model-net-topology > Presenter: Scott Mansfield Jeff Haas: I2RS was very early in doing modelling stuff for the IETF. We were required to do info models before data models so we have a lot of experience with this sort of thing. We tried RDL, and then UML, and found textual forms of UML are not usable in IETF docs - it's mostly graphical. Sue Hares: IETF docs don't have graphic insertion Lou Berger: this is a well-understood problem Sue Hares: there's an inability to detect problems from the RBNF and there's a way to go from UML to Yang automatically. I hope Yang people will continue to consider this a valid tooling technique Lou Berger: Benoit Claise will be talking about this in routing WG so we should discuss there. Scott Mansfield: it's possible to put pictures in RFCs and you do it for formats other than text Adrian Farrel: please don't publish an RFC on this as it's too fluid. Should be a wiki page. > 10 10:45 15 Title: Abstraction and Control of Transport Networks > Draft: http://tools.ietf.org/html/draft-ceccarelli-actn-framework > http://tools.ietf.org/html/draft-leebelotti-actn-info > Presenter: Young Lee Lou Berger (intro to topic): there's been discussion on ACTN for a while. There was a BOF in Hawaii and there's clearly interest in the topic. ADs requested that TEAS discuss how ACTN fits into our WG scope. So we have some key questions on what's already covered by existing docs, and what fits in TEAS. > 11 11:00 10 Title: Abstraction and Control of Transport Networks Discussion > Draft: > Presenter: Chair Moderated Lou Berger: why isn't this just part of the yang work we're doing? Almost all the requirements are common with that Young Lee: you're jumping into a solution Igor Bryskin: what would be helpful would be a good gap analysis doc from the ACTN folks. Why are topology/OAM/etc models not good enough? Young Lee: there's already a problem statement draft which has this (may be expired now) Igor Bryskin: important part is to account for current work. We've started topology and service modeling and that may be enough. Young Lee: we're saying there's more than this. It's not tied to yang per se at the moment. Operators really want a control-plane model that can adapt to the network. Also there may be performance issues - need to evaluate whether netconf is good enough. Lou Berger: the control-plane based model - is this UNI and ENNI? Young Lee: I don't think customers want that. It's not just GMPLS - NMS and PCE too. You have to understand the heterogenity Lou Berger: it'd be good if the requirements draft covered this. Lou Berger (chair hat on): the question is how does what we're working on fit into ACTN? It looks like this (what mechanisms fit into ACTN) fits into TEAS scope. So, first question is a yes: some of the ACTN work is within TEAS scope. Any objections? Andy Malis: I was at both BOFs, and my opinion based on that everything that's been discussed at ATCN fits within clause E of the TEAS charter Lou Berger: How many think that a portion of ACTN fits in TEAS (most of the room). None of it fits? (none). Lou Berger: So we should move the requirements doc to TEAS and discuss further prior to WG adoption poll. Lou Berger: will have to skip other questions and move on. Time is short. > 12 11:10 10 Title: RSVP-TE Scalability - Recommendations > Draft: http://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling > Presenter: Vishnu Pavan Beeram Pawel Brzozowski: do these extensions apply to other network types? V. Pavan Beeram: we didn't study how this applies to non-packet Lou Berger: my experience is most are already done in transport networks. If this comes into the WG it should cover all RSVP-TE use cases Pawel Brzozowski: so TEAS or MPLS? Lou Berger: TEAS. > 13 11:20 5 Title: RSVP Setup Retry > Draft: http://tools.ietf.org/html/draft-ravisingh-teas-rsvp-setup-retry > Presenter: Vishnu Pavan Beeram (presentation skipped) Lou Berger: on both of these: intention to do a BCP or standards track document? V. Pavan Beeram: informational Lou Berger: that means you can't change anything. Rob Shakir: should be a standard rather than informational Lou Berger: could be BCP if you don't change anything in the protocol. Lou Berger: should have further discussions on the list > 14 11:25 5 Title: TE LSP Crossing Topology-Transparent Zones > Draft: http://tools.ietf.org/html/draft-chen-teas-rsvp-ttz > Presenter: Huaimo Chen Lou Berger: for folks who weren't in OSPF: our AD (then) said that if we do this we have to understand how TTZ works with TE in general, so we need a separate document for this that covers OSPF and TE. Need to address this before getting into the details. Lou Berger: thanks, all. See you in Prague. > Adjourn 11:30 >