Subject: RTGWG WGLC draft-ietf-rtgwg-enterprise-pa-multihoming

From: Jeff Tantsura <[email-masked]>
Date: Mon, 16 Apr 2018 13:53:55 -0700

Dear 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. 

Please indicate support or no-support by April 30, 2018.

IPR:

If you are listed as a document author or contributor and haven’t responded to the IPR call, please respond to this

email of whether or not you are aware of any relevant IPR.

The response needs to be sent to the RTGWG mailing list.

The document will not advance to the next stage until a response has been

received from each author and each individual that has contributed to the document.

Cheers,

Jeff and Chris

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 17 Apr 2018 09:23:25 +0200

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Apr 2018 09:39:16 +0200

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-masked]> wrote:

> 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.
>
> draft lists [I-D.ietf-mptcp-experience] in its references but does not cite
> it in the text)
> transport and write another document that describes how multipath transport
> protocols can be used to solve the problems listed in this document
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Apr 2018 06:29:24 +1000

> protocols can be used to solve the problems listed in this document

+1

I've been thinking the same thing about this related draft:

"Using Conditional Router Advertisements for Enterprise Multihoming"
https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-01

Regards,
Makr.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 26 Apr 2018 13:15:39 +1000

(back from vacation finally, sorry for the delayed response)

Robert, Olivier,

First of all, thank you for the comments.

>               mptcp-experience-07 (work in progress), October 2016.

Noted, will be fixed.

> On Tue, Apr 17, 2018 at 9:23 AM, Olivier Bonaventure<[email-masked]> wrote:
>> solution to the multihoming problem : using multipath transport.

Let me clarify why Section4 discusses SLAAC/DHCP/ICMP instead of
multipath transport.
I totally agree that if all hosts were using path-aware transports
only, it would have solved the problem discussed in the Section 4 of
the draft.
However it means that enterprises can not have IPv6 multihoming until
almost all their traffic is over those path-aware transport protocols
and I have some concerns re: when it's going to happen.

Point taken, the document should mention multipath transport and
explain why we are looking for lower-level solution.

-- 
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Thu, 26 Apr 2018 13:19:45 +1000

> https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-01

Oh, I'm not sure it's the right WG to discuss that draft but as you've
mentioned it, I'd like to clarify:

https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-03
explicitly states that it describes the tactical solution, which can
be deployed *right now* in enterprise environments, where vast
majority of devices do not even support rule 5.5 of default address
selection, not mentioning having multipath transports enabled.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 26 Apr 2018 03:28:26 +0000

Hi Jen,

Many thx for reply.

One nit however which needs to be stated here is that there are neat
solutions in the market today which do not require any upgrade to hosts to
use multipath tcp between sites.

That's what your draft should discuss to make it very practical and
pragmatic for interesed enterprises.

Many thx,
Robert.

---

From: Olivier Bonaventure <[email-masked]>
Date: Sun, 29 Apr 2018 11:36:35 +0200

Jen,

> explain why we are looking for lower-level solution.

I think that it is worth to document what can be done today with single 
path transport and what will become possible with multipath transport. 
Multipath transport makes the multihoming problem much simpler from a 
network viewpoint. With Multipath TCP and soon Multipath QUIC, we cannot 
ignore the benefits that multipath will bring.

I'm ready to contribute text about multipath or propose a separate 
document if you believe that it would be better to document today's 
(single path) approach in one document and a longer term (multipath) in 
a separate document.

Olivier

---

From: Jen Linkova <[email-masked]>
Date: Mon, 30 Apr 2018 12:51:58 +1000

On Sun, Apr 29, 2018 at 7:36 PM, Olivier Bonaventure
<[email-masked]> wrote:
> I think that it is worth to document what can be done today with single path
> transport and what will become possible with multipath transport. Multipath
> transport makes the multihoming problem much simpler from a network
> viewpoint. With Multipath TCP and soon Multipath QUIC, we cannot ignore the
> benefits that multipath will bring.
>
> I'm ready to contribute text about multipath or propose a separate document
> if you believe that it would be better to document today's (single path)
> approach in one document and a longer term (multipath) in a separate
> document.

Thanks a lot Olivier!
I'm thinking of updating the document with a section which would clarify that:
- multipath transport makes multihoming easier and solves a number of
multihoming netwroks have problem;
- in particular, multihomed enterprise network would still need a
solution described in the Section 3 but if all hosts in such a network
are using
multipath transport, we might not even need a network to signal
topology changes with RAs;
- however as there are significant number of hosts which do not use
mulipath transport and they are not completely disappearing in any
foreseeable future, the solution
needs to take those hosts into account and therefore this document
discusses how to make multihoming work for the least common
denominator. Multupath transport (if/when hosts in the network start
using it) would complement  the solution described in the Section4.

Would it address your concern?

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Apr 2018 10:59:59 +0200

Hi Jen,

> using it) would complement  the solution described in the Section4.

​Why are you keep ignoring option to use MP-TCP proxy as described in
number of IETF work and few commercial products ? With use of proxies hosts
on one end or both ends of TCP connection do not need to be upgraded.

Smart router (CE) vendors can build it into their OSes too waiting for
hosts vendors to catch up.

Example:

https://www.ietf.org/proceedings/85/slides/slides-85-mptcp-0.pdf

Thx,
Robert​

---

From: Jen Linkova <[email-masked]>
Date: Tue, 1 May 2018 16:44:17 +1000

On Mon, Apr 30, 2018 at 6:59 PM, Robert Raszuk <[email-masked]> wrote:
> Why are you keep ignoring option to use MP-TCP proxy as described in number
> of IETF work and few commercial products ? With use of proxies hosts on one
> end or both ends of TCP connection do not need to be upgraded.

MP-TCP proxy does not look like a solution for the following reasons:
1) MP-TCP proxy is not a silver bullet. What about UDP? More
specifically, what about UDP which is not QUIC? What about other
protocols?
2) Explicit signalling provided by the network is always better than
pure heuristic approach (if the network does not provide any
information about what addresses are available then
yes, transport has no options but use heuristic). It's a) faster b)
saves the network resources c) easier to troubleshoot.
3) as an operator I'd rather avoid having a middle box in the network
(for scalability among other reasons). Thanks, no. We might as well
just recommend NAT ;)

> Smart router (CE) vendors can build it into their OSes too waiting for hosts
> vendors to catch up.
>
> Example:
>

Thanks for the link. I need to spend more time reading this as I'm not
sure I fully understand how it's supposed to work in the scenario,
when the network has multiple CPEs, each one connected to different
ISPs.