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

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 18 Mar 2022 12:56:18 +0000

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

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 18 Mar 2022 16:21:42 +0100

good observation. As individual I think the IOAM draft is pretty
interesting work but yes, fragmentation is an issue we need to talk about
in this context

-- tony

On Fri, Mar 18, 2022 at 1:56 PM Jeffrey (Zhaohui) Zhang <zzhang=
[email-masked]> 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
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 18 Mar 2022 09:12:25 -0700

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
   <https://datatracker.ietf.org/doc/draft-ioamteam-ippm-ioam-direct-export/>
   , the Hybrid Two-step protocol
   <https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/>,
   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

---

From: Haoyu Song <[email-masked]>
Date: Fri, 18 Mar 2022 16:33:30 +0000

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://datatracker.ietf.org/doc/html/draft-ietf-mboned-multicast-telemetry-02

Thanks,
Haoyu

From: BIER <[email-masked]> On Behalf Of Greg Mirsky
Sent: Friday, March 18, 2022 9:12 AM
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Bier] A comment about draft-xzlnp-bier-ioam

  *   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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ioamteam-ippm-ioam-direct-export%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C54735bc6c37a468de86608da08fa2969%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637832167799434793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9CAL7LuD7cjzvyh1Ol4S2a5WoxG2ouA9tHPlEXUho1w%3D&reserved=0>, the Hybrid Two-step protocol<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mirsky-ippm-hybrid-two-step%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C54735bc6c37a468de86608da08fa2969%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637832167799434793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=R28oOGExqzscbeprcOg7voRpWY3YkKGr6wf4pFtsYkg%3D&reserved=0>, 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=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

This was discussed in https://www.ietf.org/archive/id/draft-zzhang-intarea-generic-delivery-functions-02.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-zzhang-intarea-generic-delivery-functions-02.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7C54735bc6c37a468de86608da08fa2969%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637832167799434793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rO4I%2FESyfCP0UNS4jrg6Tknagik9CElcsK9yaW4rAKg%3D&reserved=0>, and was mentioned in slide #6 of https://datatracker.ietf.org/meeting/112/materials/slides-112-bier-03-bier-slicing-and-differentiation-00<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&data=04%7C01%7Chaoyu.song%40futurewei.com%7C54735bc6c37a468de86608da08fa2969%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637832167799434793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=z9oQQ8lii%2Fd1116O8q8aW0eQvgtZmONVde283ZQXxc4%3D&reserved=0> in IETF112 BIER session.

Thanks.

Jeffrey

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=04%7C01%7Chaoyu.song%40futurewei.com%7C54735bc6c37a468de86608da08fa2969%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637832167799434793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9DdeqfG8inmYYQvWDfhbx8YflxojnBtz%2FYVFZ2PcBeI%3D&reserved=0>

---

From: <[email-masked]>
Date: Sat, 19 Mar 2022 14:30:58 +0800 (CST)

Hi Jeffrey,

Thank you for bringing it up to our attention.
I do agree your GDF draft provides a third option on how to encapsulate IOAM over BIER, which is different from the two options already described and compared in this BIER-IOAM draft.
To my understanding, the initial and main motivation to introduce GDF is to provide a fragmentation header for MPLS/BIER etc, just like IPv6 FH.
With that in mind, one possible way to push this "Encapsulating IOAM in BIER" work forward is to add the third option into BIER-IOAM draft for comparison, that makes it focused and easy to follow.
What's your opinion?

Best Regards,
Xiao Min

------------------原始邮件------------------
发件人：Jeffrey(Zhaohui)Zhang
收件人：[email-masked]';[email-masked];
日 期 ：2022年03月18日 20:56
主 题 ：[Bier] A comment about draft-xzlnp-bier-ioam
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
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

---

From: <[email-masked]>
Date: Sat, 19 Mar 2022 14:51:23 +0800 (CST)

Hi Tony,

I agree with you. Will try to add some descriptions on the fragmentation issue.

Best Regards,
Xiao Min

------------------原始邮件------------------
发件人：TonyPrzygienda
收件人：Jeffrey (Zhaohui) Zhang;
抄送人：[email-masked];[email-masked];
日 期 ：2022年03月18日 23:22
主 题 ：Re: [Bier] A comment about draft-xzlnp-bier-ioam
_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

good observation. As individual I think the IOAM draft is pretty interesting work but yes, fragmentation is an issue we need to talk about in this context

-- tony

On Fri, Mar 18, 2022 at 1:56 PM Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

---

