Re: [Bier] A comment about draft-xzlnp-bier-ioam

[Haoyu Song <[e-mail]>]

Hi Xiao Min,

Data replication is a serious inefficiency we need to deal with. That some operators don't care doesn't mean we should ignore it. Since BIER is just one type of multicast network, we should have a generic solution for all of them, that's the purpose of our draft.

As for the encapsulation, I agree with the others that we may just need one method per transport. If BIER is carried in MPLS or IPv6, it seems enough if we have already have a method to encap the IOAM headers in MPLS and IPv6. Is there any benefit or necessity for encapsulating IOAM in BIER  I missed?  

Best regards,
Haoyu 

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Saturday, March 19, 2022 12:45 AM
To: Haoyu Song <[e-mail]>
Cc: [e-mail]; zzhang=[e-mail]; [e-mail]
Subject: Re:[Bier] A comment about draft-xzlnp-bier-ioam

Hi Haoyu,

Thank you for bringing your Multicast-Telemetry draft up to our attention.
As I replied to Greg, considering some multicast network operators don't care about IOAM data replication, we remain the "IOAM trace data in BIER" within the scope.
I suggest your MT draft and this discussed one give a reference to each other, what do you think?

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：HaoyuSong
收件人：Greg Mirsky;Jeffrey (Zhaohui) Zhang;
抄送人：[e-mail];[e-mail];
日 期 ：2022年03月19日 00:34
主 题 ：Re: [Bier] A comment about draft-xzlnp-bier-ioam _______________________________________________
BIER mailing list
[e-mail]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb1c52d6af0024a51ca9508da097c5a78%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637832726961652906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=vPwlOl5HOrXXb%2F5CwmFK56Yodo00M2e7ORkNZDy8Tw0%3D&amp;reserved=0

I agree with the first point made by Greg. It is inefficient to support the IOAM trace in multicast scenario due to unnecessary data duplication. In our draft we have discussed the issues and provided solutions, which are also applicable  to BIER (sec 5.3).
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-mboned-multicast-telemetry-02&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb1c52d6af0024a51ca9508da097c5a78%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637832726961652906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2xZlDcXxk4RyxKsrl%2FDA58V5j2e8gs%2B6Y7pw6eCECSs%3D&amp;reserved=0
Thanks,
Haoyu
From: BIER <[e-mail]> On Behalf Of  Greg Mirsky
Sent: Friday, March 18, 2022 9:12 AM
To: Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Bier] A comment about draft-xzlnp-bier-ioam Thank you for bringing this work to the discussion.
I have read the draft and got several comments:
the IOAM mechanism described in draft-ietf-ippm-ioam-data appears to be better suited for p2p flows. When applied in a multicast network, IOAM results in unnecessary replication of IOAM data recorded upstream. This can be avoided by separating the process of  generating telemetry information on a node according to the profile in the IOAM header from transporting that information to a collector for processing. That can be achieved using the  IOAM Direct Export mode of IOAM tracing, the  Hybrid Two-step protocol, or any other means of transportation.
I suggest updating Figure 1. As mentioned above, there are other methods of transporting IOAM data rather than in the trigger packet immediately following the IOAM Option header. I think that the right tag for the field would be "IOAM Option and Optional Data  Space". Alternatively, the figure may display IOAM Option and IOAM Data Space fields separately, noting that the latter is optional.
Regards,
Greg
On Fri, Mar 18, 2022 at 5:56 AM Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]> wrote:
Hi,
For IOAM data in BIER, I want to point out that we should use a generic header format that can be used for BIER/MPLS/IPv6. The same extension mechanism can be used for other purposes like fragmentation/security, etc.
This was discussed in  https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-zzhang-intarea-generic-delivery-functions-02.txt&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb1c52d6af0024a51ca9508da097c5a78%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637832726961652906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HOsezS63SWrCQNdBK%2FD1RNs6G%2FdZ%2B1s7SZR5Zrk4jDM%3D&amp;reserved=0, and was mentioned in slide #6 of  https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F112%2Fmaterials%2Fslides-112-bier-03-bier-slicing-and-differentiation-00&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb1c52d6af0024a51ca9508da097c5a78%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637832726961652906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Dlzx60K1SRnGq7cDWF0T7aOdsjYXZ9E9PCb%2BHGVdxPg%3D&amp;reserved=0 in IETF112 BIER session.
Thanks.
Jeffrey
Juniper Business Use Only
_______________________________________________
BIER mailing list
[e-mail]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb1c52d6af0024a51ca9508da097c5a78%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637832726961652906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=vPwlOl5HOrXXb%2F5CwmFK56Yodo00M2e7ORkNZDy8Tw0%3D&amp;reserved=0