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: [email protected] [mailto:[email protected]] 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 >> [email protected] >> http://www.irtf.org/mailman/listinfo/rrg >> > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
