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.

> 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.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%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>
>
>