From: <[email-masked]>
Date: Sat, 19 Mar 2022 15:31:44 +0800 (CST)

Hi Greg,

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

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：GregMirsky
日 期 ：2022年03月19日 00:13

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

Regards,
Greg

On Fri, Mar 18, 2022 at 5:56 AM Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]> wrote:
Hi,

---

From: <[email-masked]>
Date: Sat, 19 Mar 2022 15:44:43 +0800 (CST)

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;
日 期 ：2022年03月19日 00:34

---

From: Tianran Zhou <[email-masked]>
Date: Sat, 19 Mar 2022 13:58:29 +0000

I have concern about so many options for the same functionality.

Especially, there’s already IOAM encapsulation for MPLS and IPv6. Why we need another encapsulation in BIER layer?
As far as I understand, BIER will always be used with MPLS or IPv6.

Tianran

________________________________

Sent from WeLink
发件人： xiao.min2<[email-masked]<mailto:[email-masked]>>
收件人： zzhang=40juniper.net<zzhang=[email-masked]<mailto:zzhang=[email-masked]>>
抄送： bier<[email-masked]<mailto:[email-masked]>>
主题： Re: [Bier] A comment about draft-xzlnp-bier-ioam
时间： 2022-03-19 14:33:01

Hi Jeffrey,

Best Regards,
Xiao Min

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 19 Mar 2022 13:38:07 -0700

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 <[email-masked]> wrote:

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

> mechanism can be used for other purposes like fragmentation/security, etc.
> This was discussed in

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 20 Mar 2022 11:16:56 +0100

only advantage I see is that you can put telemetry on the data frame rather
than sending separate frame so it's somewhat more efficient but especially
you measure the data plane wihtout skewing it by telemetry (or skewing it
less than separate frames). That has pluses and minuses, biggest minus I
see fragmentation and the discussion about multicast vs. unicast OAM.
depending WHERE you want your OAM putting it on a frame may be a good or a
bad idea since the data frame determines replication

-- tony

On Sat, Mar 19, 2022 at 2:59 PM Tianran Zhou <zhoutianran=
[email-masked]> wrote:

> ------------------------------
>
> Sent from WeLink
> *发件人： *xiao.min2<[email-masked]>
> *收件人： *zzhang=40juniper.net<zzhang=[email-masked]>
> *抄送： *bier<[email-masked]>
> *主题： *Re: [Bier] A comment about draft-xzlnp-bier-ioam
> *时间： *2022-03-19 14:33:01
>
> Hi Jeffrey,
>
> I do agree your GDF draft provides a third option on how to encapsulate
> IOAM over BIER, which is different from the two options already described
> and compared in this BIER-IOAM draft.
> To my understanding, the initial and main motivation to introduce GDF is
> to provide a fragmentation header for MPLS/BIER etc, just like IPv6 FH.
> With that in mind, one possible way to push this "Encapsulating IOAM in
> BIER" work forward is to add the third option into BIER-IOAM draft for
> comparison, that makes it focused and easy to follow.
> What's your opinion?
>
> Best Regards,
> Xiao Min
>

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 20 Mar 2022 08:41:56 -0700

Tony, et al,
couple more notes that, I hope, are useful:

   - putting telemetry information into the trigger data packet has an
   inherent limitation of the length of the packet (yes, that is another way
   to name the fragmentation);
   - transporting telemetry outside of the trigger packet can be done
   out-of-band, i.e., using a different, and probably lower, CoS. Thus impact
   on the data traffic and possible skewing of metrics is lesser compared
   toE2E or HbH IOAM Trace options (inflating data packers with IOAM data is
   definitely affects the network). Telemetry information, in my opinion, is
   valuable, useful but not as critical as client data. Telemetry information
   transported within data packets is more likely to cause congestion for that
   flow than it being transported in separate but with lower CoS packets.

In my opinion, operators that know their network and choose to transport
telemetry information within data packets are free to do so. But I believe
that our documents must be explicit about the limitations of this mode and
the alternative methods that have certain advantages.

Regards,
Greg

On Sun, Mar 20, 2022 at 3:17 AM Tony Przygienda <[email-masked]> wrote:

> only advantage I see is that you can put telemetry on the data frame
> rather than sending separate frame so it's somewhat more efficient but
> especially you measure the data plane wihtout skewing it by telemetry (or
> skewing it less than separate frames). That has pluses and minuses, biggest
> minus I see fragmentation and the discussion about multicast vs. unicast
> OAM. depending WHERE you want your OAM putting it on a frame may be a good
> or a bad idea since the data frame determines replication
>
> -- tony
>

