Hi Robin, Your understanding of interworking on Independent and Ordered control is incorrect. Please read RFC5036 sections 2.6.1.1. Independent Label Distribution Control and 2.6.1.2. Ordered Label Distribution Control.
In the case described S13 (Independent) will distribute mapping for S14 without need to receive it from downstream node (that’s why it is called Independent). S12(Ordered) will then send it to its upstream The general issue with Independent is described in section 2.6.1.1. Independent Label Distribution Control and is not SR related. “A consequence of using independent mode is that an upstream label can be advertised before a downstream label is received.” Hope this clarifies, Cheers, Jeff From: Lizhenbin <[email protected]<mailto:[email protected]>> Date: Thursday, January 15, 2015 at 5:12 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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. 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)? 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. So the only choice is to upgrade all nodes to support SR all at once. is that right that the incremental deployment of SR in such scenario is difficult to adopt? Regards, Zhenbin(Robin)
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
