From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from chi.subsignal.org (cxd-2-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:ed::2]) by huchra.bufferbloat.net (Postfix) with ESMTP id D0E3421F1A8 for ; Wed, 8 May 2013 05:54:30 -0700 (PDT) Received: from [192.168.178.21] (unknown [212.255.44.191]) by chi.subsignal.org (Postfix) with ESMTPSA id B326C126109; Wed, 8 May 2013 14:55:53 +0200 (CEST) Message-ID: <518A4B04.4030702@openwrt.org> Date: Wed, 08 May 2013 14:54:28 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130112 Icedove/17.0.2 MIME-Version: 1.0 To: Ole Troan Subject: Re: [homenet] Source-specific routes in Linux [was: atomic updates...] References: <87vc6vgghx.wl%jch@pps.univ-paris-diderot.fr> <8F7177E4-6212-4A74-8A7C-A2D1703A59BF@iki.fi> <87sj1zgfot.wl%jch@pps.univ-paris-diderot.fr> <518A1F51.809@openwrt.org> <3c2ea3e2-a587-4cf6-820b-929e6d75a9ad@email.android.com> <4731AFEA-6D92-4201-BEA5-46B535C84657@employees.org> In-Reply-To: <4731AFEA-6D92-4201-BEA5-46B535C84657@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 09 May 2013 02:16:43 -0700 Cc: bloat-devel , Juliusz Chroboczek , Markus Stenberg , boutier@pps.univ-paris-diderot.fr, homenet@ietf.org X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 12:54:31 -0000 On 08.05.2013 12:58, Ole Troan wrote: > at least we're on the same track (and I think the correct one). ;-) > > on the border router this is quite simple. if a border router uses PD and it discovers a default router on the same interface, > that will result in a SADR route (S, D) -> interface, next-hop. where S is PD prefix, D is ::/0, interface is the interface the PD was received > on and next-hop is whatever router discovery came back with. > > the issue is with internal routers, where you may have an internal router connected to two exits on the same link, or behind another > IR that is connected to both..., i.e. arbitrary topology. OK, thanks again for the explanation. I think I will add an additional routing-table-ID parameter to the network daemon. This way any routing daemon that is going to be properly integrated into OpenWrt can select a target table for each route, prefix, etc. Cheers, Steven