---

From: <[email-masked]>
Date: Mon, 21 Mar 2022 09:30:22 +0800 (CST)

Hi Tianran,

Generally speaking that's because they (IPv6, MPLS, BIER) are different layers, as indicated in Jeffrey's GDF draft.
Specifically, my personal criteria is that whether this layer would affect packet forwarding, e.g., SFC NSH layer would, so there is an adopted NSH IOAM draft (draft-ietf-sfc-ioam-nsh), BIER layer is similar. For other layers that wouldn't affect packet forwarding, e.g., Geneve layer, the advantage to have IOAM over it is not clear to me.

Best Regards,
Xiao Min

------------------原始邮件------------------
发件人：TianranZhou
收件人：肖敏10093570;zzhang=40juniper.net;
抄送人：bier;
日 期 ：2022年03月19日 21:58
主 题 ：Re: [Bier] A comment about draft-xzlnp-bier-ioam
_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

发件人： xiao.min2<[email-masked]>
收件人： zzhang=40juniper.net<zzhang=[email-masked]>
抄送： bier<[email-masked]>

---

From: <[email-masked]>
Date: Mon, 21 Mar 2022 09:42:10 +0800 (CST)

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
[email-masked]
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

------------------原始邮件------------------
发件人：GregMirsky
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

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 21 Mar 2022 15:33:24 +0000

Emmm, then my question is why we need the same function at different layers?
Can we just choose one?

Tianran

Sent from WeLink
发件人： xiao.min2<[email-masked]<mailto:[email-masked]>>
收件人： Tianran Zhou<[email-masked]<mailto:[email-masked]>>
抄送： zzhang<[email-masked]<mailto:[email-masked]>>;bier<[email-masked]<mailto:[email-masked]>>
主题： Re:[Bier] A comment about draft-xzlnp-bier-ioam
时间： 2022-03-21 09:31:05

Hi Tianran,

Best Regards,
Xiao Min

------------------原始邮件------------------
发件人：TianranZhou

---

From: Haoyu Song <[email-masked]>
Date: Mon, 21 Mar 2022 18:18:54 +0000

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: [email-masked] <[email-masked]> 
Sent: Saturday, March 19, 2022 12:45 AM
To: Haoyu Song <[email-masked]>
Cc: [email-masked]; zzhang=[email-masked]; [email-masked]
Subject: Re:[Bier] A comment about draft-xzlnp-bier-ioam

Hi Haoyu,

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：HaoyuSong
收件人：Greg Mirsky;Jeffrey (Zhaohui) Zhang;
抄送人：[email-masked];[email-masked];
日 期 ：2022年03月19日 00:34
主 题 ：Re: [Bier] A comment about draft-xzlnp-bier-ioam _______________________________________________
BIER mailing list
[email-masked]
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 <[email-masked]> On Behalf Of  Greg Mirsky
Sent: Friday, March 18, 2022 9:12 AM
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]; [email-masked]
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=[email-masked]> 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
[email-masked]
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

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 21 Mar 2022 18:21:48 +0000

Hi Xiao Min,

The purpose of GDF is to use the same extension header format for functionalities that may be used at different layers. Fragmentation was one example, and IOAM is another.
For that, it is ideal if IPv6/MPLS/BIER all could use the same extension headers.

While this draft is about IOAM, if we talk about BIER extension headers we need to consider it holistically.

Jeffrey

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Saturday, March 19, 2022 7:31 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: Re:[Bier] A comment about draft-xzlnp-bier-ioam

[External Email. Be cautious of content]

Hi Jeffrey,

Best Regards,
Xiao Min

------------------原始邮件------------------
发件人：Jeffrey(Zhaohui)Zhang
收件人：[email-masked]';[email-masked];
日 期 ：2022年03月18日 20:56
主 题 ：[Bier] A comment about draft-xzlnp-bier-ioam 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://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-zzhang-intarea-generic-delivery-functions-02.txt__;!!NEt6yMaO-gk!Q-3JJzNBtHRy-DGJNrQ4wqe7oXPyU1zkyW42eRc0vbprEoml9zmtJ_tA5MyGUkgy$ , and was mentioned in slide #6 of https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/112/materials/slides-112-bier-03-bier-slicing-and-differentiation-00__;!!NEt6yMaO-gk!Q-3JJzNBtHRy-DGJNrQ4wqe7oXPyU1zkyW42eRc0vbprEoml9zmtJ_tA5F-dbdqg$  in IETF112 BIER session.
Thanks.
Jeffrey
Juniper Business Use Only
_______________________________________________
BIER mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!Q-3JJzNBtHRy-DGJNrQ4wqe7oXPyU1zkyW42eRc0vbprEoml9zmtJ_tA5JjrM0gJ$

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 21 Mar 2022 18:29:24 +0000

