Hi Acee, I don't think my proposed issues is the same case as you proposed. I think your proposed case is like forwarding agency or IGP short-cut using tunnel as the interface to hide the MPLS from the OSPF. My case is the SR-BE path in which OSPF is like LDP as one MPLS control protocol to loop up the route to determine the outgoting interface and the nexthop for the label mapping advertised by OSPF's self instead of hiding the label in the tunnel.
Regards, Robin ________________________________ 发件人: Acee Lindem (acee) [a...@cisco.com] 发送时间: 2015年1月22日 22:15 收件人: Lizhenbin; Robert Raszuk 抄送: m...@ietf.org; spring@ietf.org 主题: Re: [spring] 答复: New Comments on Segment Routing(4): Challenge of Route Dependency for SR-BE Path Hi Robin, I don’t know about other IGP implementations but the ones I’ve worked on do not resolve routes recursively (unlike LDP or BGP which do). There are cases where OSPF runs over a tunnel but in these cases the OSPF interface is either up or down dependent on the tunnel status. Hence, I think the issue you’ve raised regarding protocol synchronization is a moot point. Thanks, Acee From: Lizhenbin <lizhen...@huawei.com<mailto:lizhen...@huawei.com>> Date: Thursday, January 22, 2015 at 6:08 AM To: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> Cc: "m...@ietf.org<mailto:m...@ietf.org>" <m...@ietf.org<mailto:m...@ietf.org>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>> Subject: [spring] 答复: New Comments on Segment Routing(4): Challenge of Route Dependency for SR-BE Path Hi Robert, Please refer to my inline '[Robin]'. Regards, Robin ________________________________ 发件人: rras...@gmail.com<mailto:rras...@gmail.com> [rras...@gmail.com<mailto:rras...@gmail.com>] 代表 Robert Raszuk [rob...@raszuk.net<mailto:rob...@raszuk.net>] 发送时间: 2015年1月22日 15:46 收件人: Lizhenbin 抄送: spring@ietf.org<mailto:spring@ietf.org>; m...@ietf.org<mailto:m...@ietf.org> 主题: Re: [spring] New Comments on Segment Routing(4): Challenge of Route Dependency for SR-BE Path Hi Robin, I think your question is not applicable to SR architecture. The right SR analogy to LDP would *NOT* be hop by hop LDP like in your example, but targeted (aka directed) LDP session. [Robin] I could not understand your point. No matter T-LDP or local LDP, they should lookup in the RIB/FIB to determine if the label mapping is active. In those how to get to FEC's address is just regular lookup in the RIB/FIB (global or vrf depends on use case) and it does not matter what protocol src installed the route. [Robin] As what you described, could I understand you means for the SR based on a specific IGP(e.g. OSPF), it should look up in the RIB/FIB to determine if the label binding is up? If so, there will be the two route dependency change issues I proposed for the OSPF. Why do you think they are not applicable to SR? Also note that like in most LDP case SR "labels" or "IDs" are global so regardless on which interface packet arrives (within given topology in case of mt) the lookup result will be identical. Rgs, R. On Thu, Jan 22, 2015 at 6:07 AM, Lizhenbin <lizhen...@huawei.com<mailto:lizhen...@huawei.com>> wrote: Hi all authors of segment routing, This is the fourth comments. For LDP, when search route for the destination address which is the FEC of the label mapping, it should search the FIB in which the routes are selected from the static route, OSPF, ISIS, BGP, etc based on the preferences. Now there is one question for SR-BE path, for example, if the SID/Label is advertised through OSPF, what type of routes should the label mapping depend on when setup the SR-BE path? I think there may be two choices: 1. Only depend on the OSPF's own route; 2. Like the LDP, depends on the selected route. I don't think it should be the Option 1. For example, we configure static routes for all nodes along the path to a specific node which can be totally different from the OSPF routes to the node. If the static route has higher priority than the OSPF and the SID/label is advertised by OSPF depends on OSPF routes, there will be the inconsistency between the SR-BE path and the route path. If the option 2 is adopted, it cannot be assumed that the label mapping and the route are in the same LSDB which can be easily synchronized. There are two challenges: 1. The direct effect for the OSPF is that at the beginning it just downloads it routes to the RIB for the route selection. That is, it is the source of the route selection. But now owing to SR-BE path, it has to depend on the result of the route selection. 2. OSPF SR-BE path may depend on the routes from the static route, ISIS, BGP, etc. It is claimed that the SR can remove the IGP-LDP sync. But according to this analysis, are there the possible risk we have to introduce the OSPF-ISIS sync, OSPF-Static Route sync, OSPF-BGP sync? Or do you just think they are rare cases which should not be taken into account? Hope you have had enough analysis on this issue. According to the comments on the dependency, I hope you could specify clearly in the appropriate draft of segment routing as to follows questions for SR-BE path which is helpful for interoperability: -- depend on the longest match, or exact match, or both. -- depned on the SR protocol's own routes or the route selection resulte from multiple sources. Regards, Robin _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
