Hi Zhenqiang, Thanks for the support and comments!
As for the status of the document, certainly it cannot cover aspects in just one document, but I think the configured data types, and postcard correlation methods can and should be standardized. We could seek a consensus later. For your second point, I think each method has its merits and suitable application scenarios. Also, if we design carefully, all these schemes can in fact share many common components (e.g., data type and data export protocol) and thus the cost to support them is low. Thus I think we should have them a toolset and let users to choose. Best regards, Haoyu From: ippm <ippm-boun...@ietf.org> On Behalf Of li_zhenqi...@hotmail.com Sent: Tuesday, January 3, 2023 8:25 AM To: Tianran Zhou <zhoutianran=40huawei....@dmarc.ietf.org>; Rakesh Gandhi <rgandhi.i...@gmail.com> Cc: spring@ietf.org; ippm <i...@ietf.org> Subject: Re: [ippm] [spring] Progressing the PBT-M “Zero Overhead property” draft Hello all, I've read the doc and the discussion in this list. PBT-M is an interesting scheme which will create a lot of requirements for defining new protocols including trigger, metric config, metric export etc. I think we should keep it informational and move it forward ASAP since it is mainly a framework doc. The new protocols needed can be defined in seperate docs which should be in standard track. Till now, we have passport and postcard iOAM and for postcard we have PBT-M and iOAM DEX. Do we need so many iOAMs, which scheme is the best or each of them has its own applicable scene? ________________________________ Best Regards, Zhenqiang Li li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> 发件人： Tianran Zhou<mailto:zhoutianran=40huawei....@dmarc.ietf.org> 发送时间： 2022-12-24 11:18 收件人： Rakesh Gandhi<mailto:rgandhi.i...@gmail.com> 抄送： Gyan Mishra<mailto:hayabusa...@gmail.com>; IETF IPPM WG<mailto:i...@ietf.org>; SPRING WG<mailto:spring@ietf.org> 主题： Re: [spring][ippm] Progressing the PBT-M “Zero Overhead property” draft Hi Rakesh, Thanks very much for your suggestion. I agree the ECMP is one special case that we should take care. The authors should include some text on ECMP considerations. Do you have any special concern that wish the authors to consider in the revision? Cheers, Tianran From: Rakesh Gandhi [mailto:rgandhi.i...@gmail.com] Sent: Thursday, December 22, 2022 1:52 AM To: Tianran Zhou <zhoutian...@huawei.com<mailto:zhoutian...@huawei.com>> Cc: Gyan Mishra <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>>; IETF IPPM WG <i...@ietf.org<mailto:i...@ietf.org>>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Subject: Re: [ippm] Progressing the PBT-M “Zero Overhead property” draft Hi all, Yes, this is a useful document for telemetry use-cases where no metadata is carried in the packet. One comment I have is that the document may add some text on ECMP considerations. Happy Holidays! Thanks, Rakesh On Sun, Dec 18, 2022 at 4:09 AM Tianran Zhou <zhoutianran=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>> wrote: Hi Gyan, Thanks very much for raising this discussion in the mailing list. As discussed in the document, there are pros and cons both for PBT-M and PBT-I(IOAM-DEX). I really think this is useful, especially when the network is MTU sensitive or not powerful, like DetNet. I think the WG should progress it as a standard document. Best, Tianran 发件人: ippm [mailto:ippm-boun...@ietf.org<mailto:ippm-boun...@ietf.org>] 代表 Gyan Mishra 发送时间: 2022年12月14日 11:25 收件人: IETF IPPM WG <i...@ietf.org<mailto:i...@ietf.org>>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> 主题: [ippm] Progressing the PBT-M “Zero Overhead property” draft Dear IPPM WG RE: Progressing draft-song-ippm-postcard-based-telemetry-15 I would like to provide some important feedback related to the draft and the critically of this draft to the industry at large especially with 5G MNOs and future soon to be 6G and UPF F1 interface network slicing and IPPM telemetry for Flex Algo latency constraint for ultra low latency path for MEC services and end to end ultra low latency path instantiation. My POV as well as others whom I have discussed the draft in and outside the WG is that in order to make PBT viable and useful to operators to deploy, the changes and improvements described in this draft are very important and not just to the IPPM WG but to the industry at large namely for deployments of Segment Routing both SR-MPLS and SRv6 and viability of IOAM in-situ telemetry. This is a huge issue today and PBT RFC 9326 is an attempt to solve the issues with telemetry with Segment Routing but unfortunately that is not enough and now with this draft, PBT based telemetry with Segment Routing can finally come to fruition for all operators around the world wanting to deploy Segment Routing. I think with SR both SR-MPLS and SRv6 MSD and SR-MPLS Maximum readable label depth issues and MPLS MNA extensibility discussed in the MPLS Open DT meetings are important issues and considerations and with IOAM data with DEX PBT solution can possibly resolves the issue with the export with zero in-situ overhead philosophy and is a fabulous attempt but with a major hitch. To make RFC 9326 viable out the gate for any operators to implement, we really need the changes and updates to RFC 9326 described in this draft to be progressed. This draft should be and I think the authors of this draft as well as the authors of RFC 9326 would as well agree that this draft should be Standards Track and update the base specification RFC 9326 for PBT. I believe that would be the best path forward for the WG. All comments are welcome on this important topic. Many Thanks Gyan -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Chaoyu.song%40futurewei.com%7C763779969aa248b1755e08daeda6c8fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638083597878683349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FEOdkKaiMNRxG%2BzNZDFEqKgvSd0zjDPetO6ewq9%2BFQ8%3D&reserved=0> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347 _______________________________________________ ippm mailing list i...@ietf.org<mailto:i...@ietf.org> https://www.ietf.org/mailman/listinfo/ippm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=05%7C01%7Chaoyu.song%40futurewei.com%7C763779969aa248b1755e08daeda6c8fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638083597878839583%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dnxr8kqqvDTsTnYL6LNTz6Q7XROaMkNDN6P24vuCLOw%3D&reserved=0>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
