Hi Matthieu, Stefano, Thanks for your comments, see inline.
> [AR] I believe that we are on the same page here. The point that we > > tried to make here is that "on worst case scenario, MPTCP performs as > > good as TCP". Perhaps that was not stated clearly enough. Maybe we could > > keep this paragraph short (one sentence) and just point people to MPTCP > > RFC. Would that make sense? > Agreed with both points. The document should focus on how MPTCP can > benefit from LISP and there are several ways. The one you present is to > focus on maximally disjoint paths to support the best link backup scenario. > If increased throughput is the goal of the scenario, then maximally > disjoint paths may not be the best solution; the subflows could share some > links as long as this link is not a bottleneck for the connection. > An additional scenario could be to forward at least one subflow on a LISP > path that is considered secure, e.g., over it it would be harder for an > attacker to rebuild the stream of data. > > [AR] The MPTCP use-case presents several scenarios where LISP can be applied. We appreciate discussions like this one to identify and describe further scenarios. We appreciate as well ideas on more use-cases beyond MPTCP, multicast, NFV/SFC, etc. If you guys are aware of any other potential use-case that can benefit from a fine tuning of the LISP overlay please let us know. We'll try to cover more use-cases and scenarios on the next iteration of the draft ;) > ____________________________ > > 4. Requirements / Device Discovery > > "This is solved for xTRs by sending Map Register messages." > > > > Did you mean Map Requests? Or can you explain why only Map Register? > > > > [AR] We were talking here about the fact that in vanilla LISP the > > MappingSystem can be aware of existing xTRs since they keep sending > > MapRegisters. The MapRegister process works already as an automated > > discovery mechanism. We'll extend the sentence to clarify this. > > ok - it seems more appropriate to replace "xTRs" with "ETRs". [AR] Indeed, that's more precise. Thank you guys again for your contributions :) Alberto
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