Hi Tianran,

BIER is not necessarily always be either with MPLS or IPv6.
Even with BIER-MPLS, where the label just identifies BIER header and BIFT to use, it may not be good to put BIER extension headers as part of the MPLS extension headers.
Also notice that I am not just talking about IOAM, but any extension header that BIER may need.

Jeffrey

Juniper Business Use Only
From: Tianran Zhou <zhoutianran=[email-masked]>
Sent: Saturday, March 19, 2022 2:58 PM
To: xiao.min2 <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: bier <[email-masked]>
Subject: RE: [Bier] A comment about draft-xzlnp-bier-ioam

Tianran

Sent from WeLink

Hi Jeffrey,

Best Regards,
Xiao Min

------------------原始邮件------------------
发件人：Jeffrey(Zhaohui)Zhang
收件人：[email-masked]';[email-masked];
日 期 ：2022年03月18日 20:56
主 题 ：[Bier] A comment about draft-xzlnp-bier-ioam
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<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-zzhang-intarea-generic-delivery-functions-02.txt__;!!NEt6yMaO-gk!R7TPxlfa1oP3vqc_Y18142hBsptKuDCdDUrWzFcYPW540rTWlmeQdDEDg7zDbxjH$>, and was mentioned in slide #6 of https://datatracker.ietf.org/meeting/112/materials/slides-112-bier-03-bier-slicing-and-differentiation-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/112/materials/slides-112-bier-03-bier-slicing-and-differentiation-00__;!!NEt6yMaO-gk!R7TPxlfa1oP3vqc_Y18142hBsptKuDCdDUrWzFcYPW540rTWlmeQdDEDg18F-SAF$> in IETF112 BIER session.
Thanks.
Jeffrey
Juniper Business Use Only
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!R7TPxlfa1oP3vqc_Y18142hBsptKuDCdDUrWzFcYPW540rTWlmeQdDEDg81ICgx9$>

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!R7TPxlfa1oP3vqc_Y18142hBsptKuDCdDUrWzFcYPW540rTWlmeQdDEDg81ICgx9$>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 21 Mar 2022 12:50:30 -0700

Hi Tianran,
thank you for the question. I think that it is more related to the
operational motivation of how to use on-path telemetry mechanisms, e.g.,
IOAM. If it is applied in the underlay network (MPLS or IPv6), an operator
can monitor the performance of directly connected BIER nodes and underlay
tunnels connecting them. To gain visibility into all of the multicast
distribution from the BFIR to all BFERs each BFR must act as IOAM
encapsulating and decapsulating node. On the other hand, applying IOAM it
the BIER layer will provide telemetry information from only BFRs. I think
that both are useful and the choice should be given to operators.

Regards,
Greg

On Mon, Mar 21, 2022 at 8:33 AM Tianran Zhou <zhoutianran=
[email-masked]> wrote:

> *收件人： *Tianran Zhou<[email-masked]>
> *抄送： *zzhang<[email-masked]>;bier<[email-masked]>
> *主题： *Re:[Bier] A comment about draft-xzlnp-bier-ioam
> *时间： *2022-03-21 09:31:05
>
> Hi Tianran,
>
> Generally speaking that's because they (IPv6, MPLS, BIER) are different
> layers, as indicated in Jeffrey's GDF draft.
> Specifically, my personal criteria is that whether this layer would affect
> packet forwarding, e.g., SFC NSH layer would, so there is an adopted NSH
> IOAM draft (draft-ietf-sfc-ioam-nsh), BIER layer is similar. For other
> layers that wouldn't affect packet forwarding, e.g., Geneve layer, the
> advantage to have IOAM over it is not clear to me.
>
> Best Regards,
> Xiao Min
>
> Especially, there’s already IOAM encapsulation for MPLS and IPv6. Why we
> need another encapsulation in BIER layer?

---

From: <[email-masked]>
Date: Tue, 22 Mar 2022 13:45:46 +0800 (CST)

