Re: [shim6] [homegate] Routing protocols
Iljitsch van Beijnum <iljitsch@muada.com> Thu, 29 October 2009 09:09 UTC
Return-Path: <iljitsch@muada.com>
X-Original-To: shim6@core3.amsl.com
Delivered-To: shim6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD373A6976; Thu, 29 Oct 2009 02:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIFtV+vyzw4P; Thu, 29 Oct 2009 02:09:36 -0700 (PDT)
Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 02C5F3A686D; Thu, 29 Oct 2009 02:09:35 -0700 (PDT)
Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9T99Blb064742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Oct 2009 10:09:12 +0100 (CET) (envelope-from iljitsch@muada.com)
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset="us-ascii"; format="flowed"; delsp="yes"
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <4AE86373.2060200@strahm.net>
Date: Thu, 29 Oct 2009 10:09:44 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <7B90B3A6-02FC-4F72-ADC6-1DD1A13142CF@muada.com>
References: <p06240806c70a21204f60@10.20.30.158> <C70B34CC.15505%jason_livingood@cable.comcast.com> <147a29c80910260828x5a3289c6q53a8e0ea605c2b3f@mail.gmail.com> <p06240812c70b87043353@10.20.30.158> <147a29c80910280616v525b1af3v75a756c3848fda6b@mail.gmail.com> <4AE86373.2060200@strahm.net>
To: Bill Strahm <bill@strahm.net>
X-Mailer: Apple Mail (2.1076)
Cc: shim6@ietf.org, homegate@ietf.org
Subject: Re: [shim6] [homegate] Routing protocols
X-BeenThere: shim6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SHIM6 Working Group Mailing List <shim6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shim6>
List-Post: <mailto:shim6@ietf.org>
List-Help: <mailto:shim6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Oct 2009 09:09:37 -0000
[cc to shim6 list, prune as required] Shim6ers: there is currently a discussion on the (fairly) new homegate list about whether multiple home gateways would have to run a routing protocol between them. On 28 okt 2009, at 16:29, Bill Strahm wrote: > Please just say no to this extra complexity. Seriously, what > percentage of the market do you expect to have multiple WAN > connections to the internet Well, this is exactly the deployment scenario for Shim6. For Shim6 to work, the hosts must be able to use different addresses from different ISPs. If you have two IPv6 routers that both announce a different prefix, that can work well. There is no need for the two routers to coordinate. There is the issue of what happens when a packet with a source address from ISP A ends up on the router connected to ISP B, but this issue can be solved by the host paying attention to which router it sends which packets to. Having the routers sort this out would be more complex, I don't think simply running a routing protocol solves this. The only way this becomes a show stopper is if there are the two routers connected to ISPs A and B, and then there is a third router connected to the first two, and hosts sit behind the third one. In this case the hosts can't direct packets to the right router, so the routers would have to sort things out. Bottom line: as long as multiple routers can live on a subnet without getting in each other's way, we have 90% of what we need, so let's go for that now and see what more we can do at some later time. > Step 1: Find a nice 80% of your user base use cases > Step 2: Hyper optimize for the majority of the users > Step 3: Simplify Simplify Simplify - only do as much as needed for > the simple cases - and no more > Step 4: Think about advanced features. It's good to optimize for the most common use cases, but it's also important to not break the remaining 20% for fear of pushing towards a monoculture. See what happened in the web browser space.
- Re: [shim6] [homegate] Routing protocols Iljitsch van Beijnum