[Ippm-ioam-ix-dt] IPPM IOAM Exporting Design Team Meeting Minutes - October 2nd 2019

[Tal Mizrahi <[e-mail]>]

IPPM IOAM Immediate Exporting Design Team
Virtual meeting
October 2nd, 2019, 06:00 UTC
Webex meeting


Attendees:
Shwetha Bhandari, Frank Brockners, Tal Mizrahi, Ramesh Sivakolundu, Haoyu
Song, Tianran Zhou.

Minutes by Tal Mizrahi.


Summary:
========
- The Hop Count issue was discussed, with no clear decision at this point.
- Next steps:
  - Tianran will propose new text for the Hop Count description in the
"Issues for Further Discussion" section.
  - Once this text is reviewed the draft will be post (draft 00), asking
for feedback from the WG.


Introduction (Tal):
===================
- The main open issue in the direct exporting draft is the Hop Count issue.
- We have updated the preliminary draft on Github based on the discussion
from the previous meeting.
- The latest commit was presented:

https://github.com/inband-oam/ietf/commit/80a20d25bfcb1b0406a644005b12f9f2e85dd7ba#r35312342
- Tianran suggested on the mailing list to make the Hop Count field
optional, by using a flag that indicates whether the Hop Count is present
or not.


Hop Count Discussion
====================
Tianran: the optional approach can be a good solution. On one hand it
addresses the use case we talked about, and on the other hand does not
require transit switches to update the option if not supported.
Ramesh: how is this different than using the Hop_Lim/Node_ID data field in
the exported packet?
Tianran: in Layer 2 encapsulations the Hop_Lim/Node_ID data field cannot be
used, since the TTL is not available. Another example is hierarchical VPNs,
where the TTL is not available.
Haoyu: I have summarized a few differences between the Hop Count field and
the Hop_Lim/Node_ID data field. This is beyond the two examples Tianran
just mentioned. Using a flag to indicate an optional Hop Count field
enables to control the tradeoff. Furthermore, there is no cost in terms of
the header length, since we are reusing some of the existing bits.
Shwetha: do you recommend to use the Hop Count field only in encapsulations
that do not have the TTL (such as L2 encapsulations)?
Haoyu: it is possible, but the argument for the Hop Count is not only
encapsulations that do not have a TTL. The flag allows you to use the Hop
Count in other encapsulations as well.
Tianran: yes, it is possible in other encapsulations, such as IPv6.
Tal: I suggest that Tianran creates a pull request updating the Hop Count
text. Hopefully we can send this as an open issue to the working group.
Tianran: a question to implementers in this meeting: is there a technical
problem to enable this option?
Ramesh: even if we define it as optional, it will end up being implemented.
So having an option is not necessarily helpful. What were the arguments in
the previous meetings?
Haoyu: the main argument against the Hop Count field was that transit nodes
have to update the direct export option.
Ramesh: doesn't the Hop_Lim/Node_ID data field provide the same
functionality?
Haoyu: not exactly. As we explained, the Hop_Lim/Node_ID data field does
not indicate when an IOAM-capable node fails to export data to the
collector.
Ramesh: how do you make it optional?
Tianran: we use a flag to indicate that the Hop Count is there. Four bits
for a Hop Count may be enough, but we may consider Eight bits. We can also
think of intermediate numbers.
Ramesh: we are running out of flag bits, so we need to be careful.
Tianran: right now there are more flags than we need.
Ramesh: so the main argument against Hop Count was that every transit node
had to do a read-modify-write?
Tianran: yes. But using the optional approach you can just disable it.
Tal: can you update the section that describes the Hop Count issue?
Tianran: yes.
Tal: any other issues we want to discuss?
Tianran: what is the next step?
Tal: once we phrase the Hop Count issue as a question to the working group,
in my opinion we can post the draft in the next week or two.
Tianan: any other comments about the optional approach?
Shwetha: I am not sure there is a real use case for an encapsulation that
does not include a TTL.
Tianran: one example is the Layer 2 encapsulation.
Shwetha: but right now there is no encapsulation that has been defined
directly over Layer 2.
Haoyu: there is the Ethertype-based encapsulation.
Tianran: the encapsulation is actually another topic that we want to
discuss later. We want this draft to be general enough to apply to future
encapsulations as well. IFA also proposed to encapsulate OAM over UDP. Our
approach is universal / generic.
Shwetha: so the device that looks at IOAM does not update the L3 TTL?
Tianran: right.
Shwetha: a device that looks beyond L3 will also update the L3 TTL.
Tianran: in some implementations UDP encapsulation is used without updating
the TTL. In Layer 2 forwarding the device may look deeper into the packet
and do some processing.
Frank: from a standard perspective, a bridge is L2, and a router is L3.
Having a bridge that looks deeper than L2 into the packet is not applicable
from a standard perspective, even if in practice it exists. From an IETF
perspective it does not exist.
Tianran: some encapsulations are not standardized.
Frank: right, so you can implement some proprietary features, but not all
can be standardized in the IETF.
Tianran: we are just suggesting an optional approach for Hop Count. The L2
encapsulation is just an example.
Frank: I do not see a device that would do that.
Haoyu: that is because such devices do not exist yet.
Frank: if you want to define the behavior of a bridge you need to go to the
IEEE.
Haoyu: the purpose is to make the current proposal flexible. The Hop Count
is optional.
Frank: the whole discussion can be in a separate section / document. The
Hop Count is not related to direct exporting. The point of direct exporting
is just to signal to transit nodes when they need to export, without
changing data packets.
Haoyu: we do not change the header in-transit, but only update the Hop
Count.
Frank: you are changing the packet in-flight.
Haoyu: one of the benefits of direct exporting is that transit nodes do not
increase the length of the packet. The Hop Count just helps the collector
to correlate the packet.
Frank: you are still updating the packet on per-hop basis.
Haoyu: but there is a need to correlate the packet, and we need to find a
way to do that. This is our current proposal. We should ask the community
to decide.
Tal: I suggest to update the description in the "Issues for further
discussion" in a way that summarizes all the arguments on both sides. Then
we can post the draft and ask for feedback from the working group.
Tianran: I am fine with that.
Frank: documenting the discussion is the best we can do.