I think Mirja is right. The current text doesn't really make sense, but I think it's mainly an issue of English. However, the notion that MPTCP might spontaneously and silently decide to bypass ACP security by adding a data plane address pair is a major issue that requires a very large red flag. Possibly even a MUST NOT?
(Mirja suggested a policy framework above MPTCP. Is there any such framework defined? And in any case, do we want *autonomic* network management to be dependent on some external traditional policy mechanism? I don't think so.) Regards Brian On 06/01/2018 11:30, Michael Richardson wrote: > > Mirja Kühlewind <i...@kuehlewind.net> wrote: > > "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." > > Section 2.1.5 is discussion, it discusses ways in which the > anticipated low performance (compared to what the box might do with its > hardware accelerated forwarding). > > If we have an application that needs the bandwidth of the native hardware, > the connection can be initated over the ACP (that's what would be in DNS). > One presumes that an MPTCP layer could then enumerate the available IPs at > each end and then start off additional flows on the other destinations. > > The application would have to include application security, since it would > not be protected by the ACP. > > Perhaps MPTCP doesn't work this way. > > > However, I'm actually uncertain how this is supposed to work and what > > "Unbeknownst to the application" should mean. If another address should > be > > signaled to the other host, this needs to be indicated by the > application or at > > least some kind of policy framework above MPTCP. Also MPTCP will by > default use > > both paths simultaneously while still looking like one connection to the > > application, meaning the application has no control which path is used > for > > which traffic. I guess you can open a second subflow and then configure > the > > first subflow as backup path but I'm not sure if that's what you want > (given > > the application/policy framework will still not know which path is > used)..? > > Please provide more information about what the expected usage scenario > is here. > > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
