[Teas] Interim meeting raw mintes

["Matt Hartley (mhartley)" <[e-mail]>]

All,

Raw minutes from the interim meeting that's just finished are below. If anyone wants to change anything, the etherpad is at http://etherpad.tools.ietf.org:9000/p/notes-ietf-92-teas - please go in and do it!

Cheers

Matt

    
    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 focussed 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 buildon 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: <more presentation>
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: <presentation>
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: <presentation>
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: <presentation>
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: <presentation>
Igor: so where would SRLGs go? In types?
Tarek: yes
Tarek: <presentation><end>
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... <missed> so that te can augment the rsvp model

> -  5 min - TE Topology YANG Model Design Team Introduction (Chairs)
Deborah <presentation>
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's 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: <presentation>
Zafar: there's also a TED model
Igor: it's just a library, not a full model
Pavan: <presentation>
Pavan: any questions on logistics?
<silence>
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?
<silence>
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?
<silence>

> - 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. Raw notes will go to list.
<adjourn>