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
