Minutes IETF105: opsawg
minutes-105-opsawg-00

OpsAWG and Ops Area
Wednesday, July 24, 2019 10:00 am - 12:00 pm -- Av. Duluth
==========================================================

TACACS+ YANG
============

Ignas: No issues with the downref for T+ YANG to informational T+ document

Should the module provide a choice for transport or just handle this with
augment or bis later? Ignas: Only after T+ is ratified would additional work
start, so it might be premature to pre-add support for other transports Joe:
Agree, perhaps an augmentation later on

Ignas: We should augment the authn order here in this draft.  Do the augment
here and inform netmod

Ignas: when will this be "done"?
Bo: Within two weeks we can have changes; Huawei already supports this; feels
this module is stable

SD-WAN Service Module
=====================

Differences between OSE and SD-WAN Service Model
 Tianran: Do both groups agree with the differences as summarized here?
 Bo: Yes.  I am participating in both drafts, and we agree on these being the
 differences

MEF SD-WAN coordination:
    Charles: MEF is aware of this work
    MEF is closed, though some things can be shared.  Doing the work here and
    coordinating back to MEF makes things easier Are we comfortable with this
    unofficial liaison or do we need something more formal?

    Ignas: How much coordination is happening on the requirements side with
    ONUG? Charles: MEF and ONUG have not be able to work together very well;
    but coming to IETF makes that a bit better Both SD-WAN models will likely
    be worked on within MEF

Ignas: Service modeling has more chance outside of the IETF; technology
specific components fit better within the IETF (within technology specific
working groups) Tianran: MEF has already decided the service and they are
looking to the IETF to define the data model around their requirements Ignas:
If we are working on their [sufficient] requirements, then we can progress.
Tianran: We are not going to define the requirements; but  use  MEF Charles
Eckel: MEF 70 is the requirements for SD-WAN; MEF is doing a phased approach;
YANG modeling work could do the work, but would need IETF expertise to help
guide it and comment on it Ignas: Will the requirements be never ending?
Charles: There will be multiple changes (e.g., 70.1, 70.2, etc.)

L3VPN YANG Network Model
========================

Benoit: Great to see operators proposing service models
  Did you get feedback from other operators on SMs?
  Oscar: Yes.  Their intention was to do models from the customer point of view
  not at the provider level

Joe: Do people feel that this work is valuable to do for opsawg?
Room: many hands were raised
Joe: Oscar, take care of the open items you raised in your presentation, and we
can progress this work in opsawg

Network Management Virtualization
=================================

Joe (as a contributor): Reading through the draft, I still get the impression
that this serves as a catalog of IETF drafts.  How do we engage more operators
to address some of the gaps you raise? Qin: This will be useful to leverage
IETF YANG models as an example to help operators understand how we can
interconnect modules to solve problems.  Some of this structure may move to an
appendix, though.

Rob Wilton: Having a general framework of how types of models fit together is
useful.  Having specific modules listed in the draft will be hard to
maintain/track.  That kind of inventory is best left to GitHub or the like. 
You should focus on the abstract architecture.

Liang Geng: Useful to have a framework as a guideline if it can help operators
to know what is being worked on and what the status of modules are so that it
can drive more feedback. Rob Wilton: Agree there is a coordination problem
between operators and SDOs. Qin: Yes, we have heard from a lot of operators at
this meeting that agree this is a valuable framework Joe: I think divorcing the
module inventory from the framework would be helpful.

Frank Brockners: Now, the draft is a mix of specifics and a generic framework. 
What would be useful is to break this up, focus on a few initial use cases
where you do the specific module mapping exercise.  Then, you can up-level this
to the generic framework.  Trying to do both does a disservice to both the
mapping and the generic framework.

Ignas: The framework is good and is needed, but you cannot deploy a framework. 
You also need a set of validated modules that actually work together and are
valuable to operators.  The framework (guidance) should drive the validation of
the work.  What you are doing is in the right direction, but it now cannot be
used today. Qin: We will try and refine this document to make it more generic.

