Agenda - TEAS Virtual Interim Dec. 18, 2014 20:00 UTC (2 hour duration) Held over Webex Material is posted at: http://www.ietf.org/proceedings/interim/2014/12/18/teas/proceedings.html Recording: https://ietf.webex.com/ietf/ldr.php?RCID=fe6635b449db2141f7270c03617fe5ce Attendance copied from Webex during the meeting... Adrian Farrel Lou Berger Aihua Guo Alia Atlas Cyril Margaria Daniel King Deborah Brungard Don Fedyk Fred Gruman George Swallow Ignas Bogdanas Igor Bryskin Jonathan Sadler Kam Lam Young Lee Lyndon (Ong?) Matt Hartley Matthew Bocci M Waldman Oscar Gonzalez de Dios Pawel Brzozowski Rakesh Gandhi Scott Mansfield Susan Hares Tarek Saad Victor Lopez Vishnu Pavan Beeram Xufeng Liu Yuji Tochio Zafar Ali > - 10 min - Agenda/Intro (Lou) Welcome, ususal IETF note well Meeting is being recorded Scope: mostly about TE topology yang model Everyone should please look at draft-ietf-netmod-routing-cfg, as Adrian keeps pointing out Tarek has been coordinating TE yang model work in MPLS, which will transition to TEAS In general, generic stuff will be in TEAS and dataplane-specific things will be in CCAMP L2 network topologies are in I2RS, not TE focused yet > - 10 min - I2RS Related Activities (Sue) Protocol-Independent Data Models and RIB are part of I2RS' charter Lou: question going forward: how does TE fit in? And where do things like TE-specific OSPF stuff go? Sue: IGP chairs are in agreement that TE stuff specifically discussed in OSPF/ISIS docs are part of the OSPF/ISIS WGs. Same goes for BGP. Lou: Yang aspects of BGP-LS are still in BGP? Sue: yes. Some operators have suggested a yang model. Igor: you mentioned TE-OSPF and TE-ISIS, but what does that mean? Once information is in the TED it doesn't matter how it got there. Do you see any difference between OSPF and ISIS? Sue (very firmly as an individual :) there's a difference in the handling of information in the IGP, but not once it gets to TE Igor: OK, so there's no such thing as OSPF-TE and ISIS-TE yang models? Sue: there is a difference; if you're tracking information in OSPF or ISIS that relates to TE then that's part of OSPF/ISIS Lou: something like an opaque LSA would end up in the TED, but other things might not. Zafar: TE topology is independent of OSPF or ISIS topology Sue: yes. Abstract topologies have a link back to the TE topology Zafar: so what's the definition of an abstract topology here? Sue: The slide reflects the current level of discussion, which proposes an abstract topology. Alex Clemm is pushing for a topology where the highest level is abstact, and then things build on top of that. This is being discussed in I2RS Kam: As to the Protocol Independent, you are talking about that for topology Independent, but it is not Management Protocol Independent. Sue: I2RS is focusing on topologies that aren't linked to a protocol. If topology is attached to a protocol it needs to link to that protocol's config Kam: but next slide talks about protocol-dependent IM, so what's up with that? The term "protocol" is overloaded Sue: yes, I'm giving you I2RS' current definition of it. Important as I2RS is focussing on RIB and protocol-independent stuff first Igor: should we look at topologies from user perspective, ie who's using them and why? e.g. Which protocol was used to build the TED is unimportant (unles there's some conflict) Sue: agree, but there's work to be done in I2RS on this too. There's a bit of a grey line here. Sue: Zafar: slide 7: we have a draft for the network topology, is that the same as the abstract topology? Sue: no, they're different. Things are a bit mixed up at the moment and I think you need to have a clean definition; Clemm tends not to. This is still in discussion. Lou: I'd expect TE stuff to be addressed by the DT, and then we'll have to integrate with other models above this. Zafar: I'd like to know more about how the WG can participate. Lou: we'll get to this in a bit. Sue: I2RS will carry on examining protocol-independent modules as we need to know if netconf/restconf will need changes. > - 10 min - TE RSVP/Tunnel/LSP YANG Discussions (Tarek) Tarek: Design team has been meeting weekly Multiple drafts presented in Homolulu, need coordinating so DT was formed (draft co-authors + other intersted people) Meetings have been announced on MPLS WG mailer, will also be on TEAS going forward Zafar: where does generic RSVP work go? Lou: I don't think there is one but we'll need to discuss the division of work as this stuff goes to TEAS. We should have a placeholder yang model for RSVP that the TE-specific stuff can hang off. We also need to worry about how GMPLS fits in and how we coordinate the generic work in TEAS and the dataplane-specific stuff in CCAMP. Tarek: so you think GMPLS should bind into TE? Lou: as we move to TEAS we should have a TE model that covers both MPLS-TE and GMPLS Igor: agree. igor: new question. So there will be groupings common to RSVP and TE? e.g ERO, node, link... so how do we reconcile these common definitions? Can we create as many reusable libraries as we need that can be imported wherever needed? Tarek: we plan tohave a module with all this stuff igor: I'd rather see it in smaller chunks Tarek: OK, DT will take feedback on board Tarek: Lou: what does generic mean? RSVP-TE vs SR? Tarek: agnostic of RSVP-TE or SR. Lou: I understand it to also mean generic across dataplanes, not just control planes. We'll need to be careful about terminology here. Tarek: Igor: what's a path-template? Tarek: LSP template applies to all LSPs, path-template applies to all paths that are defined, e.g. to set all hops strict or loose or something Rakesh: so if you want to have many LSPs take the same path you can do this. Igor: so where does the definition go and how does it get shared? Tarek: in te-base, at the moment. Igor: so we should define atomic libraries for little things so that the entire model doesn't have to be imported Lou: so maybe we should have a te-types for this Tarek: Igor: so where would SRLGs go? In types? Tarek: yes Tarek: Zafar: dataplane should be separate. Tarek: yes. Lou: having discussions both on-list and in DT calls makes sense. What's the schedule for the next few calls? Tarek: one today, then resume in January Lou: instead of ietf-mpls-te, call it... so that te can augment the rsvp model > - 5 min - TE Topology YANG Model Design Team Introduction (Chairs) Deborah Zafar: work requires a lot of interaction and collaboration. not good if WG members who want to contribute aren't there. Weekly calls are good. Can we do this for the TED design team? Deborah: this is up to the DT in the short term... but in the longer term this will be a normal WG document, or the DT's work could be rejected if the WG doesn't like it. Lou: bear in mind this is also only until Dallas, and we'll poll the WG on what's been produced. There will be plenty of time for everyone to contribute both before and after we have a WG doc. Zafar: why can't you do wwhat the TE DT is doing? Igor: premature to open discussion to too many people; will make no progress at all. DT was selected to have repesentation from a variety of vendors and operators Lou: DT members really just came from different drafts. You can work with colleagues at your company or collaborators on draft you already have. Deborah: bear in mind also that TEAS has only just started so we have no baseline. many folks are interested in this and we needed to get a core group together. This is a temproary arrangement, not a new way of doing things. Kam: topology should be independent of management protocol in use (netconf, etc). There will be a draft on this. Lou: it'd be good to see the doc, and then worry about which WG to put it in. > - Design Team Led Discussion https://github.com/ietf-mpls-yang/te and https://github.com/ietf-mpls-yang/te/blob/master/draft-liu-ted.yang Pavan: Zafar: there's also a TED model Igor: it's just a library, not a full model Pavan: Pavan: any questions on logistics? Pavan: what about dependencies on network topology, etc? Igor: need to decide whether to reuse concepts like nodes, links, etc or whether to define our own. I think we should define our own so that we can do what we like with them. ISTR Lou questioned this in Honolulu Lou: no. Higher-level model doens't need to define where lower-level model comes in, but lower model needs to define where it fits in. Igor: the problem is that a lot of the basic stuff isn't working for the TE model. Looking at it another way: from a Chair's POV, would it be OK to have no base model? So we don't assume where the topology comes from or how it's used? Lou: from Chair perspective, we need to look at where we can re-use stuff or minimize duplication... but the DT doesn't necessarily need to worry too much about it. We can tidy this stuff up later once the various models are more mature. However, it needs doing before we end the WG process. igor: good. That's what we're doing. Lou: it'd be good if the doc captures open issues and flags this as a to-do Pavan: not slowing us down yet, so if it's OK to just flag it that's OK. Xufeng: if we want to base this onthe generic topology, we'd need many changes from the base topology, and the base isnt' moving forward very fast Matt: should this go to the Area yang list? Lou: syncing up models needs doing; the question is when. igor: but we don't want to get into a situation where models are so diverse that we cant' reconcile them. We'll need to keep in touch with Alex, etc but we'll push on Adrian: if one lot of peope have a dependency on another and progress isn't fast enough, contribute there too and help them out to remove the roadblock. Xufeng: so can we take the base topology to other WGs? Lou: no, make comments on the base docs in other WGs Igor: if we know how to improve things, we can contribute. But if we don't know how to change things...? Lou: so send a message to the list and talk to authors to see what can be done. Igor: we did, and we weren't happy with the answers. We thought we could inherit the idea of overlay/underlay, but we realized we can't, so we defined a te-path element which is not generic Lou: sounds like these are good things to flag in the doc. These are areas where we'll have to work across WGs. Sue: I'd like to continue this discussion... I2RS will have interim meetings and we'd like to keep communication going. Young: if the yang model doesn't provide what we need in TE, could we augment/inherit to add what we need? Can we add new semantics? Xufeng: we've been talking about augmenting the netowrk topology model to create the TE model Young: so since yang allows augmentation we can just go ahead? igor: want to define model so things we can re-use are in separate libraries. I think it's a good idea to define stuff we need and then make stuff common when we see a need to do so. Young: sounds good Zafar: where do we send comments on specific bits of the model? Pavan: TEAS list Lou: list is good. You're welcome to send stuff privately if you like Kam: idea of common information model that people can pick from is a good one. we can ensure consistency between models and divergence/inconcistency in future. We presented a draft in Honolulu. draft-betts-netmod-framework-data-schema-uml-00. From webex chat: "describes a framework for how interface protocol specific data schema can be systematically derived from an underlying common information model, focusing upon the networking and forwarding domain. The benefit of using such an approach in interface specification development is to promote convergence, interoperability, and efficiency." Lou: almost officially out of time; I think we've achieved our main objectives. Before we carry on, are there any high-level issues to discuss before people start to leave? Pavan: next thing: dependencies on MPLS-TE-specific models. We'll be collaborating with Tarek and that DT, especially on common stuff, but there may be other stuff that's TED-specific. Any other comments? Igor: it'd be good to be able to carry on with the various models in parallel and independently. So it'd be a good plan to have the common stuff defined ASAP. Tarek: agreed. Igor: also need to have the granularity correct. And need to think about which bits can be reused elsewhere when defining models Pavan: Technology-specific TE-topology models. We wanted to get the abstract/agnostic stuff done first, but how do we coordinate? Zafar: yes. What's the timeline? Submit before next IETF? Pavan; yes Lou: how much is it reasonable to do in that timeframe? Details are out of scope for DT. Zafar: that's fine. We can work offline on specific questions. Lou: to be clear, DT should not be producing technology-specific models as part of its effort (but individuals can do what they like) Pavan: are there any other topology models that will have a dependency on ours? At the moment, we're OK as a lot of stuff will be in common libraries so other models can use that. Any comments? > - Open Discussion Lou: anything else? igor: meeting has been a good experience and I'd like to thank the organizers. We can do other things in parallel :) Lou: etherpad has notes. Kudos to our new WG secretary, Matt. Raw notes will go to list.