Minutes IETF106: ippm
minutes-106-ippm-00

===============================
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.