Hannu, On 08 Mar 2010, at 10:22, Flinck, Hannu (NSN - FI/Espoo) wrote:
> > 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. As I said, the size of your mapping table scales with the number of organisation you have to contact. Except in case of scans, most of the organizations only contact a small subset of the total number of organizations that make the Internet being what it is. Of course, this may not be the best property for some entities, but on average, scaling with your use should not be too bad. If you really take care of how you build the mapping system (and deploy it), you can make sure that you can do very aggressive aggregation and thus keep the mapping system "routing table" small. A correct deployment of the mapping system should also limit the load on each link of the mapping system. However, this last point is not yet clear and we have to investigate a bit more. Therefore, I would says that the size of the mapping system is not a function of the number of EIDs, but a function of the hierarchy you are willing to have. Of course, you will have a lot of leaves, but only the direct parent of a leaf must know the existence of this leaf. > > The block/prefix based aggregation will break over the time if the > assignments are not reallocated. Why? > This has happened with the existing > prefix based allocations and will happen again. The mapping system is only used for the control plane, so why do you need to absolutely reallocate? > 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. > I do not follow you? The cache, yes, it needs to do some kind of compression if too many entries have to be installed, but again, in practice, you will have to scale to your traffic, not the Internet, you can thus provision your routers accordingly. > 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. > I am not sure to understand the problem. A well design mapping system should not take care of the number of mappings. Having a lot of prefixes for the same entity will generate a lot of different mappings, but, the overall mapping system does not take care about this. I see the mapping system as a set of pointer, each node point you to a more specialized node until you arrive a node able to provide you the mapping. So that, a node only need to know what is under the responsibility of its neighbors. This is true that in a mapping system like NERD we will have scalability troubles in the case of a lot of small mappings, but ALT will not suffer it is correctly deployed. Damien Saucez > 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