Hi Haoyu,

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：HaoyuSong
收件人：肖敏10093570;
抄送人：[email-masked];zzhang=[email-masked];[email-masked];
日 期 ：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: [email-masked] <[email-masked]>
Sent: Saturday, March 19, 2022 12:45 AM
To: Haoyu Song <[email-masked]>
Cc: [email-masked]; zzhang=[email-masked]; [email-masked]
Subject: Re:[Bier] A comment about draft-xzlnp-bier-ioam
Hi Haoyu,
------------------原始邮件------------------
发件人：HaoyuSong
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.

---

From: <[email-masked]>
Date: Tue, 22 Mar 2022 13:56:49 +0800 (CST)

Hi Jeffrey,

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：Jeffrey(Zhaohui)Zhang
收件人：肖敏10093570;
抄送人：[email-masked];
日 期 ：2022年03月22日 02:21
主 题 ：RE: Re:[Bier] A comment about draft-xzlnp-bier-ioam
Hi Xiao Min,
The purpose of GDF is to use the same extension header format for functionalities that may be used at different layers. Fragmentation was one example, and IOAM is another.
<XM>>> I see your preference :)
Note that fragmentation is for edge-to-edge, however IOAM is for both edge-to-edge and hop-by-hop, trying to combine them is ambitious and not easy.

For that, it is ideal if IPv6/MPLS/BIER all could use the same extension headers.
<XM>>> Note that IPv6 IOAM draft (draft-ietf-ippm-ioam-ipv6-options) has passed WG LC in IPPM WG.
While this draft is about IOAM, if we talk about BIER extension headers we need to consider it holistically.
Jeffrey
Juniper Business Use Only

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 22 Mar 2022 09:33:07 +0000

Hi Greg,

Even the overlay, there are at least three solutions.
The GFH, BIER-IOAM, multicast-telemetry.
BIER is rare implemented.
Are we going to standardize so many solutions?

Best,
Tianran

From: Greg Mirsky [mailto:[email-masked]]
Sent: Tuesday, March 22, 2022 3:51 AM
To: Tianran Zhou <[email-masked]>
Cc: xiao.min2 <[email-masked]>; zzhang <[email-masked]>; bier <[email-masked]>
Subject: Re: [Bier] A comment about draft-xzlnp-bier-ioam

Hi Tianran,
thank you for the question. I think that it is more related to the operational motivation of how to use on-path telemetry mechanisms, e.g., IOAM. If it is applied in the underlay network (MPLS or IPv6), an operator can monitor the performance of directly connected BIER nodes and underlay tunnels connecting them. To gain visibility into all of the multicast distribution from the BFIR to all BFERs each BFR must act as IOAM encapsulating and decapsulating node. On the other hand, applying IOAM it the BIER layer will provide telemetry information from only BFRs. I think that both are useful and the choice should be given to operators.

Regards,
Greg

On Mon, Mar 21, 2022 at 8:33 AM Tianran Zhou <zhoutianran=[email-masked]<mailto:[email-masked]>> wrote:
Emmm, then my question is why we need the same function at different layers?
Can we just choose one?

Tianran

Sent from WeLink

Hi Tianran,

Best Regards,
Xiao Min

------------------原始邮件------------------
发件人：TianranZhou
收件人：肖敏10093570;zzhang=40juniper.net<http://40juniper.net>;
抄送人：bier;
日 期 ：2022年03月19日 21:58

收件人： zzhang=40juniper.net<http://40juniper.net><zzhang=[email-masked]<mailto:[email-masked]>>
------------------原始邮件------------------
收件人：[email-masked]<mailto:[email-masked]>';[email-masked]<mailto:[email-masked]>;

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 23 Mar 2022 10:27:22 +0000

Hi Xiao Min,

Please see zzh> below.

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Tuesday, March 22, 2022 6:57 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: Re:[Bier] A comment about draft-xzlnp-bier-ioam

Hi Jeffrey,

Best Regards,
Xiao Min
------------------原始邮件------------------

 Hi Xiao Min, The purpose of GDF is to use the same extension header format for functionalities that may be used at different layers. Fragmentation was one example, and IOAM is another.
<XM>>> I see your preference :)
Note that fragmentation is for edge-to-edge, however IOAM is for both edge-to-edge and hop-by-hop, trying to combine them is ambitious and not easy.

Zzh> Whether it is edge-to-edge or hop-by-hop, if we need extension headers, we need to consider all cases holistically.

Zzh> that's why I have been proposing to reuse IPv6 headers (if possible) at different layers. *If it is possible to * reuse IPv6 IOAM header (in BIER extension header) for BIER purpose, wouldn't it be nice? We can talk about it further in the BIER meeting.
Zzh> Thanks.
Zzh> Jeffrey