[Tsv-art] TSV-ART telechat review of draft-ietf-anima-stable-connectivity
Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Wed, 10 January 2018 01:37 UTC
Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6FD12711D; Tue, 9 Jan 2018 17:37:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 WJ_Q6DhUmRJ6; Tue, 9 Jan 2018 17:37:23 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9F26124C27; Tue, 9 Jan 2018 17:37:22 -0800 (PST)
Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2EE062782B3; Wed, 10 Jan 2018 10:37:19 +0900 (JST)
Received: by mail-wm0-f48.google.com with SMTP id f140so23982255wmd.2; Tue, 09 Jan 2018 17:37:19 -0800 (PST)
X-Gm-Message-State: AKGB3mIRue/1hCncHpPbRPPC87geHo75YzeYqqifJXHheAAdhS2YvfsX Z47/156RiMOGzlZqVI7B53LLn0YqhveYePWA3vI=
X-Google-Smtp-Source: ACJfBou5LIsoA5jVL18fVOYNKBGkJhCgGfan3FzOCAKu0Te2ohvZDqgmgHAYmnji5+74Tn8YYZ3mouGgkgNuWltNWeI=
X-Received: by 10.28.50.67 with SMTP id y64mr13363201wmy.145.1515548237128; Tue, 09 Jan 2018 17:37:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.147.199 with HTTP; Tue, 9 Jan 2018 17:37:16 -0800 (PST)
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Tue, 09 Jan 2018 17:37:16 -0800
X-Gmail-Original-Message-ID: <CAO249ycJSfNrAg1QwajptZhxru2-g7ToQNXFq6er6ucehqXBXw@mail.gmail.com>
Message-ID: <CAO249ycJSfNrAg1QwajptZhxru2-g7ToQNXFq6er6ucehqXBXw@mail.gmail.com>
To: dreft-ietf-anima-stable-connectivity@ietf.org, tsv-art@ietf.org, anima@ietf.org
Content-Type: multipart/alternative; boundary="001a11412d7450699805626212c5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/3jnMtVCVLWe15_FiUDmtGTrirmY>
Subject: [Tsv-art] TSV-ART telechat review of draft-ietf-anima-stable-connectivity
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jan 2018 01:37:26 -0000
I've reviewed this document as part of TSV-ART's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised.When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art @ietf.org if you reply to or forward this review. Summary: This document is almost ready for publication, but several points need to be clarified or updated. 1: In Section 2.1.5 " MPTCP (Multipath TCP -see [RFC6824]) is a very attractive candidate to automate the use of both data-plane and ACP and minimize or fully avoid the need for the above mentioned logical names to pre-set the desired connectivity (data-plane-only, ACP only, both). For example, a set-up for non MPTCP aware applications would be as follows: DNS naming is set up to provide the ACP IPv6 address of network devices. Unbeknownst to the application, MPTCP is used. MPTCP mutually discovers between the NOC and network device the data-plane address and caries all traffic across it when that MPTCP subflow across the data-plane can be built. " It's not very clear to me how to archive this feature. I think more explanation will be required. As MPTCP resides in transport layer, I think it will be very tricky to know which endpoint is used for ACP or for data-plane. Also, although MPTCP can transmit application data to multiple destinations, it cannot identify which part of data is for ACP or for data-plane as it doesn't parse app data. 2: in Section 2.1.8 " Leverage and as necessary enhance MPTCP with automatic dual- connectivity: If an MPTCP unaware application is using ACP connectivity, the policies used should add subflow(s) via the data-plane and prefer them. " I think functions like controlling policies should be designed outside of MPTCP such as middleware between applications and transport layer, but the text is unclear about how to enhance MPTCP. Thanks, -- Yoshi
- [Tsv-art] TSV-ART telechat review of draft-ietf-a… Yoshifumi Nishida
- Re: [Tsv-art] [Anima] TSV-ART telechat review of … Toerless Eckert
- Re: [Tsv-art] [Anima] TSV-ART telechat review of … Yoshifumi Nishida
- Re: [Tsv-art] [Anima] TSV-ART telechat review of … Mirja Kuehlewind (IETF)
- Re: [Tsv-art] [Anima] TSV-ART telechat review of … Toerless Eckert