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

[Michael Hoefling <[e-mail]>]

Hello Li,

Am 27.07.2012 05:00, schrieb [e-mail]:
> 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.

If this is so then Map-Register messages with P-bit set are mandatory 
for SHDHT to work properly in the current status of the draft, right?

>  > Am 16.07.2012 11:43, schrieb [e-mail]:
>  > > Michael Hoefling <[e-mail]> 写于
> 2012-07-12
>  > > 22:32:36:
>  > >  > 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.

OK, I forgot the 0.5 while writing the mail. It would be good to include 
this in the draft.

What happens in SHDHT if only a partition of the entire EID space is 
managed using SHDHT, i.e., there exist larger gaps between Partition 
IDs? I guess this was my initial intention to ask how the size of hash 
space segments are determined in SHDHT.

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