* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ippm Status Pages

IP Performance Measurement (Active WG)
Tsv Area: Mirja K├╝hlewind, Magnus Westerlund | 1997-Jan-09 —  

IETF-105 ippm minutes

Session 2019-07-24 1330-1530: Van Horne - ippm chatroom


minutes-105-ippm-00 minutes

          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
          - 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
          - 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
          Liaison Round-up
          Presenter: Al Morton.
          - Summary of ongoing work with ITU-T, BBF.
          Advanced Unidirectional Route Assessment (AURA)
          Presenter: Al Morton
          - There were some comments from Frank Brockners.
          - We are looking at a few options for terminology of host / node.
          - 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
          - 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
          Presenter: Giuseppe Fioccola
          - A short recap.
          - An overview of the changes since the previous draft.
          - 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.
          - 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.
          - 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
          - 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.
          - 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
          - 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
          - 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
          - 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
          - 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
          - 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
          - 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
          - 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
          - 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
          - A short summary.
          - Plan to request WG adoption in SPRING.
          - 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
          - 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
          - 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
          - Jay Kumar: have you considered adding a fragmentation action?
          - Tianran: not currently. The PBT-I has a fixed length. No need for
          - 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.
          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.

Generated from PyHt script /wg/ippm/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -