Hi, Brian: Thank you for your enlightening arguments. A pleasure to have in depth discussion with you.
>>>>> A good answer is that the EID should also be aggregateable, >>>> I may be missing what you mean, because it seems to me that >>>> any set of bit strings (even of variable length) is aggregatable >>>> to an arbitrary extent. Just build a binary tree and chop it >>>> off at whatever level you want (/N if you want 2^N aggregates). >> Here the EID aggregation is based on the same mapping information, >> e.g. if 2 neighboring /16 EIDs map to different RLocs, there needs at >> least 2 entries in the mapping system for this discrimination. >> Therefore they are not "aggregateable" if concerned by scalable >> mapping. > > That seems to describe EIDs that have topological significance, and I don't > understand how that works. Of course, individual EID has no topological significance, but we are trying to make them in "groups" in the mapping system, otherwise we might need to map each IPv4 EID in /32 to their Rlocs. Practically, we use LAN prefixes to group them, you may regard this constraint as "topological significance". And we hope to make this granularity even more coarse by certain feasible aggregation, then we might need more constraints on different levels(e.g. AS level, country, RIR). > >>> Agree. Even the EID is a flat label, the corresponding ID->Locator mapping >>> system could scale well by using some methods, e.g., DHT. >>> >> DHT also builds fine hierarchies within its scheme, or to say a flat >> label can be organized in a logic hierarchical structure. Indeed >> hierarchical structure helps to alleviate scalability problems, but it >> might be prudent to say it scales "better" (than flat label) instead >> of "well" if we are facing an already massive mess. IMHO, to make EID >> organized/assigned in an "aggregateable" way beforehand can be easier >> than to find any aftermath remedies. >> >>> IMO, a major reason that the EID should be hierarchical is as follows: >>> >>> The resolution infrastructure for flat names has no "pay-for-your-own” >>> model, as the flat names are stored at essentially random nodes. In >>> contrast, the resolution infrastructure for the hierarchical host >>> identifiers has reasonable business models and clear trust boundaries. Since >>> the hierarchical host identifiers have clear organization affiliation, the >>> identifier resources and the corresponding mappings can be managed by >>> different bodies with clear administrative boundaries. >>> >> I agree. Hierarchically organized EID with some constraints on its >> assignment(clear organization affiliation) guarantees scalable >> mapping, since theoretically the information entropy reduced. > > I don't understand. There's no reason in physics or economics why > customers that happen to be adjacent in an ISP's address allocation > scheme should be adjacent in any scheme of organisational affiliation. > This argument fails for exactly the same reason that geographically > based BGP aggregation fails. > > I'm not saying there is zero correlation. Obviously, two customers > in the same city are more likely to use the same ISP than two customers > in different countries. But can you point to studies that show that > the observed correlation is enough to significantly affect aggregation? > Significantly means: this would scale a lot better than BGP aggregation > scales today, otherwise we have gained nothing from the loc/ID split. > I'm puzzled how this could be, since if there is such a correlation, > it would also help BGP aggregation. > > My understanding of the value of the loc/ID split is not that it > benefits from aggregation in the ID space, but rather that the > cost of non-aggregation is acceptable in the ID-to-loc map > because it is not subject to the performance constraints of > a routing protocol. > > Brian > IP address allocation has few constraints on prefixes usage, since there seems no "physics and economics reason" to do so. At the beginning, BGP scaled well. Later on BGP encountered great difficulties when it tried to aggregate fragmented IP prefixes. If we retrospectively reconsider the lessons learned from IPv4, we might need to admit that some constraints are helpful if it is not too much troublesome, which definitely have the aggregation significance on scalability. Then how to design the constraints (e.g. the one you have mentioned previously) which may significantly facilitate aggregation or scalability? The answer can be complicated where we may need physics and economics reasoning. BGP is hard to be adapted to enforce new constraints, since it is too overwhelming and on duty all the time. Now ID/Loc split offers us an opportunity to put things back on the right track, although it has many other appreciating values. If we take it for granted that the cost of non aggregatable EID mapping will not influence the performance of a routing protocol, we might repeat the story of IPv4 allocation and BGP. >> However, before anyone enforces these constraints in the Internet, we >> need to define the hierarchy with corresponding range of effects which >> is my intention of designing "aggregateable" EID on behalf of ID/Loc >> mapping scalability. Wei Zhang _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
