Re: [lisp] Fwd: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt

[Alberto Rodriguez-Natal <[e-mail]>]

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