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.