On Thu, Feb 01, 2018 at 12:46:14PM -0600, Spencer Dawkins at IETF wrote:
> I do see the due diligence (she's a diligent AD), but I thought Mirja was
> (also?) concerned that the draft was assuming that MPTCP could be made to
> handle two paths in failover mode, when it actually doesn't work that way.
I am not sure if/what would be missing in MP_TCP wrt. to the failover itself,
thats what signaling of addresses and and MP_PRIO are about, right ?
But the draft itself is an informational use-case validation draft, and
the notions about MP-TCP should be understood as requirements. If somethiing
is missing in MPTCP or enabllin shim-libraries on top of it, then this should
come through standards specs. draft alread says:
"Making this idea work requires additional specification work outside
the scope of this document. "
So i hope the due diligence is mostly around whethere there is something
fundamentally
wrong as opposed to try to go further down into the potentially necessary
additional
specification elements (which i think are mostly about policies for MPTCP
and/or abstract APIs).
Cheers
Toerless
> But I'll let you two keep typing :-)
>
> Spencer
>
>
> > 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
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
