[OPSAWG] Draft minutes from OpsAWG meeting.

[Warren Kumari <[e-mail]>]

Hi all,

I'd missed the fact that we only had a minutes taker for the first
part of the joint OpsArea / OpsAWG meeting. Anyway, I listened to the
audio recording on a long flight last night, and created us some
minutes - in a few cases the audio was't quite clear enough to get
names, apologies if I misattributed your comments.

These are draft minutes, and I plan on submitting them soon, assuming
no-one finds any glaring mistakes.

-------
OpsAWG Minutes.
-----------------
Audio filename: ietf89-buckingham-20140304-1610-pm3.mp3
OpsAWG portion of meeting starts at: 01:01:30


Agenda bashing.
Document summary.
 - 3 documents with IESG.
 - 5 Working Group doc, all being presented today.
 - Published RFC7124.




Management Information Base for Virtual Machines Controlled by a Hypervisor
draft-ietf-opsawg-vmm-mib-00
Hirochika - 5 minutes.
1:05:00
----------------------
Draft updates.
MIB Objects for MV Controlled by Hypervisor.
  MIB to be installed in Hypervisor, not the VMs.
Summary of changes - comments form last IETF, editorial primarily.
  Clarify objectives, etc.
Added relationship to other MIBS.
Discussions on the R/W SNMP MIB bits.
  We removed the persistant config part.
  Still have some on the operational state part.

Questions / comments:
Al Morton?: Surprised not to see VM utilization in this.
A: We install an agent on the VM and use the host object mib.
Basically this covers stuff not in host resources MIB.
Scott Bradner: With regards to vmaxmem. I think this violated spirit
of IESG SNMP statement. Don't want to solve here, but we should have a
discussion with the relevent IESG folk.
A: Yup.



CAPWAP Extension for 802.11n and Power/channel Autoconfiguration
draft-ietf-opsawg-capwap-extension-02
Dapeng Liu - 5 minutes.
1:11:30
---------------------------
Draft updates.
>From last meeting:
  Editorial review, editorial changes.
  Need IEEE Expert review
Status:
  Thanks to Tom Taylor for editorial review / suggestions, and
technical discussions. All on -03.
  New version uploaded today.
  On expert review: Haven't started yet. Dorothy cannot attend (conflict).
    TODO (Authors): Plenary in March - hope to do conflict review there.
Hope after that's done to do WGLC.
Chair: Many folk have read this.



The CAPWAP drafts
Comments/discussion on draft-ietf-opsawg-capwap-hybridmac
Comments/discussion on draft-zhang-opsawg-capwap-cds-01
Rajesh Pazhyannur - 15 minutes.
1:15:00
------------------------------
MAC profiles - draft-ietf-opsawg-capwap-hybridmac
Problem Statement:
  CAPWAP RFC - describe split MAC "profiles".
  Enc / dec could happen at AP or controller.
  No way to configure which.
  This draft fixes that - removes ambiguity.
Updates:
  Editorial. Add more descriptive text, why solving this.
  TODO (Authors): Fix typo in Table 1.
Chairs: A few have read. Most of those think a good idea.
TODO (Chairs): Start WGLC.

draft-zhang-opsawg-capwap-cds - 1:20:00
Currently supported CAPWAP architectures.
Overview of new tunneled mode.
Problem statement:
  APs managed by controller, want to tunnel traffic to differnt endpoint.
  Maybe using differrnt protocol.
Updates:
  More descriptive text.
  More technical content - new information element.
Have evidence of support onlist from number of carriers - CMCC, AT&T.
Cisco is supporting this - we have running code, hope to be shipping
in 3-4 months.
Would like Adoption.

Questions:
Dan: Do you know if you are the only vendor doing this?
A: If we were the only vendor we wouldn't be pushing this here. Want
interoperabile. Maybe Hauwei.
Dan: (Comment) - Don't want to conflict with IEEE. This is a change in
architecture. We only have a few CAPWAP contributors here.
Should this be done in OpsAWG or shoild we have another WG with more
focus on it?
A: Change is introducing tunnel mode. Tunnel parameters will be done
in other groups, with more knowledge of that.
Melinda: We are fine with it here (Minute taker note: I'm assuming
that means Melinda will handle the docs :-P)
Benoit (AD): Let's just do it here. Lots of process to spin up new WG,
looks like the same folk will do it here or there.
Joel (AD): Don't care where we do work, but don't want to shoot IEEE
in the foot. Let's coordinate with them.
TODO (Chairs): Send liasion type thingie to IEEE to ensure not
stepping on their toes.
TODO (Chairs): Assuming no conflict, send adoption call.



