Hi Olivier, I understand from what you wrote:
> For scalability reasons, I would propose to define this requirement as > follows : > > The identifier to locator mapping function MUST support mapping entries > for aggregates of identifiers. It MAY also support mapping entries for > host identifiers. > > My reasoning is that to be scalable, a mapping system must deal with > aggregates. However, some devices, perhaps for some destinations may > request or agree to receive map entries for host identifiers. Mapping > individual host identifiers is clearly not scalable and should only be > an option while the default should be to map aggregates. I don't understand what the problem is with having one, many, or most EID prefixes (LISP) or micronets (Ivip) being a single IPv4 address. I think that with IPv4, more and more end-users will have smaller and smaller chunks of space - many of them will be happy with a single IP address. Likewise, the only scenario where billions of end-users each want their own address space is mobile phones / computers. Virtually all those users would be happy with a single IPv4 address or a /64 in IPv6. Nor do I see a problem with many EID prefixes / micronets being /48s or /64s in IPv6. I think it would be a bit nutty having ITRs having to trawl through 128 bits, but I think the protocol by which the mapping is sent (push or pull) should be able to accommodate individual IPv6 addresses. That is what we are discussing, isn't it? The characteristics of the protocol by which the mapping system communicates EID prefix / micronet details to whatever requests them, along with the mapping for that EID prefix / micronet. What happens inside the mapping database - centralised or distributed - is a private matter for whoever implements it. The innards of the mapping database storage system does not need to be standardised. I don't see any scaling problem with how the EIDs or micronets are defined. All I see is some efficiency and flexibility issues. The following examples assume IPv4. One way is to have 32 bits for the base address and 5 bits for the prefix length. That is nice and compact - 5 bytes. Ivip would use 32 bits for the base address and probably 24 bits for the length. That is 7 bytes rather than 5, but enables arbitrary lengths of micronets. Since IPv4 space is so precious, I think these 2 extra bytes would be a good price to pay for the benefit of more flexible slicing and dicing. Your specification doesn't enable me to construct examples of what you want in terms of bits and bytes to represent a micronet. Could you give some examples? For instance, 3.4.5.0/31 is an aggregate, but takes no less bits to specify than 3.4.5.0/32. If your proposal is not motivated by compactness of representation of the EID prefix's starting and ending point, then what is your goal? Your statement: > My reasoning is that to be scalable, a mapping system must deal > with aggregates. doesn't convey to me why you believe that being able to specify individual IP addresses presents a scaling problem. Surely you don't mean that you assume a mapping system can only have a certain number of entries, and that to cover the address space with this limited number of entries, most of them must cover a large number of IP addresses? One of the major benefits of ALT (actually, the only one, I think) is that it can have endless divisions of the address space, without burdening the ITRs, since they only cache whatever mapping they need at the time. So there's no scaling problem due to the number of EIDs in terms of the ITRs or the conceptual nature of the ALT system - you just add more ETRs and/or more storage capacity in these ETRs. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
