Hi slitkows : Thanks for your comments, Please see inline.
Thanks Zhibo Hu From: spring [mailto:spring-boun...@ietf.org] On Behalf Of slitkows.i...@gmail.com Sent: Wednesday, January 26, 2022 1:13 AM To: bruno.decra...@orange.com; 'SPRING WG' <spring@ietf.org> Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding Hi I'm NOT supporting this draft for the following reasons: 1) The WG already have a WG document which is dealing with this problem, I don't think that WG should come with multiple documents/solutions for the same solution space as it may just confuse the industry and create deployment issues as different vendors may pick different solutions. -----> [I-D.ietf-spring-segment-protection-sr-te-paths] defines local behaviors to implement SR-TE node protection. draft-hu-spring-segment-routing-proxy-forwarding enhances SR-TE node protection. It optimized the number of entries in the Context Table. This solution solves the connectivity problem after IGP convergence, and protects binding segments. 2) Adding protocols extensions adds complexity in the solution without adding a strong value. The document claims that "[I-D.ietf-spring-segment-protection-sr-te-paths] ... may not work for some cases such as some of nodes in the network not supporting this solution.". While this is true, the proposed solution in draft-hu-spring-segment-routing-proxy-forwarding has exactly the same caveat and requires all nodes in the network to support the solution. Considering the following straight line network: A -B -C -D - E - F - G -H and an SR policy from A to H using SID_G, routers A to F have to support the extension to make the solution working, if one of the router doesn't support the extension, traffic will be dropped. Then, there is no value compared to the timer-based solution of [I-D.ietf-spring-segment-protection-sr-te-paths] Authors of draft-hu-spring-segment-routing-proxy-forwarding argued that G may have multiple upstream neighbors let's say F and F' and the solution allows for F' to support the extension while F may not support, so the solution will send the traffic to F'. Well yes, but this still requires all routers upstream to F' to support this extension and maybe F is on the path to F'. So, I don't think the argument is valid as it may possibly work tactically depending on the network topology when we look at a small portion of the network, but when we look at the whole network, operator will have to upgrade all their nodes to support the extension to ensure the benefit is there. In addition, in term of traffic, forwarding traffic to a neighbor of the failed node which wasn't initially on the path, could lead to traffic congestion or high traffic peaks on links that were not sized to carry this traffic. We could easily expect some traffic tromboning, where traffic goes to this non-natural neighbor of the failed node and then goes back over some part of the same path before reaching the destination. So these protocol extensions are bringing complexity for no value here. ---------> Protocols extensions can accurately direct traffic to a node that can perform proxy forwarding and solve the problem that traffic cannot be forwarded to a proxy forwarding node after IGP convergence. This protocol extension is necessary. This solution does not require that all network nodes support this extension, take the example you have mentioned : but it still requires that all routers upstream to F' support this extension ---> This description is inaccurate, assuming that the previous segment is node B, when node G fails. When the node B converges, the node B finds the PF node F' adjacent to G, and can push the node Sid of the node F',Even if C and D do not support this protocol extension, this is not affected. In addition, the Hold timers solution mentioned in [I-D.ietf-spring-segment-protection-sr-te-paths] does not extend protocols, but is also complex. In addition, slow deletion is required for node faults. In addition, loop prevention is implemented to prevent loops.Moreover, it cannot accurately direct traffic to a node that can perform proxy forwarding. 3) Regarding BSID, I'm not fan of advertising BSIDs in IGP as there may be hundreds or thousands of BSID on a node which again will create a lot of burden in IGP. The proposed way will have to be discussed in LSR, not in SPRING (see next comment). Note that [I-D.ietf-spring-segment-protection-sr-te-paths] could also work with BSIDs as long as BSID information of failed node is available in the control-plane of PLRs by whatever mechanism. I think this BSID handling is orthogonal to the proxy-forwarding controlplane behavior. The forwarding operations for BSID will have to be discussed more in details, we could not expect all HW to be able to do 3 or 4 lookups without any perf degradation. -------> Binding segments need to be exchanged only between neighbors and do not need to be flooded to the entire IGP domain. Therefore, binding segments do not exert pressure on IGP performance.The control-plane processing and forwarding-plane processing of the BSID are not strongly coupled.SR-TE protection takes effect only from the time during a fault occurs to the TE path converges. Therefore, SR-TE protection does not take effect during normal forwarding,Compared with impaired connectivity, performance degradation is acceptable. 4) The document is currently a bit borderline between SPRING and LSR as it talks in good details about IGP protocol extensions. If it's a SPRING doc, it should detail reqs for protocols but nothing beyond. ------->As you said, this document defines the detail requests for IGP protocols Brgds, Stephane From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On Behalf Of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> Sent: jeudi 13 janvier 2022 11:19 To: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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/ 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
