[Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting Minutes, August 19th, 2020

[Tal Mizrahi <[e-mail]>]

IPPM IOAM Design Team
Virtual meeting
August 19th, 2020, 06:00 UTC
Webex meeting

Attendees:
Shwetha Bhandari, Frank Brockners, Mickey Spiegel, Tal Mizrahi.

Minutes by Tal Mizrahi.


Summary
=======
- Flag draft: more discussion is needed on the design team mailing
list regarding loopback on the reverse path.
- The next meeting will be on September 2nd at 06:00 UTC.


Data draft
==========
Shwetha: there are a few remaining git issues. The suggested security
consideration update - we should run it by Martin.
Tal: sure. I will do that.


Direct exporting draft
======================
Tal: I will run the open issue by the mailing list again.
Mickey: it does not make sense to make the hop count optional.
Frank: right, either with or without it.
Tal: I will run it by the mailing list.


Flag draft
==========
Tal: regarding the loopback on the reverse path - we have four options
of indicating the reverse path: new flag, new IOAM type, clear the
RemaingLen field, or use an export format for the reverse path.
Mickey: not a fan of the export format. It leans towards flexibility,
which makes it more difficult in hardware. There is also a problem
with the length field for pre-allocated options. If you clear the
RemainingLen field you do not know how to handle pre-allocated.
Frank: right, so if we zero out the RemainingLen it would not work
with pre-allocated.
Tal: a new IOAM type may be the right way to go. Not too difficult to
implement, and a new flag would be a waste.
Frank: right. Do we need a new draft?
Tal: it is a question of whether we need the different IOAM type only
on the reverse path, or on both paths.
Mickey: on the forward path it is not necessary to use a different IOAM type.
Frank: you may have a point.
Mickey: it can be argued both ways. Given that insertion of the fields
is the same, it can reuse the same IOAM type.
Frank: you want to detect the failure point rapidly. If you send probe
traffic you do not guarantee fate sharing. On the reverse path fate
sharing is not an issue.
Mickey: so loopback may be on normal data traffic.
Frank: right.
Mickey: this is a bit of a problem in sink nodes.
Shwetha: why would we want a more complex solution?
Tal: we want IOAM transit nodes to know whether this is the forward or
reverse path.
Shwetha: but we want nodes to push data on the reverse path as well.
Tal: it was decided in the past that we do not want IOAM nodes to push
data on the reverse path.
Shwetha: but if the path is symmetric you can have data on the reverse path.
Frank: I also remember that it was decided not to push data on the
reverse path. Of course we could have nodes push data on the reverse
path, and it can be ignored. Just clear the loopback flag when looping
back.
Tal: then the decapsulating node would not know that it needs to
terminate the packet. Also the amplification is doubled when we push
data on the reverse path.
Frank: if you have asymmetric routing, how do you know which path the
packet was returned through?
Shwetha: do we reverse the source and destination?
Mickey: yes.
Tal: according to the current version of the draft, the source address
in the looped back packet is the address of the looping back device.
Frank: if we receive the packet at the decapsulating node, what do we do?
Mickey: you need to know that it is a looped back packet.
Frank: not necessarily.
Mickey: if you use a new type, or two different flags it would solve
the problem.
Shwetha: how does it solve the problem? You need the decap node to
somehow know that it is the decap node anyway.
Mickey: if a packet comes from somewhere else you just export it.
However, if you initiated a loopback you know that.
Shwetha: there may be multiple nodes that perform loopback.
Mickey: when you reach the perimeter you decapsulate. You also need to
know whether you forward the packet or drop it. A loopback on the
reverse path needs to be dropped.
Shwetha: a node that started the loopback has to receive the response.
Maybe an E2E option would make more sense.
Tal: in addition to the trace option?
Shwetha: yes.
Frank: E2E is Edge-to-Edge, so we need to make sure that only edges process it.
Shwetha: which is what we have.
Frank: you need a way to know that the decap node needs to drop the
packet. We need some way to indicate that. A flag, or a type, or
whatever.
Mickey: you may use the active flag to indicate to drop the packet.
Tal: that would be a problem, because the original packet may be a
probe packet that has both the loopback and active flag are set.
Mickey: right. So we need either a new flag or a type.
Shwetha: or an E2E option. It would also indicate the identity of the
original node.
Mickey: how do you know the difference between encapsulating and decapsulating?
Tal: instead of an E2E option we could create a new IOAM type that
includes the identity of the sending IOAM node, and a separate IOAM
type for the reverse path.
Shwetha: the E2E option could be used just when you need the identity
of this node.
Tal: we now have five options. How do we proceed?
Shwetha: let's start with the requirements.
Mickey: loopback is a bit of a rat hole. We need to consider how far
we want to go.
Frank: let's try to gather all available options, and see what we can
and what we cannot solve. The discussion clarifies. It also depends on
the deployment scenario.
Tal: I will send a summary on the design team mailing list.