Hi Robin, Thanks for your interest on SR/SPRING. Please see inline. [Bruno]
From: spring [mailto:[email protected]] On Behalf Of Lizhenbin Sent: Thursday, January 15, 2015 2:12 PM To: [email protected] Subject: [spring] New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment Hi all authors of segment routing, When we did research on segment routing and found some new issues. Could you help clarify if the analysis is right and how will they be taken into account in the design of SR. This is the first issue. (Non-SR) S11-----------S12----------S13---------S14 | | | | | | | | | | | | S21-----------S22----------S23---------S24 As above topoloby, there are 8 nodes and assume all the metics of the links are 1 and VPNs are deployed on S11/S21/S14/S24. If LDP is used as the tunnel for VPN on S11/S14, since LDP can support the ordered mode. The LSP for the S14 will be setup as the order S14->S13->S12->S11 for distribution of label mapping. And the shortest path for routes to S14 is also S11->S12->S13->S14. So the end-to-end LSP to S14 is setup. If one node (e.g. S13) does not support LDP, according to LDP ordered mode, the end-to-end LSP cannot setup since S12 does not receive the label mapping from the exact nexthop of the route, S13 and it will not distribute the label mapping to S11. And the result is that the VPN on S11 cannot take the LSP since the LSP cannot setup on S11. [Bruno] My understanding of your case is the following, please correct me if I'm wrong: There is no SPRING/SR. All nodes support LDP. S11, S12, S14 use ordered mode. S13 use independent mode. First, such cases happen today in multiple vendor networks since different implementation used different options. Then, I believe that your understanding of LDP independant mode is incorrect. In independent mode, S13 always advertises the S14 FEC to its neighbor, even if it don't gets a label mapping from its downstream S14. This FEC is then propagated to S11 in ordered mode. As a result, S11 gets a label for S14 and will use S14 for the VPN. However in the forwarding plane the traffic will be dropped on S13. If SR-BE path is used as the tunnel for VPN on S11/S14 and assume the S13 cannot support the SR, according to my understanding, there will be an SR-BE path for the destination S14 which is interrupted at S12. This is similar as the independent mode of LDP. If this VPN takes this SR-BE Path at S11, the VPN traffic will be dropped at S12. If the analysis is right. I have two questions: 1. How will SR avoid such risk? Some enhancement on SR or just leave it to the local implmentation (For example, LSP ping is firstly used to check the connectivity)? [Bruno] A priori, I could see 3 answers -a- I guess one could use IGP multi-topology to handle a different topology between the IP and the MPLS one. This is similar to IPv6 introduction in a IPv4 network. -b- Another option is to enable interworking between LDP and SR/SPRING to handle such incremental deployment. Please see the following draft for an introduction on this interworking: https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-ldp-interop-02 Comments are welcomed as I agree with you that's an important topic for brownfield incremental deployment -c- Another option is to incrementally deploy SR in addition to LDP and to prefer LDP for end to end LSP (using administrative distance). Then it's up to each SR application to see how much they can take benefit of partial SR deployment. e.g. FRR (TI-LFA, RLFA or DLFA) may/should be able to benefit from partial deployment. FYI, as of today/myself I say that "b" is required and "c" is nice to have. 2. Assume LDP is already deployed on all nodes in the network to bear VPN traffic. When SR-BE path is adopted in the network to replace LDP LSP, since there is the possible risk proposed by interrupted SR-BE path and I do not think it is impossible to carefully determine the upgraded nodes. [Bruno] I'm not sure to correctly understand your last sentence. Within an AS (well area/level) It is possible to identify nodes which are SR/SPRING compliant (or non compliant) as they advertise this in the link state IGP. So the only choice is to upgrade all nodes to support SR all at once. [Bruno] No. is that right that the incremental deployment of SR in such scenario is difficult to adopt? Regards, Zhenbin(Robin) _________________________________________________________________________________________________________________________ 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] https://www.ietf.org/mailman/listinfo/spring
