# OPSAWG IETF 118 {#opsawg-ietf-118} ## Monday November 6th. 13:00pm {#monday-november-6th-1300pm} Initial revision of the WG Status done by the Chairs. ## Adopted Work Section {#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 {#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 {#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 {#wednesday-november-8th-1300pm} 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.