Hey Patrick, > 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?
I'll just point out here that there is no requirement
that the networking elments implementing the ALT need to
be in the data path either.
> 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.
Yes, but we don't expect much churn on the ALT in any
event (at least not the churn we find from edges going up
and down; ALT nodes are connnected by GRE tunnels and
there are diverse underlying paths between ALT nodes).
> 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
> adjacent with the MS of the ISP.
Sure, that would be a legit deployment scenario.
> 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
> 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.
I'm not sure I understand. The map-server connects to the
ALT, which of course has a RIB, but it seems you're
talking about the DFZ RIB (RLOCs and all). Which one are
you talking about?
> When a EID changes location the ETR is updating the MS and BGP is
> announcing to all MS the change.
What you want to happen is for the ETR to register to
a map-server that can aggregate its EID prefix. If that
happens, there's zero update activity since the
map-server will already be advertising a covering prefix.
> The MS should then flush the adjacent
> 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?
The only thing I see is that the toplogy is virutal, so
one in theory can prevent any "churn" in the
register/deregister process if the map-server is already
announcing a covering prefix. Remember, the map-server
sends the map-request LISP-encapsulated to the ETR on the
underlying infrastructure, so can be anywhere (of course,
the "wheres" may have different attributes, e.g., latency,
packet loss, all of that).
> 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.
s/Then we have/If we have/
Dave
signature.asc
Description: Digital signature
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
