On Thu, Feb 01, 2018 at 12:14:54PM -0600, Spencer Dawkins at IETF wrote:
> This is Mirja's Discuss thread, and MPTCP is her working group, and she
> knows MPTCP better than I do, but I'm confused about one thing, as I'm
> reading this discussion ...
>
[...]
> If I'm understanding the discussion, the desire is to use MPTCP to handle
> failover to another pre-established flow quickly, and Mirja's point is that
> normal MPTCP would just use both flows - so, not actually failing over, but
> if you provision for each flow to carry all your traffic, which you would
> have to do in order to handle failover anyway, I'm not sure why it's bad to
> let MPTCP do what it would do normally, and load-share across
> overprovisioned paths.
I have not seen Mirja rejecting the statement of the draft that we
can make one path a backup (not written out in the draft: via MPTCP MP_PRIO).
> Is that the discussion people think they're having?
I think Mirja is trying to do due diligence that the problem can not be
solved with just TCP, and i may not have been doing textually a good enough
job highlighting how the need of an MPTCP like signaling for additional
addresses (data-plane addresses) is necessary when you only have the
GACP address in DNS but actually prefer to use the data-plane (see -09
draft version, MPTCP options 1), 2)).
Cheers
Toerless
> Thanks,
>
> Spencer, the irresponsible AD, in this case ...
>
>
> > > If all data-plane flows fail, then it might suspend
> > > traffic.
> >
> > That will not happen with MPTCP; it will fail back to use the ACP
> > connection (if there is a subflow for it).
> >
> > >
> > > I think that there is some advantage to starting the connection on the
> > ACP,
> > > because:
> > > a) no TCP SYN listener on the data-plane interface(s) reduces attack
> > > surface (assuming NOC->router initialized connections, but the same
> > > argument applies to keeping the NOC devices isolated)
> >
> > Also with MPTCP you need a TCP SYN lister on the remote data-plane
> > interface because creating a MPTCP subflow means sending a TCP SYN with an
> > MPTCP option.
> >
> >
> > >
> > > b) the IP addresses of the router on the data-plane might be hard to
> > know
> > > in advance, being subject to routing algorithms and address
> > assignment
> > > ASAs. Also some interfaces might exist only with LL addresses until
> > the
> > > need to grow a GUA occurs.
> > >
> > > The ACP addresses are essentially locked down by being embedded in
> > > certificate DNs. (see the ACP draft). That also means that a TLS
> > > connection to the router will be validatable by the router's domain
> > > certificate, while the (stable? temporary?) address assigned on the
> > dataplane
> > > interfaces will not.
> >
> > What I???m basically proposing is that you use MPTCP for case 1 (data that
> > needs a fallback to the ACP connection) but for all other transmission
> > (that should be done only over one of the paths, either data plane or ACP),
> > you have additional plain TCP connections to use. You can still add an
> > interface to MPTCP to extract the IP address information you need to start
> > these additional connections.
> >
> > Mirja
> >
> > >
> > > So that's what MPTCP gets us: the ability to start on the ACP, do
> > security,
> > > and then move the bulk traffic to another place.
> >
> > >
> > > --
> > > ] Never tell me the odds! | ipv6 mesh
> > networks [
> > > ] Michael Richardson, Sandelman Software Works | network
> > architect [
> > > ] [email protected] http://www.sandelman.ca/ | ruby on
> > rails [
> > >
> >
> >
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
