Hi Shraddha, Thank you for your comments.
I remember that I talked to you face to face in IETF meeting and suggested merging your draft and our draft a long time ago before your draft is adopted. You said it would be ok to have the two drafts in WG. In addition, I sent you an email to ask for merging the two drafts, but did not receive any reply from you. I also remember that Zhibo supported the adoption of your draft. These two drafts have some overlaps and differences. Our draft refers to yours for the overlaps, but focuses on the different method for protection and the area your draft does not cover. For example, your draft talks about using anycast SID to protect node failure. I remember that this was discussed in IETF meeting and some issues were raised by others. We do not use anycast SID for protection. Regarding to "May cause congestion somewhere else in the network", this seems true for the two drafts when a node failed. Best Regards, Huaimo ________________________________ From: spring <spring-boun...@ietf.org> on behalf of Shraddha Hegde <shraddha=40juniper....@dmarc.ietf.org> Sent: Thursday, January 27, 2022 2:15 AM To: bruno.decra...@orange.com <bruno.decra...@orange.com>; SPRING WG <spring@ietf.org> Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding WG, I don’t support the adoption of this document as a WG document. I am in agreement with stephane’s comments on the list. 1. May cause congestion somewhere else in the network There is already WG adopted document that is addressing the problem space draft-ietf-spring-segment-protection-sr-te-paths. This draft does not provide significant advantages over the proposed solutions in draft-ietf-spring-segment-protection-sr-te-paths. draft-hu-spring-segment-routing-proxy-forwarding claims to provide better solution when all nodes have not been upgraded. draft-hu-spring-segment-routing-proxy-forwarding introduces protocol extensions and the nodes that aren’t upgraded to understand the extensions will drop the traffic so there isn’t any significant improvement in the approach. In fact, the approach described in draft-hu-spring-segment-routing-proxy-forwarding may cause other issues such as bandwidth double booking since it proposes that any neighbor that claims proxy forwarding will be used to forward the protected traffic. For ex: [cid:image001.png@01D81379.DDE14C10] In above diagram SR-TE path is RT1->RT3->RT7->RT5 Only RT4 supports proxy-forwarding On failure of RT3, RT1 would send traffic to RT4 via RT1->RT6->RT7-RT4 RT4 will then send to RT7 as per the SR-TE path RT7 will then send to RT5 via RT7->RT4->RT5 In this example, same traffic is traversing the RT7->RT4 link 3 times. Operationally this solution is very complex to manage. A network that starts with no segment protection, It may be ok to drop the traffic if some nodes have not been upgraded but causing congestion somewhere else would be difficult to debug. 1. BSID solution draft-ietf-spring-segment-protection-sr-te-paths does not explicitly discuss the solution for BSIDs. Most of the BSID deployments use anycast based solution where same BSID is assigned on anycast nodes and BSID is always preceded by the anycast SID. Section 2.2 in draft-ietf-spring-segment-protection-sr-te-paths discusses this approach. draft-hu-spring-segment-routing-proxy-forwarding provides a protection solution for BSIDs when anycast is not in use. If WG is inclined to solve the BSID protection problem when anycast solution is not in use, I would prefer the Approach to be more aligned with draft-ietf-spring-segment-protection-sr-te-paths. I do not support Introducing completely different solution based on proxy forwarding which has other implications described in point 1. Rgds Shraddha Juniper Business Use Only From: spring spring-boun...@ietf.org<mailto:spring-boun...@ietf.org> On Behalf Of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> Sent: Thursday, January 13, 2022 3:49 PM To: SPRING WG <spring@ietf.org> Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding [External Email. Be cautious of content] 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%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hu-spring-segment-routing-proxy-forwarding%2F__%3B!!NEt6yMaO-gk!TWaV4x51MCL2h93fiW-3XI8ElTsP963AWA5gjKCMU6g9E1WN0cRkqV6D5Qi50WbR%24&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf11b3573b9f441267f6008d9e164cfef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637788645400164200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=S2%2BmuO29w3Yy%2F3pqvU1A2xByY7xrciCzp%2FUqZfPPUN4%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