Re: [Ila] ILA forwaring [Was Re: [5gangip] Problem Statement]

Three reactions, all personal opinion (in case someone thinks my having 
helped chair the BoF is in any way relevant; it isn't):

1) If ILA-Ns do not have caches, the ILA-Rs will become hot-spots in the 
network.  Yes, you have provision for multiple of them sharing load. 
However, if that sharing gets to be a significant percentage of teh 
routers in the network, then there is no point in having bothered with 
ILA, you are just routing on the SIR.

2) As far as I can tell, when some ILA-N have caches, the ILA-R have no 
way of knowing whether the ILA-N have caches or not.  I can understand 
what happens if all ILA-N in a network have the same cache state (either 
they all have caches or they all do not have caches).  But I do not know 
what behavior you expect of an ILA-R if the ILA-N are not uniform. 
Given the hot-spot issue above, I think you need to really explain why 
ILA-N would not ahve caches.

3 - Minor) Your usage of "sharding" seems odd.  You are simply dividing 
the domain into address blocks, and distributing responsibility for 
those blocks separately.  In other contexts, sharding seems to be used 
more generally for having subcollections of the data which can be moved 
around.

Yours,
Joel

On 5/1/18 11:54 AM, Tom Herbert wrote:
> Dino,
> 
>> I don’t want to look at code. I want you to explain clearly how a cache misser gets the RLOC. What if the identifier is not in its shard?
>>
> RLOCs don't exist in ILA, that is a LISP term.
> 
>> You are missing the point. Forward to where? How?
>>
> I will try to answer your questions in as much detail as possible.
> 
> Here are the example cases that illustrate operation.
> 
> Case #1: A network has a single SIR prefix and one ILA-R and some
> number of ILA-Ns. The ILA-Ns do not have a map cache and are only used
> for SIR to ILA transformation.
> 
> The ILA-R advertises the SIR prefix in normal IP routing. It is the
> router for the SIR prefix. Packets destined to an address with the SIR
> prefix are thus routed the to ILA-R. Mapping entries are realized as
> hosts routes in the ILA-R where the destination host is composed of
> the SIR prefix and identifier. When an ILA-R receives a packet it
> performs a route lookup. If the returned route is an ILA route then
> the ILA transformation is performed where the SIR prefix is overridden
> with the locator indicated in the route. The packet is then forwarded
> back into the network. Normal IP routing forwards the packet to an
> ILA-N corresponding to the locator (each ILA-N is assigned a unique
> locator and routing is configured so that all packets with the locator
> prefix in the destination address are forwarded to the ILA-N). At the
> ILA-N, ILA to SIR transformation occurs so that original packet is
> restored. The packet is then forwarded by the ILA-N to a downstream
> destination (e.g. a UE).
> 
> If an ILA-R receives a packet and it finds there is no route for it
> then it drops the packet. So if no ILA mapping exists for an
> identifier address then the packet is dropped. The ILA-R contains all
> the mappings for the ILA domain, if does not need to ask someone else
> if it doesn't find a mapping. ILA-Rs are not map caches.
> 
> Case #2: A network has a single SIR prefix and multiple ILA-R and some
> number of ILA-Ns. The ILA-Ns do not have a map cache and are only use
> for SIR to ILA transformation.
> 
> This is the case where ILA-Rs are replicated for load and
> availability. Each ILA-R advertises the SIR prefix in IP routing for
> the network. Routing techniques of ECMP, shortest path, etc. are used
> to route packets to the "nearest" ILA-R. Packet processing at each
> ILA-R is the same as described in case #1.
> 
> Case #3: A network has a multiple ILA-R that shard the mapping entries
> and some number of ILA-Ns. The ILA-Ns do not have a map cache and are
> only use for SIR to ILA transformation. The low order bits of the SIR
> prefix contain a shard index, the high order bits are common.
> 
> In this case the mapping table is not contained a single ILA-R, it is
> sharded across some number of them. This might be done because the
> table is too big, or for geographic locality, etc. Each shard is
> associated with an index. SIR prefixes are composed of a common prefix
> and the index in the low order bits (for instance index could be eight
> bits). Each ILA-R then advertises its SIR prefix that includes its
> index in IP routing. An ILA-R can also serve multiple shards so it may
> advertise multiple prefixes in routing. Each shard may also be
> replicated per case #2. Packet processing at each ILA-R is the same as
> described in case #1.
> 
> * Note that none of these cases so far require a mapping cache. These
> work for all packets regardless of the source. The sender may be local
> to the network, or may be a host on the Internet.
> 
> Case 4: Map caches are enabled on ILA-Ns.
> 
> The map cache is implemented as host routes in an ILA-N similar to
> ILA-R routes. When a packet is sent by a downstream device (e.g. a UE)
> it traverses an ILA-N. The ILA-N performs a route lookup on the
> packet. If an ILA route is found (a map cache hit) an ILA
> transformation is performed an the packet is forwarded directly
> towards the destination. If there is no ILA route (map cache miss),
> then another route is found possibly the default route (remember these
> are just normal route lookups). The packet is forward per the route
> and since it still has a SIR prefix in the destination address it will
> be forwarded to an ILA-R as described in case #1. The ILA-N does not
> send a mapping request and does not remember the destination, it just
> forwards without incurring any additional delay.
> 
> When ILA-Rs receive packets they transform and forward them as
> described above. It MAY also send an ILA redirect. An ILA redirect can
> only be sent to an ILA-N that is in the local ILA domain. To do this
> the ILA-R performs a reverse lookup on the source address of the
> received packets. If the lookup returns an ILA route then that will
> contain the locator corresponding to the ILA-N for the sender. A
> redirect message is sent the locator using ILAMP. This contains the
> destination and the locator. When the ILA-N receives the redirect it
> instantiates the routing table with an ILA route. Subsequent packets
> then can use the route so that packets are router directly thereby
> eliminating triangular routing.
> 
> There are other details about managing the ILA cache that are
> described in draft-herbert-ila-ilamp-00.
> 
> Tom
> 
> _______________________________________________
> ila mailing list
> ila@ietf.org
> https://www.ietf.org/mailman/listinfo/ila
> 