MUD controlller selection
=========================

Eliot: Is there interest in this draft?
Joe: Who has read it, interest?
Room: A few hands go up

Tim Carey: Is MUD turning from a URL to a system?  Need a spelled out framework
to a more systemic framework Eliot: We collapsed a framework document into the
document that became the RFC.  We can discuss offline as to whether or not we
need a more fleshed out framework. Qin Wu: Agree with Tim's comments.  What is
the holistic lifecycle of IoT devices? Eliot: I encourage your draft to spell
this out.

MUD Reporting
=============

Eliot: Is there interested in a MUD reporting tool?
Joe: Interest?
Room: A fair number of hands go up (less people claim to have read the draft)

Qin: Would like a MUD IoT side meeting readout
Eliot: No time, so I can comment offline.

Joe: Please read this draft and comment to the list

MUD TLS
=======

Eliot: Have you implemented this yet?
Dan: Yes, Tiru at McAfee has implemented this.
Eliot: Would be good to see others participate in a Hackathon to get more code
implemented for this.

Benoit: Maybe it's time to centralize MUD work in its own WG to channel
interest? Qin: There is a research group on IoT.  How is MUD coordinating with
that? Eliot: I have presented occasionally to t2rg. But this isn't
thing-to-thing.  This is about thing to network.  MUD and t2rg do talk. Joe:
There is more work around captive portals being discussed on opsawg.  Maybe it
is time to give MUD a dedicated home. Eliot: There was previous discussion
about where to do this work.  A question to consider is what is the scope of
the work?  Do we expand this to bootstrapping/onboarding for IoT? Joe: More
discussion to happen (for the sake of time)

In-situ Flow Information Telemetry (iFIT)
=========================================

Shwetha Bhandari: This document reads more like a whitepaper describing a
solution than a framework.  It is confusing as to whom the target is and how to
use it.  It has a number of references to work which has not been ratified. 
Instead of being a standalone draft, the content herein could be provided as
feedback directly to those works in flight. Haoyu: The techniques described
here are quite new (the work in progress are still drafts).  This work is meant
to be informational and act as a collection point for operator feedback. 
Another goal is to provide best industry practices and help the IETF evolve
these techniques. Shwetha: Documenting deployment experience would be useful,
but that is not in here yet.  Additionally, there are algorithms mentioned that
would be useful to optimize the work in flight, but the specifics are not in
here yet. Joe: Because of time, we need to move this discussion to the list.

IOAM Raw Data Export with IPFIX
===============================

Joe: How many have read this draft?
Room: Only a few hands
Joe: Is there work on doing this work in opsawg?
Room: Not a lot of hands
Joe: Take the question to the list

Ignas: This could become an AD sponsored document.
Warren: Where would it get more reviews?
(Will address that when asking on list)

Ops Area Session
================

Ignas: Are there any additional thoughts on where to do the MUD work?  Is there
a large community for general onboarding? Qin Wu: I would like a central place
to do all of these IoT-related work. Joe: I like the MUD work in the opsawg,
but there are a lot of side channels that exist.  So it may be beneficial to
have this in a central, dedicated group. Joel Jaeggli (channeling Darshak
Thakore): A central place for onboarding would be nice, but that should not be
homenet. Ignas: Having work decentralized might result in faster ratification
work.  If we move to a dedicated WG, that would potentially add more overhead
(e.g., charter) Qin: [I did not catch all of Qin's comments] Benoit: In the
past, when we saw that we saw we had a number of energy-related drafts, the AD
just created a charter for that work and spun up the work.  We don't always
have to go through the full set of requirements, framework, etc.  It can be as
"lightweight" as the AD desires. Ignas: It would also be up to the WG to agree
to that.  We should not try to overthink this.  If new MUD work will just be
extensions, perhaps it is best to have that happen in opsawg.  If, however, we
are looking for a more all-encompassing architecture for IoT and onboarding,
that would warrant a new WG.  Please express opinions on the list.