Hello Damien and others I am not sure if I can follow this: "...big advantage of LISP is that you mapping table scales with your traffic, not with the size of the Internet." This is true for the ITR caches, but not for the mapping system as it needs to provide mappings to all EIDs. So the size of the mapping system is a function of EIDs, not the traffic. If an EID wants to be globally reachable it needs to have an entry in the global mapping system, irrespective of the traffic.
The block/prefix based aggregation will break over the time if the assignments are not reallocated. This has happened with the existing prefix based allocations and will happen again. I can not see other way. If end devices do not renumber, then the mapping system needs to reconstruct its structure, or then the blocks will deaggregate. Migration of a single subsidiary from an enterprise to an other is not a big issue, I can see that, but over the time migration of small sites seems to be quite common. They keep on coming and going. This will lead to the extreme case that there would be long prefixes at the very top of the mapping system if we stick to the original allocation. And then all of the map-requests will go through the top of the mapping system. At least with the DNS of today that is not the most ideal case. Best regards Hannu >-----Original Message----- >From: ext Damien Saucez [mailto:damien.sau...@uclouvain.be] >Sent: Monday, March 08, 2010 10:53 >To: Flinck, Hannu (NSN - FI/Espoo) >Cc: RRG >Subject: Re: [rrg] LISP does not implement Locator / Identity >Separation > >Hannu, > >On 08 Mar 2010, at 09:34, Flinck, Hannu (NSN - FI/Espoo) wrote: > >> >> Hello Dino >> >> Just a remark that in the mapping system discussions in the >lisp list >> the strong sentiment is that EIDs must be allocated and >administered >> as EID blocks to guarantee any efficiency and scalability. If the >> identities are coming from blocks that are allocated to given >> enterprises, then what happens when one of devices or a small remote >> site joins to an other enterprise in an different EID block? >> Renumbering of EIDs maybe? How portable are the EIDs at the >end of the >> day depends on the mapping system structure and scalability. > I would >> say that EIDs are independent from locators for sure, but not from >> their allocation scheme that ties them to topology. > >We have to think more about this question. IMHO, there is no >real scalability problem for the mapping system when a company >has several prefixes that cannot be aggregated. Indeed, this >is not because two prefixes belong to the same company that >the path to get the mapping via the mapping system must be the >same. For example, if a company has the prefix A.1.2.3 and the >prefix B.4.5.6, and if ALT is deployed like a tree, the map >request will go to A, then A.1 then A.1.2 and finally A.1.2.3 >for the first prefix and to B, B.4, B.4.5 and B.4.5.6 for the >second prefix. If ALT use aggregation, Only A and B need to be >announced to the top of the tree. In this case, we even have a >good scalability for the mapping system as the requests for a >company may follow very different path in the mapping system. >Now, if we are thinking about the cache, I don't believe that >it will cause so many troubles. Of course, you will have to >install A.1.2.3 and B.4.5.6 in the cache for the company, but >as stated by Joel, it is likely that the prefixes will be >uncorrelated in term of traffic (except in the UCL use case I >sent yesterday), therefore, you will probably, on the long >term, only have one entry, not both. One big advantage of LISP >is that you mapping table scales with your traffic, not with >the size of the Internet. > >To conclude, having one company with non aggregatable prefixes >will not cause (?) deaggragation in the mapping system and >thus should not cause scalability troubles. > > >Cheers, > >Damien Saucez > >> >> - Hannu >> >>> -----Original Message----- >>> From: rrg-boun...@irtf.org [mailto:rrg-boun...@irtf.org] On >Behalf Of >>> ext Dino Farinacci >>> Sent: Monday, March 08, 2010 07:46 >>> To: Robin Whittle >>> Cc: RRG; Noel Chiappa >>> Subject: Re: [rrg] LISP does not implement Locator / Identity >>> Separation >>> >>>> An EID address is not an Identifier and an RLOC >>> >>> It is an identifier. It is used by the TCP and UDP socket >layer. Just >>> because an EID is also a scoped locator inside of a site, does not >>> preclude it from being an identifier. >>> >>>> address is not a Locator. Both kinds of address >>>> are like any IP address - they play the roles of >>>> both Identifier and Locator. ITRs use a different >>>> algorithm for EID destination addresses. All >>>> other routers and all hosts make no distinction >>>> between EID and RLOC addresses. >>> >>> LISP does separate ID and locator because you can keep an EID fixed >>> with a system, maintaining session continuity, while changing the >>> locator associated with the EID. >>> >>> Dino >>> >>> _______________________________________________ >>> rrg mailing list >>> rrg@irtf.org >>> http://www.irtf.org/mailman/listinfo/rrg >>> >> _______________________________________________ >> rrg mailing list >> rrg@irtf.org >> http://www.irtf.org/mailman/listinfo/rrg > > _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
