Thank you all who joined today’s virtual interim meeting. Other than my starting the recording late and rearranging the presentation order, I thought that the meeting went really well in that there seems to be a lot of support for trying to solve this problem, and because we have a plan to try to move towards having a WG document in the BA timeframe. The plan is for draft-bjorklund-netmod-structural-mount to be updated based on the meeting and for it to be discussed on list as the basis for the WG effort on the topic.
Attached are the very rough Ethernet minutes captured during the meeting. Please review carefully. Corrections can be made on the etherpad here: http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222 (so we can track changes, the end of meeting snapshot is here: http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222/timeslider#3933) To listen to the recording, please follow one of these two links: Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=4dc88386f13a49fa8f2c934db953f4a2 Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=1b6490fe5cc6fc95d4e3c9b913dfdc1f Thanks again, Kent and Lou On 2/22/16, 8:23 AM, "netmod on behalf of Kent Watsen" <[email protected] on behalf of [email protected]> wrote: > >Friendly reminder, this meeting starts in about 90 minutes. > >Cheers, >Kent > > > > >On 2/10/16, 10:46 AM, "netmod on behalf of IESG Secretary" ><[email protected] on behalf of [email protected]> wrote: > >>The NETCONF Data Modeling Language (NETMOD) WG will have a virtual >>interim meeting on 22 February 2016 at 10:00 EST (15:00 UTC) to discuss >>use-cases and solutions for combining YANG modules into the schema >>defined in other YANG modules, as this is a blocking item for some other >>working groups currently. The agenda for the meeting is: >> >>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 >> >>All participants should come prepared to discuss these drafts. >> >>Note: it is understood that draft-clemm-netmod-mount is related work, >>but the chairs wish to only focus on the schema composition issue at >>this time. >> >>Etherpad: http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222 >> >>Regards, >> >>NETMOD Chairs >> >>-- >>NETMOD Virtual Interim Meeting >>Monday, February 22, 2016 >>4:00 pm | Europe Time (Berlin, GMT+01:00) | 2 hrs >> >>Join WebEx meeting: >>https://ietf.webex.com/ietf/j.php?MTID=me171803d3dfe83d3f0d003f8332b032f >>Meeting number: 646 684 956 >>Meeting password: Qbds3nPZ >> >>Join by phone >>1-877-668-4493 Call-in toll free number (US/Canada) >>1-650-479-3208 Call-in toll number (US/Canada) >>Access code: 646 684 956 >>Toll-free calling restrictions >> >>Add this meeting to your calendar. (Cannot add from mobile devices.) >>https://ietf.webex.com/ietf/j.php?MTID=mf4e7a67f2b45f6542947fa3464d35e05 >> >>Can't join the meeting? Contact support. >> >>IMPORTANT NOTICE: Please note that this WebEx service allows audio and >>other information sent during the session to be recorded, which may be >>discoverable in a legal matter. By joining this session, you >>automatically consent to such recordings. If you do not consent to being >>recorded, discuss your concerns with the host or do not join the >>session. >> >>_______________________________________________ >>netmod mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/netmod >_______________________________________________ >netmod mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/netmod
[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.
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
