Dave,
So in order to preserve the behavior you are describing,
the packet needs to be routed over the RLOC space as
early as possible. This corresponds to placing the ITRs
deeper in the site (closer to the source hosts). Since
the ITR will encapsulate the packet (and the outer header
destination address will be a locator), it will find the
best exit just as it does today.
What would be the benefit and driver for such large corporate
sites to install ITRs ?
Finer-grained control over exit policy without having to
propagate global state inside your enterprise.
But what you and Tony replied are not the mirror replacement of
today's optimal routing to dst prefix ... this is optimal closest
exit strategy or in other words ability to find closest ITR. I am
not aware about an ITR to ITR relays for optimal routing towards
destination in any of the current proposals :).
Robert, I think you didn't get Dave's point. Let me restate a bit:
o If you put the ITRs at the edges of a source site, then you route on
the EID
from the source host to the edge LISP router. In this case you get
to exit
based on the default route, which is through the closest LISP router.
o When you want to get shortest path to the destination EID based on
the locators
the destination site has provide to the source site, you put the
ITRs, say in
the middle of the source site. When you do that, the packet is
routed based
on EID to the ITRs. But from that point on you route based on the
locator.
So the exit router the packet travels through is based on the
shortest path
to the destination locator.
o If you put the ITRs directly connected to the sources, one or more
on each
source subnet, you get destination based shortest paths just like
you do today.
But getting what you do today is at the cost of carrying full routes
in the source site. So if you place your ITRs at the core of the
source site, you can get good paths to each external destination
without carrying full routes *throughout* your source site.
So it will actually be less cost to do what you are doing today. You
don't need full routes everywhere, and you probably won't need iBGP
everywhere as well.
I wonder why so many networks today still run full BGP inside rather
then just injecting whole bunch of even anycast defaults into their
IGP to ASBRs. It would be nice to have such public data :).
They want shortest paths to reduce latency and packet delay.
Especially the big content providers where competition is fierce for
low latency and giving the user the best user experience.
Perhaps engineers of such networks should speak up on their reasons
as I can not disclose neither the names nor their internal network
architecture fundamentals ...
Yes, many would welcome that.
Dino
--
to unsubscribe send a message to [EMAIL PROTECTED] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
