Re: [lisp] An Incremental Deployable Mapping Service Draft

["Dong HUO" <[e-mail]>]

Hello John,

I'm one of the authors of this draft. Thx for your reply and sorry for the unclarities in some parts.
Modifications would be done soon.

Feedbacks go as follows:

2009-07-09 



Dong HUO



发件人： John Zwiebel 
发送时间： 2009-07-08  04:10:36 
收件人： Chen Gang 
抄送： [e-mail] 
主题： Re: [lisp] An Incremental Deployable Mapping Service Draft 


On Jul 6, 2009, at 5:39 AM, Chen Gang wrote:


Hello all,




Your introduction talks of sending the data packet as the query, 
this is a lisp data probe.  See 4.2 of draft-fuller-lisp-alt

[Dong]: Yes true, I need to add a reference here.


This line:


   o  to eliminate the forwarding entries, targeted to distant customer
      ASes not behind the border routers, in the border routers;


doesn't make sense.  I don't want to have to read the whole document to understand
what it means.  This is the intro and needs to be clear.


There is no explanation of what Kademlia DHT (until you get to section 7)
is nor any reference for it. Yes one can find them in wikipedia.  Is that the 
reference you want us to use?

[Dong]: Sorry about the unclarity in Introduction and the *Kademlia DHT*, we will improve it later.

FWIW: current LISP development is moving forward with ALT, ALT does not 
have any forwarding entries in the P routers.  They are in the ALT.
Point being, your EID-router sounds like an ALT router except that rather than
storing a way to get the RLOC mapping (as when the ALT gets mapping from
the ETR) you store the complete mapping in the distributed hash.  


When sending traffic along the default route to the ER, how do you differentiate
between an EID and an RLOC?  

[Dong]: RLOCs entries are in P routers, as well as the EID-RLOC aggregated prefixes. 
 The default route covers the rest (EID aggregated prefixes).


It isn't clear which system returns the answer to a mapping query.

[Dong]: The DHT Mapping Overaly returns it to the ITR.


Section 5 is about BGP, It isn't clear if the EIDs are carried in the same
BGP instance as the RLOCs.  If it is a separate instance, this is very similar to the ALT.

[Dong]: in the same BGP instance.


Is a MN just a data structure?  How can a data structure initiate a mapping query?
It would be clearer (for me at lease) if you explained how control packets are sent between the MS
and the ER to create the mapping-node structure.  I'm not sure I understand this point.

[Dong]: a MN can be implemented as a process in a MS, so it has a data structure
to store the mapping and has the ability to initiate a mapping query.

ER and the DHT Mapping Overlay can be seen as two independent parts. 
Without the DHT MO, ER can also work well, however the DHT MO provides 
more-specific mappings to decrease the number of tunnels along the path.
They share the same way (simillar to ALT) to obtain the original EID-RLOC 
mappings from ETRs.


FWIW: the ALT can also be deployed incrementally.  I do not see how deploying
a MO-MS isn't a "imperative third-party infrastructure".  


I also have to question this line, which other mechanisms?
    Note that unlike other mechanisms, no new particular devices are
   required to support backward-compatibility.

[Dong]: MO is just a supplementary way to help improve the performance, not compulsory. 
  Only deploying an ER in an AS can bring benefits.

  About the *new particular devices*, I mean the *LISP Proxy Tunnel Router (PTR)*
  in "draft-lewis-lisp-interworking-02"
  Perhaps I should say *new particular function* rather than *device*



In para 6.3 The first 3 possible destinations of the LISP packet seem to require decap 
and re-encap of packets until they finally get to the ETR.  As far as I can tell, this happens
with all packets sent between EIDs.  Doesn't this severely limit the the usefulness of your
proposal?  Doesn't this require special hardware at each of these points to decap/encap?

[Dong]: Yes true, so the DHT MO can help reduce them after the ITR gets the cache from the MO.
But before that, it has this limitation.

It would be nice to see the control packet formats you plan on using with this proposal.
I would find it very helpful in understanding what you are proposing.

[Dong]: Really appreciate your comments. I would say that our goal is not to compete with ALT.
Instead, we want to see how we could help improve the LISP from another angle.
So let's see whether there will gonna be help. :-)


 
Thanks!
Best Regards!

Dong HUO