=============================== IPPM Session IETF 105 - Montreal Monday, July 24, 2019 13:30-15:30 (UTC-04:00) Meeting Minutes =============================== WG chairs: Brian Trammell, Tommy Pauly, Bill Cerveny (remote) Meeting minutes: Tal Mizrahi Chair Slides ------------ Slides: https://datatracker.ietf.org/meeting/105/materials/slides-105-ippm-01-chair-slides-02 Summary: - Note well was presented. - The agenda for the current session was presented. - The working group status was presented. - RFC 8545 was published! - draft-mirsky-ippm-stamp-option-tlv - looks like there is consensus for adoption pending some updates. - There was a discussion about the next steps of IOAM - see below. IOAM next steps discussion -------------------------- - Brian: Looks like it was a good idea to adopt the data draft, about two years ago. Many other related drafts. - Brian: Question: is this the right working group to look at the encap drafts. Regarding 6man - looks like IPPM is the right place. Regarding other encaps - open for discussion. - Tom Herbert: "these encapsulations" is a bit too wide. Not every encap is the same. The scope should be defined. - Brian: these encaps refers to the existing documents. For example, the IPv4 encap document is probably not going to happen. The Ethernet encap document is probably not suitable for IPPM. - Tom: need to determine where the work is based on a per-case basis. - Brian: what I am hearing is - let's focus on a few of these encaps. - Tom: the data model is important. We should leverage that. - Frank: we decoupled the data fields from encaps, to allow for this to be discussed in different places. This is all contribution-driven. We are working in multiple working groups. NSH was relatively straightforward, and was adopted by SFC. Will probably move to WG LC soon. There are a few other encap documents, each discussed in a different working group. However, we believe it would be best to have one place to discuss these documents, to have a home where people are already familiar with the background. - Brian: how many encap documents do you think we would want to discuss here? - Frank: let's discuss in the IOAM session a bit later. - Mirja Kuhlewind: we have to look at other working group's charters, and decide based on that. It is actually an advantage to have to explain it individually to every working group, because this is the target audience. - Frank: we are just looking for a home to discuss these related drafts. - Brian: the Ethertype-related draft is certainly not relevant to this working group. Otherwise, IPPM is a good place to discuss these documents and possibly dispatch them to other working groups. - Tommy: we have seen a lot of individual contributions that are related. It is useful to have updates in the working group. It gives context. Liaison Round-up ---------------- Presenter: Al Morton. Presentation: https://datatracker.ietf.org/meeting/105/materials/slides-105-ippm-liaison-round-up-00 Summary: - Summary of ongoing work with ITU-T, BBF. Advanced Unidirectional Route Assessment (AURA) ----------------------------------------------- Presenter: Al Morton Presentation: https://datatracker.ietf.org/meeting/105/materials/slides-105-ippm-advanced-unidirectional-route-assessment-aura-00 Summary: - There were some comments from Frank Brockners. - We are looking at a few options for terminology of host / node. Discussion: - Al: any comments regarding the terminology options (host / node)? - Frank: let's move from 'host' to 'node'. I did not find a formal document that defines this terminology. We need to decide. - Ignacio Alvarez-Hamelin: option B sounds good - revising the term 'host'. - Sarah Banks: we have a problem if the terminology in RFC 2330 is not consistent with RFC 8200. Either define what you mean by 'host' specifically in this draft, or let's just use 'node'. - Brian: it sounds like option C is 'use node instead of host'. - Al: right. Let's seriously consider option C - use 'node'. - Al: would anyone be willing to work on the YANG model? - No hands raised. Multipoint Alternate Marking method for passive and hybrid performance monitoring --------------------------------------------------------------------------------- Presenter: Giuseppe Fioccola Presentation: https://datatracker.ietf.org/meeting/105/materials/slides-105-ippm-multipoint-alternate-marking-method-for-passive-and-hybrid-performance-monitoring-draft-ietf-ippm-multipoint-alt-mark-02-00 Summary: - A short recap. - An overview of the changes since the previous draft. Discussion: - Ignacio: how are the clusters found? It is not trivial at all. - Giuseppe: it is not in the slides, but there is a paper that will be pulished soon, that describes additional methods for finding the clusters. There are different algorithms for this partition. - Ignacio: these should be added to the draft. - Giuseppe: it is in the plan. - Brian: is there any missing detail? What are we missing before WG LC? - Giuseppe: we will need the reference to the paper that was mentioned. It will take a few months. - Brian: yes, we should wait for the paper even if it is an informative reference, and we will bring it back for discusion. IOAM Implementation in the Hackathon ------------------------------------ Presenter: Justin Iurman. Presentation: https://datatracker.ietf.org/meeting/105/materials/slides-105-ippm-5-ioam-implementation-00 Summary: - Presented an overview of the IOAM implementation over IPv6, and an overview of the environment in which it was tested. - Opaque State Snapshot is not clear enough. It breaks the way the length is computed. Discussion: - Tal Mizrahi: how come there is almost no difference in the bandwidth between applying IOAM to 50% and applying to 100%? - Justin: we are not sure. - Tal: should be a factor of 2. - Tal: what is the overhead in bytes that was added to each packet? - Justin: the packet is increased, and that is the reason for the bandwidth decrease. - Tal: right, but what was the length in bytes of this increase? - Justin: it depend on the use case. - Tal: is there a detailed document? - Justin: you can find it in the repository. Or send me in an email. - Tal: the incremental trace option is useful. Some of the devices that implement IOAM have an easier time doing this with the incremental trace option. - Frank: incremental trace option is useful. You typically do not want to mix incremental and pre-allocated trace options. - Frank: The problem with Opaque State Snapshot - we may be able to deal with this using the IOAM Profile idea (ioam-profile draft) - by using profiles you can limit the functionality of the Opaque State Snapshot. Is this going to be upstreamed? - Justin: we plan to make a patch and upstream it. - Tom: the code may be upstreamble. We need an option number in order to be upstreamed. We may be able to use early IANA allocation. IOAM Update ----------- Presenter: Frank Brockners. Presentation: https://datatracker.ietf.org/meeting/105/materials/slides-105-ippm-6-ioam-update-00 Summary: - A short overview of the history of IOAM and the IOAM drafts. - An update on the latest changes in the data document. - For postcard mode: based on discussion on the mailing list we will write a new draft about this, and remove the immediate export flag from the existing documents. - IPv6 encap will be pursued in the IPPM WG, and updates will be given to 6man. - An overview of the changes in the data draft. - The data draft has been stable for a while. IOAM Encapsulation Discussion: - Frank: what do we do regarding the IPv4 option? Some people do not like it. - Brian: I do not like it. - Frank: it possible to add extension header to IPv4 (work-in-progress). - Frank: Another issue is the Ethertype encapsulation. We can only get an Ethertype if the IESG asks for it, and that will happen only if this document is adopted. - Frank: looking for ideas of how to solve the IPv4 issue. - Tom: Geneve and VXLAN are UDP encaps, right? So we go into UDP payload and do the IOAM? - Frank: well, in Geneve you can use Geneve's TLV. In VXLAN-GPE you need a type. - Tom: if you are identifying Geneve in the network, and then changing the UDP payload it is a bad thing. It may not be feasible. IPv4 extension headers is plausible (IPv4 hop-by-hop option). Using an IP protocol number may be better. - Brian: the problem is that the lower overhead is to insert IOAM over IPv4. But this will take the most effort and time in the IETF. Looks like GRE and IPv4 is the best option. - Frank: but people do not like it. - Brian: you will not get a protocol number. The hop-by-hop options may help - you may want to take it to 6man. - Tom: we have to do it in 6man for IPv6 anyway. I posted the IPv4 hop-by-hop extension header, and there were mixed emotions about improving IPv4. - Tommy: in which group is this done? - Tom: it was posted to 6man, but there is no obvious home for it. - Tommy: if we are going to rely on IPv4 extensions we need to know where they are going to be pursued. - Tom: we need something that works in IPv4. - Brian: the GRE was using an Ethertype as a way of running IOAM over IPv4. Kind of an 'abuse', in the same way it was suggested to use the IP protocol as hop-by-hop in order to use an IPv6 extension header. - Matt Mathis: a protocol called IPMP, a few years ago died because it was forked to two communities. They used magic numbers in the payload, and the measurement payload had its own checksum. This was a hack, but nobody can detect that it was a measurement packet. - Shuping Peng: IOAM in hop-by-hop is a risk for incremental option. This option may push the routing header out of the parsing range of the network device. We have a draft that proposes to place the IOAM option header after the IP header, and then the IOAM data after the routing header. - Zhenbin Li: we can confine our discussion on encap, and focus on IOAM header. - Barak Gafni: maybe we should reconsider the IPv4 option. - Brian: good luck in getting past the IESG. - Frank: it needs to be workable. IOAM Data Draft Discussion: - Tianran Zhou: regarding the data fields there is a checksum complement field. A bit field is used. Last bit is used for checksum complement. Maybe in the flag, and not in the bitmap. - Frank: send an email to the list. - Tal: the flags are separate. In terms of the timeline may be defined later, i.e., after the data draft. We want to separate the functionality of parsing the data fields, which should be in the data draft from the flags, which are currently in a separate draft. At this point the bitmap specifies which fields are in the option, and therefore it is more clear to have the checksum complement indications in the bitmap. - Tom: comments regarding the hackathon - will be given later. The Opaque data field is problematic - needs to be discussed. In some fields there is a short field and a long field - what happens if both are present in the same option? Regarding the bitmap, the number of bits is limited - 24, and half are used. What happens when we run out? - Frank: we will cross that bridge when we come to it. - Tom: you can always allocate the last bit to represent an extension bit. - Jay Kumar: regarding the data field bitmap, what do you think about using a profile vs. using a bitmap? - Frank: there are pros and cons of bit vector vs. profile. We have been struggling with this. Let's proceed with the bit vector and we may revisit it in the future. Data Draft WG LC Discussion: - Tommy: we expect another round of discussion, partially based on the hackathon. - Brian: this is the second hackathon. Each time we get 1-2 conclusions from this. Do we want to wait with WG LC until we have another hackathon? - Frank: hard question. Last IETF: a lot of comments. This IETF: 3 comments. - Brian: a good way of getting comments is to threaten about WG LC. - Tom: this hackathon was not with a lot of data points. It would be better if we could have router vendors. We need more implementation / deployment experience. - Brian: we do not plan to significnatly change, but only to get clarifications based on the hackathon. - Tom: sort it out on the list. - Brian: we may want a WG LC that ends at the next IETF meeting. - Frank: let's get all the comments on the mailing list. Flag draft discussion: - Greg Mirsky: have you considered the impact of loopback in inter-domain scenarios? - Frank: good question. We need to think about it. - Tom: loopback sounds a bit misleading. It is actually more like Traceroute. Is there a use case? - Frank: yes. Data plane probing is a use case. Probing does not necessarily make it to the destination. Loopback helps you isolate and locate the problem. - Mirja: you designed an amplification attack. - Tal: this comment was made in the last IETF meeting, and we added a section about it to the current draft. This has peformance implications and security implications. People need to know about it, but it cannot be prevented. - Frank: it is a tool. Like a hammer - you can kill someone with a hammer. - Greg: you are creating a tool that can be used by a malicious attacker. - Tal: we will be happy to get comments about this new section and continue the dicussion from there. - Brian: we intend to adopt the flag draft as a working group document. No need for the entire adoption call process. Send us an updated draft with a draft-ietf- prefix within a week or two. If anyone has a problem with this please send your problem to the mailing list - it has to be a really good reason. - Frank: the same document, or after removing immediate export? - Brian: the next revision of this document after removing the immediate flag should be an IETF IPPM document. - Brian: does it make sense for this draft to be in a separate document, or in a common document? - Frank: it was in one document. - Brian: do you want to hold the publication of the data draft? - Frank: no. If we can converge, then we can fold these two drafts into a single draft - that would be best. - Brian: we will revisit that later. - Mirja: if flags are used to instruct transit devices to perform a different forwarding action than they were supposed to do, then this is an issue that needs a bit of discussion. There is an advantage to keep it as a separate draft. - Mirja: encap drafts should not be published before the data draft. - Brian: are there any documents that we do not plan to move forward on? - Brian: are there documents that we are not clear about the next step? - Frank: the Ethertype draft. - Mirja: is someone actively working on it? - Mirja: we may consider an AD-sponsored draft. Will look into it. - Brian: you may present it in INT-AREA. - Mirja: we will look into an AD-sponsored track. STAMP Extensions ---------------- Presenter: Greg Mirsky Presentation: https://datatracker.ietf.org/meeting/105/materials/slides-105-ippm-7-stamp-extensions-00 Discussion: - Rakesh Gandhi: thanks for addressing the feedback. Regarding direct loss measurement - please consider making it hardware friendly, by placing it in a constant location. - Greg: we will review all the TLVs again, and reconsider. - Rakesh: if the sender supports this TLV capability, but responder does not, what happens? - Greg: responder will respond with symmetric packet, but will not respond with TLVs. Will treat TLVs as padding. - Rakesh: there may be a problem with the size of the padding and how it is detected by the responder. - Greg: will look at it. Performance Measurement Using TWAMP for Segment Routing Networks ---------------------------------------------------------------- Presenter: Rakesh Gandhi Presentation: https://datatracker.ietf.org/meeting/105/materials/slides-105-ippm-8-draft-gandhi-spring-twamp-srpm-01-00 Summary: - A short summary. - Plan to request WG adoption in SPRING. Discussion: - Footer Foote: is this in line with RFC 6374? - Rakesh: yes, both concepts are similar. Some more considerations related to broadcast. - Footer: does it also include the signaling of RFC 6374 regarding uni/bidirectional? - Rakesh: for TWAMP the return path is using TWAMP. Also query could be OWAMP and response could be TWAMP. So we do not use RFC 7876 for this. - Footer: are you indicating whether you want unidirectional or bidirectional responses? - Rakesh: yes, that is the extension we are adding about the TLV return path. - Brian: keep us up to date about the progress in the SPRING WG, and during WG LC we will want to be in the loop and be able to comment. Postcard Based Telemetry ------------------------ Presenter: Tianran Zhou Presentation: https://datatracker.ietf.org/meeting/105/materials/slides-105-ippm-9-draft-song-ippm-postcard-based-telemetry-02 Summary: - Jay Kumar: have you considered adding a fragmentation action? - Tianran: not currently. The PBT-I has a fixed length. No need for fragmentation. - Jay: but the flags are the same as the IOAM flags, or separate flags? - Tianran: currently it is the same draft. - Jay: I suggest to define a new flag for fragmentation. - Tommy: flags were taken out. We are going to have a new draft for postcard mode. Is there a connection? - Frank: from my perspective we need a definition of the new IOAM option of immediate export. We may borrow from the postcard draft. The current document has a lot of other irrelevant text. - Barak: if we take the flags out, we will eventually have a single document. This will be a good idea here as well - to have a separate document and then fold it into the data draft. - Tommy: as long as we end up publishing things that is fine. - Tommy: we would like to see the authors of both documents collaborating on this. - Tianran: we would like the current postcard draft to be adopted. - Tommy: not clear why we need that. We can take the relevant text from the current document folded into a single new draft. - Frank: there are more aspects here, such as how information is exported. We certainly need a document that describes immediate export that is intended for IPPM. - Brian: the document for IPPM should talk about the data model, the mechanisms for deriving measurement information from the data model. The document should borrow content from the flag draft and from the postcard draft. We do not care who the authors are, but we would like to see a single document based on collaboration. This new draft will be intended for adoption. AOB --- Brian: we are out of time. Apologies to lightning talk presenters. Tommy: lightning talk presenters - please send a link of the slides to the mailing list and encourage discussion. Adjourned at 15:30.