Re: [ippm] Progressing the PBT-M “Zero Overhead property” draft

"庞冉(联通集团中国联通研究院-本 部)" <pangran@chinaunicom.cn> Tue, 20 December 2022 06:28 UTC

Return-Path: <pangran@chinaunicom.cn>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B97BC152574; Mon, 19 Dec 2022 22:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.328
X-Spam-Level:
X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNGdM2VCtxzP; Mon, 19 Dec 2022 22:28:13 -0800 (PST)
Received: from senda.mailex.chinaunicom.cn (senda.mailex.chinaunicom.cn [123.138.59.136]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2612C1524BF; Mon, 19 Dec 2022 22:28:09 -0800 (PST)
Received: from M10-XA-MLCEN02.MailSrv.cnc.intra (unknown [10.236.3.198]) by senda.mailex.chinaunicom.cn (SkyGuard) with ESMTPS id 4NbmrQ4TRHz43h5J; Tue, 20 Dec 2022 14:29:26 +0800 (CST)
Received: from smtpbg.qq.com (10.237.2.98) by M10-XA-MLCEN02.MailSrv.cnc.intra (10.236.3.198) with Microsoft SMTP Server id 15.0.1497.38; Tue, 20 Dec 2022 14:28:00 +0800
X-QQ-mid: Ymail-xx24b003-t1671517677tjm
Received: from DESKTOP-TS2O28F (unknown [10.252.27.12]) by smtp.qq.com (ESMTP) with id ; Tue, 20 Dec 2022 14:27:56 +0800 (CST)
X-QQ-SSF: 00900000000000G0Y710000A0000000
X-QQ-GoodBg: 0
From: "庞冉(联通集团中国联通研究院-本 部)" <pangran@chinaunicom.cn>
To: Gyan Mishra <hayabusagsm@gmail.com>, IETF IPPM WG <ippm@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Date: Tue, 20 Dec 2022 14:27:58 +0800
References: <CABNhwV38P-WV1jGJFgAGuCPws=kBLm9Ryhr0RdidebAAwVO_NQ@mail.gmail.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.20.259[cn]
MIME-Version: 1.0
Message-ID: <202212201426577331931@chinaunicom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart374051741870_=----"
X-QQ-SENDSIZE: 520
Feedback-ID: Ymail-xx:chinaunicom.cn:mail-xx:mail-xx24b003-zhyw46w
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/rce5xoDsy-C_SNyQX5kCtDtFW_g>
Subject: Re: [ippm] Progressing the PBT-M “Zero Overhead property” draft
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2022 06:28:18 -0000

Hi Gyan,

I’ve read this draft, and I agree with you this is very useful.
The value I find special on the PBT-M proposed in this document is that it may not need an extension header. And it could be easy to implement.
There are a lot of discussions in 6MAN and MPLS (MNA) about the device behavior wrt extensions. It’s a real problem.
I see both IOAM and IOAM-DEX request extension headers in IPv6 network. At least in most of the existing network, it’s very hard to deploy.
I think PBT-M could be a way to help the deployment of on path telemetry.

Best regards,
Pang Ran.

发件人: Gyan Mishra<mailto:hayabusagsm@gmail.com>
发送时间: 2022-12-14 11:25
收件人: IETF IPPM WG<mailto:ippm@ietf.org>; SPRING WG<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]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

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

M 301 502-1347


如果您错误接收了该邮件,请通过电子邮件立即通知我们。请回复邮件到 hqs-spmc@chinaunicom.cn,即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to hqs-spmc@chinaunicom.cn ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.