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

Hi All,
  I support Ray position.
  Maybe this drafts solves some situation but I believe it might bring
more problems than solutions.

regards,

Alejandro,

On 10/3/12, Ray Hunter <v6ops@globis.net> wrote:
> I have read the draft and don't see how it advances Homenet.
>
> IMHO If an MSP wants to deploy some tunnel brokers on the Internet to
> terminate what boils down to a pair of GRE tunnels, they can do so
> without the IETF providing any new standards work, and it'll all work
> just fine.
>
> I'd prefer it if people concentrated on
> http://www.ietf.org/id/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt
>
> regards,
> RayH
>
> Damien Saucez wrote:
>> Curtis,
>>
>> Thank you for the comments.
>>
>> Our target in this document is to raise the question of multihoming
>> in personal and/or small/medium enterprise networks, so for now
>> we were not looking at the mobile device such as smartphones
>> connected to both 4g and wifi (for this, the multihoming solution
>> must be implemented directly on the device). We believe that
>> SOHO would be interested being multihomed but can't afford the
>> cost of operating multihoming themselves. This is why we suggest
>> the MSP which is a way to outsource multihoming complexity.
>>
>> Now, let's go to the technical part. We didn't want to provide
>> solution so far but we had in mind the following:
>>
>> 1. traffic is tunnelled between the network and the MSP.
>>
>> 2. addresses assigned to devices in the network belong to
>> the MSP (or at least are advertised by the MSP in BGP) and
>> then they never change.
>>
>> 3. the MSP box has one "wire" (possibly vie wifi or 3/4G) per
>> ISP to which the network is connected and each NIC connected
>> to this "wire" receives addresses dynamically.
>>
>> Putting these three points together, it means that the gw are
>> invisible to the devices in the network, that addresses of devices
>> never change during communications and that traffic always go
>> through the MSP (even though it is possible to avoid this).
>>
>> I agree that there is no such thing as the MSP so far, but there
>> is a bunch of very big service providers that exist today, that are
>> peering with virtually every significant network and that would
>> certainly be happy to be the "first hop" for all the communications.
>>
>>
>> Thank you,
>>
>> Damien Saucez
>>
>> On 01 Oct 2012, at 03:21, Curtis Villamizar<curtis@occnc.com>  wrote:
>>
>>> In message<08880DCF-FEC8-4B52-8DB4-0300AC1EC811@ericsson.com>
>>> Wassim Haddad writes:
>>>
>>>> Dear all,
>>>>
>>>> We have submitted a problem statement for multihoming in homenet.
>>>> Comments appreciated!
>>>>
>>>> Regards,
>>>>
>>>> Wassim H.
>>> 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
>>>
>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "internet-drafts@ietf.org"<internet-drafts@ietf.org>
>>>>> Subject: I-D Action: draft-haddad-homenet-multihomed-00.txt
>>>>> Date: September 25, 2012 10:55:38 AM PDT
>>>>> To: "i-d-announce@ietf.org"<i-d-announce@ietf.org>
>>>>> Reply-To: "internet-drafts@ietf.org"<internet-drafts@ietf.org>
>>>>>
>>>>>
>>>>> 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
>>> _______________________________________________
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>
>>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>