Skip to main content

Minutes IETF105: ippm
minutes-105-ippm-00

Meeting Minutes IP Performance Measurement (ippm) WG
Date and time 2019-07-24 17:30
Title Minutes IETF105: ippm
State Active
Other versions plain text
Last updated 2019-07-25

minutes-105-ippm-00
===============================
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.