Hi Brian, no there is no policy framework defined. There has be discussion about path selection in the working group but often it really depends on the application.
Mirja > Am 06.01.2018 um 01:21 schrieb Brian E Carpenter > <[email protected]>: > > 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 <[email protected]> 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 <[email protected]>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> _______________________________________________ >> Anima mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/anima >> > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
