Re: [Bier] A comment about draft-xzlnp-bier-ioam Sat, 19 March 2022 07:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 748BC3A0A8C for <>; Sat, 19 Mar 2022 00:31:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=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=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nRMdgmMPCgD6 for <>; Sat, 19 Mar 2022 00:31:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 407A13A0A8B for <>; Sat, 19 Mar 2022 00:31:50 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4KLCHk1bxCz85bQM; Sat, 19 Mar 2022 15:31:46 +0800 (CST)
Received: from ([]) by with SMTP id 22J7Vi4j060507; Sat, 19 Mar 2022 15:31:44 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid201; Sat, 19 Mar 2022 15:31:44 +0800 (CST)
Date: Sat, 19 Mar 2022 15:31:44 +0800
X-Zmail-TransId: 2afb623586e0b363589a
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-MAIL: 22J7Vi4j060507
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04- with ID 623586E2.000 by FangMail milter!
X-FangMail-Envelope: 1647675106/4KLCHk1bxCz85bQM/623586E2.000/[]/<>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 623586E2.000/4KLCHk1bxCz85bQM
Archived-At: <>
Subject: Re: [Bier] A comment about draft-xzlnp-bier-ioam
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 19 Mar 2022 07:31:54 -0000

Hi Greg,

Thanks for your comments.
Please see inline with <XM>>>.

Best Regards,
Xiao Min
收件人:Jeffrey (Zhaohui) Zhang;
日 期 :2022年03月19日 00:13
主 题 :Re: [Bier] A comment about draft-xzlnp-bier-ioam
BIER mailing list

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.
<XM>>> I agree to your analysis. Note that whether using draft-ietf-ippm-ioam-data, IOAM Direct Export mode of IOAM tracing or the Hybrid Two-step protocol, some type of IOAM data needs to be encapsulated in a BIER packet, so this BIER-IOAM draft is always needed. The reason why draft-ietf-ippm-ioam-data is not excluded is that some operators told us in their multicast networks they didn't care about the replication of IOAM data.

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.
<XM>>> Personally I agree to the change you proposed. Alignment among all kinds of IOAM-Encapsulation drafts is also needed. :)


On Fri, Mar 18, 2022 at 5:56 AM Jeffrey (Zhaohui) Zhang <> wrote:
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, and was mentioned in slide #6 of in IETF112 BIER session.
Juniper Business Use Only
BIER mailing list