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 <nish...@sfc.wide.ad.jp>: > > 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 <t...@cs.fau.de> wrote: > 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 > > On Tue, Jan 09, 2018 at 05:37:16PM -0800, Yoshifumi Nishida wrote: > > 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 > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ > Tsv-art mailing list > tsv-...@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > > _______________________________________________ > Tsv-art mailing list > tsv-...@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
