Re: [lisp] Fwd: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt
Matthieu Coudron <matthieu.coudron@lip6.fr> Mon, 11 August 2014 15:51 UTC
Return-Path: <matthieu.coudron@lip6.fr>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7281A0652 for <lisp@ietfa.amsl.com>; Mon, 11 Aug 2014 08:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level:
X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3v3q-iqb_UIQ for <lisp@ietfa.amsl.com>; Mon, 11 Aug 2014 08:51:39 -0700 (PDT)
Received: from osiris.lip6.fr (osiris.lip6.fr [IPv6:2001:660:3302:283c::1e]) by ietfa.amsl.com (Postfix) with ESMTP id D763C1A050E for <lisp@ietf.org>; Mon, 11 Aug 2014 08:51:38 -0700 (PDT)
Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by osiris.lip6.fr (8.14.7/lip6) with ESMTP id s7BFpYDp005316 for <lisp@ietf.org>; Mon, 11 Aug 2014 17:51:35 +0200 (CEST)
X-pt: osiris.lip6.fr
Received: from [192.168.1.184] (AFontenayssB-152-1-52-220.w82-121.abo.wanadoo.fr [82.121.226.220]) (authenticated bits=0) by tibre.lip6.fr (8.14.7/8.13.3) with ESMTP id s7BFoHTv021415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 11 Aug 2014 17:50:18 +0200 (MEST)
Message-ID: <53E8E639.20701@lip6.fr>
Date: Mon, 11 Aug 2014 17:50:17 +0200
From: Matthieu Coudron <matthieu.coudron@lip6.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: lisp@ietf.org
References: <20140704130144.20502.78491.idtracker@ietfa.amsl.com> <CA+YHcKEb_-KmbKBxaa6xW7nfUXBvPM7Afs5+WL83w-fzAtKtqA@mail.gmail.com> <CADHp1NwM6S2Y+UJChud+D=Zir2GkK6rTbapV3mK6f+MaM9u=0Q@mail.gmail.com>
In-Reply-To: <CADHp1NwM6S2Y+UJChud+D=Zir2GkK6rTbapV3mK6f+MaM9u=0Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (osiris.lip6.fr [132.227.60.30]); Mon, 11 Aug 2014 17:51:35 +0200 (CEST)
X-Scanned-By: MIMEDefang 2.74 on 132.227.60.30
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/W-Iph0l89xbYf89f12cgteJ7S7o
Cc: Stefano Secci <stefano.secci@lip6.fr>
Subject: Re: [lisp] Fwd: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Aug 2014 15:51:41 -0000
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 <arnatal@ac.upc.edu> > Date: 2014-07-04 15:16 GMT+02:00 > Subject: [lisp] Fwd: New Version Notification for > draft-rodrigueznatal-lisp-oam-00.txt > To: "lisp@ietf.org list" <lisp@ietf.org> > > > 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: <internet-drafts@ietf.org> > Date: Fri, Jul 4, 2014 at 10:01 PM > Subject: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt > To: Albert Cabellos-Aparicio <acabello@ac.upc.edu>, Marc > Portoles-Comeras <mportole@cisco.com>, Alberto Rodriguez-Natal > <arnatal@ac.upc.edu>, Michael Kowal <mikowal@cisco.com>, Darrel Lewis > <darlewis@cisco.com>, Fabio Maino <fmaino@cisco.com> > > > > 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 > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp
- [lisp] Fwd: New Version Notification for draft-ro… Alberto Rodriguez-Natal
- Re: [lisp] Fwd: New Version Notification for draf… Matthieu Coudron
- Re: [lisp] Fwd: New Version Notification for draf… Alberto Rodriguez-Natal
- Re: [lisp] Fwd: New Version Notification for draf… Matthieu Coudron
- Re: [lisp] Fwd: New Version Notification for draf… Alberto Rodriguez-Natal