Skip to main content

Minutes IETF110: opsawg
minutes-110-opsawg-02

Meeting Minutes Operations and Management Area Working Group (opsawg) WG
Date and time 2021-03-12 12:00
Title Minutes IETF110: opsawg
State Active
Other versions markdown
Last updated 2021-03-16

minutes-110-opsawg-02

Opsawg WG

Introduction

Henk brought the meeting to order, presented the Note Well. He then gave a status. RFC 8969 published. Two drafts submitted to IESG. Several drafts have been adopted.

Then the agenda was presented. It was huge. There was no bashing.

draft-ietf-opsawg-vpn-common

Mohammed presented.

Model reorganized to make it easier for people to digest. Scope expanded to data centers.

Ready for WGLC?

draft-ietf-opsawg-l3sm-l3nm

Oscar de dios presented.

Technology section aligned with other efforts. Trees in the model were updated. The model is big, so they split it up into smaller parts. Better clarity about managing loopback interfaces. Lots of modeling updates. Lots of issues in github were addressed (see slides).

No pending issues; Ready for WGLC?

draft-ietf-opsawg-l2nm

Samier Barguil presented

Got a routing directorate review, and there are a number of open issues, and a number of issues have been closed.

Requesting expert review for EVPN.

Discussion

Rob/Joe: how are these docs interrelated?
[missed answer]

Rob: should I hold these documents until l2nm is done?

Med: don't personally see a value of holding the doc.

Eliot: are issues being addressed on list?
Joe: Maybe some are being addressed in Github, but they have to be come back to the list.
Med: there are weekly meetings. Yes, we do discuss issues on Github.
Eliot: just post notes from weekly meetings to the list.
Rob: just handle the editorial ones, but you should bring resolutions to the WG.
Warren: post decisions and summary as to the logic beyind it.

Joe: Expert EVPN review was done. Do you need something more formal in the data tracker?

{A bit of discussion about GH issue organization}

draft-ietf-opsawg-yang-vpn-service-pm-00

Bo Wu presented.

Model is used between service orchestration and network controller. Model augments RFC 8345.

Open issues:

  • Major issue? Reference RFC 8309
  • Clarify L2 info
  • Add more examples

Next Steps:

  • Address pending issues
  • Get review from L?NM teams

Joe: have more of the discussion here would be helpful to stir more comments.

Bo: this draft hasn't regularly been discussed.

Export of MPLS-SR Label type Information in IPFIX

Thomas Graf presented.

Point is to add MPLS-SR to IPFIX.

What's needed:
- A bunch of IANA registry definitions
- The registry needs a bit of cleanup.
- This is something that is being worked on.

Taken input from MPLS wg, IE46 registry.

Would like call for adoption here.

Rob: this registry allows anyone to add them.
Benoit: still worth publishing a doc to explain background. Benoit will review.
Thomas: First went directly to IANA. IANA requested an official document.

Rob: adopting this is the right thing to do.
Joe: Benoit is on the hook to review.

draft-ietf-opsawg-sbom-access-00

Eliot Lear presented.

Now a WG draft

Currently working on editorial changes for -01

While adopted, the intent is to slow-roll this document to build operational experience.
There might be some implementation drafts forthcoming.

