OPSAWG IETF 118

Monday November 6th. 13:00pm

Initial revision of the WG Status done by the Chairs.

Adopted Work Section

1. IPFIX Fixes / Enhancements
   Mohamed BOUCADAIR
   Drafts:
   https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/
   https://datatracker.ietf.org/doc/draft-ietf-opsawg-tcpo-v6eh/
   https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/

   Presenters: Benoit Claise & Mohamed Boucadair
   Four IEs to report multiple changes in the IPV6 Header. It is
   including a dependency reference between the whole set of IEs.
   Authors considered Destination options and hop-by-hop options are
   out scope.
   Joe Clarke: Asked for opinions on this.
   Rob Wilton: Agrees with leaving it out scope and starting a new
   process to include it, only until it is nedeed.
   Joe Clarke: No need to split to separate docs unless necessary.
   [On question of whether to split docs: One of TCP and another one
   for IPv6 EHs]
   Authors asked to WGLC for the I-Ds presented.

2. A YANG Data Model and RADIUS Extension for Policy-based Network
   Access Control
   Draft:
   https://datatracker.ietf.org/doc/draft-ietf-opsawg-ucl-acl/
   Presenter: Qiufang Ma
   Joe Clarke (contributor hat): Why did the group id change from
   an integer to a string?
   Qiufang: Because it is easier to encapsulate? [I didn't get the
   end, but perhaps covered by the next slide anyway]
   Med(chat): Joe, the rationale for the change of the id to string
   can be seen at:
   https://github.com/boucadair/policy-based-network-acl/issues/8. I
   think we need to have some text about this echoed in the spec.
   Joe(chat): Yes. The hierarchy sounds interesting, but there is
   no text to that effect.
   Joe Clarke: Please send details of the side meeting to the list.

   Med(chat): Added an issue for this point:
   https://github.com/boucadair/policy-based-network-acl/issues/33

3. A Data Manifest for Contextualized Telemetry Data
   Draft:
   https://datatracker.ietf.org/doc/draft-ietf-opsawg-collected-data-manifest/

   Presenter: Jean Quilbeuf (remote)
   Rob Wilton: On the example on the right (slide 4), when you send
   the data does it get sent when the subscription(?) is set up, or do
   you send more frequently?
   Jean: Idea is to have an onchange subscription. Only when there
   is a change in the subscription configuration do we need to update
   it. Onchange works for this.
   Joe Clarke: There is a side meeting on Tuesday 16:00 to 16:30 to
   see the integration with Topology (RFC8345), so session is open to
   add comments on this draft.

Other Work Section

