Subject: [ippm] Multicast telemetry

From: Michael McBride <[email-masked]>
Date: Fri, 27 Mar 2020 21:46:52 +0000

Hello,

We didn't make it on the agenda for next week, which is fine, but did want to raise awareness of draft-song-multicast-telemetry-02 which we updated last month. Among other edits, we included Frank's comments, from Singapore, where he suggested encoding the branch identifier in the existing node ID data field. Please give it a read and let's discuss on the list:

https://datatracker.ietf.org/doc/draft-song-multicast-telemetry/

thanks,
mike

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 30 Mar 2020 06:56:31 +0000

Hi Michael,

Thank you very much for bringing this interesting topic and the update to the mailing list.
I have several questions after reading the document:
1. What's your assumption for the solution on the multicast tree topology, known or unknown? If known, we know the node sequence, the branch node. I am not sure if we need to take the branch information or not, probably not. If unknown, how to identify the branch node and "We just need to configure the branch node to export the postcard and refresh the IOAM header and data."(in section 4.2)
2. Section 4.1, you propose the way to use branch node ID plus an index as the branch ID. Did you consider multiple trees in the network and one node is just in multiple trees? How to encode the index? What's the difference to the node ID + interface ID?
3. Also the section 4.1, as shown in figure 1, each node need to export the branch ID which is actually belongs to the preceding node. How to bring the preceding node information to the next hop?

As this is an informational document,  but right now it contains some normative part IMO. I have great interest on this work. What's your consequent plan?

Thanks,
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Michael McBride
Sent: Saturday, March 28, 2020 5:47 AM
To: [email-masked]
Subject: [ippm] Multicast telemetry

Hello,

thanks,
mike

---

From: Haoyu Song <[email-masked]>
Date: Tue, 31 Mar 2020 17:42:19 +0000

Hi Tianran,

Please see the inline reply.

Haoyu

From: ippm <[email-masked]> On Behalf Of Tianran Zhou
Sent: Sunday, March 29, 2020 11:57 PM
To: Michael McBride <[email-masked]>; [email-masked]
Subject: Re: [ippm] Multicast telemetry

Hi Michael,

HS> There's no assumption on whether the multicast tree topology is known or unknown. If it's known, either this is known by different entities from the monitor or you still want to verify it from the real monitoring results. If it's unknown, we can still configure the telemetry behavior to all the node. When in operation, if a node actually becomes a branch node, it will follow the configured telemetry behavior.

  1.  Section 4.1, you propose the way to use branch node ID plus an index as the branch ID. Did you consider multiple trees in the network and one node is just in multiple trees? How to encode the index? What's the difference to the node ID + interface ID?

HS> The branch ID is only valid per multicast tree instance. If a node is a branch node for multiple multicast trees, each instance can have its own branch ID set.

The most compact way to encode the index is simply numbering the interface. What you said (using node ID + i/f ID) can also differentiate the branches, but it has some issues: the i/f ID might be too long, making the resulting branch ID very different from the original node ID; the branch IDs are not consecutive numbers, making it difficult to correlate the branches and identify missing branches.

  1.  Also the section 4.1, as shown in figure 1, each node need to export the branch ID which is actually belongs to the preceding node. How to bring the preceding node information to the next hop?

HS> This is a good observation. Thank you for catch it. In the earlier version, we consider to augment/modify the IOAM DEX header to include the branch ID field. In this new version, we consider to move it to the node data field. You are right, we cannot pass this information to the next node. I think to amend this, we can make this field an optional field in the DEX header. We need to give this more thought.

HS> Our goal is to try the best to comply with the existing standard proposals such as IOAM Trace and IOAM DEX and propose solutions for different multicast techniques. So far it seems possible to realize that without introducing fundamental changes. This is still a working document and we welcome all contributions.

Thanks,
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Michael McBride
Sent: Saturday, March 28, 2020 5:47 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [ippm] Multicast telemetry

Hello,

https://datatracker.ietf.org/doc/draft-song-multicast-telemetry/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-multicast-telemetry%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7Cb6f251ec1be747dd821e08d7d47793e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637211482351714222&sdata=T4UGvpxY5zdcKztzGsszTDiq2Shv35deLFYpJCefQew%3D&reserved=0>

thanks,
mike