Hi Gyan,

Thank you firstly for introducing this document to spring and to me (not 
subscribed IPPM yet ^-^).
After read this draft and the discussions under this thread, I have recalled my 
understanding on passport, postcard (PBT-Mark, DEX).
I think PBT-M is a useful approach for postcard telemetry in general, and 
Segment Routing is a solid use case for PBT-M to be adoption.  I like it and 
even prefer it personally.

I feel that, 9326 is a big compromise and entanglement between passport and 
postcard. Please correct me if I understand it wrong.

l  RFC9326 want to be “postcard” mode, as it states: This Option-Type is used 
as a trigger for IOAM data to be directly exported or locally aggregated 
without being pushed into in-flight data packets.

l  RFC9326 reuses RFC9197 as a base, and RFC9197 starts from an “postcard” 
mode, as it states: IOAM records OAM information within the packet while the 
packet traverses a particular network domain.

As I said above, I like and even prefer the idea of PBT-M, so I tend to agree 
with your points below, and I am willing to see the progress of this document.
However, I don’t have that strong POV. I can live with 9326 and PBT-M of this 
document to be parallel, and I would also like to hear the view points from the 
community.

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


Best Regards,
Jingrong

本邮件及其附件可能含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
above. Any use of the information contained herein in any way (including, but 
not limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Gyan Mishra
Sent: Wednesday, December 14, 2022 11:25 AM
To: IETF IPPM WG <i...@ietf.org>; SPRING WG <spring@ietf.org>
Subject: [spring] 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://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to