[lisp] Fwd: Comments about draft-cheng-lisp-shdht-01

[[e-mail]]

 Hello Michael,
 
 My reply is in line. Thank you.
 
 Best Regards,
 Li Cheng

 
 Michael Hoefling <[e-mail]> 写于 
 2012-07-26 00:14:43:
 
 > Hello Li,
 > 
 > thank you for including my suggestions. I have read the -01 version and
 > still have some comments left.
 > 
 > I have additional comments and then - inlined in your reply -
 > comments on your reply.
 > 
 > 1. As far as I understand, LISP SHDHT acts as a mapping system for 
LISP,
 > i.e., an ITR sends a Map-Request-message to one SHDHT node which then
 > forwards the query to the "correct" SHDHT node which stores the mapping
 > information. This node eventually answers the query and sends the 
answer
 > directly to the ITR.
 > 
 > Noel Chiappa write two drafts about the overall LISP architecture:
 >   http://tools.ietf.org/html/draft-chiappa-lisp-introduction-01
 >   http://tools.ietf.org/html/draft-chiappa-lisp-architecture-01
 > 
 > There, it is stated that - in accordance to the standard documents -
 > ETRs are the only authoritative source for mapping information. That 
is,
 > every mapping system for LISP is actually an "indexing system" to 
enable
 > the mapping resolver (see LISP-MS) to find the correct ETR.
 > 
 > Based on this, the SHDHT node which "stores" the mapping information of
 > an ETR has to forward the Map-Request message to the ETR which then
 > sends the reply to the ITR or mapping resolver directly. The SHDHT node
 > in this case acts as LISP-"mapping server" (LISP-MS, misleading name 
but
 > already defined in the standard documents).
 > 
 > What I suggest is that you try to integrate LISP-MS in your draft and
 > get the terminology right - otherwise someone at the IETF-84 will tell
 > you to do so. I think you architecture is interesting and I would like
 > to see it presented - unfortunately I cannot make it to the IETF this 
time.
 
 In our drat, ETRs are still the authoritative source for mapping 
information.
 
 In draft-ietf-lisp-23, according to "Map-Register Message Format" on page 
41, 
 there is a p bit which is called proxy-map-reply bit. When an ETR sends a 

 Map-Register Message requesting for the Map-Server to proxy Map-Reply, it 
will 
 set the p bit to 1. 
 
 In our draft, SHDHT Nodes could be considered as Map-Servers which 
 implement the "Proxy Map Reply" mode.
 
 Furthermore, the authority verification between SHDHT Node and xTRs 
 will be for our future work.
 
 
 > 
 > Am 16.07.2012 11:43, schrieb [e-mail]:
 > > Michael Hoefling <[e-mail]> 写于 
2012-07-12 
 > > 22:32:36:
 > >  > 3. In Section 2 and 3, you introduce Partition IDs but you do not
 > >  >     clarify how the length of each Partition ID segment is 
defined. Is
 > >  >     each segment of a fixed size, i.e., Partition ID x spans a 
segment
 > >  >     between x and x+size? Or has each Partition ID a segment 
length
 > >  >     assigned? Either way, please clarify in your document.
 > > 
 > > SHDHT Nodes could determine number of Partition IDs on them 
separately
 > > and could generate Partition IDs randomly just need to make sure that
 > > the generated Partition IDs will not conflict with existing Partition
 > > IDs on the SHDHT plane.
 > > 
 > > Hash space segments are not required to be partitioned equally.  As 
SHDHT
 > > Nodes could general Partition IDs separately, when a SHDHT Node gets 
all
 > > hash segments assignment information for other SHDHT Nodes, it 
 will be able
 > > to implement the load balance of SHDHT overlay by general proper 
 > > Partition IDs.
 > 
 > I am sorry but I do not understand. Can you please clarify?
 > 
 > SHDHT nodes get assigned Partition IDs, right?
 > How is the size of the partition associated with a Partition ID
 > determined? This is described in neither version -00 nor -01 of your
 > draft. I am aware of the fact that hash segments do not have to be
 > equally partitioned but they have to have a size known to at least the
 > corresponding SHDHT node.
 > 
 > Maybe I am using the wrong terminology. I rephrase my question: If a
 > Partition ID identifies a hash space segment, what is the size of a 
hash
 > space segment and where is this information stored?
 
 Please see reply to Question 4.
 
 > 
 > >  > 4. In Section 4.1 you state that a Node Routing Table lookup using 
a
 > >  >     Resource ID returns the closest matching Partition ID. How do 
you
 > >  >     define "closest Partition ID"? What happens if the Node 
Routing
 > >  >     Table has no match for the requested Resource ID? This case is 
not
 > >  >     covered in the document yet.
 > > 
 > > 
 > > About "the closest Partition ID", please see the following
 > > example(in section 3.1 of the -01 version).
 > > 
 > >     For example, for a data object whose Resource ID is 0x8213, the
 > >     Resource ID locates between Partition ID 0x7000 and Partition ID
 > >     0x9000.  As Partition ID 0x9000 is closer to Resource ID 0x8213, 
the
 > >     data object will be stored and maintained on Node2 who is 
assigned
 > >     with the hash space segment indexed by Partition ID 0x9000.
 > > 
 > > Consider about three Partition IDs 0x5000, 0x7000 and 0x9000. Based 
on the
 > > "closest" rule, hash space segments indexed by the Partition ID 
0x7000 may
 > > be considered as [0x6000, 0x8000).
 > 
 > Ok. From the text in the draft I still do not get it, but with the
 > explanation in your reply, I think I might have understood it. Please
 > verify whether my following own explanation is correct.
 > 
 > If I get this right then every SHDHT node holds the same Node Routing
 > Table? That is, every SHDHT node knows all Partition IDs assigned to 
