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

[[e-mail]]

Hi Greg,

Please see inline with <XM2>>>.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：GregMirsky
收件人：肖敏10093570;
抄送人：BIER WG;Jeffrey (Zhaohui) Zhang;
日 期 ：2022年03月20日 04:38
主 题 ：Re: [Bier] A comment about draft-xzlnp-bier-ioam
_______________________________________________
BIER mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bier

Hi Xiao Min,thank you for your kind consideration of my notes. I have added follow-up comments in-line below under the GIM>> tag.

Regards,
Greg

On Sat, Mar 19, 2022 at 12:31 AM <[e-mail]> wrote:
Hi Greg,
Thanks for your comments.
Please see inline with <XM>>>.
Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：GregMirsky
收件人：Jeffrey (Zhaohui) Zhang;
抄送人：[e-mail];[e-mail];
日 期 ：2022年03月19日 00:13
主 题 ：Re: [Bier] A comment about draft-xzlnp-bier-ioam
_______________________________________________
BIER mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bier
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.
GIM>> I agree, in some scenarios the replication of the upstream data might be of lesser concern. But it seems prudent to explicitly call out that property of IOAM HbH Trace Option in a multicast network in the document and point to approaches to avoid it.
<XM2>>> Make sense. Will add text on it as you proposed.

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. :)
GIM>> I believe that we need to start somewhere. Besides, it appears that the authors of draft-ietf-sfc-ioam-nsh have agreed to make this update already.
<XM2>>> That's good! Will align with them.

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://www.ietf.org/archive/id/draft-zzhang-intarea-generic-delivery-functions-02.txt, and was mentioned in slide #6 of https://datatracker.ietf.org/meeting/112/materials/slides-112-bier-03-bier-slicing-and-differentiation-00 in IETF112 BIER session.
Thanks.
Jeffrey
Juniper Business Use Only
_______________________________________________
BIER mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bier