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

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.

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.

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
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
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
10 minutes

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
5 minutes

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
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
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
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

ANIMA WG updates

Toerless Eckert

Open Mic