Hannu, Dino, On 09 Mar 2010, at 07:53, Dino Farinacci 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 > > That is not my sentiment. ;-) > > A site may have to request more EID-prefix space later after it perhaps uses > all its addresses. So the entire set of EID-prefixes may not be in a > power-of-2 block. But that doesn't mean the ALT cannot scale. The ETRs just > register each EID-prefix to the map-servers that are injecting covering > routes into the ALT. >
Completely agree, we can imagine two map-servers, one responsible of A/a and one responsible of B/b. If you have A.1.2/p, just register with the first Map-server. If you have B.3.4/q, register to the second server. In the ALT, only A/a and B/b will be announced. >> 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 > > No, no renumbering required. No renumbering, except if you need all your hosts within the same prefix, but why would you need this? > Plus we want people to use their existing PI or PA prefixes as EID-prefixes > when they convert to LISP. Ow, that's interesting, it is the first time you write it, isn't it? Ok for PI, but don't you think that reusing the current PA as EID is a good idea? > For IPv6, the situation will be much better. Because large enough blocks can > be allocated so there most likely will be a single EID-prefix. > Sure, but we do not really need this aggregation, what we need is to keep the ALT aggregated, which is orthogonal to keeping the sites aggregated. >> 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. > > EIDs are not tied to topology. That is the whole point. They are assigned to > devices and stay fixed. This way, they can move if mobile or they can stay > the same when sitting at a stationary site that changes service providers. > > An EID is a network layer name that doesn't ever change. The name to EID > mapping in DNS never needs to change. The moving lever is the mapping of EID > to RLOC-set via the LISP mapping database. > Maybe they are not given forever to hosts, but IMHO, EID prefixes are given to the networks almost forever, like today PI prefixes. Damien Saucez > Dino > >> >> - 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 _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
