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.

Regards,
Greg

On Wed, Feb 9, 2022 at 7:41 PM Huaimo Chen <huaimo.chen@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 <gregimirsky@gmail.com>
> *Sent:* Tuesday, February 8, 2022 11:25 PM
> *To:* Huaimo Chen <huaimo.chen@futurewei.com>
> *Cc:* Bruno Decraene <bruno.decraene@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.chen@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-bounces@ietf.org> on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Sent:* Tuesday, February 8, 2022 4:38 PM
> *To:* Bruno Decraene <bruno.decraene@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.decraene@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>
>
>