Minutes for NETMOD at interim-2016-netmod-1
minutes-interim-2016-netmod-1-1

[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.