Re: [multipathtcp] Multipath TCP Address advertisement 5/5

Hi all,

After discussion at IETF97, I do not support this proposal. I can’t see any scenarios where this would actually be particularly useful.

Specifically, no end host really has enough knowledge to say their IPv4 and IPv6 addresses go over the same path, other than they share the same physical interface at an end host. Some ends may have a good idea, e.g. data centres.

But if you as a server know your IPv6 and IPv4 share a path, you may choose not to use one or the other. Same for the client. So under what circumstances does signalling this to the far end actually help?

Regards,
Alan

> On 6 Nov 2016, at 12:38, Fabien Duchêne <fabien.duchene@uclouvain.be> wrote:
> 
> Hello,
> 
> As we agreed in Berlin during IETF96, here are a few email to discuss
> the contributions proposed in
> https://datatracker.ietf.org/doc/draft-duchene-mptcp-add-addr/
> 
> To allow a host to inform the receiving host about the diversity of
> several addresses we propose to modify the ADD_ADDR to include 4 bits
> describing a "Community" associated to this address.
> The community values are an opaque field and it is expected that two
> addresses having the same community share some resources.
> 
> With the community bits, a dual-stack host could elect to regroup all
> the addresses attached to a single interface under the same community,
> allowing the receiving host to decide on which advertised addresses it
> wants to establish new subflows.
> This is because in the case of a dual-stack host, establishing v4 and V6
> subflows
> is not always the best solution.
> The idea here is to design a generic solution to regroup the address
> that shares
> the same forwarding type in a specific class.
> 
> Fabien
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp

Re: [multipathtcp] Multipath TCP Address advertisement 5/5 - Communities