Open Questions:
- Should we support one or multiple SBOMs out of a single system?
- How would multiple SBOMs be returned/stored?
- How to fully determine if a vulnerability has been fixed in a piece of software (even if the version doesn't change)
- Remove SWID references in lieu of CycloneDX references?
- Examine work of ROLLIE

Jeff Haas (via Chat): Should the sbom actually be a recursive set of manifests? A component may contain other components that have manifests. Groups of components are used to build a system. Etc.
Eliot: Yes, an SBOM should be a set of manifests, but how this is conveyed to be determined, which is why this is being slow-rolled in order to build more insight as to how
best to do this
Henk (as individual): Yes, there can be dependencies between SBOMs and they can point to each other. These interdependencies should be discoverable. With respect to examples, this should
be technology-agnostic. With respect to Cyclone, there should be more (three, perhaps) to maintain agnosticity.
Eliot: Will follow up on list.

OpenMetrics

Richard Hartmann

Promethius discussion.
Wide organic adoption since 2012 with millions of installations.

OpenMetrics

There were some competitive/political issues, so they wanted to have a neutral name, and then do a really careful evolution.

There is ecosystem interest.

Goto-san: supports adoption.
Tianran: what do you want to standardize?
Richard: wants to standardize both the data model and transport.
Benoit: we have many different definitions of interfaces, with yet another data model to map somewhere somehow.
Eliot: informational doc to get 1.0 out. will community show up?
Rich: yes, this is our general intent. There is also Open Telemetry.
Warren: yes, make it an informational doc; also has some concerns that we will get good representation from the community.
Rich: "We are committing to work on this stuff here."

qlog - QUIC logging

Robin Marx

We like data to analyze, but it's more difficult for QUIC {encryption, etc}. Not all protocol aspects are reflected on the wire.

Pull flows from both ends and from intermediaries. qlog is a single format/single schema. What does a received packet look like? How should congestion control be linked? qvis tool can ingest all of this fun stuff. This stuff could be used for more than just QUIC. DNS, other things.

There's a certain lack of experience on these aspects.

Some of the challenges:
- formats and datatypes
- privacy
- manageability

Uses JSON. Evolving to an ad hoc data definition language.

In theory we could scrub logs, but for some use cases we might need raw IP. What is the santization approach? Tagging of individual fields.

On manageability, what can we do better? Spinbit/lossbit woes. Could we use sanitized qlogs to help monitor performance of end-to-end connections.

Next steps:
- for now stay in QUIC WG. Can you join us there?

Jeff: Give a good look at YANG. It can handle multiple serializations (JSON, CBOR, etc). You will need a common header.
Henk: Maybe synergize with PCAP format.

Rob: quick poll on interest to do work here:

12 hands raised.

Rob will talk with Martin and others about where this work should take place.

draft-mvmd-opsawg-ipfix-fwd-exceptions

This is proposal extends IPFIX to describe exceptions that caused a dropped packet.

Changes since 109

Additional description of nexthop ID. Not considering CBOR/CCDL.

Next Steps

More feedback
WG Adoption?

Thomas Graf: very welcome from a network operator's perspective. What is the main benefit of the new fields? IPFIX 89 has a "dropped". Further clarification on next hop ID.

Shivam Vaid: for a given box there is a relationship between the collector and the reporter. There are differences in behaviors between vendors, we want only organic data to simplify performance matters. {Long explanation followed}

Next steps: WG adoption?

Joe: please take this to the list.

draft-claise-opsawg-service-assurance-archiecture-04 and draft-claise-opsawg-opsawg-service-assurance-yang

Presented by Benoit Claise and Benoit Donnet.

Benoit Claise began.

Fault location and root cause isolation. Which service is impacted? Sub-services. Uses an assurance graph.

Controller/orchestrator architecture

Want to standardize the interfaces.
Not going to standardize the actual boxes in the architecture.

Interest level?

Benoit Donnet then continued on the diagnostic agent.

Main goal: evaluate SAIN architecture with open source tools, use cases etc.

{Explanation of demo code for dxAgent}

Adam Montville: May be a question with an obvious answer, but would SAIN be useful for security assurance in addition to operational assurance? For example, assuring that network devices/components are configured in conformance with a security checklist like a CIS Benchmark or DISA STIG?
Benoit Claise (via chat): short answer, yes. Longer answer: yes, if you can translate your security checklist into an (assurance) graph

Med: How is the service assurance graph designed?

Benoit: no free lunch. domain expertise is required.

Rob: yes, this is something we should be working on. Good topic for the IETF. Is this the right model? More discussion required.

Benoit: what is the right formal language to use in this context?

Qin: very valuable.

Conclusion of OPSAWG

Ops Area

Warren presented.

iotops had its first wg meeting.

Rob: we could use some candidates for wg chairs.
Warren: this is for the entire ops area.
Ops Hour starts after this session.

Class dismissed.