Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu

On Thu, Jan 27, 2022 at 1:42 PM Haoyu Song <haoyu.song@futurewei.com> wrote:

> Hi Gyan,
>
>
>
> Thank you for your comments! Please see inline for response marked with
> [HS]
>
>
>
> Best,
>
> Haoyu
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Wednesday, January 26, 2022 9:03 PM
> *To:* Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>
> *Cc:* Greg Mirsky <gregimirsky@gmail.com>; Haoyu Song <
> haoyu.song@futurewei.com>; IETF IPPM WG <ippm@ietf.org>; spring@ietf.org
> *Subject:* Re: [ippm] [spring] Active OAM in SRv6
>
>
>
> Hi Haoyu
>
>
>
> I think it would be good to identify the problem statement and gap with
> existing IPPM WG STAMP, TWAMP PM technologies and why they cannot be
> utilized or fall short in what you are trying to achieve with Active OAM in
> SRv6.
>
>
>
> [HS] My understanding is that STAMP/TWAMP are for end-to-end measurements,
> here we want to collect data from every node and every link on any path,
> without needing to set up any sessions. So the scope and coverage are
> different.
>
>  Gyan> Understood.  STAMP/TWAMP can be used as well to collect from every
> node as well.
>
> In-situ IOAM data packets is already possible with SRv6 as mentioned as
> this draft mentions below as normative reference.
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-16
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-data-16&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136005568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=b6abSWTm77Z4Td%2B0X5hjmZBrFHTe%2FpPdZuWyXNEY3vU%3D&reserved=0>
>
>
>
> [HS] There’s no accepted solution on how to support IOAM in SRv6 yet. Our
> proposal aims to provide such a solution, and (1) the solution avoids the
> issues on encapsulating the IOAM trace in EHs and (2) it’s extensible to
> include OAM methods beyond IOAM.
>
>  Gyan> IPPM WG can speak to this document which has been adopted and been
> developed since 2016 and provides in-situ OAM as you desire and supports
> Segment Routing SRv6 as well as other encapsulations.
>
> This draft as well mentioned as normative reference draft below provides
> OAM ping and traceroute with SRH O flag to SRv6 PGM endpoints and SID list
> tracing capabilities very handy for troubleshooting.
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-1
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-6man-spring-srv6-oam-12&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136005568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EnHxos0Nc%2BF3d%2FehCZuIoSswxZ7udPLASp22oW5UES4%3D&reserved=0>
> 3
>
>
>
> [HS] This is for in-band OAM for SRv6 user traffic and it only works for
> triggering postcard exports (i.e., don’t allow the packet to carry data).
> Our proposal support all the IOAM options and more important, it’s an
> active method which means one can generate and inject probing packets to
> cover arbitrary paths by crafting an SRH.
>
>  Gyan> Understood
>
> This draft as well also mentioned as normative reference draft below
> provides in-situ IOAM for OAM and PM information can be piggybacked in data
> packets in SRH TLV SRv6 PGM SIF function SRv6.TLV recording the operational
> and telemetry info in the data packets.
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ali-spring-ioam-srv6-05
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ali-spring-ioam-srv6-05&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136005568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9zM0yFTsl2jKvDDd8uDv0rtGcOsoaKY%2FEaqUXZmsJ5U%3D&reserved=0>
>
>
>
> [HS] This draft proposes to encapsulate IOAM in SRH TLV. Due to the
> overhead concern (IOAM trace could be large) and other issues related to
> EH, I don’t support such a solution.
>
>  Gyan> Understood.  Work is being done in 6MAN WG to address EH headers
> issues below as well as other drafts to make EH viable and reduce overhead.
>

https://datatracker.ietf.org/doc/html/draft-herbert-6man-eh-limits-00.txt

[HS] The three drafts you mentioned are all be reference in our draft and
> discussed. We think our use cases are different and our approach is more
> general and extensible to our use cases.
>
> Gyan> Understood.  I think if you can add some additional verbiage as to
> problem statement and why existing solutions drafts mentioned are not
> sufficient for your requirements.  Maybe listing out your requirements
> would help couple to your proposed solution.
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Wed, Jan 26, 2022 at 10:19 PM Tianran Zhou <zhoutianran=
> 40huawei.com@dmarc.ietf.org> wrote:
>
> Hi Haoyu,
>
>
>
> The application is really interesting and useful.
>
> I am not sure if it is necessary to create a new OAM protocol at transport
> layer.
>
> IMHO, a per hop/per segment extension based on STAMP could be more
> practical.
>
> https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-wang-ippm-stamp-hbh-extensions-03.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136005568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zqVhnbQoOc33My8fwqES5arm9vT0NCeUs3kIIkGPlug%3D&reserved=0>
>
>
>
> Best,
>
> Tianran
>
>
>
> *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Greg Mirsky
> *Sent:* Thursday, January 27, 2022 7:01 AM
> *To:* Haoyu Song <haoyu.song@futurewei.com>
> *Cc:* spring@ietf.org; IETF IPPM WG <ippm@ietf.org>
> *Subject:* Re: [ippm] [spring] Active OAM in SRv6
>
>
>
> Hi Haoyu,
>
> thank you for bringing the topic of Active OAM to the discussion. As the
> concept of Active IOAM is introduced in the IPPM WG draft
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5rsC694oCufl11dAM4pfiB%2FIKazRSNV3KWAmY%2B7hReA%3D&reserved=0> it
> seems to me like adding the IPPM WG community to the discussion is the
> right thing to do.
>
> Please find my notes in-lined below under the GIM>> tag.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurewei.com>
> wrote:
>
> Hi SPRING WG,
>
>
>
> Real time monitor on every node and every link on a network is necessary
> to detect  gray failures, which are the key culprit for poor QoS but hard
> to catch. SR provides an ideal mechanism, when working with some efficient
> planning algorithm, to achieve that with low cost.   Our proposal SRv6
> In-situ Active Measurement (SIAM) suggests a simple  active measurement
> approach which can support different
>
> GIM>> I wonder what gaps you find in the existing active measurement
> protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an
> acronym). It appears to me that, for example, STAMP and its extensions,
> including the SRPM draft
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nbxsguDj1bZHDKu2RkvdBkOUxvrXeY%2F5Vlc5jBj2qgE%3D&reserved=0>,
> comprehensively address the PM OAM requirements for SRv6.
>
> options of IOAM and other OAM methods in SRv6, without needing to worry
> about the extension header issue.
>
> GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:
>
>    In terms of the classification given
>
>    in [RFC7799] IOAM could be portrayed as Hybrid Type 1.
>
> Does your proposal change that?
>
>
>
> Your comments, questions, and suggestions are very welcome. I’d like to
> know your opinion if you think this work is in scope and should be adopted
> by the working group.  If you are interested in contributing to this work,
> please also let me know.
> https://datatracker.ietf.org/doc/draft-song-spring-siam/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aV3fE%2BZWpaILCWRLJQEo98%2FZ65gN5U%2FIR%2BJdyFHQjyU%3D&reserved=0>
>
>
>
> Thank you very much!
>
>
>
> Best regards,
>
> Haoyu
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6l%2F90vtnx7lbNsKu5RwYBBqjS5M4D%2BD6KhaiHSZpjVs%3D&reserved=0>
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OntVxXeEzhGZ8G%2B00zHbhdCc9b1%2ByhJp9inqWabEVo0%3D&reserved=0>
>
> --
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UZoeWsVHOHCoe8ZCPdcr7yf930qNAFZMli9E3H02WY0%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
-- 

<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*