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 <v6...@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<cur...@occnc.com> wrote: >> >>> In message<08880dcf-fec8-4b52-8db4-0300ac1ec...@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-dra...@ietf.org"<internet-dra...@ietf.org> >>>>> Subject: I-D Action: draft-haddad-homenet-multihomed-00.txt >>>>> Date: September 25, 2012 10:55:38 AM PDT >>>>> To: "i-d-annou...@ietf.org"<i-d-annou...@ietf.org> >>>>> Reply-To: "internet-dra...@ietf.org"<internet-dra...@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 > _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet