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 <[email protected]> > Subject: Re: Some LISP proposals > Date: September 23, 2015 at 2:53:43 PM PDT > To: [email protected] > Cc: JACQUENET Christian IMT/OLN <[email protected]>, Dino > Farinacci <[email protected]> > >> 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 > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