1. An Information Model for Packet Discard Reporting
   Draft:
   https://datatracker.ietf.org/doc/draft-opsawg-evans-discardmodel/
   Presenter: John Evans
   Greg Mursky: You refer to active and passive. Are these as
   described in RFC 7799?
   John: Use active monitoring to mean probes on the network to
   detect loss and passive to mean data direct from device
   Greg: RFC7799 established 3 types: active, passive and something
   in between. Hybrid can be seen as onpath telemetry. Data traffic can
   be enhanced to instrument monitoring perf. By active do you mean
   injecting test packets specifically constructed as well as using
   hybrid.
   John: Don't mean hybrid. Really mean passive. Hybrid not
   fundamentally solving the problem.
   Greg: Still believe hybrid could be used in some cases.
   John: Focus here is on unsampled accurate measuring, measuring ?
   loss with cause.
   Greg Mursky: When you have measurements, is there an evaluation
   step that decides whether we are above/below the threshold for
   tolerance
   John: Yes. Covered more later in slide 11.
   Rob Wilton: Anything that clarifies the meaning of the counters
   is great. Want to get more towards the data models and information
   models though.
   Rob (continued): Do still wonder when it comes down to
   populating counters, sometimes it's hard because the counters
   doesn't quite match the model. It's always a bit of a compromise
   about how you "fudge them in". Maybe add an exceptions counter for
   this?
   John: Any classification scheme doesn't have a perfect fit. But
   would like vendors to expose the underlying mapping to the classes.

   Rob: When the MIB counters were defined, as the hardware evolved
   they moved towards the meaning of the MIB counters (over a long
   time, say 20 years).
   Thomas Graf: Have you considered increasing the scope not only
   for dropped packets, but also to include causality eg of packets
   sent to the control plane?
   John: Trying to keep this work clean on discards. But same
   concepts would apply to other areas.
   Thomas: See some relationship with ipfix + forwarding status.
   Have another document updating forwarding status. A few reason codes
   not supported there. Would be interesting to see how those reason
   codes could be updated.
   Benoit Claise: The information model is important and the
   mapping needs to be right. For [notetaker didn't catch this] have
   4 different states: unknown, forwarded, drop and consume. Doesn't
   quite go into the detail you want, but is what you're trying to do.

   John: (general agreement)
   Joe Clarke: These various questions/points Would be a great
   discussion to have on the list.

2. Incident Management for Network Services
   Draft:
   https://datatracker.ietf.org/doc/draft-feng-opsawg-incident-management/

   Presenter: Qin Wu
   ShowOfHands: Is there interest in adopting this draft? 18 yes, 1
   no, 59 no opinion
   Joe Clarke: Might be worth taking to the list.
   Rob Wilton Slide 6. Not clear how you correlate the two alarm
   layers together. Also, are you reporting these as separate layer
   alarms or combining them together into a generic "incident alarm"?
   If you define a generic incident alarm, interesting problem about
   how you preserve alarm-specific data.
   Olga Havel: Wanted to comment about relationship to topology and
   layering. Different things topology needs to connect to. Maybe it
   would be good to do it in some generic way from the topology itself.

3. Applying COSE Signatures for YANG Data Provenance
   Draft:
   https://datatracker.ietf.org/doc/draft-lopez-opsawg-yang-provenance/

   Presenter: Diego R. Lopez
   Alex Huang-Feng: For the CBOR encoding it would be transparent
   as JSON so no issue.
   Alex (continued): Also have a comment about how to validate the
   message. This signature placement is important and the way you use
   it breaks validation. How can you know whether there is a signature
   or not because you're changing the Yang module. Could place the
   signature in the yang push header?
   Alexander: Don't need to modify Yang push. Believe it can be
   easily accommodated.
   Rob Wilton: Yang packages draft: one concept being considered
   there was adding checksums to the files. Was removed from the latest
   version because people weren't sure whether it was a necessary
   complexity. One thing we were struggling with is: what is the
   checksum of a Yang file? eg does it include whitespace or is it
   based on a canonical representation of the file? Not giving a
   specific direction, just want the author to be aware of this as a
   potential issue.
   Joe Clarke: Sounds like there's potential for discussion on
   this.

4. Mapping YANG Data to Label-Set Time Series
   Draft:
   https://datatracker.ietf.org/doc/draft-kll-yang-label-tsdb/
   Presenter: Kristian Larsson (remote)
   Joe Clarke (contributor hat): Notice that you mapped the path
   separator as an underscore as well as you mapped dashes to
   underscores. Seen in other projects that path separator gets mapped
   to two underscores.
   Kristian: Excellent suggestion. Will touch on it in slide 4.
   Rob Wilton: What is the overlap with Thomas's work on Kafka
   schema, etc.
   Thomas Graf: It complements very well with the work we're doing.
   At the end we need TS data. The work we are proposing is preserving
   the yang push message and the schema end-to-end.
   Benoît: YANG (streaming telemetry) in TSDB is necessary next
   step for the industry. Thanks Kristian.

Ops-Area Section

Administrivia - scribes, minutes, etc.
Warren / Rob

Open Mic
15 minutes (as needed)

Benoit: Lots of ops-related side meetings (perhaps more
interesting). Perhaps those with side meetings can do a lightning talk
on what they are about.
Warren: Fantastic. Please remember, side meetings are not official,
but for informational purposes they can pitch their meetings
Benoit: There is on on SRv6 management later on today. Tomorrow is
on YANG and Kafka, followed by digital map. Wednesday, is issues with
OpenConfig and network management
Rob: Check the side meeting wiki for side meetings
Warren: Check the wiki, again, side meetings are not official

Qin: Time schedule and user-based ACL is coming up Wednesday and
incident management's side meeting is tomorrow
Warren: Check the wiki to find interesting side meetings. People
hosting side meetings should add a description for their meeting.

Rob: PLEASE provide your NOMCOM feedback! Now is the time.
Warren: If you don't provide feedback, you got no right to complain.

CLOSE OF MEETING

=== End Monday Meeting Slot ===

Wednesday November 8th. 13:00pm

1. Sustainability Insights
   Drafts:
   https://datatracker.ietf.org/doc/draft-almprs-sustainability-insights/

   https://datatracker.ietf.org/doc/draft-opsawg-poweff/
   Presenter: Snezana Mitrovic
   Daniele Ceccarelli (IVY cochair): My feeling is that part of
   this work is related to inventory and you just confirmed it. Just to
   let you know there is some work in ivy related to this. Consider
   splitting inventory into ivy and non-inventory here.
   Snezana: Yes. Addressed on slide 4.
   Warren: Better if we focused just on the power part and skipped
   CO2eq etc. The latter is nice to do in the future.
   Snezana: Agreed. Draft focuses on the power -- that's what we
   can do right now.
   Marisol Palmero: Might be more side meetings around the general
   topic of sustainability in the future.
   Joe Clarke: Question for ADs: Sounds like there might be other
   projects interested doing this sort of stuff. Is this the right WG?

   Rob Wilton: Maybe. Is there interest in doing this work?
   Warren: "Doing this sort of stuff" -> hand-wavy. We should be
   asking are we interested in looking at impact with particualr
   constraints -- eg "just the energy". Can quickly get unwieldy eg
   with supply chain, upstream/downstream impact.
   ShowOfHands: Is there interest in this topic? 20 yes, 2 no, 54
   no opinion
   Marisol Palmero: Should we go to IETF, should we go to
   OpenConfig? This is a use case that needs to be solved now. Don't
   have 5 years.
   Joe Clarke: In my opinion this is a good place but might be
   desire to spin another WG.
   Rob Wilton: Not big enough for another WG. Would rather it
   starts here than move somewhere else. (Speaking personally) let's
   get on with this.
   Warren: Following on from that, there has been some discussions
   on forming an "Energy Consumption" WG. Reasonable idea is to start
   here on the understanding that it might move to another WG in the
   future.

2. Joint Exposure of Network and Compute Information for
   Infrastructure-Aware Service Deployment
   Draft:
   https://datatracker.ietf.org/doc/draft-rcr-opsawg-operational-compute-metrics/

   Presenter: Jordi Ros Giralt
   Adrian Farrel (Cochair of cats WG): Cats has a specific charter
   item to work on compute metrics. Compute metrics have specific needs
   for specific applications. May find that grouping them together
   makes them unusable in any application. So work out very carefully
   what it is you need to know for the thing you're trying to do, then
   move on to the metrics.
   Rob Wilton: Thanks Adrian. Looking at slide 2, within IETF the
   plan is that alto will finish its documents and likely close. Alto
   will probably disappear from the picture on this slide. Therefore is
   the only consumer cats? If so, maybe working on this within cats is
   a better choice. But do take Adrian's point that cats' definition
   may be tighter than what's discussed here.
   Adrian: Let me give an example. Cats is trying to steer traffic
   in the here and now ("have a service request, this is the compute we
   need"). Other apps may be asking "where are we going to spin
   containers, where are we going to do truck rolls". Very different
   metrics needed there.
   Jordi: Not about defining metrics that are good for everything.
   When you do service placement, which is another important lifecycle
   step, definitely don't want to use the same metrics as cats because
   want to look deeply in the infrastructure.
   Joe Clarke: Notice draft was published on the cutoff date.
   Encourage you to discuss more widely (eg side meetings, the list,
   cats etc) to decide where this belongs.

3. Modeling the Digital Map based on RFC 8345: Sharing Experience and
   Perspectives
   Draft:
   https://datatracker.ietf.org/doc/draft-havel-opsawg-digital-map/
   Presenter: Olga Havel
   Rob Wilton: Are you asking to open RFC 8345 to do a bis to fix
   it, or do augmentations to fix it, or something else?
   Olga: bis would be ideal.
   Rob: Is it extensions to the base model, or NBC changes to it?
   Olga: Could do it using augmentation but preference is to do the
   bis. Proposal is it is backwards compatible.
   Rob: Might be good to take this question to the list.
   Italo Busi: Some of this is already addressed by RFC 8795 in
   TEAS WG in a generic way. Better to reuse this solution rather than
   defining different solutions for OSPF, IS-IS and TE.
   Joe Clarke: Take it to the list.
   ACTION ITEM: Query on-list for appetite to take on bis work for

   8345. This can kick off some additional discussion around the topic.

4. IPFIX Alternate-Marking Information
   Draft:
   https://datatracker.ietf.org/doc/draft-gfz-opsawg-ipfix-alt-mark/
   Presenter: Giuseppe Fioccola
   (there were no questions or comments)

5. A YANG Data Model for Network Diagnosis by scheduling sequences of
   OAM tests
   Draft:
   https://datatracker.ietf.org/doc/draft-contreras-opsawg-scheduling-oam-tests/

   Presenter: Luis M. Contreras
   Balazs: We see a lot of scheduler type items. Should we have a
   general scheduler model in Yang instead of everyone defining their
   own?
   Luis: We have a side meeting in this IETF working on this
   scheduling stuff. Would be open to pulling out common elements,
   finding a common approach/model, etc.
   Balazs: Would like to see this in netmod.
   Rob Wilton: Interesting idea. Why are they defined as config
   nodes rather than rpc and action?
   Victor: I can answer this. If there is a reflector, we need to
   configure the reflector. But you are right: how to trigger the
   models, etc will need to incorporate feedback from the group.
   Joe Clarke: Let's discuss this on the list.

6. YANG modeling for routing topologies
   Drafts:
   https://datatracker.ietf.org/doc/draft-ogondio-opsawg-isis-topology/

   https://datatracker.ietf.org/doc/draft-ogondio-opsawg-ospf-topology/

   Presenter: Oscar González de Dios
   Joe Clarke: Are you presenting this in routing?
   Oscar: Not this time.