# IPPM Agenda IETF 110 Chairs: Tommy Pauly & Ian Swett ## Session 1 *Monday 8 March 2021, 14:30-15:30 UTC* ### Welcome, Note Well, Agenda, Status ### draft-ietf-ippm-ioam-ipv6-options - Frank presenting https://datatracker.ietf.org/meeting/110/materials/slides-110-ippm-sessb-in-situ-oam-ipv6-options-00 - Editor/Author list cleanup needed - Frank: Review the draft in 6man? - Tommy: Any normative dependency? - Frank: None, early allocation of option numbers done - Haoyu Song: tunnelling vs in-situ inclusion of option, original intent was to monitor and collect measurements in-situ, this is a deviation from the intent - Frank: Tradeoff due to RFC8200 policy of no insertion of options/headers in-situ. Double encap is necessary ### draft-ietf-ippm-ioam-yang - Tianran presenting https://datatracker.ietf.org/meeting/110/materials/slides-110-ippm-sessb-a-yang-data-model-for-in-situ-oam-00 - No comments ### draft-brockners-opsawg-ioam-deployment - Frank presenting https://datatracker.ietf.org/meeting/110/materials/slides-110-ippm-sessb-ioam-deployment-00 - Tommy: Has this document been discussed in opsawg - Frank: Sometime in 2020 - Tommy: Any sense of whether opsawg or ippm will be the right wg to progress this work? - Frank: Need to check, preference is to continue it in ippm as there is full context at ippm. - Robert Wilton: opsawg may be the right place to review/work on this - Frank: Will check in the wg mailer (not sure I lost audio around Robert's suggestion and Frank's response, someone else please correct this) ### IOAM Data Integrity - Frank presenting https://datatracker.ietf.org/meeting/110/materials/slides-110-ippm-sessb-integrity-of-in-situ-oam-data-fields-00 - Martin Duke: variant of option 3 that uses symmetric keys - Frank: should we add that method? - Martin: no strong opinion, there will be additional overhead with one signature per hop. Would like see single signature option with symmetric/asymmetric key based methods - Haoyu: This will introduce processing overhead, DEX mode is preferred if the data collection insitu has security concerns in some deployments. - Martin: Are there any advantage in per hop signature - e.g. method 1 & 2 - Frank: it was to exhaustively - Tommy: 4 has higher level of crypto complexity, 1 & 2 are not practical. Should we consider a variant of option 3 with assymetric keys? - Frank: it was to prevent replays on a per packet basis. the methods are listed here so we can evolve and narrow down on practical solution - Tommy: integrity protect IOAM data with no rapidly changing keys. Optimize Method 3 - Greg Mirsky: rapidly changing keys is challenging in high scale environments. - Frank: should we narrow down to methods per discussion here? method 3 with assymetric keys and discussion on rekey like ipsec? - Tommy: evolve and more discussions on the list - Martin Duke One more comment: we should probably adopt this as a Standard, although I see why the current draft is Information - Al Morton Thanks for the analysis of integrity options, may be useful beyond IOAM protocol...20:51:28 ### Loopback and Direct Export Tal to present https://datatracker.ietf.org/meeting/110/materials/slides-110-ippm-sessb-ioam-flags-and-direct-exporting-00 (moved to later) Martin presenting the challenges with loopback and DEX - https://datatracker.ietf.org/meeting/110/materials/slides-110-ippm-sessb-ioam-loopback-direct-export-concerns-00 - Greg : (didnt quite get the gist of this) - Tal : IPFIX and other export methods also have these challenges. If we need to find a solution of this it should. be generic for IOAM and IPFIX and other methods. - Tommy : Will batch processing help? will make it more deterministic. Will this be acceptable? - Mirja Kühlewind with ipfix you usually don't export at every node only at the network edge typcially yes also with ipfix you do time-based exports or at the end of a flow - Haoyu - suggest sampling - Frank: PSAM/IPFIX cadence based with batching for export instead of per packet by all the transit nodes for IOAM? - Tommy: Other comments please take it to the list. ## Session 2 *Friday 12 March 2021, 16:00-18:00 UTC* ### Welcome, Note Well, Agenda, Status Agenda bash-adding in Loopback/DEX to finish from last time. ### Loopback and Direct Export (Continued from session 1) Tal presenting Amplification threat, discussed earlier. Both drafts call out perf and security considerations. The threats are worse in wide area networks Loopback & DEX mitigate via rate limiting Loopback mitigates with applying to a subset, being truncated, and being a single data field Suggestions are to add: - Probability bound for loopback and DEX - Stronger restriction to a domain Tommy: How do we restrict to a domain? Tal: This would be text to say that you need to understand your deployment topology. Tommy: Shouldn't we be considering changing the export strategy to delay/batch the export? Tal: We want to reference ipfix and other docs about sampling strategy. Tommy: But we should have this be about export time, not sampling rate. Tal: We want deterministic logic around when DEX nodes export. Martin: I'm concerned about this deterministic approach here. I'm also concerned about just saying we need to be careful about the domain. We could say that you must not do this in an overlay, etc. Could be effective even if it makes it less useful. Mirja: You've been talking about sampling of requesting data. But we need to also restrict on the nodes doing the exporting, in the node, not from the requester. We need to give advice for how the nodes apply protection mechanisms individually. You can also only allow exporting to nodes that are known nodes. I'm still not convinced this will be a safe/good design, since there are so many sharp edges. We would do well to find a different design. Tal: Also have open issues around hop count field and DEX option length. ### draft-ietf-ippm-capacity-metric-method Al: Following up on IESG feedback, lots of iteration on the list. Added an applicability sub-section. Restricted to access measurement, and added requirements for limiting to diagnostic measurement. Added more detail on method and algorithm. Changed SHOULDs to MUSTs Updated running code section Updates to expected safe range for key parameters Timeouts for senders and receivers guarantee that tests stop Magnus: What's determining the retransmission value? Al: It's a static timeout value as defined here. It doesn't care about round trip delay, it's about inter-packet arrival time. Magnus: The control loop is feedback timer + RTT. The traffic load is based on feedback, but this doesn't have the same congestion control as TCP or QUIC. Al: In the context of static timeouts, can you provide the values you're comfortable with? If you don't receive packets, you tell the other side, and it lets the other side know. There's not traditional loss detection, but it does provide the info. This is how we define methods and metrics in IPPM. Magnus: We shouldn't go way overboard when measuring capacity. Al: Many protocols could overwhelm the network if they don't follow the bounds. J Ignacio: There are many services like speedtest, etc, that measure your bandwidth. This is no so strange to measure capacity. If you don't receive all the packets, you stop sending. We just need to set up the limits. Tommy: I disagree with the blockage here, I think this is appropriate for a metric/method. Martin: We'll want a new WGLC, and then re-ballot it. Zahed: I think it looks like this will be ready to progress once the WG approves again. Greg White: It may be good to clarify if this is trying to be friendly to other flows or not. That would help explain how this algorithm works. Is it fair capacity, remaining capacity, or full capacity? Al: Full capacity. We'll push other traffic down for a few moments during the measurement. It's not friendly. It's trying to measure the maximum. ### draft-ietf-ippm-connectivity-monitoring Ruediger: Measures on segment routed paths. Still doing updates editorially to the metrics. (Terminology will continue to be updated, etc.) Metrics will need to be completed more later. J. Ignacio: Why use the mean of the time, not the median? ### draft-mdt-ippm-explicit-flow-measurements Mauro: Explicit Flow Measurement (EFM) adds a few marking bits to measure delay and round-trip/one-way packet loss. Hackathon implementations from telecom italia, ericsson, orange, huawei. Single spin bit has limitations with holees in traffic. Delay bit fixes that. New delay bit is a single bit measurement, and independent of spin bit. Different from previous 2-bit measurement. Greg: What about compact marking that uses one bit? Mauro: This is more about protocols like QUIC where the transport doesn't allow the bits to be changed by the path. Martin: I'm concerned about if QUIC is engaged enough Where would the privacy review live? Tommy: I'd like to call for adoption, and cross list to QUIC Ian: Are some of the authors who have major servers interested in deploying this? Gorry: Is this a protocol or method in IPPM? Tommy: My impression is that this is just a method. Gorry: This could be in GRE too. Let's write a good method, and then leave not limit the protocol work. ### draft-mirsky-ippm-hybrid-two-step Greg: HTS is now a new IOAM trace option type, for the IANA registry. Authentication for HTS, and clarified intermediate node behavior. HTS can be used as a method to collect IOAM data. IOAM is a trigger packet, and HTS is used for transmitting the data. Can extend more in the future, but current auth uses 16 octet digest HMAC. Asked for adoption; no comments at mic, some support on Jabber. ### draft-mirsky-ippm-epm (Low on time, doing a lightning talk) ### draft-xiao-ippm-ioam-conf-state (Low on time, doing a lightning talk) ### draft-gandhi-ippm-stamp-srpm Did a show of hands to get input on working on this. 9 in favor. 5 against. 28 did not respond. ## Lightning Talks ### draft-song-ippm-ioam-ipv6-support ### draft-song-ippm-inband-e2e-rtt-measurement ### draft-li-ippm-stamp-on-lag ### draft-zhou-ippm-enhanced-alternate-marking ### draft-li-ippm-ref-delay-measurement