When: Friday 31 July 2020, 14:10 - 15:50 UTC
Chairs: Tommy Pauly & Ian Swett
Notetakers: Mirja Kühlewind, Simon Leinen, Brian Trammell
Martin Duke (AD): did read ioam-data and have only a few small comments; should ship soon
(Greg Mirsky)
New flags field with 3 flags: U(nrecognized), M(alformed), I(ntegrity)
Padding should be filled with random numbers
Timestamp TLV is variable length
seq# used for HMAC to avoid replay attacks
New subTLVs for location TLV also to supoort different IP address lengths
Discussion on-going; new version will be published soon
(Al Morton)
route-metric draft is on IESG telechat agenda (missing in chairs update)
metric defines maximum IP-layer capacity (measurements shown)
external reviews from ETSI STQ-Mobile, BBF, FCC WG on Gbps, and ITU-T SG12 led to update of measurement considerations
Approved in SG12, ETSI STO (part of 5G performance measurements), and now also BBF
Close to reach four harmonized standards!
Next: WGLC?
Tommy: doc is stable. Good time to go to LC. Comments? LC will trigger more attention.
(Frank Brockners)
Early allocation completed; draft is stable; in Linux kernel implementation
Problem with forwarding behavior of non-iOAM nodes
deployment doc (draft-ioametal-ippm-6man-ioam-ipv6-deployment): iOAM option bounded by hosts or network devices -> encapsulation -> packets should not escape that domain
2 values in early allocation: first two bits are 00 which means ship if you don't understand
spec says packet should be dropped because of concerns that packet might escape an iOAM domain
Proposal is to remove that text
Adopt deployment draft?
Tommy: do we think this needs to be a separate doc? or fold into v6 option itself?
Frank: option needs be PS to allocate a codepoint. deployment can be informational. But fine either way.
Tommy: when replacing paragraph we need to make sure that is contained otherwise. Normative requirement in same doc.
Haoyu: later we have a talk related this draft. issue with buffer and overhead.
Frank: should we just merge?
Tommy: doc have to be aligned anyway
hum on 1) is wg okay with merging 2) adopt as separate doc 3) don't need doc at all
1) piano
2) piano
3) pianissimo
Tommy: check with AD. Personally I would prefer in the same doc
Martin: Does anyone feel strongly about any of these outcomes? Please speak up.
(Tal Mizrahi)
Added discussion of amplification attacks to sec consideration section
Open issue about loopback flag: nodes need to know that they don't need to push iOAM data on reverse path -> new flag, IAOM type, remainingLen field?
Greg: Active flag: we do have a set of active OAM protocols for performance / defect detection, what's the benefit of creating this flag in IOAM as opposed to include IOAM header into existing protocols
Tal: section in the draft (use cases) to explain where this is used. One, active protocols not defined in this context, may also include an IOAM header for IOAM nodes, Here, the active flag says the decap node should drop. Two, cloning/replication, data packets forwarded, encap may replicate, in this case replica includes active flag so decap can terminate.
Greg: concern is similar to that with loopback. Replication/creation of shadow packets is a tempting attack vector.
Tal: also addressed in document. Text analyzes this issue and proposes mitigations.
Greg: will continue on list.
Tommy: would like to see more reviews from people who have concerns. Martin Duke and Brian Trammell, please read.
Brian: Like to have a chance to do that review before we do early secdir review for obvious reason to avoid being killed in that review. Just didn't have time since April. Thanks for reminder. Will do in the next couple of weeks and will challenge Martin to do the same.
Open issue: explicit hop count field or not? otherwise use hop limit node id
Discussion on mailing list and sec in draft; opinion from others and chairs!?
Tommy: chairs will review thread & document and summarize on list for the group to understand well the options
Haoyu: third option to have optional field
(Mauro Cociglio)
Explicit Performance Monitoring (EPM) for passive observer to measure RTT and loss
Second delay bit to have precise point of mesurement to avoid uncertainty when reordering
One PL-bit for round-trip packet loss based on train of packets which is reflected twice; comparing trains reveals packet loss to passve observer
Works if there are enough packets in both directions
Q-bit/sQuare-bit for one-way packet loss
R-bit: reflection square bit enables observation of loss on path in oposite direction
two-point packet loss can be measured with Q-bit only
Only two bits in QUIC left
Open issue in EPM: who decides wether to mark traffic? Scalability/monitor all connections/which to choose? How to monitor both directions?
device owner decides to mark traffic with problem for both side measurements; server should follow client's decision; information send to external body (provider/regulator)
Ian: This working group is not in charge to allocate any bits in QUIC. draft should just refer QUIC as a potential substrate.
Tommy: Did talk with ADs and QUIC chairs: measurements work belongs in IPPM and recomemndation how scheme are created for different protocols
Igor: all for explicit measurements. want to point out that we have another draft in tsvwg and quic (draft-ferrieuxhamchaoui-tsvwg-lossbits-03) which also uses step function but works with uni-directional observation, provides accurate upsream and downstream loss, and does not suffer from differences in uplink and downlink packet rate. If there is interest I'm happy to present next time or to work with current authors. People interested read draft-ferrieuxhamchaoui-tsvwg-lossbits-03 draft. Validated by Akamai running it for a while in colaborations with passive observers in several ISPs and it performed very well
Tommy: There is a lot of overlap and doc is already calaloging different option. Would authors be willing to come together and come to IPPM with one document?
Mauro: Yes there are many kind of measurement in this doc. we can add another one. difference is the use of only one bit. Igor's draft used L bit taht exports count of loss. Next hackathon to have a demo to have Q bit, R bit and L bit and compare. Use spindump code from Ericsson
Martin Duke: +1 on scope as Tommy said. Think through privacy implications carefully. The idea of explicit user consent is often difficult. call support service to turn it on, or browser decides? Get some outside review, and significant "privacy considerations" before something can be adopted.
Fabio: agree on collaboration with orange/akamai to find good solution for everyone. Differently from our R-bit, the L-bit depends on internal protocol events. Our solution is protocol agnostic which is an advantage.
Giuseppe: good to combine and work together as they address same problem. generalize methodology makes sense.
Tommy: call for adoption of combined proposal at next IETF eventually if some discussion on list
(Rakesh Gandhi)
Separate drafts for stamp (draft-gandhi-spring-stamp-srpm) and twamp
Greg: Control for the return path is applicable for entire session or does it change from packet to packet?
Rakesh: It's per session. doesn't change for that session
Greg: Would it make sense to send reflected packet back to sender as part of data model
Rakesh: No state on the reflector.
Greg: only one case. If we look at stamp reflector could be stateful or stateless. But you assume only one mode. I have a concern about updating the base format. why not include it into the TLV itself how to interpret at reflector
Rakesh: stateless model in sr. the state is carried in packet itself. That's how sr is designed. label stack can change on sender side. Stateful mode in non-sr routing could be used.
Greg: that the return path could change contradicts the assumption that it doesn't change. Because for two-ways measuremnents you then measure different paths.
Rakesh: don't want to start a new session when reverse path changes
Tommy: take to the list because of time.
(Haoyu Song)
(Tianran Zhou)
Frank: We need some config no matter what. And this could be a good candidate. Nearly done with data model. How should we move on? When is a good time to adopt? Data draft to be RFC first?
Tommy: data draft is mature. So we can do that earlier. Need more reviews or at least opinions on the list. Keep updating.
Frank: will try to get more people from yang angle to get closer reviews
(Yali Wang)