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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to