Hi Dino, the following is the original email:
++++++++++++++++++++++++ Hi co-author of this draft, As I had mentioned at the mic, the mechanism proposed in this draft needs to consider the prefix overlapping issue which has been considered and addressed by LISP. To Ron, The default route on the spoke can not be resorted to address the potential issue caused by the prefix overlapping issue. The reason is that it's the longest-matching route 10/8, rather than the default route is used to route the packet destined for 10.10.10.10, in the case where a route for 10/8 has been returned to that spoke due to a request from that spoke for the longest-matching route for a given host address 10.0.0.1. As a result, the traffic for 10.10.10.10 would be forwarded to the nexthop for 10/8 which in turn forward that traffic according to a more spefic route for 10.10.10.10. This is suboptimal. Assume the traffic volume for the destination of 10.10.10.10 is high, how to trigger a requtst for a "real" direct route to 10.10.10.10 if there exists a host route for 10.10.10.10/32 at the hub? One possible way is to always request a more specific route until a host route for the destination of the received packet is found at the spoke. Since this issue has been disccussed at LISP WG many years before. I copy this email to LISP as well. Best regards, Xiaohu ++++++++++++++++++++++++++ ________________________________________ 发件人: [email protected] [[email protected]] 代表 Dino Farinacci [[email protected]] 发送时间: 2013年11月9日 15:01 收件人: Robert Raszuk 抄送: Xuxiaohu; [email protected]; [email protected] 主题: Re: [lisp] 答复: Prefix overlapping issue for draft-bonica-l3vpn-orf-covering-prefixes-00 Can you guys give us context. Robert, you didn't copy [email protected] with the original message/claim from Xiaohu. Dino > On Nov 8, 2013, at 10:51 PM, Robert Raszuk <[email protected]> wrote: > > Hi Xiaohu, > > Prefix overlap within VPN is either on purpose injected into given VPN > or is due to VPN misconfiguration. > > Detection or mitigation of this as far as I can see is outside of > scope of this draft. > > LISP operates in global space, this draft operates in VPN space. Those > spaces while seemingly similar in reality have very different routing > characteristics. > > Best, > R. > >> On Sat, Nov 9, 2013 at 7:36 AM, Xuxiaohu <[email protected]> wrote: >> Hi Robert, >> >> As long as there is a possibility of prefix overlapping within a given VPN >> instance, the mechanism defined in this draft would encounter the same >> problem that LISP had ever encountered. >> >> Best regards, >> Xiaohu >> ________________________________________ >> 发件人: [email protected] [[email protected]] 代表 Robert Raszuk >> [[email protected]] >> 发送时间: 2013年11月9日 14:09 >> 收件人: Xuxiaohu >> 抄送: [email protected]; [email protected] >> 主题: Re: [lisp] Prefix overlapping issue for >> draft-bonica-l3vpn-orf-covering-prefixes-00 >> >> Hi Xiaohu, >> >> While you are asking Ron directly you are cc-ing the lists so let me >> clarify your observation .. >> >> In each L3VPN context each PE advertise set of routes towards other >> PEs. Those routes are most often advertised via RR. >> >> I have never seen the case where RR or set of RRs would in any sort >> summarize routes more then PEs advertise. >> >> So if site has a host with the address of 10.10.10.10 which our high >> bandwith flow is destined to PE (or PEs) connected to such site will >> advertise the most specific subnet possible to reach 10.10.10.10. >> >> And that is all what is needed here. >> >> Based on the request from the v-spoke RR will return the longest match >> which will have next hop pointing to one of PEs connected the end >> site. I see really no problem there. >> >> If customer/provider on purpose enforced that to get to 10.10.10.10 >> you need to traverse some other site (for example DMZ/firewall/service >> XYZ) that is on purpose and we MUST honor it. This draft RFC7024 can >> not modify such routing enforced by customer. >> >> Best, >> R. >> >> PS. I see no relation to LISP here ;) >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
