=============================== IPPM Session IETF 106 - Singapore Monday, November 18, 2019 10:00-12:00 (UTC+08:00) Meeting Minutes =============================== WG chairs: Brian Trammell, Tommy Pauly, Bill Cerveny (remote) Meeting minutes: Tal Mizrahi Chair slides: ------------- https://datatracker.ietf.org/meeting/106/materials/slides-106-ippm-chair-slides-00 Summary: - Note well was presented. - The agenda for the current session was presented. - Agenda bashing: none. - Two new drafts adopted: IOAM flag draft, and IOAM IPv6 options. - STAMP draft is in the RFC editor queue. - TWAMP Yang still in MISREF. STAMP Yang Data Model --------------------- Presenter: Greg Mirsky. Slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-ippm-simple-two-way-active-measurement-protocol-stamp-yang-data-model-draft-ietf-ippm-stamp-yang-00 Summary: - A few changes based on feedback from the working group. - Seeking any questions or comments about the changes in the current version of the draft compared to the previous version. STAMP Extensions ---------------- Presenter: Greg Mirsky. Slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-ippm-simple-two-way-active-measurement-protocol-stamp-extensions-draft-ietf-ippm-stamp-option-tlv-00 Summary: - Two new co-authors. - Two new extensions: -Access Report TLV -Follow-up Telemetry TLV Discussion: - Sarah Banks: if the reflector can't consume the timestamp, does this allow the reflector to use it anyway? - Greg: this allows the accurate timestamp to be incorporated in the follow-up TLV rather than in the original test packet. No information is overwritten. It is additional information. - Tommy: it is the actual transmission time, right? - Greg: if the system provides a more accurate measure of the timestamp, this is a field that allows it to convey it. - Sarah: how do you know the sender did not already insert a timestamp? - Al Morton: this makes sense to me, but requires more description. - Rick Taylor: how does the application know that follow up TLVs are going to be used? - Greg: there is no guarantee that the follow up will use the same path. - Rick: but how does the application know? - Greg: a management layer is assumed, using a YANG module. - Rick: pre-configuration? - Greg: yes. - Mirja: since this document was adopted, two TLVs were added. Do you plan to add more TLVs, and should addtional TLVs be in a spearate draft and not in the same draft? - Rick: regarding the access report TLV. - Greg: it is specifically for the 3GPP PMF. - Rick: I am involved in non-3GPP radio measurement. I am not sure the access report TLV is cooked yet. Need to understand it more. - Greg: let's discuss it more on the list. - Tommy: three points. - Since we are adding TLVs, we want to make sure there is concensus on these new TLVs. - Access report TLV: it would be best to have it as generic as possible, and not just for the 3GPP use case. - A clarification regarding the follow up TLV would also be necessary here. - Rick: is there an inband negotiation here? You can split it up from a process perspective. Registry for Performance Metrics -------------------------------- Presenter: Al Morton. Slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-ippm-registry-for-performance-metrics-00 Summary: - IETF last call complete. - Meeting with IANA this week, and will update the WG. Discussion: - Mirja: it says "expert review", and standard required. - Al: we want industry consensus. Need to change it to specificatoin required. - Rick: we need some room for experiments. - Al: build your metric, test it, and come back and tell us about it. - Brian: the ID is not a code point on the wire. There is a practical limitation that the names should not be more than 4 KB. There is no need for the ID to define the scope. - Tommy: let us know when you meet with IANA. When do we expect another update? - Al: hopefully this week. Advanced Unidirectional Route Assessment (AURA) ----------------------------------------------- Presenter: Al Morton. Slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-ippm-advanced-unidirectional-route-assessment-aura-00 Summary: - Updated based on reviews. - The authors believe the draft is ready for WG LC. Discussion: - Tommy: how many people have read the latest version? - A few hands raised. - Tommy: we will get a last call going for 3 weeks. Multipoint Alternate Marking ---------------------------- Presenter: Giuseppe Fioccola. Slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-ippm-multipoint-alternate-marking-method-for-passive-and-hybrid-performance-monitoring-draft-ietf-ippm-multipoint-alt-mark-03-00 Summary: - The document was updated based on comments. - The document is stable. Discussion: - Brian: how many people have read and reviewed the document? - A few hands raised. - Brian: are you asking for a working group last call? - Giuseppe: yes. - Brian: should we go ahead and start WG LC? - Tommy: let's pipeline it. - Brian: the WG LC will start after the AURA WG LC will be completed. IOAM WG Document Update ----------------------- Presenter: Frank Brockners. Slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-ippm-ioam-wg-i-ds-update-revision-00 Summary: - The following documents were discussed: - IOAM data draft. - IOAM flag draft. - IOAM IPv6 option draft. IOAM Data Draft Discussion: - Brian: why not use the term "IOAM Option Type Header" rather than "Option Type"? - Frank: go ahead and creat a pull request for that. - Frank: a comment we received today: some of the fixed data fields have a short version and a long version. The intention was to have a fixed format field, with a bit of flexibility for various use cases. Greg Mirsky raised the question whether we need this flexibility. Question: do we want to go with what we have? - Brian: we can pipeline this working group last call after the multipoint alternate marking draft, roughly at the beginning of January. - Frank: the question is whether we need to change anything. - Brain: it looks like the document is becoming stable. - Tommy: we received inputs from the hackathon in IETF 105. Were this inputs reflected in the current IOAM implementation? - Frank: do we have people in the room who were in the IETF 105 hackathon? Not refelcted in the current implementation, but can be updated by January. - Brian: please read the draft, and we can expect WG LC in January. - Frank: do we feel that we want to stay with the current format of the short/long fields, or change it? Any comments? - Brian: are there people in the room that work for a silicon vendor? - Barak Gafni: I support leaving the draft as-is. - Tommy: so what is the alternative suggestion? - Frank: it was suggested to use the long fields. - Brian: the current state seems like a good compromise. I will be surprised if there are other issues with this. Please speak up if you have an issue with this. IOAM Flag Draft Discussion: - Frank: a couple of things we want to add to the draft based on comments from the IOAM side meeting today: - Loopback: no need to record data on the return path. - Loopback: need to specify that the sender is an encapsulating node. We only need to specify that the loopback only makes sense if there is an explicit source field in the encapsulation. - Loopback: if a source (encap) node detects a looped back packet that was not originated by the current node, the packet is dropped. - Active flag: Greg's comment was that you can add IOAM information to an active OAM packet. Why is there a need for the active flag? We are going to emphasize that the flag is intended to simplify implementations. - Frank: are we ready for WG LC? - Mirja: loopback allows an amplification attack. You need to limit the scope of this possible attack. - Frank: is there a way to resolve this problem? - Mirja: Traceroute can be used. - Frank: Traceroute is very slow. - Brian: the fact that a single input packet only results in a single output packet is an essential requirement. If you can create a routing loop with a loopback flag, you burn your network. - Mirja: the other option is to have more access control. - Brian: do we want to couple the two documents? Right now the flag draft is not likely to be accepted. Maybe an early SEC DIR review is a good idea. - Frank: if you have an idea how to prevent amplification, please let me know. I believe we have a way to resolve the routing loop problem. - Barak: I believe the routing loop problem is limited due to the TTL. - Brian: between now and Vancouver we need to consider the amplification problem. - Frank: we can try to converge on the mailing list. - Tommy: do you prefer to decouple the data draft from the flag draft? - Frank: yes, we prefer to decouple them, and avoid delays. - Mickey: there is a Node ID, and it can be used to identify the source. IOAM IPv6 Option Discussion - Frank: we are asking for an early allocation. - Brian: will do that. - Xiao Min: there seems to be a conflict in the phrasing - whether an unknown option should cause the packet to be dropped. - Frank: that sounds like a bug in the document. Thanks for the catch. - Mirja: there is a bunch of exprimental values that can be used. - Frank: the two implementations in open source use other code points. - Brian: what will take longer: an early allocation, or a WG call? We will do the early allocation first. - Brian: is there anyone in the room who believes that early allocation is a bad idea? - No hands raised. IOAM Direct Exporting --------------------- Presenter: Tal Mizrahi. Slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-ippm-ioam-direct-exporting-00 Summary: - This draft presents a consolidated approach of two previously discussed proposals: postcard telemetry and immediate exporting. - The authors suggest WG adoption. Discussion: - Greg: in the proposed DEX option format, is it possible that only one of the two fields will be present - Flow ID or Sequence Number? - Tal: no, in order to simplify things the format is defined such that either both of the fields are present, or none of them. - Greg: does this approach support multicast? - Tal: do you see an issue with multicast here? - Greg: yes, and it is related to the draft I am presenting later. - Tal: a point to think about. - Tianran Zhou: I believe the current draft has only considered unicast, and for multicast we will need more extensions. - Barak: I believe it is important for the current draft to discuss multicast. - Frank: we should use the terminology "DEX option type". - Brian: that would be a comment for the 00 revision of the working group document, if we choose to adopt it. - Brian: regarding the architecture diagram, there is a risk of a reflection/amplification attack here. It may be different than the loopback attack, but the working group version of the document should include whatever we come up with to protect the flag threat. We want the same protection strategy if possible. - Tal: are you saying the analysis should be done for both cases even though the solution is not necessarily the same? - Brian: I am thinking of something that requires a bit of cryptographic protection, like a lightweight token. We need to look at existing approaches that exist in the transport layer. Direct export and loopback will need a pretty lightweight security solution, so I suspect the solution can be unified. - Greg: the question is whether DEX is a generalized case of loopback. Maybe just having DEX is enough, with an encoding for loopback. - Tal: there is a distinction between the data plane and management plane. The loopback is intended to be used by the data plane, whereas DEX is intended to be used by the management. - Greg: why not just have a flag in the DEX that indicates this is a loopback? - Brian: we are alreay having this discussion in the working group, so this is de-facto a working group document. We are going to go ahead with the call for adoption. - Pascal Thubert: do you think there may be a filter that determines what kind of data is exported? - Tal: the encapsulating node does not insert a DEX option into all data packets, but it can insert a DEX option into some of the data packets, based on a filter or statistically. - Pascal: maybe you want to distinguish important packets from less important packets at different nodes in the network. - Tal: are you looking for a way for the encapsulating node to indicate the type of traffic to the transit nodes? - Greg: the DEX IOAM-Trace-Type indicate which data is exported. - Pascal: what if I collect 5 data fields, and I only want to export one? - Frank: the IOAM-Trace-Type tells you what is collected. The assumption is that you only collect what you want to export. The encapsulating node decides what is going to be collected and exported, and not the exporting nodes themselves. Actually, if you want the exporting node to decide what to export - you can also implement that with the way the DEX option is currently defined. - Tommy: let's continue on the list. This is a very interesting topic, and thanks for the collaboration. - Brian: after adoption do we need to continue the design team? - Tal: it is useful to have a mailing list and bi-weekly meetings. We may want to change the scope, but we want to keep it going. - Brian: that is a NO-OP for me. Metrics and Methods for IP Capacity ----------------------------------- Presenter: Al Morton. Slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-ippm-metrics-and-methods-for-ip-capacity-00 Summary: - This is a new draft. - IP layer capacity measurement. Discussion: - Al: who has read the draft? - A couple of hands raised. - Mike Ackermann: I support this draft. How can I help? - Al: review the draft. - Nalini Elkins: this is useful. The question that often comes up is what is the capacity that the ISP provided? - Dave Sinicrope: there is a community behind this draft. - Brian: we will start a WG adoption call for this. Telemetry Collection in Multicast Network ----------------------------------------- Presenter: Greg Mirsky. Slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-ippm-telemetry-collection-in-multicast-network-draft-mirsky-ippm-hybrid-two-step-draft-song-multicast-telemetry-00 Summary: - New draft. - Addresses multicast use cases in IOAM/telemetry. Discussion: - Barak: what is the problem with replication along the path? - Greg: packets are replicated, causing redundant data. - Barak: I do not see the issue with replication. - Frank: we do not specify the semantics of the Node ID in the data draft. You can encode all the information you need in the Node ID, so there is no need for an extra field. - Haoyu Song: we have not defined how to implement the branch information. Any other mechanism can be used. Adjourned at 12:00.