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