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

Gyan Mishra <hayabusagsm@gmail.com> Wed, 21 December 2022 05:47 UTC

MIME-Version: 1.0
References: <CABNhwV38P-WV1jGJFgAGuCPws=kBLm9Ryhr0RdidebAAwVO_NQ@mail.gmail.com> <63a15615.170a0220.83d57.dc80SMTPIN_ADDED_BROKEN@mx.google.com>
In-Reply-To: <63a15615.170a0220.83d57.dc80SMTPIN_ADDED_BROKEN@mx.google.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 21 Dec 2022 00:47:05 -0500
Message-ID: <CABNhwV2uK1V_PGuwDh3_A00qEYQy1qJQYgzFbY58P+sMUGWTAw@mail.gmail.com>
To: "庞冉(联通集团中国联通研究院-本部)" <pangran@chinaunicom.cn>
Cc: IETF IPPM WG <ippm@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bfb90405f0501594"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Qosu5vBEGDc1-gNPwVgtCQERS4o>
Subject: Re: [ippm] Progressing the PBT-M “Zero Overhead property” draft
Precedence: list

Hi Pang

Thank you for bringing up the extension headers issues.   That is a
complicated issue with HBH processing and being able to process in the fast
path.

On 6MAN Bob Hinden has the HBH processing draft to help with the issue.

https://datatracker.ietf.org/doc/draft-ietf-6man-hbh-processing/04/

Shuping and myself have a v6OPS draft addressing the issue.

https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-hbh

SR-MPLS may run into similar issues with MSD with MNA extensibility.

So this PBT-M draft is really the only viable path forward today for on
path telemetry for SR.

Thanks

Gyan

On Tue, Dec 20, 2022 at 1:28 AM 庞冉(联通集团中国联通研究院-本部) <pangran@chinaunicom.cn>
wrote:

> 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 <hayabusagsm@gmail.com>
> *发送时间：* 2022-12-14 11:25
> *收件人：* IETF IPPM WG <ippm@ietf.org>; SPRING WG <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://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mishra@verizon.com <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.
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*

[ippm] Progressing the PBT-M “Zero Overhead prope… Gyan Mishra
Re: [ippm] Progressing the PBT-M “Zero Overhead p… Tianran Zhou
Re: [ippm] Progressing the PBT-M “Zero Overhead p… Huaimo Chen
[ippm] 答复: Progressing the PBT-M “Zero Overhead p… Aijun Wang
Re: [ippm] Progressing the PBT-M “Zero Overhead p… 庞冉(联通集团中国联通研究院-本部)
Re: [ippm] Progressing the PBT-M “Zero Overhead p… Gyan Mishra
Re: [ippm] Progressing the PBT-M “Zero Overhead p… Rakesh Gandhi
Re: [ippm] Progressing the PBT-M “Zero Overhead p… Tianran Zhou
Re: [ippm] [spring] Progressing the PBT-M “Zero O… li_zhenqiang@hotmail.com
Re: [ippm] [spring] Progressing the PBT-M “Zero O… Haoyu Song
Re: [ippm] [spring] Progressing the PBT-M “Zero O… Xiejingrong (Jingrong)
Re: [ippm] [spring] Progressing the PBT-M “Zero O… Gyan Mishra