Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

[Huaimo Chen <[e-mail]>]

Hi Greg,

    Thank you very much for your comments.

    My responses/explanations are inline below with [HC3].

Best Regards,
Huaimo

________________________________
From: Greg Mirsky <[e-mail]>
Sent: Thursday, February 10, 2022 3:40 PM
To: Huaimo Chen <[e-mail]>
Cc: Bruno Decraene <[e-mail]>; SPRING WG <[e-mail]>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

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.
[HC3]: The environments are the same for two different solutions.
That is that the same environment for two different solutions.
A node X on the shortest path from a upstream node to N does not
support any protection/solution. That is that node X does not support
the mechanism in draft-ietf-spring-segment-protection-sr-te-paths or
our solution. Other nodes support the protection/solution. That is that
they support the mechanism in draft-ietf-spring-segment-protection-sr-te-paths or
our solution.

Regards,
Greg

On Wed, Feb 9, 2022 at 7:41 PM Huaimo Chen <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

    Thank you very much for your notes.

    My responses/explanations are inline below with [HC2].

Best Regards,
Huaimo

________________________________
From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 8, 2022 11:25 PM
To: Huaimo Chen <[e-mail]<mailto:[e-mail]>>
Cc: Bruno Decraene <[e-mail]<mailto:[e-mail]>>; SPRING WG <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> on behalf of Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 8, 2022 4:38 PM
To: Bruno Decraene <[e-mail]<mailto:[e-mail]>>
Cc: SPRING WG <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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%7C562185d788f440835c4108d9ecd5a5be%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637801224640802016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=e0ry4z9YrilB2FTe%2BZ3XjUhPWymkSrJQJa2dKgUcAWE%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
[e-mail]<mailto:[e-mail]>
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%7C562185d788f440835c4108d9ecd5a5be%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637801224640802016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=VQnW%2BkJgo%2FgfVg3XJ4gC3JL8R75B5BhaYe15%2FcX1ZKM%3D&reserved=0>