Hi Dino, Please see my responses inline.
I understand that you mean Map-Register messages MUST NOT be transmited. ETR MUST send Map-Register directely to Map-Server. I will consider the scenarios based on [LISP-MS]. For some comments mentioned this problem, I didn't reply inline. Thank you. Dino Farinacci <[email protected]> 写于 2013/03/14 16:11:49: > > > > > > > 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. Yes, I mean the "push/pull" hybrid mode. > > > > > 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 LISPsite 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? In the example, responsible means that Node Ox4444 is requested to store mapping information according to the partition-IDs. Node 0x123 is the backup node. > > > > > 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. I will consider about this. > > > > > | 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? I will modify it in the next version. > > > > > > > > | 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. Yes, I see. It's not the comparison of EID with a Partition-ID. SHDHT Node hashes EID to be a Resource ID. Closeness function is a comparison of Resource ID with a Partition ID. > > > > > > > > > > > 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. My fault. It's not the same with LISP Sites. Domain SHDHT Nodes maintain default routes pointing to the Border Nodes. > > Dino -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately.
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
