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

Jeffrey Haas <jhaas@pfrc.org> Wed, 15 March 2017 15:29 UTC

Return-Path: <jhaas@slice.pfrc.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 0B506131678 for <idr@ietfa.amsl.com>; Wed, 15 Mar 2017 08:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 VjMzxmixyDOi for <idr@ietfa.amsl.com>; Wed, 15 Mar 2017 08:29:22 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9D98313167A for <idr@ietf.org>; Wed, 15 Mar 2017 08:29:22 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 4FBC61E33B; Wed, 15 Mar 2017 11:35:34 -0400 (EDT)
Date: Wed, 15 Mar 2017 11:35:34 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Nick Hilliard <nick@foobar.org>
Cc: IETF IDR Working Group <idr@ietf.org>
Message-ID: <20170315153534.GR12864@pfrc.org>
References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <58C85ECE.3080109@foobar.org> <20170314214817.GI12864@pfrc.org> <58C955CA.7040405@foobar.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <58C955CA.7040405@foobar.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/z-BLMOkGPX3IZ5Zvh_2xpcKHS8k>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 15 Mar 2017 15:29:24 -0000

On Wed, Mar 15, 2017 at 02:55:06PM +0000, Nick Hilliard wrote:
> Jeffrey Haas wrote:
> > We had some text in earlier internal versions of the document that tried to
> > make this explicit.  I believe the text that remains is appropriately
> > permissive but maybe not as explicit as you might like:
> 
> it's definitely permissive, but sometimes it's good to make things easy
> for the reader.  FWIW, I think you're having some reverse bikeshedding
> here, and part of the reason is a lack of broad brush strokes to make it
> easy for the casual reader to follow what's going on in the heads of the
> authors.

This is more the issue of three different authors wordsmithing the document
with different styles.  This round had enough bits rewritten that the focus
was on correctness rather than ease of reading.  Next round will hopefully
address that presuming the technical content is accepted.

> Again, to make it easier for the reader, I'd suggest adding in some
> helicopter-view text to explain the rationale behind this feedback
> mechanism.  It's quite a nice way of handling bfd session stability,
> btw, but it really is not obvious from a first (or even second) reading
> what the overall picture is.

Agreed.

> >> lolno, if I'm reading this correctly.  It's quite usual to have
> >> bilateral + multilateral sessions configuration between router pairs.
> > 
> > I suspected the sanity check might bounce here. :-)
> 
> "This text was included intentionally to see if people were paying
> attention".

:-)

> > We'll update the wording accordingly.  The main consideration is the new
> > SAFI doesn't get negotiated and start transitively propagating the state.
> 
> Right, I hadn't considered that.  That would cause a pile of hilarity,
> no doubt about it.

Exactly.  This state, for want of better terminology, is session local.
However, most implementations of BGP use generic RIB plumbing that makes
redistribution a likely accident.

> > It might be worth adding verbiage about ensuring RS-Reachable SAFI have an
> > AS_PATH that is consistent with directly connected peers instead.
> 
> ew, ugly hack. Please don't.

Why not? It's the closest thing we have to "only accept stuff from the
adjacent peer".  We don't currently have a "verify that no-advertise did its
job" feature.

-- Jeff