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.