Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt (Niels Bakker) Tue, 14 March 2017 14:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1868D12025C for <>; Tue, 14 Mar 2017 07:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4gKgW98xHb4B for <>; Tue, 14 Mar 2017 07:43:33 -0700 (PDT)
Received: from ( [IPv6:2001:888:1037:1337::53:53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 272C312025D for <>; Tue, 14 Mar 2017 07:43:33 -0700 (PDT)
Received: by (Postfix, from userid 910) id 14A4D14A1; Tue, 14 Mar 2017 15:43:31 +0100 (CET)
Date: Tue, 14 Mar 2017 15:43:30 +0100
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Mar 2017 14:43:35 -0000

* (Robert Raszuk) [Tue 14 Mar 2017, 11:05 CET]:
>Learning two paths for given net with different NHs (even if RS has more
>then two) seems to provide sufficient robustness and enables you to measure
>quality to the destinations as well as do things line multipath TCP

This would require a major rearchitecting of pretty much all network 
components out there because we'd be doing away with the concept of 
having one best path that's chosen by each hop handling a packet.

>Now if someone is really so weak on the edge and attaches to IX to only
>peer locally we should perhaps invent co-located with RS pair of data plane
>boxes where such weak guys would for forwarding just default to such data
>plane gateway. That way those two forwarders could have as many paths as RS
>feeds it with yet all weak clients are happy to forward and reach all open
>peers of a given IX.
>In fact most IX switches while running in L2 mode could be configured for
>L3 as well so no need to even invest new $$$ needed.

As Nick said, not even wrong.

Route servers decouple the forwarding plane from the control plane 
in an additional way beyond what already happens inside routers for 
hardware design reasons.  This draft seeks to add a mechanism 
to signal any dislocations, improving robustness of existing 


	-- Niels (former IXP operator, current IXP participant hat)