I looked at draft-bashandy-rtgwg-segment-routing-uloop again and it appears to be proposing RFC 5715 Section 6.3 far side tunnelling with the constraint that the path into Q space is congruent with the post convergence path.
What draft-bashandy does not emphasis clearly enough in my opinion is that EVERY ingress that might be carrying traffic over the failure MUST take part in this process. A further thing to note is that it is actually quite difficult to compute the post convergence path because to do so you need to determine the decision that every node along the path will take and you cannot do that with 100% certainty because you cannot be sure which of the available next hops it will consider using and even if that is not an issue you cannot anticipate the ECMP decision that it will take as that may well be different depending on the MPLS label stack (which will be different in the case of draft-bashandy compared to native transit). Now of course this will not affect the loop free convergence process if this is wrong, but that takes me to the point in the next paragraph. Rather than do the complicated congruence calculation, a very good approximation (and compatible approach) would be to tunnel the traffic into Q space WRT the failure using one or two labels as needed (what draft-bashandy does but without the attempt at the strict constraint constraint). Of course if a node chooses to perform the complex calculation to find path congruence it may do so, but this approximate approach will work just as well and interoperably with nodes that chose a simpler approach. If an ingress node choses to use nearside tunnelling as far as I can see this would be a perfectly viable alternative and would be compatible with nodes choosing the approach in draft-bashandy. Now I note that draft-bashandy requires a conservative estimate of the convergence time of the slowest router along the path. That value will change over time (possibly faster possibly slower) as the network evolves, and thought should be given to the protocol work that we started in RTGWG to advertising this parameter some years ago (draft-ietf-rtgwg-routing-timer-param-sync). So I as far as I can see the requirement in the TiLFA draft needs to be that a network MUST deploy a loop-free convergence strategy. That strategy can be any of the RFC 5715 strategies. If the PLR can be sure that the whole network is using one of the tunnel approaches that is fine, but we should note that an individual ingress router may chose either the nearside or the far side approach using any topology that safely delivers the packet into Q space WRT the failure. If the PLR cannot be sure that the whole network supports a tunnel based approach it may independently finesse this by using the incremental link cost approach. - Stewart
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
