Hi Greg,
Thank you very much for your notes.
My responses/explanations are inline below with [HC2].
Best Regards,
Huaimo
________________________________
From: Greg Mirsky <[email protected]>
Sent: Tuesday, February 8, 2022 11:25 PM
To: Huaimo Chen <[email protected]>
Cc: Bruno Decraene <[email protected]>; SPRING WG <[email protected]>
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
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> on
behalf of Greg Mirsky <[email protected]<mailto:[email protected]>>
Sent: Tuesday, February 8, 2022 4:38 PM
To: Bruno Decraene <[email protected]<mailto:[email protected]>>
Cc: SPRING WG <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
