Minutes IETF111: opsawg
minutes-111-opsawg-00
Meeting Minutes | Operations and Management Area Working Group (opsawg) WG | |
---|---|---|
Date and time | 2021-07-30 23:00 | |
Title | Minutes IETF111: opsawg | |
State | Active | |
Other versions | markdown | |
Last updated | 2021-08-04 |
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