Hi Huaimo, thank you for the expedient response. Please find my follow-up notes in-lined below under the GIM>> tag.
Regards, Greg On Tue, Feb 8, 2022 at 6:35 PM Huaimo Chen <huaimo.c...@futurewei.com> wrote: > Hi Greg, > > Thank you very much for your comments. > > My responses/explanations are inline below with [HC]. > > Best Regards, > Huaimo > on behalf of co-authors > > ------------------------------ > *From:* spring <spring-boun...@ietf.org> on behalf of Greg Mirsky < > gregimir...@gmail.com> > *Sent:* Tuesday, February 8, 2022 4:38 PM > *To:* Bruno Decraene <bruno.decra...@orange.com> > *Cc:* SPRING WG <spring@ietf.org> > *Subject:* Re: [spring] WG adoption call - > draft-hu-spring-segment-routing-proxy-forwarding > > Dear Authors, et al., > I've read the draft and would appreciate it if the authors can clarify one > question: > > - What do you consider as the significant advantage of the mechanism > defined in your draft compared with the mechanism defined in > draft-ietf-spring-segment-protection-sr-te-paths? > > As I've compared the two solutions, I couldn't find any significant > advantage of the proxy forwarding to have two standardized mechanisms for > SR path e2e protection. It might be reasonable to have one standard while > other proposals get experimental status? > [HC]: It provides more protection coverage in some cases as compared to > the mechanism defined in draft-ietf-spring-segment-protection-sr-te-paths. > GIM>> I find it hard to quantify your characterization. I imagine that if an operator uses the protection mechanism defined in draft-ietf-spring-segment-protection-sr-te-paths it designs the network with that in mind and thus minimizes if not completely avoids any possible limitation the protection mechanism may have. Perhaps you can help with some more specific scenarios. > This improves the reliability of networks, and QoE. This should be a > significant advantage. There is no solution for BSID protection in the > other existing draft. > GIM>> Though BSID may be used inside the network, I find such use case questionable making no significant impact on the usefulness of the protection mechanism. > The solution for BSID protection in our draft has > been there for a few years. In addition, after a node failed, in > our solution, the nodes of the entire network converge to the latest > state consistently in time. After a node failed, the mechanism defined > in the other existing draft holds off the FIB during the HoldTimer > period configured, when the network changes again, > GIM>> I consider that property of the protection defined in draft-ietf-spring-segment-protection-sr-te-paths as a benefit that allows better control for the proper coordination between protection mechanisms that operate on different network layers. > our solution continues > to converge at any time. > The mechanisms in two drafts are different. It seems ok and reasonable > to have the two drafts to be adopted in the WG. > GIM>> I agree with you, drafts are fundamentally different and, in my opinion, merging them would not change the situation. But I don't see that as the justification for producing two standards. It seems to me, releasing two standard-based specifications might be detrimental and I propose the authors consider taking this draft onto the experimental track. I'd support the adoption of it as the experimental track document. > > > Regards, > Greg > > On Thu, Jan 13, 2022 at 2:19 AM <bruno.decra...@orange.com> wrote: > > Dear WG, > > > > This message starts a 2 week WG adoption call, ending 27/01/2022, for > draft-hu-spring-segment-routing-proxy-forwarding > > > https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/ > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hu-spring-segment-routing-proxy-forwarding%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cac2dd1d7357c4424598c08d9eb4b66bd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799531373515436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TG7KuyAlTpbdIQksgm0QoKY%2FBYcNcmBvBlijQqaCPXE%3D&reserved=0> > > > > After review of the document please indicate support (or not) for WG > adoption of the document to the mailing list. > > > > Please also provide comments/reasons for your support (or lack thereof) as > this is a stronger way to indicate your (non) support as this is not a vote. > > > > > If you are willing to work on or review the document, please state this > explicitly. This gives the chairs an indication of the energy level of > people in the working group willing to work on the document. > > > > Thanks! > > Bruno, Jim, Joel > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > 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%7Chuaimo.chen%40futurewei.com%7Cac2dd1d7357c4424598c08d9eb4b66bd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799531373515436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ktnbwc0TVvPj70GbJNAst9BIAP9W0T1yS6SxQulvH2s%3D&reserved=0> > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
