# OPSAWG @ IETF 111 What: Combined OpsAWG / OpsArea When: 16:00-18:00 Friday Session III, July 30, 2021 Where: Room 4 ## OpsAWG Section -------------------- ### Administrivia - scribes, minutes, etc. Tianran / Joe / Henk 5 minutes Joe kicked off the party. Rob and Eliot taking minutes. Status report on published and pending RFCs See slides for details. Rob: I've started the NTF module; it's on the top of his queue. Rob: l2nm drafts in last call Liaison statement from SG 13 on Quantum key distribution Eliot: Did SG 13 specifically ship this to the OPSAWG? Joe: Yes they did, but perhaps OPSSEC would be a broader area? Scott Mansfield: Yes, they sent this directly to OPS area. I working on crafting a response back to SG 13, but also need to add some words from the IRTF. If anyone wants to contribute to the response then please contact me. Eliot: Presuming this is for control and management aspects. There was a discussion in the security area about what to about quantum crypto. Definitely a process kicking off in the security area and might want to sync with Roman about this. Tianran: If this is new then perhaps we could incubate this work within OPSAWG. We then moved on to the agenda. There was no agenda bashing. ### SAIN (Service Assurance for Intent-based Networking) Benoit Claise Draft: https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-architecture/ He reviewed the work; looking at service impact based on component failure. #include "picture from the past.png" ;-) Infers bottom to top health of service, with base components on the bottom. Open/multivendor model. Changes- feedback from a few people Work is better connected with other IETF work Meat is in the next document. Time synchronization is required. Slide 9: Eliot: Is it possible that the model could have circular dependencies? Benoit: I hope that there would be no circular dependencies. Eliot: Perhaps circular dependencies could occur in complex cases, and perhaps the tool could spot these. The model might be useful to find these circular dependencies. Benoit: Potentially. I hope that we are not going to have circular dependencies. Looking at slide 7. Have some subservices, but with different parameters. If we have a way to see circular dependencies but that would be good. Can you provide an example? Eliot: More likely to see this if you go higher in the stack. E.g., application services or container functions, I could very easily see a circular dependency from time to time. Perhaps that is beyond what you were intending to model. Benoit: Going into the application layer is welcome. Ideally want to extend this draft in multiple directions. Lets discuss if we can detect circular dependencies ... Kireeti: ... audio issues. https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/ 20 minutes Slides 10, 11 12: the YANG model Draft Tree shown some model changes Slides 13 and 14: elaboration of the ISIS example from the architecture draft created instances Slide 15: provided guidelines for subservice extensions Slide 16: one open issue Kiriti: tunnels over tunnels may lead to dependency loops, so that's worth checking Benoit: the trick is in the parameters Rob: are parameter specific to subservices or generic? Benoit: example interface id- use an existing definition from a yang module rather than a string or unique TLV. Joe: what are next steps? Benoit: I'll work with Eliot and Kireeti on the dag issue, more feedback please. More code, please. Joe: Hackathon... ### A Layer 2 VPN Network YANG Model Oscar González de Dios Draft: https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/ 15 minutes Slide 2 Two additional modules to be maintained by IANA One issue by Moti Slides 3, 4 EVPN support aligned with other IETF work Slight model changes Kireeti: Can RDs be autoderived too? Oscar: Already included in existing work and this draft. Slide 5: connection container Restructured similar to L3NM. Slide 6: Added active global parameters These are at the service level. Slide 7: six closed issues. Slide 8: Examples added Slide 9: next steps Ready for WGLC - extended due to summer holidays Joe: do you expect to fold in the two new functions before you're done or as extensions? Oscar: as extensions at a later stage Kireeti: we have a prototype implementation Oscar: we can document them in the Appendix and look forward to feedback. ### A YANG Model for Network and VPN Service Performance Monitoring Bo Wu Draft: https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/ 10 minutes Slide 2: background This is complimentary to l2/l3nm. Slide 3: updates Issues raised during adoption were addressed. Added a container for L2VPN MAC entry counter and a leaf of pm-source. Also used defintions from l2nm and added examples. Slide 4: model updates As described in slide 3 Slide 5: next steps Work with Lxnm Design teams More comments needed Joe: pm-source is a string. Why? Would an identity be better? Bo: There may be a great many sources, and the source may not have been modeled, and there may be no standard identity. But it's a good question and an open issue. MUD Related ### Discovering and Retrieving Software Transparency and Vulnerability Information Eliot Lear Draft: https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/ 10 minutes - Summarising changes. - openc2 is not RESTful, but protocol end point. Should get a formal review of draft from OASIS? - Slide should be CycloneDX rather than CyberDX - MUD mainly use for network discovery - But file format may still be useful - Discussing SBOMs for cement drying sensors ... - Some open questions ... - Asking about supporting CoRIM/CoSWID ... - Requesting some early reviews and guidance on security. YANG doctors, security, .well-known. - Aiming for WGLC before next IETF, if possible Questions? Henk: As contributor, like top level semantics of transparency. Aligns with various efforts about supply chain. Regarding CoSWID, says that it is being use for vulnerability informationa and fits well. XXX also included CoSWID as one of the mandatory formats. For MUD, don't worry about content format too much. Consider will this be a CycloneDX expression. Will be useful for customer. Could just add to a list of formats. Regarding CoRIM, definitely uses CoSWID. MUDdy RATS will discover CoSWID. Eliot: Aim is for draft to look at content type. Some of the formats are interchangeable. It may be reasonable to include an accepts-header (when it lives in the cloud), but not so clear that makes so sense when accessing a device. Regarding CoRIM, there are lots of various reglatory constraints. Henk: This shouldn't be big issues and should be able to resolve these in 1-2 months. Eliot: Also need directorate and YANG reviews. Joe: Yes, I will get those done. [AI: Send for DIR reviews, SEC and YANG Doc] ### Ownership and licensing statements in YANG Eliot Lear Draft: https://datatracker.ietf.org/doc/draft-lear-opsawg-ol/ 5 minutes - Simple extension to solve a point problem. - A very small model. - Please can we have discussion and adopt this draft Joe: Seemly like interesting work. Henk: Put the request to the OPSAWG list and we can put that to the WG adoption. Eliot: Once that is done, I will ask for a GENART and YANG doctors review. AI: Get YANG Doc review ### Operational Considerations for use of DNS in IoT devices Michael Richardson Draft: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations 10 minutes Problem: need consistent implementation of name resolution and access control functions Slide 4: dnsop - it's not going to work to do geofencing Eliot: DNSOP folks might not like the solution, but one choice is that queries can be intercepted in the network and then you deal with the response. You manage expectations of cache clients. Important point: Retry request. This problem is oblivated if ??? Michael: That is a good suggestion but that brakes if they do DNS over HTTP. Perhaps should have a strong suggestion that they don't do this. This has to be advice to IOT Manufacturers. Perhaps to check on compliance? Eliot: Need to get advice to manufucturers to be consistent. Consider service volume, and not have to heavily load balance. Nervous about giving device. But better approach might be better to work this on deployement. ### Authorized update to MUD URLs Michael Richardson Draft: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-acceptable-urls/ 5 minutes For some MUD extensions it may be necessary to update the URL The key principle behind the draft is that the origin should remain the same This draft is stable. More reviews, or WGLC. Joe: We should get some directorate reviews. Michael: Yes please. ### PCAP Next Generation (pcapng) Capture File Format Michael Richardson Draft: https://datatracker.ietf.org/doc/draft-tuexen-opsawg-pcapng/ 10 minutes This concept has been around for AGES Some discussion on list PCAP is proposed to be informational to document the format. Needs to go through IETF for IANA considerations. PCAP can't be concatenated PCAPng proposed to be standards track, but need some backward compatibility with existing blocks If doing now would use CBOR's CDDL Lots of IANA registries (mostly FCFS but not standardization required) Eliot: Suggest splitting discussion into two. PCAP is definitely informational. Michael: PCAP outside of IETF refers to lots of things (e.g., getting stuff outside of the kernel.) Eliot: As long as the specification is done, I would support adopting and doing to information. Regarding PCAPng, lots of support in wireshark community for this work to be done in the IETF. Is an RFC the right mechanism? Will work be too fast for us to keep up? Michael: Work is cummulative. Yes new stuff is added. Would have a IANA registration for new blocks that would just be specification required. Deal with a new link type request every couple of months, but that doesn't really matter. But Rob: fellow ADs are fine with the doc going directly to historic. Michael: Yes, that would make sense. Warren: Will we be stepping on peoples' toes? Michael: I run the TCP Dump group, most folks that are active are authors on the doc. I don't think that we are stepping on anyones toes. Eliot: Willing to support adoption of this work. I don't think that new work should be thrown around as random URLs. If the work is going to be done here then let it be done here. Perhaps have a running periodal of updates. Really uncomfortable of just specifying the base work. Michael: I think that you are misunderstanding. Common link types are widely used. Also less usual types. Eliot: If the works coming here then let it come here. Lets have this as an open issue for discussion. Michael: Applies to both PCAP and PCAPng. Let's just publish the PCAP doc as informational. Joe: I had a similar comment as Eliot. Clearly interest, will bring it to the list. Will see what the WG thinks about the NG work. ## Ops-Area Section --------------------- ### Administrivia - scribes, minutes, etc. Warren / Rob 15 minutes - Joe didn't see slides - Welcome to Ops Area; no updates per se - Feedback, comments, stuff we can do better? - No comments - Rob: some suggestion as to whether or not we should have a DISPATCH-y WG in Ops; do we need it? - Michael Richardson: opsawg could function as DISPATCH; scheduling will be difficult otherwise - Rüdiger Volk: agree, but if you find opsawg is overwhelmed with that then something else should be done - Warren: Rob and I would appreciate any feedback on what we're doing well and what we're doing poorly - Rob: you can also send items to NOMCOM as I will be standing for Ops Area Director again - Warren: You can also send my feedback NOMCOM - Eliot Lear: You guys have a good view of other areas; are you finding other areas are doing a good job of highlighting operational issues and making sure they come to Ops? - Warren: It's working, but not as well as it could. We need more people in OPS DIR. Thanks to those that are in OPS DIR, but we need more volunteers for people will to do reviews ### ANIMA WG updates Toerless Eckert 15 - (Slides were not pre-sent and uploaded; but were presented to SACM. Joe will get them uploaded after the meeting) - ANI bootstraps devices out of the box with an secure operational network via the Autonomous Control Plane - Works by defining a "seed" node to act as a registrar (which drives overall process) - Pledges are new devices that desire to be on-boarded into the AN - MASA lets the pledge know it can trust the registrar - ANIMA now going through second charter, pushing Intent out to NMRG - There are IoT on-boarding and MUD adjacencies (some work done at the IETF111 HaT) - ANI presents an interesting environment to automate general purpose network functions while providing secure underpinning - "As long as someone else is doing it, it's automated to me" - ANIMA helps to modernize the idea of a self-driving network ### Open Mic