[Please add your name to the virtual blue sheet at the end, and notes inline in the appropriate Notes block.] IETF NETMOD Virtual Interim Meeting Feb 22, 2016 Online Agenda and Slides at: https://www.ietf.org/proceedings/interim/2016/02/22/netmod/proceedings.html Data tracker: http://datatracker.ietf.org/wg/netmod/ Tools page: http://tools.ietf.org/wg/netmod Agenda: 5 min: agenda bashing, scribes, note well, etherpad, etc. 20 min: use-case summary (draft-rtgyangdt-rtgwg-device-model-02) 20 min: proposal #1 (draft-lhotka-netmod-ysdl-00) 20 min: proposal #2 (draft-bjorklund-netmod-structural-mount-00) 55 min: general discussion or end early Attendees: - Kent Watsen Lou Berger Christian Hopps Einar Nilsen-Nygaard Juergen Schönwälder Ladislav Lhotka Xufeng Liu Martin Björklund Xian Eric Volt Vishnu Pavan Beeram Acee Lindem Gert Michael Scharf Himanshu Shah Ashesh Mishra Benoit Claise Robert Wilton Tarek Saad Dan Romanscanu Aihua Steve Baillargeon Notes: (please add to the appropriate time block) Agenda basking by Eric Voit: would like to make sure that the mount discussed here doesn't preclude extensibility (see clemm-mount draft ) > 5 min: agenda bashing, scribes, note well, etherpad, etc. > https://www.ietf.org/proceedings/interim/2016/02/22/netmod/slides/slides-interim-2016-netmod-1-2.pptx > 20 min: use-case summary > http://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-02 > https://www.ietf.org/proceedings/interim/2016/02/22/netmod/slides/slides-interim-2016-netmod-1-1.pptx Lou Presenting draft-rtgyangdt-rtgwg-device-model-02: - Chris Hopps: clarification on slide 12, the LNE needs only be managed, does not necessarily have to be inside the host - Kent Watsen: LNEs may be remote (in cloud) - this okay so long as it can be managed as a single network device - Kent Watsen: needing to support LNE directly is not as important as being able to manage everything from host - Eric Voit: What is the perspective of the YANG interface exposed to an external device? If an LNE contains many VNF, why wouldn't a management interface allow abstraction of the internal VNFs. In this case within the LNE, they might want to mount information from the various VNFs in a way invisible to external entities. As the VNF might be on different devices/VMs, this opens up addressability/latency/etc. questions. Note that this stuff has been asked for in the BNG context to increase overall control plane scale from the external management perspective. - Kent Watsen: assigning resources from host to LEN may require transformation (e.g., flagging as read-only). (Lou: good draft comment) - Rob Shakir: ??? - Martin Bjorklund: ??? (Lou: let's use yang-library) - Lada: ??? (Lou: whatever we do will impact clients/servers, so cleanest answer is desired, maybe needs YANG 1.2 would be needed) (???: why would we need to rev YANG? Lou: a new YANG type? Lada: no, how to find mounts, - ???: is it still needed to augment the interface model? Lou: yes, base model has all interfaces, but some assigned to an LNE, that's why augmentation is needed) - Xufeng: is it possible to mount just a part of a module? Lou: inner/outer interfaces discussion > 20 min: proposal #1 > http://tools.ietf.org/html/draft-lhotka-netmod-ysdl-00 > https://www.ietf.org/proceedings/interim/2016/02/22/netmod/slides/slides-interim-2016-netmod-1-0.pdf Lada presenting draft-lhotka-netmod-ysdl-00: - Kent Watsen: static list of modules, no runtime additions? - how does this work for VNFs? (Lada's answer seemed to miss the point) - Juergen: My understanding is that Lada defines the mount point at runtime, Martin requires the mount point to be defined at schema definition time. Am I correct? - ???: server can return different answers over time, so it's actually dynamic, right? Lada: client is able to learn up front and doesn't have to refresh. ???: but we want the client to refresh on demand - Juergen: I think I like that a mount point can be augmented into a module without having to update the module (this is a strong point of Lada's proposal), I think I also like to be able to determine from a set of YANG modules what I can expect to be at which location, that is the mount is still schema defined. In other words: in bar.yang: augment /foo:foo { mount if:ietf-interfaces } Chris Hopps: With YSDL are the "mount points" dynamic (i.e., can they chnage per server impementation) or static (i.e. they will always be the same regardless of server implementation)? If I am a client can I code a static path string (e.g., "/lne/1/routing/isis/level") or do I need to first query the server and construct the path from the answer returned (i.e., client: "where is isis", server: "under /foo/bar/isis", client: "/foo/bar/isis/level")? > 20 min: proposal #2 > http://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-00 > https://www.ietf.org/proceedings/interim/2016/02/22/netmod/slides/slides-interim-2016-netmod-1-3.pdf Martin presenting draft-bjorklund-netmod-structural-mount-00: - Lou: on slide #3, under point 2, the library isn't actually there, it's just a reference. Lada: this causes yang-library to become disributed. Martin: different LNEs may have difference modules mounted, an advantage to this soln is that it supports recursive mounts. Lada: disagree with last point (on last slide), in either case the client has to be prepared. Rob Wilton?: would there be any merit to split into separate mounting solutions (in-tree and outside-of-tree)? Chris Hopps: 3rd type: schema-writer could say a very specific model is mounted (set in RFC text) > ?? min: Clemm draft discussion Eric: It looks like we might run out of time today. I am going to place some questions below that either should be addressed on the mailing list, or perhaps we should have another interim call. (These were not fully discussed in the meeting.) (1) Some of the requirements described are in the peer-mount draft, some are not. How do we ensure that we do not preclude a syntax which supports and is extensible for multiple uses? (2) YANG "Mount" is a successful technology in OpenDaylight. A quick Google search shows 830 pages using the term on the OpenDaylight site. Creating an incompable use would be confusing to the industry, especially when considering the overlapping contexts. (3) A requirements presentation on "Alias Mount" was made in IETF 94 which could be adapted for these requirements. Considering all the issues here, a unified requirements document might be worth having for this context. Lou: (some general wrap up discussion): Next step for Martin to update structural-mount based on today's discussion, including ensuring the three different mount methods are documented, correct? Martin: Yes, can do that Lou: Question to Lada re his next step Lada: Not wedded to YSDL and willing to work with authors of other document Lou: Excellent. Then is everyone comfortable with starting with a version of structural-mount updated based on today's discussion as the starting point, i.e., 1st WG draft, as a solution starting point. With expectation that the authors of the related drafts (Martin, Lada and Alex, and other authors) will work together and bring a proposed modified solution to the WG after WG adoption. (general agreement.) Lou: then we will discuss on list once there is the version updated based on today's discussion.