Dear all,
we reviewed the draft and following offline discussions with Albert, you
will find below a few comments.
Best regards,
Matthieu Coudron
Stefano Secci
____________________________
2. Underlay definition
"The underlay corresponds to the RLOC space"
This appears as too restrictive, as information about the underlay could
come also from local AS/domain-level information such as traffic
engineering databases, monitoring tools, etc, unaware of LISP.
____________________________
3.2 MPTCP
"Each of these sub-flows behaves as a legacy TCP flow and hence, from
the network point of view, each sub-flow is a different TCP session. The
network conditions over the different paths the sub-flows follow affect
the whole MPTCP session. Since MPTCP has to keep the aggregate session
consistent, each aggregated flow can perform as good as the worst of the
sub flows it integrates."
This paragraph seems incorrect. MPTCP RFC 6182 section 2.1 states that
MPTCP should be at least as good as TCP, which in practice is true
except in a few cases (e.g., if a subflow with a large share of the
window becomes inactive, then you need to wait several timeouts before
being able to be aggressive enough on other subflows). The RFC does not
precisely address the scheduling mechanisms, but if for instance you
consider the Linux implementation (http://www.multipath-tcp.org), it
sends a maximum amount of data on the subflow with the lowest RTT and
once its window is full, it will send on the 2nd lowest RTT subflow
etc... so providing there is enough buffering at each endpoint, in terms
of sheer throughput MPTCP should be able to aggregate all the subflows
independently of their latency. It is true though that if packets are
not scheduled carefully on each subflow, then application latency may
increase.
At LIP6, we already run LISP+MPTCP coupling experimentations (LISP
providing topology informations and forwarding capabilities to the MPTCP
layer), we documented last year in this article “Cross-layer Cooperation
to Boost Multipath TCP Performance in Cloud Networks” available at:
http://www-phare.lip6.fr/~secci/papers/CoSePuRaGa-CLOUDNET13.pdf . In
our experiment, RTTs of the different paths were close to each other,
which lead to very good performance, as the lower the RTT gap the better
MPTCP performance. See here another interesting article about this
matter: "How hard can it be? Designing and Implementing a Deployable
MPTCP" available at
https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf
____________________________
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?
____________________________
4. Requirements / Forwarding Actions
"These actions can be implemented as extensions to the current
specifications of LISP-TE or LISP-SR or be defined by means of a new LCAF."
Here it would be better not to exclude existing LCAF. For the MPTCP
use-case, we have a prototype using already proposed LCAF messages.
____________________________
7. Security Considerations
"When including capabilities to allow for the discovery of devices and
its capabilities, as well as the collection of metrics regarding the
underlay and the local device itself, it should be taken into
consideration that proper controls are put in place to enforce strict
policies as to which devices can access what type(s) of information."
Do you have any protocol in mind to get metrics from the overlay to the
underlay?
Relevant nodes should be chosen carefully so that they are not malicious
or misfunctioning. For instance the TCP RTT seen by a VM is higher than
one seen by a physical machine due to the hypervisor scheduling latency.
On 11/08/2014 16:46, Matthieu Coudron wrote:
---------- Forwarded message ----------
From: Alberto Rodriguez-Natal <[email protected]>
Date: 2014-07-04 15:16 GMT+02:00
Subject: [lisp] Fwd: New Version Notification for
draft-rodrigueznatal-lisp-oam-00.txt
To: "[email protected] list" <[email protected]>
Dear all,
We have just submitted a new draft discussing OAM (Operations
Administration Management) use-cases and requirements for LISP.
Please, feel free to review it and provide feedback.
Thanks,
Alberto
---------- Forwarded message ----------
From: <[email protected]>
Date: Fri, Jul 4, 2014 at 10:01 PM
Subject: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt
To: Albert Cabellos-Aparicio <[email protected]>, Marc
Portoles-Comeras <[email protected]>, Alberto Rodriguez-Natal
<[email protected]>, Michael Kowal <[email protected]>, Darrel Lewis
<[email protected]>, Fabio Maino <[email protected]>
A new version of I-D, draft-rodrigueznatal-lisp-oam-00.txt
has been successfully submitted by Alberto Rodriguez-Natal and posted to the
IETF repository.
Name: draft-rodrigueznatal-lisp-oam
Revision: 00
Title: LISP-OAM (Operations Administration Management): Use
cases and requirements
Document date: 2014-07-04
Group: Individual Submission
Pages: 13
URL:
http://www.ietf.org/internet-drafts/draft-rodrigueznatal-lisp-oam-00.txt
Status: https://datatracker.ietf.org/doc/draft-rodrigueznatal-lisp-oam/
Htmlized: http://tools.ietf.org/html/draft-rodrigueznatal-lisp-oam-00
Abstract:
This document describes Operations Administration and Management
(OAM) use-cases and the requirements that they have towards the LISP
architecture.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
