So now we have two ETRs and two MSes which need to be
coordinated. The two MSes both announce the one EID prefix
on the ALT network. Yet they are supposed to still be
coordinated during outages.
The 2 Map-Servers will converge into a topology that will aggregate
the
site's Registered EID-prefix so we can have a smaller ALT core.
Smaller
meaning, a small number of EID-prefixes needing to be stored in the
core of
the ALT network.
Dino,
I'd like to add to what Dave said.
I think the Map-Server proposal is great and I can see synergies with
my hIPv4 framework proposal.
Cool, thanks.
Because the Map-Server is not put in the forwarding path, it is
similar to a DNS solution, why can not the Map-Server contain all
prefixes and their RLOC identifiers, i.e. the Map-Server would become
the new DFZ and Map-Severs (MS) are tied together with BGP?
Right, that is the concept. When the Map-Servers use LISP-ALT, they
are tied together with BGP. If the database mapping service is a DHT,
or CONS, or NERD, then those mechanisms tie together the map-servers.
The MS is decoupled from the forwarding fabric, it is more or less a
database and "signaling" instance, right? A powerful server with a lot
of memory should be able to deal with the RIB churn.
Right.
I have also a feeling that every service provider would prefer to have
their own MS and therefore the ITR/ETR of that service provider are
That will depend on the business model. And if the site wants to
decouple it's physical link dependency on an ISP with the one it uses
for database mapping services.
adjacent with the MS of the ISP. The ISP would still have in their RIB
all prefixes attached to the SP's network and the RIB also need to
carry all global RLOC identifiers. But overall the growth of the
Which are out of PA blocks so can be aggregated to keep routing table
size down.
entries in the routers' RIB and FIB would be reduced for each AS.
When a client resolves a destination and found out the destination IP
address it is forwarded to the network, if the destination is not
found in the RIB/FIB it is forwarded to the closest ITR upon the
default route. The ITR make a lookup from the MS and once the RLOC is
found the packets are encapsulated and forwarded to the ETR. The ETR
updates its cache on the information in the packet. Most likely the
ETR has to inform the adjacent MS that it is dealing with this new EID
entry.
Yes, you just described LISP egress forwarding from a site in one
paragraph.
When a EID changes location the ETR is updating the MS and BGP is
announcing to all MS the change. The MS should then flush the adjacent
Well, we did think people would get this reaction to the registration
services. But that is not what was intended. The registration service
is used so an ETRs at a site can tell the database mapping system that
they are available to answer Map-Requests. They are not really
registering mappings. They are registering the EID-prefixes they are
authoriatively going to answer for. The list of RLOCs in a Map-
Register message don't have to be all the RLOCs used to encapsulate
data to the site. It's just a list of RLOCs willing to answer Map-
Requests for the site.
ITR/ETRs, if they have "subscribed" for that specific EID during the
last , e.g. 24 hours. The update churn is not "flat" anymore, all MS
will be influenced but not all ITR/ETR, except if they have been using
the affected EID.
Or have I misunderstood something?
No, it's not that dynamic. We are not claiming you Register and
timeout for achieving EID mobility.
Then we have the exhaustion of the IPv4 address space, when that
occurs we have to upgrade the hosts anyway and my draft is trying to
address that issue. I'm little bit early with my proposal but now I
can see both fitting together on a high level. Then a commercial:
draft 01 is on its way through the process - the LSR can be removed in
the future and also "session based" multihoming can be achieved
without the need to implement AS border routing.
Well, I'll use this opportunity to say, that once the ISPs get back PA
blocks from the sites that move to LISP and decide to get PI blocks,
the ISPs can now assign RLOCs to many more sites and those sites can
run IPv6-only and use IPv6 addresses as EIDs.
So the fact that IPv4 addresses become available is not to keep IPv4
living longer, but to accelerate the adoption of IPv6.
Dino
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
