Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt

Nick Hilliard <nick@foobar.org> Tue, 14 March 2017 12:56 UTC

Return-Path: <nick@foobar.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C551294E4 for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 05:56:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nldhUZl-oVgj for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 05:56:04 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8FA12706D for <idr@ietf.org>; Tue, 14 Mar 2017 05:56:04 -0700 (PDT)
X-Envelope-To: idr@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2ECu10k087154 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Mar 2017 12:56:01 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
Message-ID: <58C7E860.3010403@foobar.org>
Date: Tue, 14 Mar 2017 12:56:00 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.11 (Macintosh/20170302)
MIME-Version: 1.0
To: Robert Raszuk <robert@raszuk.net>
References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <m2k27tzs5k.wl-randy@psg.com> <CA+b+ERmmqtUkJMtfOE9ABFHN0gNdztjOGELmirNgWRnDENrjaA@mail.gmail.com> <m2zigpxu7o.wl-randy@psg.com> <CA+b+ER=MaOqOr0A9VZ3TfgbSWgjk3eGwLKmnfr=byvOs11Ppfg@mail.gmail.com> <m2o9x4whh2.wl-randy@psg.com> <CA+b+ERnTJ4TJtgp=Jnn7k08j4dPibhB4gC69WWyQ4wDbxxr5zA@mail.gmail.com> <m260jcw5gg.wl-randy@psg.com> <CA+b+ERn5XT=SFCj+tTegASRq9PTEONH3kkpvkvRsQ3mX4_cYCQ@mail.gmail.com> <58C7D45E.80704@foobar.org> <CA+b+ERnFFEi=cbNN7s0cnmE3vxm-hZ8jzXq1sUGYaWxL2efpuA@mail.gmail.com>
In-Reply-To: <CA+b+ERnFFEi=cbNN7s0cnmE3vxm-hZ8jzXq1sUGYaWxL2efpuA@mail.gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0EUkF1rip51eOBXxiGVKwtj3ue4>
Cc: Interminable Discussion Room <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2017 12:56:06 -0000

Robert,

your proposal is not even wrong.

Nick

Robert Raszuk wrote:
> If someone is using weak BGP stacks which can not handle two BGP paths
> per net .. sorry that to me does not justify inventing new SAFI. 
> 
> Moreover the idea behind the new SAFI is flawed since it assumes RS
> always would have a secondary path to send to client. Otherwise noise of
> 1000 peers bombarding RS with message "NH-X is not reachable" is pretty
> useless if given net has only one NH on the RS. 
> 
> Moreover those weak clients which can not run best path for RS received
> nets are now subject to handle 1000 BFD sessions ... it really does not
> sound right that an edge can do the latter just fine and not the former. 
> 
> Last to address real world problem - I proposed very easy solution which
> you as an IXP operator can enable today via simple config on your switch
> and treat such switch (or pair of switches) as default forwarder. Done !
> Fully backward compatible with existing IXP deployment too.