Hi Jeff,
I very much agree with Olivier here.
Rather then patching legacy models it would be awesome for IETF to at least
leverage solutions which were already worked on and accepted in other WGs.
At minimum they should be discussed in new documents and analysis should be
provided why they do not meet the objective of new work.
We see this more and more in number of WGs that other work is being ignored
and new (not always better) solutions are progressing fwd.
Also please note that references in the draft need review and update.
Example: missing ref to RFC8041 .. draft is still listing:
[I-D.ietf-mptcp-experience]
Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and
Operational Experience with Multipath TCP", draft-ietf-
mptcp-experience-07 (work in progress), October 2016.
Best,
R.
On Tue, Apr 17, 2018 at 9:23 AM, Olivier Bonaventure <
[email protected]> wrote:
> Jeff, RTGWG,
>
>>
>> The authors have requested the RTGWG to last call
>> draft-ietf-rtgwg-enterprise-pa-multihoming.
>>
>> There was consensus that document is ready for the last call and the
>> authors have resolved all the comments received from the v6ops reivew.
>>
>
> The document discusses a range of solutions to enable legacy hosts to
> select the right source address to use to reach a given destination.
> However, I think that it complety ignores a very clean and efficient
> solution to the multihoming problem : using multipath transport. The IETF
> has already approved Multipath TCP in RFC6824. It is widely deployed on one
> popular brand of smartphones and the MPTCP working is progressing towards a
> standards-track version of MPTCP. In parallel, the charter of the QUIC
> working group includes multipath support and there is already an
> implementation which is available (see https://www.multipath-quic.org).
> Multipath RTP has already been discussed within the IETF as well.
>
> With Multipath transport, the entreprise pa multihoming problem can be
> solved in a much cleaner manner. A multipath transport has much more
> flexibility in a multihomed site than a single path transport protocol.
> With a multipath transport, it is possible to :
> - select a source address at the beginning of a connection and switch to
> another one during the lifetime of the connection without breaking it
> - use multiple source addresses for a given connection to achieve best
> performance (low delay, higher bandwidth by bonding, ...)
> - learn a new source address when a link comes up and use it during a
> connection
> - react to congestion on one uplink by switching traffic to the other
> uplinks
>
>
> I think that it would make sense to either :
> - discuss the impact of multipath transport in the current document (the
> draft lists [I-D.ietf-mptcp-experience] in its references but does not cite
> it in the text)
> - indicate that the current document is restricted to single path
> transport and write another document that describes how multipath transport
> protocols can be used to solve the problems listed in this document
>
> I'm happy to contribute if the WG decides to go in either of these
> directions.
>
> Best regards,
>
>
> Olivier Bonaventure
>
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
