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

xiao.min2@zte.com.cn Tue, 22 March 2022 05:46 UTC

Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B569A3A080B for <bier@ietfa.amsl.com>; Mon, 21 Mar 2022 22:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eC-_ubDyAK2c for <bier@ietfa.amsl.com>; Mon, 21 Mar 2022 22:45:55 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E603A0801 for <bier@ietf.org>; Mon, 21 Mar 2022 22:45:54 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4KN0p76s8Gz85bJ3; Tue, 22 Mar 2022 13:45:51 +0800 (CST)
Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl2.zte.com.cn with SMTP id 22M5jlJD066781; Tue, 22 Mar 2022 13:45:47 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid201; Tue, 22 Mar 2022 13:45:46 +0800 (CST)
Date: Tue, 22 Mar 2022 13:45:46 +0800
X-Zmail-TransId: 2afb6239628affffffff8fd-d8339
X-Mailer: Zmail v1.0
Message-ID: <202203221345468614548@zte.com.cn>
In-Reply-To: <BY3PR13MB4787729F7E3C1EC7949D7BCC9A169@BY3PR13MB4787.namprd13.prod.outlook.com>
References: BL0PR05MB56526573902EEC959F7F4072D4139@BL0PR05MB5652.namprd05.prod.outlook.com, 202203191544437100174@zte.com.cn, BY3PR13MB4787729F7E3C1EC7949D7BCC9A169@BY3PR13MB4787.namprd13.prod.outlook.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: haoyu.song@futurewei.com
Cc: gregimirsky@gmail.com, zzhang=40juniper.net@dmarc.ietf.org, bier@ietf.org
Content-Type: text/plain; charset="UTF-8"
X-MAIL: mse-fl2.zte.com.cn 22M5jlJD066781
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 6239628F.000 by FangMail milter!
X-FangMail-Envelope: 1647927951/4KN0p76s8Gz85bJ3/6239628F.000/10.30.14.239/[10.30.14.239]/mse-fl2.zte.com.cn/<xiao.min2@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6239628F.000/4KN0p76s8Gz85bJ3
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/2zkS63oQChnPHgJAjhV002rZKbk>
Subject: Re: [Bier] A comment about draft-xzlnp-bier-ioam
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2022 05:46:02 -0000

Hi Haoyu,

Please see inline with <XM>>>.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人:HaoyuSong
收件人:肖敏10093570;
抄送人:gregimirsky@gmail.com;zzhang=40juniper.net@dmarc.ietf.org;bier@ietf.org;
日 期 :2022年03月22日 02:19
主 题 :RE: Re:[Bier] A comment about draft-xzlnp-bier-ioam
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.
<XM>>> There may be some misunderstanding. I didn't say we should ignore your draft. I meant we should not exclude IOAM tracing options in BIER, although IOAM data replication would happen at the branch node of multicast tree.
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?
<XM>>> I believe what Jeffrey and Greg have explained[1][2] is clear and much better than what I expected to say.
[1]: https://mailarchive.ietf.org/arch/msg/bier/ulGblR0CNBtVDZCun9uke12SjVA/
[2]: https://mailarchive.ietf.org/arch/msg/bier/1FVBD796gMxTi7P3DDUo-1xMosA/
Best regards,
Haoyu
-----Original Message-----
From: xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>
Sent: Saturday, March 19, 2022 12:45 AM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: gregimirsky@gmail.com; zzhang=40juniper.net@dmarc.ietf.org; bier@ietf.org
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;
抄送人:draft-xzlnp-bier-ioam@ietf.org;bier@ietf.org;
日 期 :2022年03月19日 00:34
主 题 :Re: [Bier] A comment about draft-xzlnp-bier-ioam _______________________________________________
BIER mailing list
BIER@ietf.org
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 <bier-bounces@ietf.org> On Behalf Of  Greg Mirsky
Sent: Friday, March 18, 2022 9:12 AM
To: Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org>
Cc: draft-xzlnp-bier-ioam@ietf.org; bier@ietf.org
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=40juniper.net@dmarc.ietf.org> 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%2BHGVdx
 Pg%3D&amp;reserved=0 in IETF112 BIER session.
Thanks.
Jeffrey
Juniper Business Use Only
_______________________________________________
BIER mailing list
BIER@ietf.org
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