The COMAN drafts:
draft-ietf-opsawg-coman-probstate-reqs-01
draft-ietf-opsawg-coman-use-cases-01
Ersue, Mehmet  - 15 minutes.
01:41:00
---------------------------------
draft-ietf-opsawg-coman-probstate-reqs
Updates:
  Bugfixes, updates, better focus, new terms. better security
considerations. Deleted apendixes.

draft-ietf-opsawg-coman-use-cases
Updates:
  Was more work.
  New section on access technolgies.
  New use case, shortened military.
Open issues:
  Better align security considerations sections.
  Section 3.11 - may need to be reworked if IETF doesn't like this
kind of use case.
  Sections 3.8, 3.9 - merge?
We thought we were done, then got a bunch of additional comments.
  Have to address them, then think ready for WGLC.
  Fair bit of work, but look valid / useful.
Comment (name?): Working on similar things on CORE, might be
interesting to folk.


Network Configuration Negotiation Problem Statement and Requirements
draft-jiang-config-negotiation-ps
Brian Carpenter - 15 minutes.
01:47:00
----------------------------------
First time talking about this in this WG.
Context:
  Desire to decreate (well, stop increasing) operational costs in
carrier networks.
Autonomy of config should help with that - "plug and play for the ISP".
Devices should configure themselves.
  Need to negitiate with each other.
Want to make this practical, not just a research topic.
Model derives from routing protocols.
How can we extend this to all types of config.
Less hirarchy.
Devices need to learn from other devices - config decided in compatiable manner.
Draft - analysis of scenraio, design requirmenents. Looking if any
existing protocols are a good match.
Need generic protocol.
Want no human intervention, and support dry run.
Network itself can setup resources on other devices, and automated recovery.
Need strong auth between devices.
Allows better use of resources.
Looked at netconf / rsvp - not good fits.
Questions:
Mehmet Ersue: Have you looked at RestConf in NETCONF WG? Might be a good fit.
A: Nope, hadn't seen that. Not interesting in owning our own protocol,
will look at that.
Wes George: Also look at opsawg-automatic-network-configuration. It is
related / overlap in considerations. Might be interesting / useful to
you.
A: Looked at it, we went further, will look again / more.
Stefan Winter: Been following this, I'll talk about automating edge in
a bit. Are edge devices in scope?
A: In abstract, everything is in interest.
Brian: Are folk interested in this here?
A: Some, not a huge number of hands.
Wes George: I think there is a problem here to discuss. Scale of
problem is tricky. Defining the problem / use case is important, lots
of work in differnt places.


Update on ETSI NFV Management & Orchestration WG
Ersue, Mehmet - 10 minutes
2:09:00
------------------------------------
Overview / update on work on ETSI NFV Management and Orchestration WG.
Quick overview.
  Which bits do what.
Progress:
  Adopted interface approach.
  Cleaned up descriptors and information elements..
  Discussion on architectural improvements are ongoing,
  IETF, 3GPP, DMTF, TOSCA and OpenStack gap analysis are in development.
Big list of described interfaces.
Next step.



draft-winter-opsawg-eap-metadata-00
Stefan Winter - 10 minutes
02:18:00
---------------------------
Purpose:
  Securely configuring EAP on edge devices.
Problem:
  EAP is a container. It's tricky for end users to configure, many parameters.
  Let's make this simpler.
  Devices can have multiple methods, priority?
Draft:
  A way to send EAP peer configuration to the user, and have them
import the config.
  Especially an issue in BYOD, with long PDF instructions.
  We keep hearing it's too hard to make work properly.
  Many implmentations offer shortcuts, which often make things insecure.
  We propose a standard way to ship EAP configs around and allow users
to import these.
    XML or JSON, or something?
  We have an actual implmentation!
    Currenty produces the vendor versions, and the spec in this draft.
    Have clients that read these XML, for Linux and Android.
Questions:
Name?: I propose YANG, I rewrote the XML schema into YANG. I might be biased :-)
A: We wrote the XML first. Can change to YANG if folk want.
Benoit: I like the idea. I like that you have implementation. Might be
worth getting vendors to say that they like it.
Ern ?: I like this. Don't care about format. Still no standard way to
get data to clients.
A: We looked how Apple does it, but this doesn't include a method for
that. [Audio cuts off / truncated.]



-- END --