> > So, in your mind how many SIR prefixes will be used in a typical T1 operator domain?
Sri, very good question and I don't think anybody figured this yet for 5G.. > Also, how can we quantify the state that ILA introduces in different parts of the network? Please look at topology of section 2 in https://tools.ietf.org/html/draft-herbert-ila-ilamp-00. ILA routers collectively contain the all the mappings for the domain. The mappings can be sharded on the routers serving a shard can be replicated. There are two cases where ILA transformation is needed: at netwrok ingress (e.g. from Internet) and intra domain traffic. The first case is served by edge routers which as I mentioned would have considerable load. For intra domain communications routers would be used aslo, but they can be augment by the use of mapping caches in forwarding nodes. Forwarding nodes perform ILA to SIR transformation before delivery-- this does not need a lot of state. Presumably every mobile node in the network has an identifier to locator mapping. So the number of mappings in the domain equals the number of mobile nodes. This number is expected to reach into the the billions, a scale a single device won't have the memory for the full mapping table so it would be sharded. Each shard also would be replicated N ways. So number of routers needed is num_shards * num_replicas. Another major consideration for scaling is changes to the mapping system. It's a little harder to quantify since the load on the system depends on the rate at which mobile nodes are moving. I'm not sure what the rate of device moving in cellular network is (someone might have good insights on that), but for scaling estimates I'm using 1 % (that is at an given time 1% of devices are moving to different eNb). Tom, 1% seems to be incorrect assumption even for 4G and also regardless of how you partition shreds I see potential for massive state introduced in the core (in various nodes); and I am not even sure how "making anchorless" solution is the most important/pressing goal. -- Uma C.
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm