Subject: [ippm] Questions about draft-ietf-ippm-ioam-flags

From: wangyali <[email-masked]>
Date: Wed, 5 Aug 2020 07:09:00 +0000

Dear authors,

This is Yali. After reading, I have the following questions interested in.

First, as Loopback mode allows an IOAM encapsulating node to receive per-hop data about both the forward and the return path, so is it co-routed bidirectional path?

Second, how does each return path from transit node and destination nodes towards the encapsulation node be determined? And are these return paths from each transit node towards the encapsulation node the same?

Third, in the Loopback mode, as each transit nodes along the forward path will create a copy of the received packet and send it back to the source of the packet, these are a large amount of redundant tracing data recorded at the same transit node that packet traverse.

In addition, in draft-wang-ippm-stamp-hbh-extensions-00<https://datatracker.ietf.org/doc/draft-wang-ippm-stamp-hbh-extensions/> , we propose an alternative way to realize active measurement with IOAM Trace Option. In this draft, a new IOAM Tracing Data TLV is extended to STAMP, which is used for recording the IOAM tracing data of each transit node along the forward path that STAMP sender test packets traverse. Similarly, we could insert  IOAM Trace Option in the reflector test packets to record the IOAM tracing data about the reverse path. So that the STAMP session-sender can receive per-hop IOAM tracing data about both the forward and the backward path. Any comments and inputs for the new draft are very welcome.
Waiting forward to your response.
Thanks,
Yali

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 6 Aug 2020 09:44:51 +0300

Hi Yali,

Thanks for the comments.

> First, as Loopback mode allows an IOAM encapsulating node to receive per-hop data about both the forward and the return path, so is it co-routed bidirectional path?

The loopback reverse path functionality is an open issue that we
discussed in the IETF meeting last week. This point in the draft is
expected to undergo changes.
As discussed, IOAM data insertion on the reverse path will be removed
from the draft.

> Second, how does each return path from transit node and destination nodes towards the encapsulation node be determined? And are these return paths from each transit node towards the encapsulation n…

Following the point above, there is no specific requirement about the
reverse path, other than the fact that it is assumed that a reverse
path exists. It does not have to be a bidirectional path.

> Third, in the Loopback mode, as each transit nodes along the forward path will create a copy of the received packet and send it back to the source of the packet, these are a large amount of redunda…

Right. Loopback is a bit similar to Traceroute in the sense that each
transit node responds to the sender, but different from Traceroute in
the sense that a single packet triggers response from all the transit
nodes. The performance and security aspects of this amplification are
discussed in the draft (Section 7 and Section 8).

>
>
> In addition, in draft-wang-ippm-stamp-hbh-extensions-00 , we propose an alternative way to realize active measurement with IOAM Trace Option. In this draft, a new IOAM Tracing Data TLV is extended to STAMP, which is used for recording the IOAM tracing data of each transit node along the forward path that STAMP sender test packets traverse. Similarly, we could insert  IOAM Trace Option in the reflector test packets to record the IOAM tracing data about the reverse path. So that the STAMP session-sender can receive per-hop IOAM tracing data about both the forward and the backward path. Any comments and inputs for the new draft are very welcome.
>

Cheers,
Tal.

---

From: wangyali <[email-masked]>
Date: Fri, 7 Aug 2020 10:04:10 +0000

Hi Tal,

Thanks for your reply. Please see inline [Yali].

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]] 
Sent: Thursday, August 6, 2020 2:45 PM
To: wangyali <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Questions about draft-ietf-ippm-ioam-flags

Hi Yali,

Thanks for the comments.

> First, as Loopback mode allows an IOAM encapsulating node to receive per-hop data about both the forward and the return path, so is it co-routed bidirectional path?

The loopback reverse path functionality is an open issue that we discussed in the IETF meeting last week. This point in the draft is expected to undergo changes.
As discussed, IOAM data insertion on the reverse path will be removed from the draft.

> Second, how does each return path from transit node and destination nodes towards the encapsulation node be determined? And are these return paths from each transit node towards the encapsulation n…

Following the point above, there is no specific requirement about the reverse path, other than the fact that it is assumed that a reverse path exists. It does not have to be a bidirectional path.

> Third, in the Loopback mode, as each transit nodes along the forward path will create a copy of the received packet and send it back to the source of the packet, these are a large amount of redunda…

Right. Loopback is a bit similar to Traceroute in the sense that each transit node responds to the sender, but different from Traceroute in the sense that a single packet triggers response from all the transit nodes. The performance and security aspects of this amplification are discussed in the draft (Section 7 and Section 8).

[Yali]: Yes. There's a big difference. In traceroute function, multiple packets with an increasing TTL will be sent out until the destination is reached. I mean,  in your draft, a copy of the received packet created by each transit node along the forward path carries a part of redundant tracing data lists which have been responded by previous transit nodes. Why don't the n-th transit node create a copy of the received packet with only the h-th node data list [h] in the IOAM trace option and remove node data list [0..h] before transmitting the lopped back packet back towards the encapsulating node. Is it a way to decrease the cost of the network bandwidth?

Cheers,
Tal.