Re: [lisp] An Incremental Deployable Mapping Service Draft

[John Zwiebel <[e-mail]>]

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

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?

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?

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

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.

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.

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.


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?


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.

thanks