> Thank you very much for your comments. Please see my responses inline.
You are welcome. I trimmed some of your email and included the parts that I am replying to in this email. > > > > > According to hybrid model databases such like LISP-ALT [RFC6836] and > > > LISP-DDT [I-ietf-lisp-ddt], architectures of these mapping databases > > > > What do you mean by hybrid? And why isn't LISP-NERD or LISP-DHT hybrid? > > This is my mistake. LISP-DHT is also a hybrid model database, and I should > not > classify them by this. In my opinion, LISP-NERD is a push model database, > isn't > it? Sure, fine, but define hybrid in this context. I think you mean a "push/pull" hybrid? I am not sure if you are. > > > are based on announcement/delegation of hierarchically-delegated > > > segments of EID namespace (i.e., prefixes). Therefore, based on > > > these architectures, when a roaming event occurs and a LISP site or a > > > LISP MN receives new RLOCs, the site or MN has to anchor pre- > > > configured map-server to register its new mapping information no > > > matter where the site or MN currently locates, just in order to > > > protect EID prefixes announced aggregately in the database > > > [I-D.meyer-lisp-mn]. > > > > Yes, this is a huge scaling feature. A static address allocation > > should not be affected by movement or change of location. > > > > I am not sure if you are stating a disadvantage that LISP-SHDHT will > > fix? Can you clarify please? > > In LISP-SHDHT, LISP sites especially LISP-MNs need not anchor a configured > map-server. Let take a LISP-MN for example. A LISP-MN could send the register > message to any SHDHT Node which will forward the message to the SHDHT Node > who You shouldn't spec this or even support it, because now you are defining a new API that an xTR uses to interface to the mapping system. We have one already in the draft-ietf-lisp-ms RFC. > plays roles of Map-Server for this LISP-MN. Of course, there is a Map-Server > for a particular LISP-MN. The difference with other mapping database is that, > LISP-MN does not need to maintain connection with the Map-Server. Its > register > message will be forward to the Map-Server. The mapping database systems we have experimented to date with are modular. That means they are called "mapping database transport systems", which means only the MRs and MSes need to change to support a new one. The sites do not need to change. Architecturally, we would like to keep this modularity. There is no reason SHDHT cannot fit in as another mapping database transport system. > If Node 0x0123 is backup node for Node 0x4444, it stores all data values of > Node > 0x4444. But Node 0x123 is not the responsible node for these partition-IDs > ranges, unless there's something wrong with Node 0x4444. What does responsible mean in this context? Meaning 0x4444 will be the one that forwards the Map-Request? > > > 3.3. Node Routing Table > > > > > > In SHDHT, each node maintains a Node Routing Table containing routing > > > information of all other SHDHT Nodes locate in the same SHDHT > > > overlay. Table I shows the Node Routing Table on SHDHT Nodes of > > > Fig.1. A Node Routing Table contains all Partition IDs and their > > > associated Node IDs and node addresses. For simplification, Node IDs > > > and Partition IDs shown in the draft are only 16-bit numbers. > > > > Can you say in the above paragraph how each node builds this routing > > table? Is it statically configured or is there a message exchange > > routing protocol of sorts that builds the table. > > A SHDHT node floods it routing information to other nodes belong to the same > LISP-SHDHT.A SHDHT node floods it routing information to other nodes belong > to > the same LISP-SHDHT. Okay, so you are implementing a new routing protocol of sorts. You haven't spec'd that out. Like how are these flood messages sent reliably. Do you assume a transport under you? > > > When SHDHT Node receives a message points to a particular Resource > > > > I think you mean a lookup request? If not, please make it more clear. > > Not just lookup requests, but also map-register messages. Map-Register > messages > could also be forwarded by a SHDHT Node. You shouldn't do this. You are changing the definition of the Map-Register. It is defined in the RFCs to be sent from ETR to Map-Server. Not to a specific type of node in a specific type of mapping database transport system. > > > ID, it could look up Node Routing Table and find out the Partition ID > > > which is closest to the Resource ID. Furthermore, message could be > > > transferred to the corresponding SHDHT Node. > > > > > > +--------------+---------+---------------+ > > > | Partition ID | Node ID | Address | > > > +--------------+---------+---------------+ > > > | 0x1234 | 0x0123 | 10.0.0.2:2000 | > > > > Shouldn't the node ID just be the locator of the SHDHT node that is > > routable in the underlying routing system so you can et messages > > from you to other SHDHT nodes? Otherwise, you will have to maintain > > yet another mapping. > > Node ID is just an identifier of a SHDHT node. The partition ID and Node ID > both > described in the routing table, and it does not need to maintain another > mapping. > Ok, I will also consider to take Node IDs as the nodes’ locators, it seems > simpler. Yes, I know what it is. Why can't it be an IP address that is routable. > > > | 0x3234 | 0x4444 | 10.0.0.3:2000 | > > > > And what is 10.0.0.3:2000? Is 10.0.0.3 the IP address of a SHDHT > > node. Is 2000 a UDP port number of something else? Providing a > > simple clear example would really be helpful. > > Sorry, my mistake. I should write the title as "Address: UDP Port". And why do you need a UDP port here? > > > > > | 0x5000 | 0xe000 | 10.0.0.4:2000 | > > > | 0x7000 | 0x0123 | 10.0.0.2:2000 | > > > | 0x9000 | 0x4444 | 10.0.0.3:2000 | > > > | 0xaaaa | 0xc000 | 10.0.0.5:2000 | > > > | 0xcccc | 0xc000 | 10.0.0.5:2000 | > > > | 0xeeee | 0xe000 | 10.0.0.4:2000 | > > > +--------------+---------+---------------+ > > > > > > TABLE I SHDHT Node Routing Table > > > > > > For example, if Node 1 (ID: 0x1234) in Fig.1 needs to implement put/ > > > get/remove operations for a data object with Resource ID 0x8213. > > > Node 1 first looks up its Node Routing Table and finds out that the > > > closest Partition ID corresponding to this Resource ID is 0x9000. > > > Then Node 1 will send put/get/remove request to the node owns the > > > Partition ID, in Fig.1 is Node2, whose Node ID is 0x4444 and address > > > is 10.0.0.3:2000. > > > > Shouldn't the closeness function be a comparison of EID with a > > partition-ID that looks like a power-of-2 address of some sort? > > There could be multiple methods to choose the corresponding partition ID. > Based > on the closeness function, it will help to balance load on SHDHT Nodes. Also, > you could choose a simpler method. You did not answer my question. I will raise it at the mic tomorrow in the LISP WG. > > > > > > > 4. LISP SHDHT > > > > > > LISP SHDHT is proposed to provide "EID-to-RLOC(s)" mapping > > > information lookup service for sites running the Locator/ID > > > Separation Protocol (LISP). > > > > > > In LISP SHDHT, mapping overlay consists of SHDHT Nodes which play > > > roles of SHDHT Map Server and/or SHDHT Map Resolver. In this draft > > > > Or neither, right? Can't there be a SHDHT node that is neither a > > map-resolver or map-server? > > No "neither". In our strategy, each SHDHT node could receive messages > (Map-Request/Map-Register) from xTRs and could hold data value according to > its hash segment. A receiver of a Map-Request does not define a system to be a map-resolver. > I see what you mean. For Map-Register, it may register mapping information > for > such like 10.1.0.0/16 and 10.1.1.1/32. How to hash and store these > map-registers, right? Right. > Ok, I will take an example. Also answer questions posted earlier. > > Suppose a Domain SHDHT is operated by a mapping service provider who is > responsible to maintain all mapping information for 10.1/14. It assigns a > "hash > bits" for its domain SHDHT which is 16bits. All map-request/register will be > hashed as a /16 EID-prefix. When a node receives a register message for > 10.1.0.0/16, it hash 10.1.0.0/16 to be the resource ID 0x8200 for example, > and > the mapping information of 10.1.0.0/16 is stored based on corresponding > Partition ID(The node who receives register message looks up its routing > table > to determine which SHDHT node maintains the corresponding Partition ID, and > forwards the Map-Register message to that node.). When the LISP-MN registers > 10.1.1.1, the node also hashes it as 10.1.0.0/16. As a result mapping > information > of 10.1.0.0/16 and 10.1.1.1/32 are hashed to be the same resource ID and are > stored on the same node. We need voice for this. We can discuss in WG. Not sure if there will be enough time. > > If you do this, a cell-phone that is doing ETR functions will have > > to do SHDHT. Architecturally, we should have an opt-in to do this > > but it definitely should not be required. If it is required, the > > solution will be a non-starter IMO. > > ETR just chooses the nearest SHDHT Node and sent Map-Register message to it. This is not good because now the mapping system will have the same entropy as the roaming devices. We want roamability to scale and to have hand-offs occur fast, so you have to allow roaming to update the fewest possible network entities. > > > 5.3.2. Inter Domain Mapping Request > > > > > > When SHDHT Node of a Domain SHDHT Overlay receives a Map-Request > > > message, it checks if the requested EID is covered by local domain > > > overlay's EID prefixes. If the requested EID entry is not stored on > > > local domain overlay, SHDHT Node directly forwards the Map-Request to > > > Border Nodes. Border Nodes of local domain overlay then forwards it > > > to corresponding domain overlay based on Inter-Domain Routing Table. > > > > Which border node? All of them? > > Just like in LISP Sites, there may be multiple ITRs. SHDHT Node will choose > one border node to forward the message. I don't known what you mean "just like LISP Sites". ITRs select RLOCs based on the best priority value. But that is orthogonal to what you are doing. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
