Subject: [homenet] Fwd: I-D Action: draft-haddad-homenet-multihomed-00

From: Wassim Haddad <[email-masked]>
Date: Wed, 26 Sep 2012 10:26:27 -0700

Dear all,

We have submitted a problem statement for multihoming in homenet.
Comments appreciated!

Regards,

Wassim H.

Begin forwarded message:

> From: "[email-masked]" <[email-masked]>
> Subject: I-D Action: draft-haddad-homenet-multihomed-00.txt
> Date: September 25, 2012 10:55:38 AM PDT
> To: "[email-masked]" <[email-masked]>
> Reply-To: "[email-masked]" <[email-masked]>
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : Multihoming in Homenet
> 	Author(s)       : Wassim Haddad
>                          Damien Saucez
>                          Joel Halpern
> 	Filename        : draft-haddad-homenet-multihomed-00.txt
> 	Pages           : 7
> 	Date            : 2012-09-25
> 
> Abstract:
>   So far, multihoming in Homenet must be supported by the hosts as
>   there is no mean to use simultaneously the different Internet Service
>   Providers of the "Homenet" without risking flow disruption.  In this
>   memo, we describe the problem statement for multihoming in Homenet.
>   We also propose a high level solution that answers this particular
>   problem.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-haddad-homenet-multihomed
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-haddad-homenet-multihomed-00

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 30 Sep 2012 21:21:53 -0400

In message <[email-masked]>
 
> We have submitted a problem statement for multihoming in homenet.

Wassim,

You are proposing a solution, not submitting a problem statement.

A problem with your solution is that the most common multihoming is
the mobile device having IP access through both WiFi (via DSL or cable
or hotspot) and 4G mobile.  In this case the "MSP middlebox" you
propose would have to be inside the mobile device, which is already
both one of the gateways and the end host.

Another problem is the current non-existance of a Multihoming Service
Provider (MSP)" somewhere out "in the cloud" to replace the source
address of packets.

No where in your document does the principle issue with multihoming
get addressed.  The source address used by the host must be chosen
somehow by the host or replaced somewhere.  The function of the "MSP
middlebox" as described is only to redirect outgoing packets.  If the
source address reflect going through ISP2, and that link goes away,
then the packets can now go out through ISP1 but the problem of using
the wrong source address remains.

If the source address is somehow provided by the MSP, then the traffic
has to be tunnelled from MSP middlebox to MSP as might be implied by
the last paragraph in section 4 where it says "In addition, if Gw1 and
Gw2 provide addresses by the mean of DHCPv6 or RA, addresses at the
MSPMB will be configured automatically as well".  The word "address"
barely appears in the draft except for the prior statement and one in
the intro saying why Shim6 or MPTCP should not be used.  The word
"tunnel" doesn't appear at all.  The word "source" (as in "source
address") doesn't appear at all.

So you don't seem to be proposing a viable solution or perhaps you had
something to do with tunnelling in mind that you didn't describe at
all clearly.

Curtis