Telechat Review of draft-ietf-anima-stable-connectivity-07
review-ietf-anima-stable-connectivity-07-tsvart-telechat-nishida-2018-01-09-00

Request Review of draft-ietf-anima-stable-connectivity
Requested rev. no specific revision (document currently at 10)
Type Telechat Review
Team Transport Area Review Team (tsvart)
Deadline 2018-01-10
Requested 2018-01-05
Requested by Mirja Kühlewind
Other Reviews Secdir Last Call review of -07 by Magnus Nystrom (diff)
Iotdir Last Call review of -07 by Francesca Palombini (diff)
Genart Last Call review of -07 by Matthew Miller (diff)
Opsdir Last Call review of -07 by Carlos Martínez (diff)
Comments
This document talks about MPTCP as part of the proposed solution, therefore I would like anothe review from an MPTCP expert. I guess there is only Yoshi in the ART but we could proably also ask Alan Ford or Christoph Paasch to help out for this doc...? Btw. we really should consider to add another MPTCP expert to the ART.
Review State Completed
Reviewer Yoshifumi Nishida
Review review-ietf-anima-stable-connectivity-07-tsvart-telechat-nishida-2018-01-09
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/3jnMtVCVLWe15_FiUDmtGTrirmY
Reviewed rev. 07 (document currently at 10)
Review result Almost Ready
Draft last updated 2018-01-09
Review completed: 2018-01-09

Review
review-ietf-anima-stable-connectivity-07-tsvart-telechat-nishida-2018-01-09

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