all
 > SHDHT nodes?
 > 
 > With this assumptions I would interpret the "closest" rule as follows:
 > If we have three consecutive Partition IDs a, b, and c which are the
 > only Partition IDs in SHDHT for our example, then the range of each 
hash
 > space segment is defined as follows:
 >   Partition ID a: [id(a)-d(c,a); id(a)+d(a,b))
 >   Partition ID b: [id(b)-d(a,b); id(b)+d(b,c))
 >   Partition ID c: [id(c)-d(b,c); id(c)+d(c,a))
 > with functions
 >   id(x): value of Partition ID x in hash space
 >   d(x,y): distance between Partition ID x and y in hash space
 > 
 > Did I get this right?
 
 Almost correct.
 
 The space segment is defined as:
 
    Partition ID a: [id(a)-0.5*d(c,a); id(a)+0.5*d(a,b))
    Partition ID b: [id(b)-0.5*d(a,b); id(b)+0.5*d(b,c))
    Partition ID c: [id(c)-0.5*d(b,c); id(c)+0.5*d(c,a))
 with functions
    id(x): value of Partition ID x in hash space
    d(x,y): distance between Partition ID x and y in hash space
 
 Yes, my description in draft was not clear enough. I will modify it 
 in the next version.
 
 
 > 
 > >  > 5. In Section 4.4.2 you are talking about encapsulated 
Map-Register
 > >  >     messages. As far as I know, the standard document allows
 > >  >     encapsulated control messages for map requests only. See the
 > >  >     LCM-description on page 44 of draft-ietf-lisp-23. You 
 either clarify
 > >  >     in your text that you - in conflict with the official standard
 > >  >     document - have to use encapsulated Map-Register messages to 
make
 > >  >     LISP-SHDHT work. Or you re-work this part of SHDHT's 
 architecture to
 > >  >     make it LISP-compliant.
 > > 
 > > Yes, agree. We have removed this section. Based on domain SHDHT 
 deployment,
 > > the register messages are not need to be encapsulated.
 > 
 > What do you mean by "domain SHDHT deployment"? I could not find any
 > information regarding this in the draft. Please clarify!
 
 In section 1 or Version 01, I specified that "In actual deployment 
 of LISP SHDHT, mapping database could be maintained by operators and
 could be deployed as collaborative combination of multiple domain 
 LISP SHDHTs."
 
 Detailed information of domain SHDHT deployment will be described in
 our next version.
 
 > 
 > >  > 6. Section 6 about security considerations is marked as TBD. One 
of the
 > >  >     hard problems to be solved in DHTs is security. How do you 
tackle
 > >  >     Partition ID over-claiming? How do you prevent Node 
ID/Partition ID
 > >  >     hijacking? How do you prevent ETRs from falsely 
 registering mappings
 > >  >     at SHDHT nodes?
 > > 
 > > *Partition ID over-claiming:* Each SHDHT Node maintains all Partition 

 > > IDs of
 > > the SHDHT overly in Node Routing Table. As I explained in Q.3, SHDHT 
Node
 > > will make sure that the generated Partition IDs are not conflict with 

 > > existing
 > > Partition IDs on the SHDHT plane.
 > > 
 > > *About Node ID/Partition ID hijacking and ETRs falsely registering:*
 > > 
 > > As we described in -01 version.
 > > 
 > > "This draft just specifies the outline of SHDHT and the basic 
 > > application of
 > > LISP SHDHT. In actual deployment of LISP SHDHT, mapping database 
could be
 > > maintained by operators and could be deployed as collaborative 
combination
 > > of multiple domain LISP SHDHTs. Deployment of collaborative domain 
LISP 
 > > SHDHTs
 > > is for future study, as well as the security strategies on/between 
 > > domain LISP
 > > SHDHTs."
 > 
 > Better.
 > 
 > > If the domain LISP SHDHT is maintained by an operator, I don't think 
the 
 > > two
 > > kinds problems are serious. If you still think they are important, 
would 
 > > you
 > > please show me the particular scenarios? Thank you very much.
 > 
 > Imagine a rogue ETR which wants to hijack traffic of another ETR, e.g.,
 > for fishing purposes or censorship. How do you prevent rogue ETRs from
 > registering false mappings in SHDHT? Do you plan to use digital
 > signatures/LISP-SEC features in SHDHT?
 
 Yes, I think use digital signatures/LISP-SEC features is a good idea for.
 
 > 
 > >  > 7. Reference I-D.mathy-lisp-dht should be replaced with the 
following:
 > >  >         L. Mathy and L. Iannone, “LISP-DHT: Towards a DHT to Map
 > >  >         Identifiers onto Locators,” in Re-Architecting the 
Internet
 > >  >         (ReArch), Madrid, Spain, Dec. 2008.
 > >  >     You can obtain a copy here: 
 > > http://dl.acm.org/citation.cfm?id=1544073
 > > 
 > > Thank you.
 > 
 > You did not replace the reference I-D.mathy-lisp-dht! As far as I know,
 > the ID has been removed from the official IETF page because the draft's
 > information has been published as paper. Please change the reference to
 > the above mentioned reference!
 
 Well, I misunderstood last time. I will modify it.
 
 > 
 > I look forward to receiving your reply.
 > 
 > Regards,
 > Michael
 > 
 > -- 
 > Dipl.-Inform. Michael Hoefling, M.Sc.
 > University of Tuebingen
 > Faculty of Science
 > Department of Computer Science
 > Chair of Communication Networks
 > Sand 13, 72076 Tuebingen, Germany
 > phone: [phone], fax: [phone]
 > mailto: [e-mail]
 > http://kn.inf.uni-tuebingen.de/staff/hoefling
 > 



--------------------------------------------------------
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.