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

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 <xiao.min2@zte.com.cn> wrote:

> Hi Greg,
>
> Thanks for your comments.
> Please see inline with <XM>>>.
>
> Best Regards,
> Xiao Min
> ------------------原始邮件------------------
> 发件人：GregMirsky
> 收件人：Jeffrey (Zhaohui) Zhang;
> 抄送人：draft-xzlnp-bier-ioam@ietf.org;bier@ietf.org;
> 日 期 ：2022年03月19日 00:13
> 主 题 ：Re: [Bier] A comment about draft-xzlnp-bier-ioam
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> 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.

>
> 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.

>
> 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://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
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>