[Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting Minutes

[Tal Mizrahi <[e-mail]>]

IPPM IOAM Design Team
Virtual meeting
September 2nd, 2020, 06:00 UTC
Webex meeting

Attendees:
Shwetha Bhandari, Frank Brockners, Barak Gafni, Greg Mirsky, Mickey
Spiegel, Tal Mizrahi.

Minutes by Tal Mizrahi.


Summary:
========
- Loopback on the reverse path: based on the discussion below, Tal
will send an updated proposal to the mailing list of how loopback on
the reverse path will work.
- Frank has merged the IPv6 encapsulation draft with IPv6 deployment
draft. Feedback will be welcome.
- The next meeting will be on the 16th of September.


Flag Draft:
===========
Tal: there was some correspondence on the mailing list about loopback
on the reverse path. Frank Suggested to think some more about the
option to use a dedicated encapsulation/exporting format on the
reverse path.
Frank: yes. There is a leaking issue we need to solve, and if the
looping device just uses the source address it may not reach the
original node if the paths are not symmetric.
Barak: is it specific to IPv6 encapsulation?
Frank: you will need double encapsulation anyway. Loopback is
applicable to IPv6 native environments - this is a major scenario. The
only solution we have in IPv6 is double encap.
Barak: maybe we can consider that the only node allowed to set the
loopback flag is the IOAM encapsulating node?
Frank: so the source of the packet needs to be at the edge of the IOAM
domain. But you do not know if the source gets the looped back packet.
Barak: if you are using the source IP address, it guarantees that it
goes back to the encapsulating node.
Frank: right. That may be a way to go. Constrain it just to the host.
Barak: yes, the originating node may be a switch as well.
Frank: synthetic traffic may not share its fate with the data traffic.
That is why we need loopback. If you initiate loopback on a switch the
source address may be different than data traffic, and that means
there is no fate sharing with data traffic.
Greg: right, ECMP may prevent fate sharing. However, there are
existing solutions for this. You can discover all possible paths and
trace them by scanning different L4 ports.
Frank: right, but we would like to avoid that.
Greg: the advantage of using the data traffic itself is fate sharing.
However, control path allows you to trace all possible paths, which is
another advantage.
Frank: exploring all possible paths is an important feature, but in
some use cases you only want to troubleshoot a specific path.
Barak: unlike Ping and Traceroute you can use the exact same packet
that you need to troubleshoot.
Frank: right, but if such a packet is generated by a switch, its
source address is different than the data packet that it was meant to
simulate.
Mickey: when we do IPv6-in-IPv6, what are the outer addresses?
Frank: the outer destination address is the IOAM edge.
Mickey: you have to prevent leaking. Not necessarily needed to put a
different address in the forward direction.
Frank: the outer IPv6 addresses are of the IOAM encap/decap nodes.
Greg: in an IP network there is no guarantee that forward and reverse
path are the same.
Frank: right. But double encap was the only way to get it past 6man.
We are all on the same page.
Greg: 6man insisted on tunneling, since at the edge the tunnel is removed.
Frank: if you explicitly put the destination address of the edge in
the looped back packet it seems to solve the problem.
Mickey: but you do not necessarily need an export format.
Frank: right, the main issue is what destination address you put in
the looped back packet.
Mickey: in the IPv6 case you already put the address of the IOAM
edges, so the problem is solved.
Frank: right. IPv6 is already a tunneled environment, and the IOAM
encap node is an edge, so there is no problem to flip the address. If
the IOAM source is a host, that is no problem either - no additional
filtering required.
Barak: not sure this prevents leaking. It is possible to send an IOAM
packet into the IOAM domain, and it will be sent back to the sender.
Frank: but if you do it the way I suggested, all the loopback traffic
goes back to the sink node. The question is how you send the sink
address: in band, or out of band.
Frank: not sure we have made progress. Let's keep this option in mind.
Mickey: I think reversing the address does not increase the leaking
problem. In the non-IPv6 case you are relying on boundary filtering
anyway.
Tal: should we restrict loopback only to the tunnel case?
Barak: it looks like we are already there.
Mickey: there are cases of returning information to the source that is a host.
Frank: do you suggest an option type?
Mickey: either an option type or a flag.
Frank: and there was the approach to use an E2E option.
Tal: we only have 4 flags, and one of them was taken as the overflow
flag, so if we use a flag for the reverse path we consume all flags.
Shwetha: but why do you want a flag?
Barak: you do not need to add another header.
Shwetha: but we said that it is okay to collect data on the reverse
path. You clear the loopack flag anyway.
Barak: sounds reasonable. It is not a concern to collect more data on
the reverse.
Mickey: loopback still needs to be dropped by the encap node.
Barak: the destination address is the edge.
Tal: what you are suggesting is to have the looping IOAM node clear
the loopback flag, have IOAM nodes push more data, and finally the
IOAM edge node terminates that packet based on its destination
address?
Frank: an edge can look at the first hop of the trace information, and
see that the node ID is the current node, and this can indicate that
the packet started from the current node.
Greg: loopback is supposed to get back to the sender. If it does not,
there is a problem.
Mickey: there is a restriction that you can do loopback only if there
is double encap, or the IOAM edge node is a host.
Frank: right.
Greg: we need to distinguish between what is supposed to be and what
is a security threat.
Shwetha: the backdoor is a general IOAM problem, not just loopback.
Frank: right.
Mickey: you still have to secure your edges. Loopback is just another
point to consider.
Frank: let's summarize that either the traffic is originated by the
host, or tunneled from IOAM edge to IOAM edge. By flipping the address
you get to either the host or IOAM edge. The Loopback flag on the
forward path, and cleared on the reverse path. We continue to collect
on the reverse, and the loopack is identified by the IOAM source by
comparing its node ID.
Mickey: I do not think these are all the IOAM use cases we are
familiar with. What about VXLAN and the VXLAN is imposed by the hosts,
but the IOAM domain starts at the top-of-rack, then loopback will not
work.
Frank: not sure that will work in general.
Tal: I agree with Frank's suggestions. We can define the assumption
under which loopback is applicable. I will post it on the mailing list
and see if there is feedback.


IPv6 Deployment
===============
Frank: I put together a consolidated IPv6 encap / deployment draft.
Haven't changed the text, just consolidated. Please take a look at it.


Data Draft
==========
Barak: I am suggesting to add a few new data fields. I will post it on
Github in the next few days.


Export Draft
============
Frank: the export draft is about to expire soon. Mickey - would you
like to refresh it?