Subject: [Tsv-art] TSV-ART telechat review of draft-ietf-anima-stable-connectivity

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 9 Jan 2018 17:37:16 -0800

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

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 17 Jan 2018 03:37:29 +0100

Mirja, Yoshifumi

I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt

I have reworked the MPTCP text based on your threads feedback with
the intention to fix errors and have it answer the questions/concerns raised,
but without otherwise changing the scope of it:

- What are they key features making MPTCP interesting
- How could it be used to solve the stable-connectivity issue
- Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK
  beyond the scope of this document
- Describe the areas of specification work required
  - API/policy, control by apps
  - dealing with dual VRF addresses

Please check diff in this URL (not complete diff of -08, just fix for your discuss/comment):

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74ad152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt

I hope this resolves your DISCUSS/comments.

Note that the term ACP was changed in the doc to GACP based on resolving Alvaros discus. See:

https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/08-01-alvaro-retana.txt

Thank you
    Toerless

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 22 Jan 2018 00:34:59 -0800

Hi Toerless,

Thanks for the updates. It looks better to me.
Just one very minor comment..

   "GACP and data-plane addresses exist in different VRFs.  The MPTCP
   stack needs to be able to access multiple VRFs and know which local
   address is existing in which VRF.  There also needs to be a logic to
   determine which peer address is expected to be reachable via which
   local VRF/address.  Because the GACP is an isolated network, data-
   plane addresses are not reachable via the GACP therefore devices can
   determine if a peer address is a data-plane address."

I personally think the logic to determine which peer is expected to be
reachable
doesn't need to be in MPTCP stack. Or, if a MPTCP stack tries all possible
combinations
of address pairs to establish subflows, we might not need to have such a
logic. It may be
redundant, though.

Thanks,
--
Yoshi

On Tue, Jan 16, 2018 at 6:37 PM, Toerless Eckert <[email-masked]> wrote:

> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=
> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/
> 14d5f9b66b8318bc160cee74ad152c0b926b4042/draft-ietf-anima-
> stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt&url2=
> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/
> c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf-anima-
> stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt
>
> https://raw.githubusercontent.com/anima-wg/autonomic-
> control-plane/master/draft-ietf-anima-stable-connectivity/08-01-alvaro-
> retana.txt
>
> Thank you
>     Toerless
>
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 22 Jan 2018 13:25:57 +0100

Hi Toerless,

I agree with Yoshi here. I guess a quick fix is the following:

s/The MPTCP stack/The endpoint/ 

I have one more comment that I will send in reply to your other mail.

Mirja

> Am 22.01.2018 um 09:34 schrieb Yoshifumi Nishida <[email-masked]>:
> 
> Hi Toerless,
> 
> I personally think the logic to determine which peer is expected to be reachable
> doesn't need to be in MPTCP stack. Or, if a MPTCP stack tries all possible combinations 
> of address pairs to establish subflows, we might not need to have such a logic. It may be 
> redundant, though.
> 
> Thanks,
> --
> Yoshi
> 
>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 22 Jan 2018 19:43:55 +0100

Ack. Fill fix after second comment from Mirja is resolved.

-- 
---
[email-masked]