Hi Sri, My comments are inline.
> https://tools.ietf.org/html/draft-herbert-ila-motivation-00 provides some > comparisons between ILA and ILNP, encapsulations, SR, and transport layer > mechanisms that can achieve some effects in mobility. > > The choice of mapping system is critical. The mapping of identifier, or > equivalently virtual to physical address mapping, seems to be a common > problem in mobility and networking virtualization. As you mentioned, LISP > defines a query method to populate a mapping cache. I assume this problem > needs to be tackled in SR for mobile user-plane but I'm not sure what > solution is preferred after reading the draft. > > [Sri] There are multiple approaches on how we manage this mapping state. > Obviously, ILA is one approach, but there are few other approaches as well > that we need to review. It's a good discussion to have. > ILA partitions the problem into a two level hierarchy: ILA routers and IL > forwarding nodes. This is somewhat analogous to core IP routers and nodes > running neighbor discovery. ILA routers contain all the (possibly sharded) > mappings. They are authoritative. Forwarding nodes are located close to user > devices and maintain a working set cache of entries driven by user activity. > If a packet doesn't hit the cache it's forwarded to a router that will do the > ILA transformation. If the cache is hit, the packet can be transformed at the > forwarding node to eliminate triangular routing. Caches can be populated by > pull or push models. ILAMP (the ILA mapping protocol) supports both of these, > but my current preference for scalability and mitigating DOS attacks on the > cache is to use secure redirects sent by ILA routers (analogous to ICMP > redirects). > > > [Sri] When I last reviewed the ILA I-D, I do not seem to remember reading > about the cache state, ILMP. or about how the mapping gets to the ILA > routers. Looks like the spec is evolving as we speak. With ILAMP type control > protocol for cache management, I see more similarities to LISP. > > We separate data plane from the control plane. The ILA draft describes the data plane, other drafts (ILAMP, BGP/ILA, ILA in the datacenter) describe control plane aspects. We'll post a draft shortly with details specific to the mobile user plane. There are similarities to LISP, but also differences. > > > >> On a different note, just curious if SID prefix can ever have topological >> relevance and can be used for routing. In other words, can you ever route a >> packet without translating the SIR prefix of the destination address with >> the locator? Can SID prefix be used as a locator in some special cases? > > > Yes, the SIR prefix is routable to forward to an ILA router. This is > necessary for the redirect mechanism I describe above. I suppose this could > be contorted to make the SIR address be a home address like in MobileIP and > locators are COAs (if my use of MobileIP terminology is correct). There also > might be nodes in the network, as well as external nodes that don't do go > through a cache to their packets need to hit an ILA router to get forwarded > to the location of mobile nodes. An upshot of that is that edge routers might > need to perform transformations (SIR to ILA) at high rates so the mechanism > needs to be very efficient and amenable to HW implementation. > > > [Sri] This is precisely what I was thinking. > > I get that SIR prefix takes the packet awards the ILA domain and some ILA > router in the path can apply the mapping. I was thinking there may not be a > good reason to have more than one or two SIR prefixes for each ILA domain. As > long as the SIR prefix can take the packet from a non-ILA domain (internet) > to ILA domain, then the edge router can apply the mapping. But, that also > implies the edge routers will have to have too much of mapping state. Now, if > we have many SIR prefixes and associate a SIR prefix for each PGW/UPF, that > state can be distributed and keep the edge routers stateless, but it also > brings anchoring back into the picture. In one simplest mode, as you say, HNP > (home network prefix) can be a SIR and the PGW/SGW or (LMA/MAG) can do the > translation of SIR - ILA, without the need for tunneling. > > So, in your mind how many SIR prefixes will be used in a typical T1 operator > domain? One SIR prefix is the simplest way. This allows 64 bit identifier lookups instead of 128 bit. Also, there's no ambiguity in ILA to SIR address translation since all locators may back to the same SIR. However, there's nothing in the architecture that prevents multiple SIR addresses as long as the mapping from ILA to SIR address is unambiguous. Non local address identifiers do this. > 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 _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
