[lisp] Fwd: Some LISP proposals

[Dino Farinacci <[e-mail]>]

Folks, I sent high-level comments to Christian and Mohamed about their series of new LISP drafts. I wanted them to have a first look before posting to the list. They have granted me permission to post the comments now.

A more detail commentary is pending.

Thanks,
Dino

> Begin forwarded message:
> 
> From: Dino Farinacci <[e-mail]>
> Subject: Re: Some LISP proposals
> Date: September 23, 2015 at 2:53:43 PM PDT
> To: [e-mail]
> Cc: JACQUENET Christian IMT/OLN <[e-mail]>, Dino Farinacci <[e-mail]>
> 
>> We submitted the following contributions:
> 
> Here are my brief comments. I want through all the documents and have comments about the problems you are trying to solve and how you are solving them. We had thought about of these issues and made some tough design choices early on to put LESS protocol machinery in rather than more. But with a pub/sub solution, most of you documented (as well as some implementation techniques) can solve most of these problems.
> 
> On other note, if you guys are interested to play with my lispers.net LISP implementation, we can test out some of these solutions I may (or will) have implemented.
> 
>> draft-boucadair-lisp-bulk-00 
>> LISP Mapping Bulk Retrieval
> 
> This can already be solved with Map-Requests. We don’t need a new message format. In fact, we have thought of adding a bit where you can request “all-more-specifics” of an EID-prefix you put into a Map-Request.
> 
> We can talk about this more.
> 
>> draft-boucadair-lisp-function-discovery-00 
>> LISP Mapping Service Functions Discovery using OSPF
>> draft-boucadair-lisp-idr-ms-discovery-00 
>> LISP Mapping Service Discovery at Large
>> draft-boucadair-lisp-ms-assisted-forwarding-00 
>> Mapping System-Assisted Forwarding for Inter-Domain LISP Deployments
> 
> Wanting to do what you propose in the above drafts is quite fine. But I think there are simpler ways to do it. Using anycast addresses for map-resolvers solves the Map-Request side. And as for the Map-Server side, you want to build redundancy in your network anyways. My implementation uses DNS names for these components, so you can get a level of indirection this way. Thereby, not littering the IGPs and BGP with this information that is not needed everywhere (but will have to be propagated and stored everywhere in an IGP).
> 
>> draft-boucadair-lisp-subscribe-01 
>> Improving Mapping Services in LISP Networks
> 
> There is a proposal not published yet that does this with Map-Requests and Map-Notify messages. I am about to do an implementation of it. I would welcome you to try it out. We need the pub/sub model to work for the VM-mobility use-case as well as signal-free multicast. So any mechanism that alrealy uses Map-Notify messages to solve its own use-case needs to have pub/sub work. So we can’t introduce new message types or else the other designs have to change a lot.
> 
>> draft-boucadair-lisp-itr-failure-00 
>> Improving ITR Resiliency in LISP Networks
> 
> Luigi and Damien tried to solve this problem and we folks at cisco discouraged them. Because it was complex as well as reloading the cache with old map-cache entries. We didn’t want to add overhead. I know it is important to you to not do packet drops but an implementation locally could checkpoint the map-cache and reload it when it comes up.
> 
> This gives you what you want with less protocol machinery.
> 
>> draft-boucadair-lisp-triggered-map-request-00 
>> Triggered LISP Map-Request for Inter-Domain LISP Deployments
> 
> So my implementation supports the “distinguished-name” AFI. So I can encode names in EID or RLOC records. So you might want to play with that.
> 
> We also had thought about “DNS snooping” to solve the first-packet-loss problem. But we considered snooping on the DNS reply so the EID could be looked up directly. But the return path of the DNS reply and the forward path of the packet, could take you to different ITRs. Same with your proposal. The DNS request could travel through ITR1, and when the SYN packet is sent by the source, it could travel to ITR2. That is if there were equal cost paths and hashing of the 5-tuple would take a different path. So the solution is not reliable, but can reduce, in some cases, packet loss. But this is an architecture layer violation and may not be worth the effort, since you’ll have dropped packets in any case.
> 
>> draft-boucadair-lisp-v6-compact-header-00 
>> A Compact LISP Encapsulation Scheme to Transport IPv4 Packets over an IPv6 Network
> 
> I think this is a fine idea, but you will lose the identity of the ITR doing the encapsulation. Meaning if a multi-home domain has more than one ITR, then you need 2 different locator prefixes to distinguish them. Since you use 64-bits for the locator, and as long as the PA addresses assigned to the site are not /64 allocations, you could be okay.
> 
> One of the big advantages of using encapsulation for locator/id split solutions is that you have 4 addresses to debug from when you are sniffing packets in the underlay. This is always why I preferred encapsulation versus translation mechanisms.
> 
>> Your comments, suggestions, and inputs are more than welcome.
>> 
>> Cheers,
>> Med
> 
> Thanks for doing this work. It is great work and you guys really thought it out well. I am here to help you, so let me know what I can do to possibly converge these ideas into fewer documents. Glad LISP is important to you.
> 
> I can give you detailed comments once we decide on how to take all the documents and make them cohesive for the problems that we need to solve with protocol changes.
> 
> I leave it up to you guys to decide if these comments should go to the list. I wanted you to see them first before going public.
> 
> Thanks again,
> Dino
> 
>