Hi Haoyu On Thu, Jan 27, 2022 at 1:42 PM Haoyu Song <haoyu.s...@futurewei.com> wrote:
> Hi Gyan, > > > > Thank you for your comments! Please see inline for response marked with > [HS] > > > > Best, > > Haoyu > > > > *From:* Gyan Mishra <hayabusa...@gmail.com> > *Sent:* Wednesday, January 26, 2022 9:03 PM > *To:* Tianran Zhou <zhoutianran=40huawei....@dmarc.ietf.org> > *Cc:* Greg Mirsky <gregimir...@gmail.com>; Haoyu Song < > haoyu.s...@futurewei.com>; IETF IPPM WG <i...@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....@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-boun...@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* Thursday, January 27, 2022 7:01 AM > *To:* Haoyu Song <haoyu.s...@futurewei.com> > *Cc:* spring@ietf.org; IETF IPPM WG <i...@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.s...@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 > i...@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.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > *M 301 502-1347* > > > -- <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
