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 庞冉(联通集团中国联通研究院-本部) <pang...@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 <hayabusa...@gmail.com> > *发送时间：* 2022-12-14 11:25 > *收件人：* IETF IPPM WG <i...@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.mis...@verizon.com <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. > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
