Minutes IETF103: opsawg
minutes-103-opsawg-02

What: Combined OpsAWG / OpsArea
When: 16:10 - 18:10        Tuesday Afternoon session II
Where: Chitlada 2

OpsAWG Section
--------------

Administrivia  - scribes, minutes, current draft status, etc.

Minutes taker: William Lupton
Jabber Scribe: Joel Jaeggli

Tianran / Joe
10 minutes

YANG Data Model for Composed VPN Service Delivery
Roni Even
Draft:
https://datatracker.ietf.org/doc/draft-evenwu-opsawg-yang-composed-vpn/
15 minutes

randy bush: had commented on list re multi-company issues; not in scope of
current draft joe: this draft is very different from 2016 draft and doesn't
appear to address issues raised in 2016 tianran: this idea was proposed two
years ago, and there was some concerns then. The service delivery model exists
conceptually, but it's hard to identify  between the service model and device
model. roni: will try to address security and security assumptions

SD-WAN Service Model
Bo Wu
Draft:
https://datatracker.ietf.org/doc/draft-sun-opsawg-sdwan-service-model/
15 minutes

ignas (as contributor): expected requirements to flow from ONUG to IETF rather
than vice versa bo: don't see it this way take offline...

charles eckel: MEF also very interested in SD-WAN and also talked to ONUG; MEF
looks to SP whereas ONUG looks to customer; MEF is working on architecture (?)
and YANG model; should try to align bo: we're defining missing components
tianran: this is a service model, which is not so usual in IETF ignas (as AD):
how should the work be done? should be driven by requirements rather than by an
implementation joe: what has ONUG said about this? bo: have asked them for
comments on the draft; not received any yet ignas (as AD): ONUG have a meeting
in December and will finalize their requirements then randy bush: IETF has a
long history of standardizing people's implementations! joe: this might be a
very specific approach; maybe need to scope this work differently; will
continue discussion on the list
 - Joe has since followed up to opsawg@ regarding technical issues

TACACS+ YANG Model
Bo Wu
Draft:
https://datatracker.ietf.org/doc/draft-zheng-opsawg-tacacs-yang/
10 minutes

bo: already received comments from Juniper that the approach is quite different
from the RADIUS approach; plan to address this in the next draft joe: I would
have said this too! is there support for this? ebben aries: already commented
offline; yes we need this eliot lear: which should we do first? update TACACS
or work on the model? benoit: yes it's nice to have it but it's low priority
ignas: both RADIUS and TACACS are universally deployed; need to define the
hooks that allow extension to future versions of both chairs: take it to the
list

IoT On-boarding
Eliot Lear
Drafts:
https://datatracker.ietf.org/doc/draft-lear-eap-teap-brski/
https://datatracker.ietf.org/doc/draft-friel-brski-over-802dot11/
https://datatracker.ietf.org/doc/draft-lear-brski-pop/
20 minutes

randy bush: two missing rows: (1) what happens to me when the manufacturer
fails? (2) what happens to me when I want to sell the device to someone else
with a non-cooperative manufacturer? eliot: yes, they should have been listed
steve mccann (sp?): 802.11 has just completed some work that could ease SSID
selection; 802.11aq amendment (includes lightweight mDNS over 802.11) michael
richardson: to address randy's questions: distinguish low-value equipment where
the manufacturer won't support ownership transfer from high-value equipment
where they will; what about the mid-value equipment in between? really should
address this case... maybe the voucher should indicate whether the device is
still supported? eliot: yes, should work on these issues; there's a
side-meeting... dan martins: might be better for the network to discover the
device (this is how DTP (DPP?) works); this solves a lot of problems eliot:
will take this to the side-meeting dave robin...(sp?): many devices don't
listen, so network-initiation often won't work

MUD Extension: Bandwidth Usage
Eliot Lear
Draft:
https://datatracker.ietf.org/doc/draft-lear-opsawg-mud-bw-profile/
10 minutes

ted lemon: it's interesting; what about exceptional usage such as firmware
updates? eliot: probably don't want to reveal such info joe: is there a plan
for WG adoption? eliot: would like to collect more comments then discuss with
the chairs

Network Telemetry Framework
Haoyu Song
Draft:
https://datatracker.ietf.org/doc/draft-song-opsawg-ntf/
10 minutes

rob shakir: not useful to draw distinction between control and management
planes; will have up-hill struggle to make this useful; things are changing
rapidly both inside and outside IETF; also, document scope is too wide benoit
claise: sympathize with rob here; at least the management, control and data
planes are likely to merge over the next few years rob shakir: could be clearer
and more forward-looking to define the mechanisms and their attributes joe:
maybe elements of this belong in IRTF, e.g. closed loop and intent haoyu: feel
that the planes are distinct; left-hand side on slide 2 illustrates the
differences ignas: what about the requirements? where is it applicable and what
does it solve? which verticals, operator groups and users? is it addressing
real problems or is it more of a feasibility study into what can be done haoyu:
it's solving real problems (some are listed in the draft) robin (other name;
li???): discussed with OTT customers and operators who think it's useful; much
of the work has already been done rob shakir: should consult with operator
groups joe: of the people who've read it, quite a lot support adopting the work
(but some oppose) ignas (as AD): there is valuable information here, but it's
not suited for an RFC or for IETF joe: should bring it to other groups, e.g.
NMRG and other users, e.g. operator supports

In-situ Flow Information Telemetry Framework
Haoyu Song
Draft:
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/
10 minutes

joe: who has read the draft? not many; should re-ask the questions on the list;
have you asked operator groups? haoyu: yes; they are interested in this and
don't have current solutions joe: reiterate: should re-ask the questions on the
list

Ops-Area Section
----------------
Administrivia - scribes, minutes, etc.
Ignas
5 minutes

ONUG: informal agreement that they will collect requirements for SD-WAN models;
will do something by the December meeting

IPFIX Bulk Sampling YANG Model
William Lupton
Draft:
https://datatracker.ietf.org/doc/draft-boydseda-ipfix-psamp-bulk-data-yang-model/
10 minutes

benoit claise: agree with most of the proposals; the bulk data model isn't
present in the draft so it seems natural to regard this as phase 2 dave
sinicrope: draft authors have tight timescales; want confirmation that "phase 1
and phase 2" doesn't imply and RFC and then a later RFC benoit claise: ok

Open Mic

benoit claise: how to manage creation of SD-WAN models? rather than IETF doing
the work, use the YANG catalog to collect models and rely on evolution ;
additionally, should these service models be published asynchronously for
testing (akin to open source model)? ignas: concern is that this organic
approach might not result in something usable