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

[Haoyu Song]

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  On Behalf Of li_zhenqi...@hotmail.com
Sent: Tuesday, January 3, 2023 8:25 AM
To: Tianran Zhou ; Rakesh Gandhi 

Cc: spring@ietf.org; ippm 
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 mailto:zhoutian...@huawei.com>>
Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>; IETF 
IPPM WG mailto:i...@ietf.org>>; SPRING WG 
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 
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 mailto:i...@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 expo

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

[li_zhenqi...@hotmail.com]

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
 
发件人： Tianran Zhou
发送时间： 2022-12-24 11:18
收件人： Rakesh Gandhi
抄送： Gyan Mishra; IETF IPPM WG; SPRING WG
主题： 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 
Cc: Gyan Mishra ; IETF IPPM WG ; SPRING 
WG 
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 
 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] 代表 Gyan Mishra
发送时间: 2022年12月14日 11:25
收件人: IETF IPPM WG ; SPRING WG 
主题: [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
-- 
Gyan Mishra
Network Solutions Architect 
Email gyan.s.mis...@verizon.com
M 301 502-1347
 
___
ippm mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Tianran Zhou]

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 
Cc: Gyan Mishra ; IETF IPPM WG ; SPRING 
WG 
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 
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] 代表 Gyan 
Mishra
发送时间: 2022年12月14日 11:25
收件人: IETF IPPM WG mailto:i...@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]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

___
ippm mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Rakesh Gandhi]

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  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] *代表 *Gyan Mishra
> *发送时间:* 2022年12月14日 11:25
> *收件人:* IETF IPPM WG ; SPRING WG 
> *主题:* [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
>
> --
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mis...@verizon.com *
>
> *M 301 502-1347*
>
>
> ___
> ippm mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Gyan Mishra]

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 庞冉(联通集团中国联通研究院-本部) 
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 
> *发送时间：* 2022-12-14 11:25
> *收件人：* IETF IPPM WG ; SPRING WG 
> *主题：* [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
> --
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347 *
>
> 如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 
> hqs-s...@chinaunicom.cn，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。
> If you have received this email in error please notify us immediately by
> e-mail. Please reply to hqs-s...@chinaunicom.cn ,you can unsubscribe from
> this mail. We will immediately remove your information from send catalogue
> of our.
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[??????????????????????-????]

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
发送时间： 2022-12-14 11:25
收件人： IETF IPPM WG; SPRING WG
主题： [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]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347


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

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

[Tianran Zhou]

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] 代表 Gyan Mishra
发送时间: 2022年12月14日 11:25
收件人: IETF IPPM WG ; SPRING WG 
主题: [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]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

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