Hi Huaimo, thank you for responding to my notes and questions. I wanted to highlight one issue (top-posting):
For the mechanism in draft-ietf-spring-segment-protection-sr-te-paths, if a node X on the shortest path from a upstream node to N does not support the mechanism, node X drops the traffic transported by the path. For the solution in our draft, proxy capable nodes off node X on the shortest path to a neighbor of N are used. >From reading your response, it seems that you compare how different solutions behave not in identical environments. I don't see that as a fair comparison. Regards, Greg On Wed, Feb 9, 2022 at 7:41 PM Huaimo Chen <huaimo.c...@futurewei.com> wrote: > Hi Greg, > > Thank you very much for your notes. > > My responses/explanations are inline below with [HC2]. > > Best Regards, > Huaimo > > ------------------------------ > *From:* Greg Mirsky <gregimir...@gmail.com> > *Sent:* Tuesday, February 8, 2022 11:25 PM > *To:* Huaimo Chen <huaimo.c...@futurewei.com> > *Cc:* Bruno Decraene <bruno.decra...@orange.com>; SPRING WG < > spring@ietf.org> > *Subject:* Re: [spring] WG adoption call - > draft-hu-spring-segment-routing-proxy-forwarding > > 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. > [HC2]: Assume that a SR path has the SID of a node N and node N failed. > For the mechanism in draft-ietf-spring-segment-protection-sr-te-paths, > if a node X on the shortest path from a upstream node to N does not > support the mechanism, node X drops the traffic transported by the path. > For the solution in our draft, proxy capable nodes off node X on the > shortest > path to a neighbor of N are used. The neighbor re-routes the traffic > around > failed node N towards the destination. The traffic is protected. > > 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. > [HC2]: Considering two drafts A and B. Draft A supports protection > of a SR path, which contains two types of components, say C1 and C2. > If the path contains a third type of components, say, C3, then > protection of the path for C3 is not supported. > Draft B supports protection of a SR path, containing C1, C2 and C3. > In this case, draft B seems having a significant advantage over draft A. > > 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%7C4baac6ced8b241b8e8a008d9eb8444e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799775601962149%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=BIJm6UvUkp9QxNFwgzH9yyZE%2F59AXZo2x6aYUEqi7Aw%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%7C4baac6ced8b241b8e8a008d9eb8444e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799775602118366%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0TaWVJRQEEpWAng%2FE62IG2%2Fzv9CbwEWVp4Q0PiD7Nvs%3D&reserved=0> > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
